lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Keyboard regression by intel-vbtn
Date
> -----Original Message-----
> From: Hans de Goede <hdegoede@redhat.com>
> Sent: Wednesday, September 30, 2020 8:28
> To: Limonciello, Mario; Barnabás Pőcze; Andy Shevchenko
> Cc: platform-driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org; Takashi
> Iwai
> Subject: Re: Keyboard regression by intel-vbtn
>
>
> [EXTERNAL EMAIL]
>
> Hi,
>
> On 9/29/20 10:47 PM, Limonciello, Mario wrote:
> >>
> >> I requested on the Ubuntu bug for someone to provide these.
> >>
> >
> > Joe Barnett was kind enough to share two ACPI dumps to compare.
> > Not affected:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/54153
> 18/+files/1.2.0.acpidump
> >
> > Affected:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/54154
> 05/+files/1.13.0.acpidump
>
> Thank you, I took a look at these (before completing my allow-list fix),
> but there is not really much which stands out. The only related thing which
> stands out is that the 1.13.0 dsdt.dsl has this new bit:
>
>
> Case (0x08)
> {
> Return (^^PCI0.LPCB.H_EC.VGBI.VGBS ())
> }
>
> Inside the _DSM of the HIDD / INT33D5 device.
>
> Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> {
> If ((Arg0 == ToUUID ("eeec56b3-4442-408f-a792-
> 4edd4d758054")))
>
>
> What is interesting here is that the PCI0.LPCB.H_EC.VGBI.VGBS object/method
> does not actually exist the correct path is:
>
> ^^PCI0.LPCB.ECDV.VGBI.VGBS
>
> So this does suggest that something around the VGBS handling changed
> (and since it points to a non existing ACPI object, possibly broke)
> in the newer BIOS version. But what exactly is going on on this XPS 2-in-1
> cannot really be derived from the acpidumps.
>
> Regards,
>
> Hans

Looking through some publicly found content I think I might have figured out what
bight be the missing link.

https://software.intel.com/sites/default/files/detecting-slate-clamshell-mode-and-screen-orientation-in-convertible-pc-1.pdf

You can see that the device with CID PNP0C60 is supposed to indicate the presence
of a convertible hinge. We don't currently have anything that matches that _CID or _HID
in intel-vbtn.

In the DSDT dump you can see that the status method for the INT33D3 device returns
0x0F on 2-in-1.s

Device (CIND)
{
Name (_HID, "INT33D3" /* Intel GPIO Buttons */) // _HID: Hardware ID
Name (_CID, "PNP0C60" /* Display Sensor Device */) // _CID: Compatible ID
Method (_STA, 0, Serialized) // _STA: Status
{
If ((OSYS >= 0x07DC))
{
Return (0x0F)
}

Return (Zero)
}
}

On a non 2-in-1 device I don't see this present. So I think we should have intel-vbtn
look for that INT33D3/PNP0C60 device to decide whether to offer the switch.

Similarly as mentioned in that document I think that we should not be showing the
docking switch only when INT33D4/PNP0C70 is present and returns 0xF.

\
 
 \ /
  Last update: 2020-09-30 17:15    [W:0.069 / U:13.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site