> Hmm - so I got > [ 561.809723] [ACPI Debug 64952760] Integer 0x0000000000000000 > for my Store (BSWF, Debug) call. This is the core issue. > 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. Sorry, you lost me. What functionality do you think is disabled where, specifically? > 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 :-( Did you mean _L21? I assume you were talking about Skylakes above, but _L11 is not used on these. Also, what do you mean you "get notifications from all buttons"? Please clarify. > 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. What do you mean by "everything"? Please be specific, reading ACPI code is already hard as it is. I would guess you meant BSWF, RFHF, AHKF and IRBF, but guessing will not get us far. > 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) I think you are missing the point. The fact that BLNF always sets some bit in AHKF is meaningless, because even if you got notified about that in some manner, you still wouldn't know whether brightness is supposed to be increased or decreased. The only way ACPI code makes that distinction is using BSWF, which is apparently broken. > 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. This looks awfully like the issue I had with a Dell machine and a certain hotkey [1]. It later turned out that ACPI variables are set to different values after a certain "magical" SMBIOS call is made. Meanwhile the same hotkey worked just fine on other models without any prior initialization. The case we are looking at here might be similar, i.e. something worked on Haswells without any initialization, but Skylakes require some special call before brightness-related key presses are properly reported. > >>> 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. Sorry, the above sentence does not parse for me. > I don't know, why / how the brightness keys are working in Windows. Perhaps this is the time to explore the Windows path after all. My guess would be brightness-related hotkeys do not work on a Windows instance with no Fujitsu-supplied software. BTW, I did some more fiddling with _L11 on my Haswell and it seems its code run before the BSWF check is identical to that found in _L21 on Skylakes. Moreover, BSWF equals 0 before the FSMI call. Which means that BSWF is written to by the processor in response to an SMM call. Which in turn means we will not be able to debug why it writes 0 and not 1 or 2 without assistance from Fujitsu or a successful attempt to figure out how the Fujitsu-supplied Windows software works. [1] https://www.spinics.net/lists/platform-driver-x86/msg07094.html -- 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
