All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Carey <carvsdriver@gmail.com>
To: linux-input@vger.kernel.org
Cc: Dave Carey <carvsdriver@gmail.com>, jikos@kernel.org, bentiss@kernel.org
Subject: [PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero
Date: Fri, 15 May 2026 13:52:53 -0400	[thread overview]
Message-ID: <20260515175253.873796-1-carvsdriver@gmail.com> (raw)

The INGENIC 17EF:6161 touchscreen (Lenovo Yoga Book 9 14IAH10) reports
HID_DG_CONTACTCOUNT=0 in the frame immediately following the last finger
lift rather than omitting the frame entirely.  In mt_touch_report() the
existing code only updates num_expected when contact_count is non-zero,
so a zero contact count on the first packet of a new frame leaves
num_expected at its previous value (e.g. 2 for a two-finger gesture).
The sync check "num_received >= num_expected" then evaluates "0 >= 2"
and never fires, preventing INPUT_MT_DROP_UNUSED from releasing the
stale slots.  Those slots remain active in the kernel MT layer until the
next touch, at which point they are released in a batch alongside the
new contact — causing the userspace event consumer to miss the intervening
finger-up sequence and corrupt its gesture session state.

Fix by resetting num_expected to 0 when contact_count is zero and
num_received is still 0 (i.e., this is the first and only packet of the
frame, not a continuation packet in a multi-packet sequence).  With
num_expected=0 the sync check "0 >= 0" fires immediately, calling
input_mt_sync_frame() which drops the stale slots via INPUT_MT_DROP_UNUSED.

The num_received==0 guard is critical: continuation packets in a
multi-packet frame arrive after at least one contact has already been
processed (num_received>0), so they are correctly excluded from this
path and the existing multi-packet logic is unaffected.

Signed-off-by: Dave Carey <carvsdriver@gmail.com>
Tested-by: Dave Carey <carvsdriver@gmail.com>
---
This follows commit 108ac841 ("HID: multitouch: Fix Yoga Book 9 14IAH10
touchscreen misclassification"), applied to hid/for-next on 2026-05-12.
That commit established MT_CLS_YOGABOOK9I.

This fix is independent of the companion ghost-contacts patch ("HID:
multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts",
sent 2026-05-14), which adds MT_QUIRK_CONTACT_CNT_ACCURATE to the same
class.  Both apply cleanly on top of 108ac841.

Tested on Lenovo Yoga Book 9 14IAH10 (83KJ).

 drivers/hid/hid-multitouch.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index ec04dba..e91ba89 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1336,6 +1336,18 @@ static void mt_touch_report(struct hid_device *hid,
 		/* A non 0 contact count always indicates a first packet */
 		else if (contact_count)
 			app->num_expected = contact_count;
+		/*
+		 * contact_count == 0 on the first packet of a new frame means
+		 * all contacts have lifted (the firmware sends an explicit zero
+		 * to signal all-up rather than simply omitting the frame).
+		 * Reset num_expected so that the sync check below fires and
+		 * INPUT_MT_DROP_UNUSED releases any stale slots.  This is safe
+		 * for multi-packet continuation frames because those arrive with
+		 * num_received > 0 (at least one contact was already processed
+		 * from the preceding first-packet in the same frame).
+		 */
+		else if (app->num_received == 0)
+			app->num_expected = 0;
 	}
 	app->prev_scantime = scantime;
 
-- 
2.54.0


             reply	other threads:[~2026-05-15 17:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-15 17:52 Dave Carey [this message]
2026-05-21 13:17 ` [PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero Benjamin Tissoires
     [not found]   ` <CALPvROT0GE24qUOpjZdEd6FiSfMFVWjbwmS=9CiP7NiF+ZQGSA@mail.gmail.com>
2026-05-21 15:52     ` Benjamin Tissoires
2026-05-22 11:15 ` [PATCH 2/5] " Dave Carey
2026-06-24 19:19   ` [PATCH v2] " Dave Carey

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=20260515175253.873796-1-carvsdriver@gmail.com \
    --to=carvsdriver@gmail.com \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.