Re: Touchpad multitouch leaves ghost fingers

Hi Benjamin,

Thank you for the quick and detailed response. The solution sounds
great! It will take me some time to learn how to code, build, and
compile HID-BPF on my machine and figure it out. If you can provide me
with additional guidance to speed up the process, I would greatly
appreciate it!

If it is a common issue, as you suggested, having public instructions
to refer to would also be very helpful for others running into the
same issue (e.g. the other 2 users from the libinput issue).

Thanks,
Yinon

On Mon, Sep 22, 2025 at 7:11 PM Yinon Burgansky
[off-list ref] wrote:

Hi Benjamin,

Thank you for the quick and detailed response. The solution sounds great! It will take me some time to learn how to code, build, and compile HID-BPF on my machine and figure it out. If you can provide me with additional guidance to speed up the process, I would greatly appreciate it!

If it is a common issue, as you suggested, having instructions to refer to would also be very helpful for others running into the same issue (e.g. the other 2 users from the libinput issue).

Thanks,
Yinon


On Mon, Sep 22, 2025 at 4:32 PM Benjamin Tissoires [off-list ref] wrote:

quoted

Hi,

On Sep 21 2025, Yinon Burgansky wrote:

quoted

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

quoted

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!