[PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero

[PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero

[Dave Carey]

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

Re: [PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero

[Benjamin Tissoires]

On May 15 2026, Dave Carey wrote:
> 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.

I've just tested the change, and the testsuite seem to still be happy
and I can't find a flaw in the design.
However: (inlined comment)

> 
> 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;

this succession of if/else if makes the code harder to understand,
especially with long blocks of comments.

How about this instead (wouldn't mind a second pair of eyes):

        /*
         * Includes multi-packet support where subsequent
         * packets are sent with zero contactcount.
         */
        if (contact_count > 0)
                app->num_expected = contact_count;
        else if (!contact_count && app->num_received == 0 &&  app->prev_scantime != scantime) {
                /*
                 * New multi-report frame:
                 *
                 * For Win8 PTPs the first packet (td->num_received == 0) may
                 * have a contactcount of 0 if there only is a button event.
                 *
                 * Some other devices use a sentinel frame with 0 to release all contacts
                 */
                app->num_expected = 0;
        }

At least the test-suite is happy with this change.

Cheers,
Benjamin

>  	}
>  	app->prev_scantime = scantime;
>  
> -- 
> 2.54.0
> 
> 

Re: [PATCH] HID: multitouch: Fix stale MT slots when contact count drops to zero

[Benjamin Tissoires]

On Thu, May 21, 2026 at 5:03 PM Dave Carey <carvsdriver@gmail.com> wrote:
>
> Benjamin - would you like me to make that update and test?  I don't see an immediate problem with it otherwise.

Yes, please test and send as a v2.

Cheers,
Benjamin

>
> On Thu, May 21, 2026 at 9:17 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
>>
>> On May 15 2026, Dave Carey wrote:
>> > 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.
>>
>> I've just tested the change, and the testsuite seem to still be happy
>> and I can't find a flaw in the design.
>> However: (inlined comment)
>>
>> >
>> > 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;
>>
>> this succession of if/else if makes the code harder to understand,
>> especially with long blocks of comments.
>>
>> How about this instead (wouldn't mind a second pair of eyes):
>>
>>         /*
>>          * Includes multi-packet support where subsequent
>>          * packets are sent with zero contactcount.
>>          */
>>         if (contact_count > 0)
>>                 app->num_expected = contact_count;
>>         else if (!contact_count && app->num_received == 0 &&  app->prev_scantime != scantime) {
>>                 /*
>>                  * New multi-report frame:
>>                  *
>>                  * For Win8 PTPs the first packet (td->num_received == 0) may
>>                  * have a contactcount of 0 if there only is a button event.
>>                  *
>>                  * Some other devices use a sentinel frame with 0 to release all contacts
>>                  */
>>                 app->num_expected = 0;
>>         }
>>
>> At least the test-suite is happy with this change.
>>
>> Cheers,
>> Benjamin
>>
>> >       }
>> >       app->prev_scantime = scantime;
>> >
>> > --
>> > 2.54.0
>> >
>> >

[PATCH 2/5] HID: multitouch: Fix stale MT slots when contact count drops to zero

[Dave Carey]

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>
---
v2:
- Restructured contact_count block per Benjamin Tissoires' review:
  replace three-branch if/else-if/else-if with a cleaner two-branch
  form, dropping the outer if (contact_count >= 0) wrapper
- Add prev_scantime != scantime guard to the zero-contact sentinel case

 drivers/hid/hid-multitouch.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index ec04dbafb..f1a2b3c4d5 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1321,21 +1321,18 @@ static void mt_touch_report(struct hid_device *hid,
 	 * Includes multi-packet support where subsequent
 	 * packets are sent with zero contactcount.
 	 */
-	if (contact_count >= 0) {
+	if (contact_count > 0)
+		app->num_expected = contact_count;
+	else if (app->num_received == 0 && app->prev_scantime != scantime) {
 		/*
+		 * New multi-report frame:
+		 *
 		 * For Win8 PTPs the first packet (td->num_received == 0) may
 		 * have a contactcount of 0 if there only is a button event.
-		 * We double check that this is not a continuation packet
-		 * of a possible multi-packet frame be checking that the
-		 * timestamp has changed.
+		 *
+		 * Some other devices use a sentinel frame with 0 to release all contacts
 		 */
-		if ((app->quirks & MT_QUIRK_WIN8_PTP_BUTTONS) &&
-		    app->num_received == 0 &&
-		    app->prev_scantime != scantime)
-			app->num_expected = contact_count;
-		/* A non 0 contact count always indicates a first packet */
-		else if (contact_count)
-			app->num_expected = contact_count;
+		app->num_expected = 0;
 	}
 	app->prev_scantime = scantime;

--
2.53.0