linux-kernel - Re: Keyboard regression by intel-vbtn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Sep 2020 11:21:27 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        Barnabás Pőcze <pobrn@...tonmail.com>
Subject: Re: Keyboard regression by intel-vbtn

Hi,

On 9/29/20 10:48 AM, Takashi Iwai wrote:
> Hi Hans,
> 
> it seems that the recent update of intel-vtn broke the keyboard input
> on some laptops with libinput:
>    https://bugzilla.opensuse.org/show_bug.cgi?id=1175599
> 
> Blacklisting intel-vtn fixes the issue, so it's likely the falsely
> reported tablet mode switch that leads libinput misbehaving.  The
> affected machines are Acer E5-511 and ASUS X756UX laptops, and they
> shouldn't have the tablet mode at all, AFAIK.
> 
> Could you take a look?  I guess it's the commit cfae58ed681c that
> broke.  The chassis type is Notebook on those, and this type should be
> excluded as well as Laptop.
> 
> The dmidecode outputs and other info are found in the bugzilla above:
>    https://bugzilla.opensuse.org/attachment.cgi?id=841999
>    https://bugzilla.opensuse.org/attachment.cgi?id=842039
> 
> The one for ASUS is embedded in hwinfo outpt:
>    https://bugzilla.opensuse.org/attachment.cgi?id=841157

Ugh. What a mess, sorry about this.

So as the commit message from commit cfae58ed681c
("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type")
explains the reason to NOT NOT report SW_TABLET_MODE on devices
with a chassis type of 10 ("Notebook") is that at least
some HP ... 360 ... models use that chassis type and do
report a correct SW_TABLET_MODE through the intel-vbtn driver.

The SW_TABLET_MODE on these actually got regressed by
de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
which first introduced the chassis-type check.

And to complicate things further even though some
HP ... 360 ... models use that chassis type and from the DSDT
it seems that they do report a correct SW_TABLET_MODE through the
intel-vbtn driver. In practice it is also broken on some
HP ... 360 ... models, see:

https://forum.manjaro.org/t/keyboard-and-touchpad-only-work-on-kernel-5-6/22668
http://git.infradead.org/linux-platform-drivers-x86.git/commit/d823346876a970522ff9e4d2b323c9b734dcc4de
"platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"

Since the problem of wrongly reporting SW_TABLET_MODE=1 in combination
with libinput, leads to a non-usable system. Where as OTOH many people will
not even notice when SW_TABLET_MODE is not being reported, I believe it
is best to move to a dmi based allow-list approach here, as we recently
did for SW_TABLET_MODE reporting by the asus-wmi driver. Allowing:

dmi chassis-types: 8 /* Portable */,  31 /* Convertible */, 32 /* Detachable */
and the HP Stream x360 11-p000nd which has working intel-vbtn SW_TABLET_MODE
support combined with a chassis-type of 10 /* Notebook */.

I will prepare a patch for this right away.

Note this patch will effectively replace:
"platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"
We will no longer need this workaround with the allow list and I believe
that it would be better to drop that one.

Andy can you drop that one from your review-andy branch please?

Regards,

Hans