Re: Keyboard regression by intel-vbtn

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 9/30/20 5:12 PM, Limonciello, Mario wrote:
>> -----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.

That is a good find, thank you for digging into this and finding this.

But it seems we have a typical case of the microsoft/intel example DSDT code being
blindly copied everywhere here too:

The chassis-type check was originally introduced by you in:
commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")

     Some laptops such as the XPS 9360 support the intel-vbtn INT33D6
     interface but don't initialize the bit that intel-vbtn uses to
     represent switching tablet mode.

     By running this only on real 2-in-1's it shouldn't cause false
     positives.

     Fixes: 30323fb6d5 ("Support tablet mode switch")

I have a XPS 9360 (which is not 2-in-1) acpidump and that has:

         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)
             }
         }

And on an asus e200ha (also not a 2-in-1), where we were seeing
similar problems, but then using asus custom WMI interface for
getting SW_TABLET_MODE I see:

         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
             {
                 Return (0x0F)
             }
         }

I have quite a few DSDTs (mostly byt/cht tablets or 2-in-1s though) and
65 of them define a "PNP0C60" device and only 1 unconditionally
returns 0 from the _STA method for this device. Most others have
an OSYS check. Some also check for some other, presumably BIOS
configured variable, but by far most always return 0x0F, or do
so after an OSYS check which will be true in our case.

So I'm afraid that almost all devices which have the intel-vbtn (INT33D6)
ACPI device will also have a PNP0C60 device with the exact same
_STA method as found on the XPS 9360 and that this thus is not
helpful.

Regards,

Hans