[ltp] Re: Thinkpad keyboard backlight ACPI interface

[Pali Rohár]

On Thursday 13 August 2015 23:25:51 Fabio D'Urso wrote:
> On Sunday, August 09, 2015 11:26:04 PM Pali Rohár wrote:
> > On Sunday 09 August 2015 23:20:26 Fabio D'Urso wrote:
> > > On Tuesday, July 28, 2015 02:05:03 PM Pali Rohár wrote:
> > > > On Tuesday 28 July 2015 13:56:32 Bjørn Mork wrote:
> > > > > Pali Rohár <pali.rohar@gmail.com> writes:
> > > > > > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> > > > > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > > > > >> > I would like to write kernel patch for thinkpad_acpi.c to
> > > > > >> > support keyboard backlight (like other modules in
> > > > > >> > drivers/platform/x86/ tree),
> > > > > >> > but last missing information is how to detect current level
> > > > > >> > of brightness and check if backlight is supported...
> > > > > >> 
> > > > > >> Based on the code you posted, I would assume that MLCG returns
> > > > > >> the current brightness level.  Did you test that?
> > > > > > 
> > > > > > Of course and it returns:
> > > > > > 
> > > > > > 0x50200 - off
> > > > > > 0x50201 - level 1
> > > > > > 0x50202 - level 2
> > > > > > 
> > > > > > But I do not understand why it returns 0x5020{0,1,2} and not
> > > > > > only 0,1,2.
> > > > > 
> > > > > Looks like it might have several bitfields with different
> > > > > meanings. You'll probably have to guess what they are.
> > > > 
> > > > Yes... Last number looks like current level. But what others? Maybe
> > > > it represent if backlight feature is supported? Do not know.
> > > > 
> > > > But it would be good, if more people with Thinkpad machines with
> > > > and also without keyboard backligth send output from "MLCG" ACPI
> > > > call.
> > > 
> > > I can confirm that everything is as you described also on my W541
> > > (with backlight), except for the line
> > > 
> > >  OperationRegion (MNVS, SystemMemory, 0xCCD7D018, 0x1000)
> > > 
> > > which is actually
> > > 
> > >  OperationRegion (MNVS, SystemMemory, 0x7CE7D018, 0x1000)
> > > 
> > > The rest of the DSDT code is like yours, MLCG always returns
> > > 0x5020{0,1,2} and MLCS {0,1,2} works as expected and returns 0x0.
> > > 
> > > I have also toggled the Fn lock and Ctrl/Fn swapping, but the
> > > mysterious 0x5020n did not change. I have the latest BIOS version
> > > (2.21).
> > > 
> > > Fabio D'Urso
> > 
> > Thanks for confirmation. Now I need dumps also from machines without
> > backlight keyboard, but with MLCG method.
> 

Hi!

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

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

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

> 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.
> 
> Fabio D'Urso
> 

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?

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