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 -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
