> > 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.html
> > 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. If the GPE count isn't increased when
> > brightness-related keys are pressed, it means some hardware
> > initialization may be required before these keys are handled. In that
> > case we would likely be screwed without assistance from Fujitsu.
> >
> > 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).
>
> The brightness buttons work in Windows 7 with the Fujitsu button driver.
> Didn't check, if they even work without. I can get my hands on a Windows
> 7 laptop, but that'll take some time, if this additional info would help.
No need to do that, at least for now. The sole fact that something
works on Windows is not much of a help if we don't know the technology
used behind the scenes.
--
Best regards,
Michał Kępień
--
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
