Am 24.06.2016 um 09:12 schrieb Michał Kępień:
>> 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?
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?
>> 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.
>> 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:
DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNB293 ", 0x010A0000)
{
External (AHKF)
External (BSWF)
External (DSEN)
External (DSWF)
External (GINT)
External (IRBC)
External (IRBF)
External (LCDA)
External (RFHF)
External (RFSW)
External (\_SB.FEXT)
External (\_SB.PCI0.GFX0.DD1F._DCS)
External (WSEF)
External (\FSMI, MethodObj)
External (\_GPE.SWPC, MethodObj)
External (\_SB.FEXT.SIRB, MethodObj)
External (\_SB.PCI0.GFX0.DD1F.BLNF, MethodObj)
Method (\_GPE._L21, 0, NotSerialized) // _Lxx: Level-Triggered GPE
{
Store (0xDEADBEAF, Debug)
Store (Zero, DSWF)
If (LEqual (\_SB.PCI0.GFX0.DD1F._DCS, 0x1F))
{
Store (One, LCDA)
}
Else
{
Store (Zero, LCDA)
}
Store (LCDA, Debug)
FSMI (0x89, Zero, Zero)
Store (DSEN, Debug)
Store (DSWF, Debug)
If (LAnd (LEqual (And (DSEN, 0x03), Zero), DSWF))
{
Store (One, Debug)
SWPC ()
}
Store (BSWF, Debug)
If (BSWF)
{
\_SB.PCI0.GFX0.DD1F.BLNF ()
}
Store (RFHF, Debug)
If (RFHF)
{
Store (One, WSEF)
Notify (\_SB.FEXT, 0x80)
Store (ShiftRight (RFHF, One), RFSW)
Store (Zero, RFHF)
}
Store (AHKF, Debug)
If (AHKF)
{
Notify (\_SB.FEXT, 0x80)
}
Store (IRBF, Debug)
If (IRBF)
{
If (LEqual (IRBC, 0xFD00))
{
Store (One, GINT)
}
Else
{
\_SB.FEXT.SIRB (IRBC)
}
Notify (\_SB.FEXT, 0x80)
Store (Zero, IRBF)
}
}
}
dmesg output
Press brightness
[ 4924.223692] [ACPI Debug 65675410] Integer 0x00000000DEADBEAF
[ 4924.224258] [ACPI Debug 65675982] Integer 0x0000000000000000
[ 4924.228018] [ACPI Debug 65679741] Integer 0x0000000000000000
[ 4924.228065] [ACPI Debug 65679791] Integer 0x0000000000000000
[ 4924.228175] [ACPI Debug 65679901] Integer 0x0000000000000000
[ 4924.228250] [ACPI Debug 65679977] Integer 0x0000000000000000
[ 4924.228325] [ACPI Debug 65680052] Integer 0x0000000000000000
[ 4924.228400] [ACPI Debug 65680127] Integer 0x0000000000000000
Press touchpad
[ 4942.346856] [ACPI Debug 16690175] Integer 0x00000000DEADBEAF
[ 4942.347414] [ACPI Debug 16690739] Integer 0x0000000000000000
[ 4942.351169] [ACPI Debug 16694492] Integer 0x0000000000000000
[ 4942.351216] [ACPI Debug 16694542] Integer 0x0000000000000000
[ 4942.351327] [ACPI Debug 16694653] Integer 0x0000000000000000
[ 4942.351403] [ACPI Debug 16694730] Integer 0x0000000000000000
[ 4942.351479] [ACPI Debug 16694806] Integer 0x0000000000000008
[ 4942.351572] [ACPI Debug 16694898] Integer 0x0000000000000000
Press brightness
[ 4943.381885] [ACPI Debug 17725230] Integer 0x00000000DEADBEAF
[ 4943.382553] [ACPI Debug 17725902] Integer 0x0000000000000000
[ 4943.386264] [ACPI Debug 17729614] Integer 0x0000000000000000
[ 4943.386310] [ACPI Debug 17729662] Integer 0x0000000000000000
[ 4943.386418] [ACPI Debug 17729771] Integer 0x0000000000000000
[ 4943.386495] [ACPI Debug 17729848] Integer 0x0000000000000000
[ 4943.386569] [ACPI Debug 17729922] Integer 0x0000000000000008
[ 4943.386621] [ACPI Debug 17729975] Integer 0x0000000000000000
>> 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.
Yup - I didn't actually look at the Haswell ACPI handling.
>> 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 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)
}
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.
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.
> 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'll point them to this thread.
No news yet about the touchpad key.
Regards,
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
