Tails

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 and intel_backlight are available, and adjusting brightness with GNOME controls affects the value in brightness in both directories.
• Tails 3.2~rc1
  • During early boot the brighness is now set to a pretty low level. Both acpi_video0 and intel_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 to acpi_video0/brightness does change the brightness, and also incidentally updates the value in intel_backlight/brightness. Same with acpi_backlight=video.
  • If I pass one of acpi_backlight=vendor, acpi_backlight=native or acpi_backlight=none, then only intel_backlight is available, the initial brightness is much higher, echo’ing to intel_backlight/brightess works, but the controls in GNOME still don’t work.
• 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:

• https://wiki.archlinux.org/index.php/backlight
• https://wiki.ubuntu.com/Kernel/Debugging/Backlight

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.