[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3plpgl2zsx4do2odwdeowodkkdnfqpexlwqg5a5mckyibxlge@qai35f5yeswy>
Date: Mon, 22 Sep 2025 18:51:13 +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
On Sep 22 2025, Yinon Burgansky 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!
Well, I was meaning that I would provide a HID-BPF MR ready to install
for you. But if you want to play with it, feel free to do so :)
For a jump start on HID-BPF:
https://libevdev.pages.freedesktop.org/udev-hid-bpf/tutorial.html
The advantage of HID-BPF is that we can drop the file in the filesystem
and then forget about 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).
Yeah, once we get the MR out, we need to update the libinput bug.
My plan is to have the HID-BPF detect whether the quirk has been applied
or not and would gracefully remove itself once the kernel is fixed.
Cheers,
Benjamin
PS: please try to refrain from top-posting your reply. The usage is to
inline your reply or reply below, and there are docs that explain why.
You might get angry answers from people on the LKML if you top post :/
>
> Thanks,
> Yinon
>
> On Mon, Sep 22, 2025 at 7:11 PM Yinon Burgansky
> <yinonburgansky@...il.com> 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@...nel.org> 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!
Powered by blists - more mailing lists