Bug #14712

Display backlight brightness regressions in 3.2~rc1

Added by intrigeri 2017-09-24 08:18:19 . Updated 2017-09-28 18:50:17 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
Category:
Hardware support
Target version:
Start date:
2017-09-24
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

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:

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.


Subtasks


Related issues

Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 2017-09-02
Related to Tails - Bug #14623: Tor Browser sandbox breakout via X11 testing extensions Confirmed 2017-09-12
Blocks Tails - Feature #13234: Core work 2017Q3: Foundations Team Resolved 2017-06-29

History

#1 Updated by intrigeri 2017-09-24 08:19:54

#2 Updated by intrigeri 2017-09-24 08:22:07

#3 Updated by intrigeri 2017-09-24 08:22:12

  • related to Bug #14623: Tor Browser sandbox breakout via X11 testing extensions added

#4 Updated by intrigeri 2017-09-24 08:27:31

As said in the description, on my test machine things work fine again with current testing branch. A quick look at the gnome-settings-daemon code suggests that XTEST is used by the power manager plugin, that exits if XTEST is not supported, and that is involved in controlling backlight brightness. So I think that was just another instance of “disabling XTEST on X.Org breaks tons of stuff”.

I’ll ask confirmation to those who reported this bug (and the lack of notification on low battery, that seems to share the same root cause).

#5 Updated by intrigeri 2017-09-24 08:39:58

intrigeri wrote:
> I’ll ask confirmation to those who reported this bug (and the lack of notification on low battery, that seems to share the same root cause).

Done.

#6 Updated by intrigeri 2017-09-24 08:44:48

Dear anonym, I’m really sorry about the XTEST mess: I had used codesearch.debian.net to build a (huge) list of packages that seemed to use XTEST, and my plan was to look closer at those we ship and heavily rely on. And then somehow (probably I’ve rebooted and lost my scratch buffer) I’ve lost track of this work. I should have added a note to the ticket about it.

#7 Updated by anonym 2017-09-24 09:34:23

intrigeri wrote:
> Dear anonym, I’m really sorry about the XTEST mess: I had used codesearch.debian.net to build a (huge) list of packages that seemed to use XTEST, and my plan was to look closer at those we ship and heavily rely on. And then somehow (probably I’ve rebooted and lost my scratch buffer) I’ve lost track of this work. I should have added a note to the ticket about it.

No worries! I’m just glad we’re at a place we’re we can try somewhat crazy/unusual things like this during release candidates and get reports from our users that help us see that it wasn’t a good idea. :)

#8 Updated by intrigeri 2017-09-25 05:39:50

  • Status changed from In Progress to Fix committed
  • % Done changed from 10 to 100

I’ve received a confirmation that this is fixed in current testing :)

#9 Updated by emmapeel 2017-09-25 07:38:45

I tested the tails-amd64-testing-3.2-20170923T1532Z-2593cffc71 ISO with a Thinkpad x220 and I still have a dark start, although my keyboard shortcuts with Fn and ‘sun up, sun down’ work as it worked in 3.2~rc1

#10 Updated by intrigeri 2017-09-25 07:47:46

> I tested the tails-amd64-testing-3.2-20170923T1532Z-2593cffc71 ISO with a Thinkpad x220 and I still have a dark start :S

I’ve asked clarification on XMPP as it’s unclear to me where the starts begins and ends.

#11 Updated by anonym 2017-09-28 18:50:17

  • Status changed from Fix committed to Resolved