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

[Benjamin Tissoires <bentiss@kernel.org>]

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