RFC: changing acpi-video brightness_switch_enabled default to 0
Hi All,
I was already considering asking for $subject for a while, but I did not see any bug reports caused by it so I didn't ask. Until today I discovered that I'm not seeing any bugs because Fedora is carrying a kernel patch changing the default.
A quick google search for brightness_switch_enabled OTOH reveals that for other distros it is a serious problem, see ie:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/527157
http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-steps
The problem is that acpi-video is unique in that it not only generates brightness up/down keypresses, but also (sometimes) actively changes the brightness itself.
This presents an inconsistent kernel interface to userspace, basically there are 2 different scenarios, depending on the laptop model:
1) On some laptops a brightness up/down keypress means: show a brightness osd with the current brightness, iow it is a brightness has changed notification.
2) Where as on (a lot of) other laptops it means a brightness up/down key was pressed, deal with it.
Most of the desktop environments interpret any press as in scenario 2, and change the brightness up / down as a response to the key events, causing it to be changed twice, once by acpi-video and once by the DE.
With the new default for video.use_native_backlight we will be moving even more laptops over to behaving as in scenario 2. Making the remaining laptops even more of a weird exception. Also note that it is hard to detect scenario 1 properly in userspace, and AFAIK none of the DE-s deasls with it.
Therefor I would like to propose to change the brightness_switch_enabled default to 0.
Regards,
Hans
Quoted 29 lines · Hans de Goede
Hi All,
I was already considering asking for $subject for a while, but I did not see any bug reports caused by it so I didn't ask. Until today I discovered that I'm not seeing any bugs because Fedora is carrying a kernel patch changing the default.
A quick google search for
brightness_switch_enabledOTOH reveals that for other distros it is a serious problem, see ie:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/527157
http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-stepsThe problem is that acpi-video is unique in that it not only generates brightness up/down keypresses, but also (sometimes) actively changes the brightness itself.
This presents an inconsistent kernel interface to userspace, basically there are 2 different scenarios, depending on the laptop model:
1) On some laptops a brightness up/down keypress means: show a brightness osd with the current brightness, iow it is a brightness has changed notification.
2) Where as on (a lot of) other laptops it means a brightness up/down key was pressed, deal with it.
Most of the desktop environments interpret any press as in scenario 2, and change the brightness up / down as a response to the key events, causing it to be changed twice, once by acpi-video and once by the DE.
Quoted 7 lines
With the new default for video.use_native_backlight we will be moving even more laptops over to behaving as in scenario 2. Making the remaining laptops even more of a weird exception. Also note that it is hard to detect scenario 1 properly in userspace, and AFAIK none of the DE-s deasls with it.
Therefor I would like to propose to change the
brightness_switch_enableddefault to 0.
Aaron, what do you think about that?
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
Quoted 35 lines · Rafael J. Wysocki
Quoted 34 lines · Hans de Goede
Hi All,
I was already considering asking for $subject for a while, but I did not see any bug reports caused by it so I didn't ask. Until today I discovered that I'm not seeing any bugs because Fedora is carrying a kernel patch changing the default.
A quick google search for
brightness_switch_enabledOTOH reveals that for other distros it is a serious problem, see ie:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/527157
http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-stepsThe problem is that acpi-video is unique in that it not only generates brightness up/down keypresses, but also (sometimes) actively changes the brightness itself.
This presents an inconsistent kernel interface to userspace, basically there are 2 different scenarios, depending on the laptop model:
1) On some laptops a brightness up/down keypress means: show a brightness osd with the current brightness, iow it is a brightness has changed notification.
2) Where as on (a lot of) other laptops it means a brightness up/down key was pressed, deal with it.
Most of the desktop environments interpret any press as in scenario 2, and change the brightness up / down as a response to the key events, causing it to be changed twice, once by acpi-video and once by the DE.
With the new default for video.use_native_backlight we will be moving even more laptops over to behaving as in scenario 2. Making the remaining laptops even more of a weird exception. Also note that it is hard to detect scenario 1 properly in userspace, and AFAIK none of the DE-s deasls with it.
Quoted 4 lines
Quoted 2 lines
Therefor I would like to propose to change the
brightness_switch_enableddefault to 0.Aaron, what do you think about that?
Personally, I like this.
Last time I remembered, people who do not use GUI or use a simple GUI which does not provide handling of backlight events prefer to having this param default to 1(and they have a working acpi_video interface of course). But I suppose most people are using a GUI that handles such events and the in kernel handling of backlight events is indeed unique for acpi_video and cause in consistence with other backlight control interfaces, I think it is a good thing to set brightness_switch_enabled to 0 by default.
Thanks,
Aaron