acpi 'video' driver, and issues with 'brightness_switch_enabled=0'
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
So what you can suggest here?
Regards,
Maxim Levitsky
Quoted 3 lines · Maxim Levitsky
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
if you boot into console mode w/o ACPI video driver, does the brightness still change when you press the hotkeys?
Quoted 4 lines
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
we need to support the brightness control in console mode. and "brightness_switch_enabled" should be cleared in graphics mode to prevent the ACPI video driver action upon hotkey events.
Quoted 11 lines
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
No, when "brightness_switch_enabled" is cleared, gdm should still use the ACPI backlight sysfs I/F if available to change the backlight, i.e. /sys/class/backlight/acpi_video0/...
what's the model name of your laptop?
are you using Intel graphics?
please attach the output of acpidump and lspci.
It would be great if you can file a bug report about this issue at bugzilla.kernel.org.
thanks,
rui
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Zhang Rui
Quoted 3 lines · Maxim Levitsky
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
if you boot into console mode w/o ACPI video driver, does the brightness still change when you press the hotkeys?
They always work.
For s while, due to buggy ACPI table, acpi 'video' driver won't work, so I blacklisted it, and yet hw keys did work.
Quoted 8 lines
Quoted 5 lines
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
we need to support the brightness control in console mode. and "brightness_switch_enabled" should be cleared in graphics mode to prevent the ACPI video driver action upon hotkey events.
How gnome power manager can do that, use /sys/module iface?
Quoted 7 lines
Quoted 7 lines
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
Quoted 8 lines
Quoted 5 lines
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
No, when "brightness_switch_enabled" is cleared, gdm should still use the ACPI backlight sysfs I/F if available to change the backlight, i.e.
/sys/class/backlight/acpi_video0/...
Indeed it does, but I don't like it, hardware already changed the brightness, but it receives another two events about brightness up/down.
It (and I too) can change the brightness, but it doesn't update to reflect current brightness (/sys/class/backlight/acpi_video0/brightness) shows cached value from last time it was set.
there is also the actual_brightness, but I think it isn't used by gpm.
Quoted 2 lines
what's the model name of your laptop?
acer aspire 5720G
Quoted 1 line
are you using Intel graphics?
no, nvidia 8400GS
Quoted 4 lines
please attach the output of acpidump and lspci.
It would be great if you can file a bug report about this issue at bugzilla.kernel.org.
No problem.
Quoted 3 lines
thanks,
rui
Thanks too,
Best regards,
Maxim Levitsky
Quoted 11 lines · Maxim Levitsky
Quoted 6 lines · Zhang Rui
Quoted 3 lines · Maxim Levitsky
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
if you boot into console mode w/o ACPI video driver, does the brightness still change when you press the hotkeys?
They always work.
For s while, due to buggy ACPI table, acpi 'video' driver won't work, so I blacklisted it, and yet hw keys did work.
so if you kill acpid, and run "cat /proc/acpi/event", there are some ACPI video events popping up when you press the hotkeys, right?
this is bad, because these events are "Used to notify OSPM that the output device brightness should be increased/decreased by one level. Used to notify OSPM that the user pressed a button or key that is associated with cycling brightness." according to the ACPI spec. So, if BIOS changes the brightness for OS, it should not issue an event any more.
Quoted 22 lines
Quoted 8 lines
Quoted 5 lines
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
we need to support the brightness control in console mode. and "brightness_switch_enabled" should be cleared in graphics mode to prevent the ACPI video driver action upon hotkey events.
How gnome power manager can do that, use
/sys/moduleiface?Quoted 12 lines
Quoted 12 lines
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
Quoted 6 lines
Quoted 3 lines
No, when "brightness_switch_enabled" is cleared, gdm should still use the ACPI backlight sysfs I/F if available to change the backlight, i.e.
/sys/class/backlight/acpi_video0/...Indeed it does, but I don't like it, hardware already changed the brightness, but it receives another two events about brightness up/down.
well, this is rather a hardware problem to me.
Because OS should change the brightness upon such a notification, either in ACPI video driver, or in user space.
IMO, if BIOS doesn't want OS to change the backlight, it should not issue such events at all.
Quoted 7 lines
It (and I too) can change the brightness, but it doesn't update to reflect current brightness (
/sys/class/backlight/acpi_video0/brightness) shows cached value from last time it was set.there is also the
actual_brightness, but I think it isn't used by gpm.
/sys/class/backlight/acpi_video0/brightness doesn't reflect the actual brightness level, gdm should use actual_brightness instead.
But if gdm uses the sysfs backlight I/F, the value of these two files should be the same.
can you do this test please?
1. attach the output of "grep . /sys/class/backlight/acpi_video0/*"
2. press the hotkey
3. redo step 1.
Quoted 4 lines
Quoted 3 lines
what's the model name of your laptop?
acer aspire 5720G
hah, I know this laptop.
Quoted 8 lines
Quoted 1 line
are you using Intel graphics?
no, nvidia 8400GS
Quoted 4 lines
please attach the output of acpidump and lspci.
It would be great if you can file a bug report about this issue at bugzilla.kernel.org.
No problem.
And I know you're good at reporting bugs. :p
why not move this discussion to the bugzilla so that I can better track this bug?
thanks,
rui
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 87 lines · Zhang Rui
Quoted 11 lines · Maxim Levitsky
Quoted 6 lines · Zhang Rui
Quoted 3 lines · Maxim Levitsky
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
if you boot into console mode w/o ACPI video driver, does the brightness still change when you press the hotkeys?
They always work.
For s while, due to buggy ACPI table, acpi 'video' driver won't work, so I blacklisted it, and yet hw keys did work.so if you kill acpid, and run "cat
/proc/acpi/event", there are some ACPI video events popping up when you press the hotkeys, right?this is bad, because these events are "Used to notify OSPM that the output device brightness should be increased/decreased by one level. Used to notify OSPM that the user pressed a button or key that is associated with cycling brightness." according to the ACPI spec. So, if BIOS changes the brightness for OS, it should not issue an event any more.
Quoted 22 lines
Quoted 8 lines
Quoted 5 lines
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
we need to support the brightness control in console mode. and "brightness_switch_enabled" should be cleared in graphics mode to prevent the ACPI video driver action upon hotkey events.
How gnome power manager can do that, use
/sys/moduleiface?Quoted 12 lines
Quoted 12 lines
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
Quoted 6 lines
Quoted 3 lines
No, when "brightness_switch_enabled" is cleared, gdm should still use the ACPI backlight sysfs I/F if available to change the backlight, i.e.
/sys/class/backlight/acpi_video0/...Indeed it does, but I don't like it, hardware already changed the brightness, but it receives another two events about brightness up/down.
well, this is rather a hardware problem to me.
Because OS should change the brightness upon such a notification, either in ACPI video driver, or in user space.
IMO, if BIOS doesn't want OS to change the backlight, it should not issue such events at all.Quoted 7 lines
It (and I too) can change the brightness, but it doesn't update to reflect current brightness (
/sys/class/backlight/acpi_video0/brightness) shows cached value from last time it was set.there is also the
actual_brightness, but I think it isn't used by gpm./sys/class/backlight/acpi_video0/brightness doesn't reflect the actual brightness level, gdm should use
actual_brightnessinstead.But if gdm uses the sysfs backlight I/F, the value of these two files should be the same.
can you do this test please?
1. attach the output of "grep ./sys/class/backlight/acpi_video0/*"
2. press the hotkey
3. redo step 1.Quoted 4 lines
Quoted 3 lines
what's the model name of your laptop?
acer aspire 5720G
hah, I know this laptop.
Quoted 7 lines
Quoted 1 line
are you using Intel graphics?
no, nvidia 8400GS
Quoted 4 lines
please attach the output of acpidump and lspci.
It would be great if you can file a bug report about this issue at bugzilla.kernel.org.
Quoted 10 lines
Quoted 1 line
No problem.
And I know you're good at reporting bugs. :p
why not move this discussion to the bugzilla so that I can better track this bug?
thanks,
rui
I''ll check this.
Best regards,
Maxim Levitsky
Quoted 6 lines · Zhang Rui
Quoted 5 lines · Maxim Levitsky
Quoted 4 lines · Zhang Rui
Quoted 3 lines · Maxim Levitsky
I have a notebook which handles brightness keys in hardware, but tells loudly when it does so.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
if you boot into console mode w/o ACPI video driver, does the brightness still change when you press the hotkeys?
They always work.
For s while, due to buggy ACPI table, acpi 'video' driver won't work, so I blacklisted it, and yet hw keys did work.so if you kill acpid, and run "cat
/proc/acpi/event", there are some ACPI video events popping up when you press the hotkeys, right?
If 'video' acpi driver is loader, otherwise no events
Quoted 48 lines
this is bad, because these events are "Used to notify OSPM that the output device brightness should be increased/decreased by one level. Used to notify OSPM that the user pressed a button or key that is associated with cycling brightness." according to the ACPI spec. So, if BIOS changes the brightness for OS, it should not issue an event any more.
Quoted 22 lines
Quoted 8 lines
Quoted 5 lines
Currently, acpi 'video' also sets the brightness, which result in double setting, and on top of that it emits a key that makes gpm set brightness again.
we need to support the brightness control in console mode. and "brightness_switch_enabled" should be cleared in graphics mode to prevent the ACPI video driver action upon hotkey events.
How gnome power manager can do that, use
/sys/moduleiface?Quoted 12 lines
Quoted 12 lines
And (yes...) on top of that keyboard emits a brightness up/down even, which (you guessed...) sets brightness again.
I found out that it is possible to tell gnome-power-manager not to set brightness, but yet in kernel driver still sets it.
I found out even earlier that I can use brightness_switch_enabled=0, which supposed to make inkernel driver not touch the brightness. But I found out that this driver won't update the brightness, in /sys interface when I set this param.
Quoted 6 lines
Quoted 3 lines
No, when "brightness_switch_enabled" is cleared, gdm should still use the ACPI backlight sysfs I/F if available to change the backlight, i.e.
/sys/class/backlight/acpi_video0/...Indeed it does, but I don't like it, hardware already changed the brightness, but it receives another two events about brightness up/down.
well, this is rather a hardware problem to me.
Because OS should change the brightness upon such a notification, either in ACPI video driver, or in user space.
IMO, if BIOS doesn't want OS to change the backlight, it should not issue such events at all.Quoted 5 lines
It (and I too) can change the brightness, but it doesn't update to reflect current brightness (
/sys/class/backlight/acpi_video0/brightness) shows cached value from last time it was set.
Quoted 7 lines
Quoted 2 lines
there is also the
actual_brightness, but I think it isn't used by gpm./sys/class/backlight/acpi_video0/brightness doesn't reflect the actual brightness level, gdm should use
actual_brightnessinstead.But if gdm uses the sysfs backlight I/F, the value of these two files should be the same.
If it sets the brightness that is. /sys/class/backlight/acpi_video0/brightness reflects last value written to it.
Quoted 5 lines
can you do this test please?
1. attach the output of "grep ./sys/class/backlight/acpi_video0/*"
2. press the hotkey
3. redo step 1.
maxim@maxim-laptop:~$ grep . /sys/class/backlight/acpi_video0/* /sys/class/backlight/acpi_video0/actual_brightness:3 /sys/class/backlight/acpi_video0/bl_power:0 /sys/class/backlight/acpi_video0/brightness:7 /sys/class/backlight/acpi_video0/max_brightness:9 maxim@maxim-laptop:~$ grep . /sys/class/backlight/acpi_video0/* /sys/class/backlight/acpi_video0/actual_brightness:2 /sys/class/backlight/acpi_video0/bl_power:0 /sys/class/backlight/acpi_video0/brightness:7 /sys/class/backlight/acpi_video0/max_brightness:9 maxim@maxim-laptop:~$
Note the above with brightness_switch_enabled=0, and with hal laptop_panel.brightness_in_hardware=true
Which makes it ignore key-presses.
And thus everyting almost work, but OSD of gpm doesn't reflect the current brightness (it uses /sys/class/backlight/acpi_video0/brightness it seems)
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
what's the model name of your laptop?
acer aspire 5720G
hah, I know this laptop.
Quoted 1 line
Quoted 1 line
are you using Intel graphics?
Quoted 8 lines
Quoted 7 lines
no, nvidia 8400GS
Quoted 4 lines
please attach the output of acpidump and lspci.
It would be great if you can file a bug report about this issue at bugzilla.kernel.org.
No problem.
And I know you're good at reporting bugs. :p
And like to make linux better in any way I can
Quoted 3 lines
why not move this discussion to the bugzilla so that I can better track this bug?
done: http://bugzilla.kernel.org/show_bug.cgi?id=13210
Quoted 5 lines
thanks,
rui
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html