Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6

[Jan-Marek Glogowski <glogow@fbihome.de>]

Am 23.06.2016 um 14:35 schrieb Michał Kępień:
>>> I looked at the ACPI tables you sent me and it looks like
>>> brightness-related keys should be handled by ACPI method _L21 on
>>> Skylakes.  As far as I can tell without playing with the hardware
>>> myself, the ACPI code doesn't strike me as outright broken, so the first
>>> step would be to confirm whether the relevant GPE is raised at all when
>>> you press brightness-related keys.  To check it, launch the following
>>> command in a terminal:
>>>
>>>     watch -n 1 cat /sys/firmware/acpi/interrupts/gpe21
>>>
>>> and press Fn+F6 or Fn+F7.  The counter should get increased by one.
>>
>> Yup - great. This works :-)
>> I would be interested to know, how you came to this conclusion. Is this
>> encoded in the ssdt tables?
> 
> First I figured out (using a command almost identical to the one I
> suggested to you) which GPE is used for signalling brightness-related
> key presses on my Haswell machine.  This immediately led me to ACPI
> method _L11.  I selectively commented out ACPI code from this method,
> recompiling and overriding it using /sys/kernel/debug/acpi/custom_method
> after every change until I figured out exactly which method invocation
> causes the key events to be generated.  Once I knew that, I searched for
> a similar invocation in a Skylake DSDT dump.  This led me to ACPI method
> _L21, which is very similar to Haswell's _L11.
> 
>> I really want to understand this. Should I
>> read the ACPI specs?
> 
> Well, I cannot stop you from doing that, but I would advise against it
> if you value your own mental health.  Unless you have a very specific
> reason to do otherwise, just follow the code.  If you would like to
> learn a bit more about GPEs specifically, I recommend this great blog
> post by Matthew Garrett:
> 
>     http://mjg59.livejournal.com/117532.htmlBSWF = Zero
> 
>>> If it does, try overriding ACPI method _L21 [3] so that you can read
>>> the value of BSWF when the method is invoked.
>>
>> I'll read [3] and report back later.
>>
>>> If that value is 0, it's
>>> obviously a vendor bug as it would prevent the ACPI video device from
>>> being notified. 

Hmm - so I got
[  561.809723] [ACPI Debug 64952760]  Integer 0x0000000000000000
for my Store (BSWF, Debug) call.

Then I had a look at the \_SB.PCI0.GFX0.LCD.BLNF () function in my
ssdt7.dsl, and it sets "BSWF = Zero" as the 2nd last call. And it's the
same in the ssdt6.dsl of the Haswell hardware, except there the call to
BLNF is guarded by an "LGreaterEqual(OSYS, 0x07D6)" guard, so I guess
for newer operating systems, all the functionality is also disabled on
Haswell.

But BLNF also sets "AHKF |= One", which triggers this code path
containing just a "Notify (\_SB.FEXT, 0x80)", but since it's actually
never called, I get no notifications - how did I ever get notifications?

...

until I have pressed the "touchpad" button, which changes AHKF to 8 -
permanently - and now I get notifications from all buttons, since all
use _L11 :-(

So I actually never got any direct ACPI events from the brightness
control, but this was just toggled because of the "touchpad" key,
enabling the notifications…

And then I "instrumented" all if's by dumping the value just before the
if => everything is always 0, except the permanent 8 in AHKF after
pressing the "touchpad" button.

So - just for the sake of it, I had a look for some AHKF code and the
button function S000 got new code to handle AHKF - both brightness (AKA
BSWF AKA AHKF & One) and the touchpad (AKA AHKF & 0x08)

But this is just called, if you call the ACPI button function in the
device driver.

Which leaves me with the problem, that BSWF is always 0.

>>> To sum up, I see no immediate reason for brightness control not to work
>>> on Skylakes, so you will have to get your hands a bit dirty to get to
>>> the bottom of this (and it might still not yield a solution).

That's enough for today.

I'm quite sure Fujitsu changed the in-ACPI-HW-touchpad-disable-handling
to be done by the driver.
I don't know, why / how the brightness keys are working in Windows.

Jan-Marek