> >> 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?
>
> Probably the day was too long.
>
> I just saw, that the code path is the same for Haswell and Skylake, if
> OSYS >= 0x07D6
> I missed that on Haswell BSWF is not 0, when a key is pressed, wight?
Correct. It is either 1 ("brightness down") or 2 ("brightness up").
Though I still fail to understand your point regarding OSYS processing.
It looks pretty clear to me: Haswells send notifications to the ACPI
video object on "newer" systems and fall back to GBLS/SBLL for
everything else; Skylakes do not have the fallback branch.
> >> 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.
>
> Yup.
>
> > Also, what do you mean you "get notifications from all buttons"? Please
> > clarify.
>
> All three key combinations are handled via _L21.
> I originally thought that "Notify (\_SB.FEXT, 0x80)" was generated for
> all of them, but I was wrong.
>
> If I don't press the touchpad key, which sets AHKF to 0x8, AHKF stays at
> 0, and I don't get any notify call for the brightness keys. And since
> AHKF is stuck to 0x8, until a driver calls the S000 function, it seemed
> to me, that the brightness keys generate the notify events, which they
> "logically" don't do.
Understood, thanks for clarifying.
> >> 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.
>
> My _L21:
>
> (...)
All clear now, thanks.
> >> 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 wanted to express, that currently the only conclusion I took from all
> the reading and testing of ACPI code snippets is, that Fujitsu moved the
> former touchpad disable handling from "in hardware" to "to be handled by
> the driver", as there is now code in the S000 function:
>
> // Brightness
> If (And (AHKF, One))
> {
> Or (Local0, 0x02000000, Local0)
> XOr (AHKF, One, AHKF)
> }
>
> // Touchpad
> If (And (AHKF, 0x08))
> {
> Or (Local0, 0x04000000, Local0)
> XOr (AHKF, 0x08, AHKF)
> }
Ah, okay, got it. This means I can probably prepare an experimental
patch to support the touchpad button.
> So you still have to call another function from the driver to know, if
> the brightness level went up or down, but a key indication is there.
Well, yes, but two questions still remain:
1) Why are no brightness-related notifications sent to either the ACPI
video device or FEXT (i.e. why is BSWF constant)?
2) You wrote "call another function from the driver to know if the
brightness level went up or down". The question is _which_ function
to call - I do not see it, do you?
> And they added the 0x02000000 and 0x04000000 values to the bitmask they
> generate when you call S000 with Arg0 = 0
>
> >> 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.
>
> So for you the FSMI call changes the BSWF value.
Yes.
> > 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.
>
> Hmm.
>
> So I got a reply from my vendor CC some Fujitsu persons.
>
> They claim the non-working brightness buttons is an error in an Intel
> driver and they are going to contact the Linux/Ubuntu community.
I am not sure what the Intel driver has to do with this, but hey, who am
I to tell them how their hardware works?
> I'll point them to this thread.
Please do, I will be happy to help.
> No news yet about the touchpad key.
Let me think about a patch which would support it. I will get back to
you once I have actual code.
--
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
