[ltp] Re: Thinkpad keyboard backlight ACPI interface

[Pali Rohár]

On Friday 14 August 2015 13:33:21 Fabio D'Urso wrote:
> On Friday, August 14, 2015 09:26:12 AM you wrote:
> [...]
> > > Hi, I have news from the I-have-the-backlight side:
> > > 
> > > If you set the 0x20000 bit in /proc/acpi/ibm/hotkey, you'll get a 0x1012
> > > hotkey notification when the backlight brightness changes.
> > > 
> > > xev shows such events as XF86KbdLightOnOff key.
> > 
> > Is this event received via i8042 AT keyboard or via ACPI/WMI?
> 
> ACPI, it is received by thickpad_acpi's hotkey_notify function. So I guess it 
> should be easy to steal it if you want to.
> 

Ok, hooking in thinkpad_acpi.c is possible and should be easy...

> > > This notification happens when you press Fn+SPACE, but also when you call
> > > MLCS. Even with this bit set, the hardware still takes care of cycling the
> > > brightness levels on its own.
> > 
> > On linux-input was discussion and conclusion was that kernel should not
> > report key press to userspace if that key press has some side efect in
> > hardware/firmware/bios. E.g that pressing key automatically change
> > keyboard backlight or hard block wifi rfkill.
> > 
> > Reason was that userspace can handle these special keys (key for
> > keyboard backlight change, key for wifi button, ...) and then can send
> > some command to linux kernel to do some action. But because userspace
> > does not know if firmware/bios already handled that action, there can be
> > cyclic problem: user pressed brightness key, bios changed brightness,
> > userspace detected brightness key, userspace sent command chane
> > brightness, command in bios generated brightness key, ...
> 
> I see your point.
> 
> > So I'm strictly against enabling that mask for Fn+Space key. But finding
> > other way how to deliver that event to userspace is OK. Months ago I
> > proposed some solution that leds class drivers (which are used for
> > keyboard backlight control) could have knotify or sysfs notify method so
> > poll syscall on "brightness" sysfs entry could be interrupted when level
> > was changed. And for this kernel driver (maybe with enabled mask) needs
> > to handle such event...
> 
> Well, instead of not enabling the hotkey bit, I'd say we should force it to be 
> always enabled, catch its event in thinkpad_acpi and possibly report it 
> through the led class interface you described. Is this what you meant?
> 

Yes it could be possible, but first somebody must write patches for led
class interface. This infrastructure does not exist yet. But now for
Thinkpad and Dell laptops this can be useful. Dell Latitude machines via
ACPI-WMI reports when keyboard backlight is changed (by firmware) too.

> > > By the way, in my previous message I forgot to point out that MLCG
> > > actually
> > > takes a numeric argument, but then ignores it. This can be seen from the
> > > DSDT dump you posted, so I'm sure you already noticed. But maybe this
> > > information can be useful to those who want to report data from their
> > > ThinkPads.
> > 
> > Hm... is that argument from MLCG propagated somewhere? And what happen
> > in linux kernel if we do not call ACPI method with correct number of
> > arguments? ACPI fail or? Or missing arguments will be used as NULL/zero
> > or some other default value?
> 
> The DSDT says that it takes one argument but it never references it (Arg0):
> 
> >  Method (MLCG, 1, NotSerialized)
> >  {
> >      Store (\KBLS (0x00, 0x00), Local0)
> >      Return (Local0)
> >  }
> 
> In fact both
>   acpi_evalf(hkey_handle, &res, "MLCG", "dd", 0 /* dummy */)
>   acpi_evalf(hkey_handle, &res, "MLCG", "d")
> work here (i.e. res becomes 0x5020{0,1,2}), but the latter also results in 
> "ACPI Warning: \_SB_.PCI0.LPC_.EC__.HKEY.MLCG: Insufficient arguments - Caller 
> passed 0, method requires 1 (20150410/nsarguments-256)" on dmesg.
> 
> Fabio D'Urso
> 

Now I see it. My DSDT contains also one arg for MLCG. And it is
discarded too... So passing dummy zero sounds good.

-- 
Pali Rohár
pali.rohar@gmail.com