Re: Touchpad multitouch leaves ghost fingers
From: Yinon Burgansky
Date: Mon Sep 22 2025 - 12:25:54 EST
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
<yinonburgansky@xxxxxxxxx> 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 <bentiss@xxxxxxxxxx> wrote:
>>
>> 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!