> > I played with my Lifebook E744 a bit and there is a chance it is not as
> > different from the Skylake machines as I originally imagined. Earlier
> > in this thread, I already mentioned that pure ACPI brightness control
> > doesn't work, just like it doesn't work on Skylakes. However, input
> > events are correctly generated when Fn+F6 or Fn+F7 is pressed.
>
> That's no mystery, because the brightness control ACPI device (AKA
> FUJ02B1 is available on e7x4 notebooks and the diriver also generates
> the keycodes in addition.
No, at least not on Haswells. For proof, do an `rmmod fujitsu-laptop'
on a Haswell machine and press Fn+F6 or Fn+F7. The input event will
still be generated. What happens is that pressing Fn+F6 or Fn+F7 raises
a certain GPE (General-Purpose Event; 0x11 on Haswells). This causes
the corresponding ACPI method (_L11) to be called, which in turn sends
notifications to both FUJ02B1 and the ACPI video device. On my Haswell
machine, the former [1] effectively does nothing, because subsequent
calls to GBLL keep returning the same brightness level, apparently
ignoring key presses, but the latter [2] is enough because it causes
acpi_video to generate an input event. For further proof, boot a 4.5+
kernel on a Haswell machine with command line parameter
video.report_key_events=1. Brightness-related input events will not be
generated any more.
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. If
it does, try overriding ACPI method _L21 [3] so that you can read the
value of BSWF when the method is invoked. 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 diff between e7x4 and e7x6 DSDT is ~43k lines or 1.3MB
> And the DSDT of 736 and 756 is identical.
>
> > And I am
> > sure these events are generated by ACPI code as booting with acpi=off
> > makes the input events disappear, while also causing brightness to be
> > correctly adjusted. Thus, I can try to figure out which part of the
> > ACPI code causes the input events to be generated. That information
> > combined with your DSDT dump might help us in figuring out how to make
> > it work for your machine. However, it might just as well turn out that
> > Fujitsu switched to using WMI or some opaque vendor-specific magic.
>
> The ACPI code doesn't generate the keycodes.
> Look at the acpi_fujitsu_notify function in
> drivers/platform/x86/fujitsu-laptop.c
>
> And sure, without ACPI no ACPI driver will be loaded.
>
> So without ACPI, the brightness buttons work correctly (not that's an
> option to run a laptop without ACPI)?
Indeed. My understanding is that on an operating system without ACPI
support, brightness is adjusted directly by the BIOS.
[1] Notify (\_SB.PCI0.LPCB.FJEX, 0x80)
[2] \_SB.PCI0.GFX0.LCD.BLNF ()
[3] see: Documentation/acpi/method-customizing.txt
--
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
