[ltp] Re: Thinkpad keyboard backlight ACPI interface

[Fabio D'Urso]

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.

> > 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?

> > 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