linux-kernel - Re: Touchpad multitouch leaves ghost fingers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bjtev7sgmcafoysd53xrxih4nawn2dbq4odylwdglbub6td2a3@nhoxenprhjvy>
Date: Mon, 22 Sep 2025 15:32:40 +0200
From: Benjamin Tissoires <bentiss@...nel.org>
To: Yinon Burgansky <yinonburgansky@...il.com>
Cc: jikos@...nel.org, linux-input@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: Touchpad multitouch leaves ghost fingers

Hi,

On Sep 21 2025, Yinon Burgansky wrote:
> When using the touchpad with multi-finger gestures, ghost fingers sometimes
> remain.
> This is reproducible with `hid-replay hid-recorded.txt`: after the
> recording, two ghost fingers remain on the touchpad,
> so a subsequent single-finger tap is interpreted as a triple tap.
> Tapping with three or four fingers resets the device state.
> 
> I compared `hid-recorded.txt` to `evtest.txt` for the same events and it
> appears the problem occurs when the device sends a single HID report that
> changes the contact count from 3 -> 1,
> while the kernel's evdev stream removes only one contact (3 -> 2) instead
> of clearing the two removed contacts.
> The following are the exact events where the issue first appeared:
> 
> hid recorder:
> 
> ```
> # ReportID: 3 / Confidence: 1 | Tip Switch: 1 | Contact Id: 0 | # | X: 792
> | Y: 378
> # | Confidence: 1 | Tip Switch: 1 | Contact Id: 1 | # | X: 564 | Y: 403
> # | Confidence: 1 | Tip Switch: 1 | Contact Id: 2 | # | X: 383 | Y: 542
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0 | Scan
> Time: 43407 | Contact Count: 3 | Button: 0 | #
> E: 000085.948315 30 03 03 18 03 7a 01 07 34 02 93 01 0b 7f 01 1e 02 00 00
> 00 00 00 00 00 00 00 00 8f a9 03 00
> # ReportID: 3 / Confidence: 1 | Tip Switch: 0 | Contact Id: 1 | # | X: 564
> | Y: 406
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0
> # | Confidence: 0 | Tip Switch: 0 | Contact Id: 0 | # | X: 0 | Y: 0 | Scan
> Time: 43615 | Contact Count: 1 | Button: 0 | #
> E: 000085.960958 30 03 05 34 02 96 01 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 5f aa 01 00
> ```

Actually, this doesn't seem to be 3->1 but 3 ->0:
- first report has all 3 touches with "Tip Switch: 1" -> 3 touches
- second report has only one report of a touch with "Tip Switch: 0", so
	the kernel thinks only Contact Id 1 has been released.

What we are missing here is a common defect in some touchpad: "not seen
means up". And so we need the multitouch class
`MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU`.

And following the libinput report, it seems you already found this
yourself :)

Unfortunatelly, because your touchpad is an integrated one using I2C, we
can not dynamically assign this quirk at boot so testing will require
you to recompile the hid-multitouch module or inserting a HID-BPF
module.

I would lean toward providing a small HID-BPF program while the kernel
is being fixed as this will be a much quicker way of fixing it for you
(but the kernel will still need to be fixed).

How does that sound?

Cheers,
Benjamin

> 
> evtest:
> 
> ```
> Event: time 1758384424.367216, -------------- SYN_REPORT ------------
> Event: time 1758384424.380922, type 3 (EV_ABS), code 47 (ABS_MT_SLOT),
> value 0
> Event: time 1758384424.380922, type 3 (EV_ABS), code 54
> (ABS_MT_POSITION_Y), value 378
> Event: time 1758384424.380922, type 3 (EV_ABS), code 47 (ABS_MT_SLOT),
> value 1
> Event: time 1758384424.380922, type 3 (EV_ABS), code 53
> (ABS_MT_POSITION_X), value 564
> Event: time 1758384424.380922, type 3 (EV_ABS), code 54
> (ABS_MT_POSITION_Y), value 403
> Event: time 1758384424.380922, type 3 (EV_ABS), code 47 (ABS_MT_SLOT),
> value 2
> Event: time 1758384424.380922, type 3 (EV_ABS), code 53
> (ABS_MT_POSITION_X), value 383
> Event: time 1758384424.380922, type 3 (EV_ABS), code 54
> (ABS_MT_POSITION_Y), value 542
> Event: time 1758384424.380922, type 3 (EV_ABS), code 1 (ABS_Y), value 378
> Event: time 1758384424.380922, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP),
> value 547800
> Event: time 1758384424.380922, -------------- SYN_REPORT ------------
> Event: time 1758384424.393487, type 3 (EV_ABS), code 47 (ABS_MT_SLOT),
> value 1
> Event: time 1758384424.393487, type 3 (EV_ABS), code 57
> (ABS_MT_TRACKING_ID), value -1
> Event: time 1758384424.393487, type 1 (EV_KEY), code 333
> (BTN_TOOL_DOUBLETAP), value 1
> Event: time 1758384424.393487, type 1 (EV_KEY), code 334
> (BTN_TOOL_TRIPLETAP), value 0
> Event: time 1758384424.393487, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP),
> value 568600
> ```
> 
> This is an old issue (at least a year old) that I still encounter
> occasionally. I originally reported it downstream:
> https://gitlab.freedesktop.org/libinput/libinput/-/issues/1194
> 
> ```
> uname -a
> Linux fedora 6.16.7-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 11
> 17:46:54 UTC 2025 x86_64 GNU/Linux
> ```
> 
> Please let me know if you need anything else,
> Thank you!