Display backlight brightness regressions in 3.2~rc1
Some users report worse default backlight brightness settings at boot
and/or inability to control the backlight brightness, both being
regressions vs. Tails 3.1. Presumably this is caused by the kernel
update (4.9 → 4.12). On many systems there are multiple possible ways in
which backlight can be controlled, and apparently sometimes the wrong
one is now picked. The usual trick to fix such issues is to pass one of
acpi_backlight=none; that generally works and could be documented
on our Known Issues page, but it’s impractical when using a Live system,
so let’s try to find something else.
E.g. on a MacBook Pro 8,1 13-inch:
- Tails 3.1: brightness is OK at boot, GNOME controls work. Both
intel_backlightare available, and adjusting brightness with GNOME controls affects the value in
brightnessin both directories.
- Tails 3.2~rc1
- During early boot the brighness is now set to a pretty low
intel_backlightare available in
/sys/class/backlight/. In GNOME, pressing the brightness control keys has no effect (not even the OSD feedback), which suggests that GNOME does not know what it should control. echo’ing to
acpi_video0/brightnessdoes change the brightness, and also incidentally updates the value in
intel_backlight/brightness. Same with
- If I pass one of
acpi_backlight=none, then only
intel_backlightis available, the initial brightness is much higher, echo’ing to
intel_backlight/brightessworks, but the controls in GNOME still don’t work.
- During early boot the brighness is now set to a pretty low level. Both
- current testing branch (somewhere between 3.2~rc1 and upcoming 3.2): everything works fine like on 3.1
systemd-backlight(8) says that when restoring the levels saved to disk during previous shutdown, “brightness is clamped to a value of at least 1 or 5% of maximum brightness, whichever is greater. This restriction will be removed when the kernel allows user space to reliably set a brightness value which does not turn off the display”. Doing this to ensure that the initial brightness is sane probably makes sense on a non-live system, where the same systemd service will save backlight brightness to disk at shutdown, and restore it at boot.
Let’s keep in mind that whatever change caused these regressions might also have improved things for other hardware without us hearing about it: hardware support improvements are reported much less often than regressions. So “just revert the change no matter why it was applied” might not be the best answer.