From: Hans de Goede <hdegoede@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Barnabás Pőcze" <pobrn@protonmail.com>
Subject: Re: Keyboard regression by intel-vbtn
Date: Tue, 29 Sep 2020 11:21:27 +0200 [thread overview]
Message-ID: <bedb9d1b-3cca-43e2-ee44-1aac0e09a605@redhat.com> (raw)
In-Reply-To: <s5hft71klxl.wl-tiwai@suse.de>
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
next prev parent reply other threads:[~2020-09-29 9:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 8:48 Keyboard regression by intel-vbtn Takashi Iwai
2020-09-29 9:21 ` Hans de Goede [this message]
2020-09-29 9:29 ` Takashi Iwai
2020-09-29 9:59 ` Barnabás Pőcze
2020-09-29 10:17 ` Hans de Goede
2020-09-29 12:27 ` Limonciello, Mario
2020-09-29 12:54 ` Hans de Goede
2020-09-29 14:25 ` Limonciello, Mario
2020-09-29 16:53 ` Andy Shevchenko
2020-09-29 20:37 ` Limonciello, Mario
2020-09-29 20:47 ` Limonciello, Mario
2020-09-30 13:28 ` Hans de Goede
2020-09-30 15:12 ` Limonciello, Mario
2020-09-30 15:36 ` Hans de Goede
2020-09-30 16:02 ` Limonciello, Mario
2020-09-29 14:19 ` Hans de Goede
2020-09-30 13:21 ` Hans de Goede
2020-09-30 13:21 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bedb9d1b-3cca-43e2-ee44-1aac0e09a605@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pobrn@protonmail.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox