LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] HID: multitouch: handle faulty Elo touch device
@ 2019-05-21 13:38 Benjamin Tissoires
  2019-05-21 13:50 ` Benjamin Tissoires
  0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Tissoires @ 2019-05-21 13:38 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: linux-input, linux-kernel, Benjamin Tissoires, Breno Leitao

Since kernel v5.0, one single win8 touchscreen device failed.
And it turns out this is because it reports 2 InRange usage per touch.

It's a first, and I *really* wonder how this was allowed by Microsoft in
the first place. But IIRC, Breno told me this happened *after* a firmware
upgrade...

Anyway, better be safe for those crappy devices, and make sure we have
a full slot before jumping to the next.
This won't prevent all crappy devices to fail here, but at least we will
have a safeguard as long as the contact ID and the X and Y coordinates
are placed in the report after the grabage.

Reported-and-tested-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/hid/hid-multitouch.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index ef635964cfe1..a344a3cf5398 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -642,6 +642,13 @@ static void mt_store_field(struct hid_device *hdev,
 	if (*target != DEFAULT_TRUE &&
 	    *target != DEFAULT_FALSE &&
 	    *target != DEFAULT_ZERO) {
+		if (usage->contactid == DEFAULT_ZERO ||
+		    usage->x == DEFAULT_ZERO ||
+		    usage->y == DEFAULT_ZERO) {
+			hid_dbg(hdev,
+				"ignoring duplicate usage on incomplete");
+			return;
+		}
 		usage = mt_allocate_usage(hdev, application);
 		if (!usage)
 			return;
-- 
2.19.2


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] HID: multitouch: handle faulty Elo touch device
  2019-05-21 13:38 [PATCH] HID: multitouch: handle faulty Elo touch device Benjamin Tissoires
@ 2019-05-21 13:50 ` Benjamin Tissoires
  2019-05-22 10:38   ` Jiri Kosina
  0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Tissoires @ 2019-05-21 13:50 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: open list:HID CORE LAYER, lkml, Breno Leitao

On Tue, May 21, 2019 at 3:38 PM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> Since kernel v5.0, one single win8 touchscreen device failed.
> And it turns out this is because it reports 2 InRange usage per touch.
>
> It's a first, and I *really* wonder how this was allowed by Microsoft in
> the first place. But IIRC, Breno told me this happened *after* a firmware
> upgrade...
>
> Anyway, better be safe for those crappy devices, and make sure we have
> a full slot before jumping to the next.
> This won't prevent all crappy devices to fail here, but at least we will
> have a safeguard as long as the contact ID and the X and Y coordinates
> are placed in the report after the grabage.

Grmbl, I forgot:
Fixes: 01eaac7e5713 ("HID: multitouch: remove one copy of values")
CC: stable@vger.kernel.org # v5.0+

Cheers,
Benjamin

>
> Reported-and-tested-by: Breno Leitao <leitao@debian.org>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/hid/hid-multitouch.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index ef635964cfe1..a344a3cf5398 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -642,6 +642,13 @@ static void mt_store_field(struct hid_device *hdev,
>         if (*target != DEFAULT_TRUE &&
>             *target != DEFAULT_FALSE &&
>             *target != DEFAULT_ZERO) {
> +               if (usage->contactid == DEFAULT_ZERO ||
> +                   usage->x == DEFAULT_ZERO ||
> +                   usage->y == DEFAULT_ZERO) {
> +                       hid_dbg(hdev,
> +                               "ignoring duplicate usage on incomplete");
> +                       return;
> +               }
>                 usage = mt_allocate_usage(hdev, application);
>                 if (!usage)
>                         return;
> --
> 2.19.2
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] HID: multitouch: handle faulty Elo touch device
  2019-05-21 13:50 ` Benjamin Tissoires
@ 2019-05-22 10:38   ` Jiri Kosina
  0 siblings, 0 replies; 3+ messages in thread
From: Jiri Kosina @ 2019-05-22 10:38 UTC (permalink / raw)
  To: Benjamin Tissoires; +Cc: open list:HID CORE LAYER, lkml, Breno Leitao

On Tue, 21 May 2019, Benjamin Tissoires wrote:

> On Tue, May 21, 2019 at 3:38 PM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > Since kernel v5.0, one single win8 touchscreen device failed.
> > And it turns out this is because it reports 2 InRange usage per touch.
> >
> > It's a first, and I *really* wonder how this was allowed by Microsoft in
> > the first place. But IIRC, Breno told me this happened *after* a firmware
> > upgrade...
> >
> > Anyway, better be safe for those crappy devices, and make sure we have
> > a full slot before jumping to the next.
> > This won't prevent all crappy devices to fail here, but at least we will
> > have a safeguard as long as the contact ID and the X and Y coordinates
> > are placed in the report after the grabage.
> 
> Grmbl, I forgot:
> Fixes: 01eaac7e5713 ("HID: multitouch: remove one copy of values")
> CC: stable@vger.kernel.org # v5.0+

I've now pushed this to for-5.2/fixes. Thanks,

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-05-22 10:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21 13:38 [PATCH] HID: multitouch: handle faulty Elo touch device Benjamin Tissoires
2019-05-21 13:50 ` Benjamin Tissoires
2019-05-22 10:38   ` Jiri Kosina

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).