Hi,
On 9/12/20 1:00 AM, Barnabás Pőcze wrote:
Hi,
thanks for the quick response and patch. I compiled a kernel and
the user reported that it no longer reports SW_TABLET_MODE as active,
and the keyboard and touchpad are usable.
Ok, so at least the regression is fixed.
As a sidenote, another interesting thing is that seemingly no ACPI events are fired when
the device is "folded".
Hmm, that is weird, there is a handler for such an event in the EC event handler
table in the DSDT. How did you monitor this?
acpid + acpi_listen, evtest, and now evemu-record. None of them show any activity.
Can you ask the user to run "sudo evemu-record" and then select the
"Intel Virtual Button driver" device? That should now report 0 as state
for SW_TABLET_MODE when booted in normal clamshell mode; and hopefully it
will change to 1 when the user folds the 2-in-1 into tablet mode.
Reportedly, that does not happen. It stays zero.
Bummer, the DSDT does have this embedded-controller event-handler,
but I guess that is not getting triggered then:
Method (_Q49, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
If ((ROLS == Zero))
{
Notify (VGBI, 0xCD) // Hardware-Specific
}
Else
{
Notify (VGBI, 0xCC) // Hardware-Specific
}
}
Interestingly, the keyboard
and touchpad are disabled nonetheless in tablet mode.
Yes that is probably done by in firmware by the embedded-controller.
I actually verified that the (ROLS == Zero) condition means laptop
mode by checking what the emitted 0xCD event does in the intel-vbtn.c
code, to verify that my check for the 0x10 bit would behave as it should:
Method (VGBS, 0, Serialized)
{
If ((^^PCI0.LPCB.EC0.ROLS == Zero))
{
VBDS = 0x10
}
Else
{
VBDS = Zero
}
Return (VBDS) /* \_SB_.VGBI.VBDS */
}
Which as you see also gets set when (ROLS == Zero).
Interestingly enough, I have a HP Stream X360 11 myself
(note a Stream not a Pavilion) and that has:
Method (VGBS, 0, Serialized)
{
If ((^^PCI0.LPCB.EC0.ROLS == Zero))
{
VBDS = Zero
}
Else
{
VBDS = Zero
}
Return (VBDS) /* \_SB_.VGBI.VBDS */
}
But this is not a problem because it does emit events,
including an event at boot shortly after loading the
vbtn driver, fixing the invalid initial state.
Anyways too bad that we cannot get the SW_TABLET_MODE
reporting to fully work, but at least my patch fixes
the regression.
So I will submit my fix for the regression upstream now.
<snip>
I have no idea what might be going on with that laptop, but fortunately,
the patch seems to have solved the most pressing issue.
If you feel like digging deeper, you could try to figure out
why the _Q49 method does not get called. Chances are it has
something to do with the ACPI embedded-controller (EC) code.
You could ask for a full dmesg and check for:
a) kernel cmdline parameters which should normally not be there
b) ACPI EC errors
And maybe also see "cat /proc/interrupts" output and check that
there is an "acpi" interrupt handler (typically IRQ 9).
Regards,
Hans
