Thinkpad keyboard backlight ACPI interface

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Thinkpad keyboard backlight ACPI interface

Pali Rohár
Hello,

I'm trying to control backlight of Thinkpad X1 Carbon via software ACPI
calls. With doing some tests I come up to conclusion that ACPI method
MLCS from LEN0068 ACPI device controls level of keyboard backlight.

With this shell snippet and acpi_call.ko kernel module I can control
keyboard backlight.

 level=2 # 0, 1 or 2
 sudo modprobe acpi_call
 path=`cat /sys/bus/acpi/devices/LEN0068:00/path`
 sudo sh -c "echo $path.MLCS $level > /proc/acpi/call"

Here is relevant AML code from DSDT table for it:

 Method (MLCG, 1, NotSerialized)
 {
     Store (\KBLS (0x00, 0x00), Local0)
     Return (Local0)
 }
 
 Method (MLCS, 1, NotSerialized)
 {
     Store (\KBLS (0x01, Arg0), Local0)
     If (LNot (And (Local0, 0x80000000)))
     {
         If (And (Arg0, 0x00010000))
         {
             \_SB.PCI0.LPC.EC.HKEY.MHKQ (0x6001)
         }
         Else
         {
             If (\_SB.PCI0.LPC.EC.HKEY.MHKK (0x00020000))
             {
                 \_SB.PCI0.LPC.EC.HKEY.MHKQ (0x1012)
             }
         }
     }
 
     Return (Local0)
 }

I would like to ask you: It is safe to call MLCS function? Do you
somebody have any documentation for Thinkpad machines which describe
this ACPI functionality? Is there any way to detect (via ACPI call) if
some Thinkpad model has backlight keyboard?

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

Can you somebody help me?

--
Pali Rohár
[hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Pali Rohár
On Monday 27 July 2015 23:55:49 Pali Rohár wrote:

> Hello,
>
> I'm trying to control backlight of Thinkpad X1 Carbon via software ACPI
> calls. With doing some tests I come up to conclusion that ACPI method
> MLCS from LEN0068 ACPI device controls level of keyboard backlight.
>
> With this shell snippet and acpi_call.ko kernel module I can control
> keyboard backlight.
>
>  level=2 # 0, 1 or 2
>  sudo modprobe acpi_call
>  path=`cat /sys/bus/acpi/devices/LEN0068:00/path`
>  sudo sh -c "echo $path.MLCS $level > /proc/acpi/call"
>
> Here is relevant AML code from DSDT table for it:
>
>  Method (MLCG, 1, NotSerialized)
>  {
>      Store (\KBLS (0x00, 0x00), Local0)
>      Return (Local0)
>  }
>  
>  Method (MLCS, 1, NotSerialized)
>  {
>      Store (\KBLS (0x01, Arg0), Local0)
>      If (LNot (And (Local0, 0x80000000)))
>      {
>          If (And (Arg0, 0x00010000))
>          {
>              \_SB.PCI0.LPC.EC.HKEY.MHKQ (0x6001)
>          }
>          Else
>          {
>              If (\_SB.PCI0.LPC.EC.HKEY.MHKK (0x00020000))
>              {
>                  \_SB.PCI0.LPC.EC.HKEY.MHKQ (0x1012)
>              }
>          }
>      }
>  
>      Return (Local0)
>  }
>
> I would like to ask you: It is safe to call MLCS function? Do you
> somebody have any documentation for Thinkpad machines which describe
> this ACPI functionality? Is there any way to detect (via ACPI call) if
> some Thinkpad model has backlight keyboard?
>
> 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...
>
> Can you somebody help me?
>

If somebody is interested, here is KBLS part of DSDT code:

 OperationRegion (MNVS, SystemMemory, 0xCCD7D018, 0x1000)

 ...

 OperationRegion (SMI0, SystemIO, 0xB2, 0x01)
 Field (SMI0, ByteAcc, NoLock, Preserve)
 {
     APMC,   8
 }
 
 Field (MNVS, AnyAcc, NoLock, Preserve)
 {
             Offset (0xFC0),
     CMD,    8,
     ERR,    32,
     PAR0,   32,
     PAR1,   32,
     PAR2,   32,
     PAR3,   32
 }
 
 Mutex (MSMI, 0x07)
 Method (SMI, 5, NotSerialized)
 {
     Acquire (MSMI, 0xFFFF)
     Store (Arg0, CMD)
     Store (0x01, ERR)
     Store (Arg1, PAR0)
     Store (Arg2, PAR1)
     Store (Arg3, PAR2)
     Store (Arg4, PAR3)
     Store (0xF5, APMC)
     While (LEqual (ERR, 0x01))
     {
         Sleep (0x01)
         Store (0xF5, APMC)
     }
 
     Store (PAR0, Local0)
     Release (MSMI)
     Return (Local0)
 }

 ...

 Method (KBLS, 2, NotSerialized)
 {
     Return (SMI (0x14, 0x09, Arg0, Arg1, 0x00))
 }


--
Pali Rohár
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Bjørn Mork
In reply to this post by Pali Rohár
Pali Rohár <[hidden email]> 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?

The thinkpad_acpi driver use code like this to test for supported
features:

      tp_features.bluetooth = hkey_handle && acpi_evalf(hkey_handle, &status, "GBDC", "qd");

You could do something similar for the keyboard backlight feature,
couldn't you?



Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Pali Rohár
On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:

> Pali Rohár <[hidden email]> 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.

MLCS returns 0x0.

> The thinkpad_acpi driver use code like this to test for supported
> features:
>
>       tp_features.bluetooth = hkey_handle && acpi_evalf(hkey_handle, &status, "GBDC", "qd");
>
> You could do something similar for the keyboard backlight feature,
> couldn't you?
>

Sounds good, but I do not know what "GBDC" and "qd" means... :-(
So because of that I need some "documentation" which say how to do it.

--
Pali Rohár
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Bjørn Mork
Pali Rohár <[hidden email]> writes:

> On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
>> Pali Rohár <[hidden email]> 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.

> MLCS returns 0x0.
>
>> The thinkpad_acpi driver use code like this to test for supported
>> features:
>>
>>       tp_features.bluetooth = hkey_handle && acpi_evalf(hkey_handle, &status, "GBDC", "qd");
>>
>> You could do something similar for the keyboard backlight feature,
>> couldn't you?
>>
>
> Sounds good, but I do not know what "GBDC" and "qd" means... :-(
> So because of that I need some "documentation" which say how to do it.

The "qd" part is documented in the driver source - it's specific to the
acpi_evalf() helper.  For the "GBDC" I don't think there is any
documentation.  People have done what you have: Looked at the DSDT,
added some intelligent guesswork, and then tested the result.


Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Pali Rohár
On Tuesday 28 July 2015 13:56:32 Bjørn Mork wrote:

> Pali Rohár <[hidden email]> writes:
>
> > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> >> Pali Rohár <[hidden email]> 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.

From output from one machine I'm not able to decode what it means.

If you look at posted ACPI DSDT code, you will see that MLCG is just
wrapper around SMI call which return that value. It is not generated or
constructed by ACPI....

> > MLCS returns 0x0.
> >
> >> The thinkpad_acpi driver use code like this to test for supported
> >> features:
> >>
> >>       tp_features.bluetooth = hkey_handle && acpi_evalf(hkey_handle, &status, "GBDC", "qd");
> >>
> >> You could do something similar for the keyboard backlight feature,
> >> couldn't you?
> >>
> >
> > Sounds good, but I do not know what "GBDC" and "qd" means... :-(
> > So because of that I need some "documentation" which say how to do it.
>
> The "qd" part is documented in the driver source - it's specific to the
> acpi_evalf() helper.  For the "GBDC" I don't think there is any
> documentation.  People have done what you have: Looked at the DSDT,
> added some intelligent guesswork, and then tested the result.
>

Yes and for that I need output from as many Thinkpad machines, so I can
do some "statistic" output.

--
Pali Rohár
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Bjørn Mork
Pali Rohár <[hidden email]> writes:

> Yes and for that I need output from as many Thinkpad machines, so I can
> do some "statistic" output.

Would love to help, but neither my ancient X301 nor my newer T420s have
the MLCG and MLCS methods.  Which makes sense, as they don't have
backlit keyboards either...


Bjør
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

green-9
In reply to this post by Pali Rohár
Pali Rohár wrote at 2015-07-28 07:05 -0500:
> But it would be good, if more people with Thinkpad machines with and
> also without keyboard backligth send output from "MLCG" ACPI call.

What standard shell command can be used to acquire this output?
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Pali Rohár
In reply to this post by Bjørn Mork
On Tuesday 28 July 2015 14:53:41 Bjørn Mork wrote:

> Pali Rohár <[hidden email]> writes:
>
> > Yes and for that I need output from as many Thinkpad machines, so I can
> > do some "statistic" output.
>
> Would love to help, but neither my ancient X301 nor my newer T420s have
> the MLCG and MLCS methods.  Which makes sense, as they don't have
> backlit keyboards either...
>
>
> Bjør

Ok, so does somebody on this list has Thinkpad with Ivy Bridge or newer
generation without backligh keyboard?

--
Pali Rohár
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Nikos Alexandris
* Pali Rohár :

 ...

> Ok, so does somebody on this list has Thinkpad with Ivy Bridge or newer
> generation without backligh keyboard?

You mean like any model?  ThinkPad X1 Carbon 2nd Gen. Is this suitable?
If it's not a lot of work to do, I can try.

Cheers, Nikos


ps-  Please, if it's not difficult, could you send me a link with what, how and why?  I am not
following closely the list.
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Fabio D'Urso
In reply to this post by Pali Rohár
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 <[hidden email]> writes:
> > > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> > >> Pali Rohár <[hidden email]> 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

> >From output from one machine I'm not able to decode what it means.
>
> If you look at posted ACPI DSDT code, you will see that MLCG is just
> wrapper around SMI call which return that value. It is not generated or
> constructed by ACPI....
>
> > > MLCS returns 0x0.
> > >
> > >> The thinkpad_acpi driver use code like this to test for supported
> > >>
> > >> features:
> > >>       tp_features.bluetooth = hkey_handle && acpi_evalf(hkey_handle,
> > >>       &status, "GBDC", "qd");> >>
> > >> You could do something similar for the keyboard backlight feature,
> > >> couldn't you?
> > >
> > > Sounds good, but I do not know what "GBDC" and "qd" means... :-(
> > > So because of that I need some "documentation" which say how to do it.
> >
> > The "qd" part is documented in the driver source - it's specific to the
> > acpi_evalf() helper.  For the "GBDC" I don't think there is any
> > documentation.  People have done what you have: Looked at the DSDT,
> > added some intelligent guesswork, and then tested the result.
>
> Yes and for that I need output from as many Thinkpad machines, so I can
> do some "statistic" output.

--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Pali Rohár
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 <[hidden email]> writes:
> > > > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> > > >> Pali Rohár <[hidden email]> 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.

--
Pali Rohár
[hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thinkpad keyboard backlight ACPI interface

Fabio D'Urso
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 <[hidden email]> writes:
> > > > > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> > > > >> Pali Rohár <[hidden email]> 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, 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.

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.

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

--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> writes:
> > > > > > On Tuesday 28 July 2015 13:17:58 Bjørn Mork wrote:
> > > > > >> Pali Rohár <[hidden email]> 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
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
[hidden email]
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
Loading...