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=video
, acpi_backlight=vendor
, acpi_backlight=native
and 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
acpi_video0
andintel_backlight
are available, and adjusting brightness with GNOME controls affects the value inbrightness
in both directories. - Tails 3.2~rc1
- During early boot the brighness is now set to a pretty low
level. Both
acpi_video0
andintel_backlight
are 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 toacpi_video0/brightness
does change the brightness, and also incidentally updates the value inintel_backlight/brightness
. Same withacpi_backlight=video
. - If I pass one of
acpi_backlight=vendor
,acpi_backlight=native
oracpi_backlight=none
, then onlyintel_backlight
is available, the initial brightness is much higher, echo’ing tointel_backlight/brightess
works, 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.
Background info:
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.
Related issues
- Related to #12213
- Related to #14623
- Blocks #13234 (closed)
Original created by @intrigeri on 14712 (Redmine)