Comment 149 for bug 1098216

Revision history for this message
In , seth (seth-linux-kernel-bugs) wrote :

(In reply to comment #21)
> I see that _BCM and _BQC only work with the 16 step table
> (\_SB.PCI0.LPC.EC.BRTW).
> When interacting with the backlight through sysfs, brightness node can be set
> to any value from _BCL, but actual_brightness reports its current value from
> _BQC. This causes a discrepancy between brightness and actual_brightness
> where
> brightness could be 75 but actual_brightness remains at 70.

Yes, since _BCM only discards the value and doesn't return an error, acpi_video thinks the brightness change was successful and thus updates the cached brightness value. actual_brightness shows that the firmware discarded the value.

> Gnome uses RandR to change backlight, which reports actual_brightness when
> available. When Gnome tries to change brightness in reaction to media keys,
> it
> tries to do so in 5% increments based on actual_brightness. Now, since 75% is
> not supported in the BRTW table, stepping up from 70% would never succeed and
> so Gnome's brightness OSD gets stuck at 75% and cannot go any higher. Same
> thing happens when trying to step down from 20%.
>
> I have created a test kernel by commenting out the get_brightness entry in
> acpi_backlight_ops. RandR seems to fallback to the brightness node and
> everything works fine in Gnome.

We shouldn't expose the backlight to userspace if it isn't going to work properly. So the possible solutions I can think of are quirking to use "!Windows 2012" by default, quirking to disable acpi_video backlight, or quirking somehow to make acpi_video only use the values that actually work.

> Brightness adjustment with media keys in virtual terminals still has no
> effect.
> But I have no idea how the brightness keys are handled in VT so I can't
> comment
> on that.

This depends to some degree on how the firmware behaves. Most of the time a keycode is emitted when you press the brightness keys which userspace needs to respond to. When you're in a VT there's probably no software responding to the brightness keycodes, thus no change in brightness.