Comment 206 for bug 1098216

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

(In reply to comment #79)
> (In reply to comment #77)
> > Unfortunately, just setting acpi_backlight=vendor has too many side effects
> to
> > completely solve the problem:
> > 1. It causes _BCL not to be called, so the firmware won't generate ACPI
> events
> > for the keypresses. Instead, the firmware will handle them entirely
> internally,
> > changing the brightness. (See [1])
>
> Is it possible for thinkpad-acpi module to control this behaviour? I mean, on
> hotkey press, do not handle backlight internally, just send out event.

I see a call to _BCL in thinkpad_acpi, but it doesn't seem to be getting called for some reason when acpi_backlight=vendor. That's the only way to disable the firmware handling the backlight internally.

> > 2. thinkpad_acpi will not mask the brightness keys, so we get hotkey events
> > through that, in addition to the firmware's internal brightness changes.
>
> I don't see anywhere backlight gets changed internally. Is it done by some
> HKEY
> function?

It's in \_SB.PCI0.LPC.EC._Q14 and _Q15 on my T530 firmware.

> > 3. thinkpad_acpi creates its "thinkpad_screen" sysfs device, which
> userspace
> > prefers to the intel_backlight device that we want to be using.
>
> Does that interface work or not?

It doesn't appear to, for either reading or writing. I booted an unmodified kernel with acpi_backlight=vendor. thinkpad_screen/actual_brightness always returns 0. You can write any value to thinkpad_screen/brightness and it will save it and return it, but it has no effect.

The brightness keys do work through the firmware, but the actual brightness has no effect on the values thinkpad_screen returns. By default, the hotkeys are unmasked, so I get a useless on-screen-display of brightness failing to change. Masking the hotkeys takes both kernel and userspace out of the picture, so there's no OSD.