| Summary: | three-finger tap on touchpad interpreted twice | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Sever Oraz <severoraz> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu-record output wherein the behaviour is possibly captured
libinput-debug-events-20171124-01 dmesg 2017-11-29 dmesg 2017-11-30 |
||
|
Description
Sever Oraz
2017-11-17 16:59:44 UTC
best to run sudo libinput-debug-events --enable-tap to verify that the problem is on the libinput side. If you see the right button events float past but the browser still misbehaves it's somewhere higher up the stack. If the issue is at the libinput side, then I'll need an evemu-record from such a broken sequence Created attachment 135677 [details]
evemu-record output wherein the behaviour is possibly captured
Hi, here is the evemu-record output. If I am not mistaken, the three-finger clicks (tripletaps in the log) in lines 397 and 446 are only 100 ms apart (which I certainly didn't attempt, and wouldn't be such an easy feat to accomplish anyway).
not quite, the delta time that counts is the one from the EV_SYN after the event. So you have a tripletap at 1.012535, downgraded to double tap at 1.075461 (~63ms later) with a full release 17ms later (i.e. the next hardware event). That's a common sequence when releasing fingers. Then, 568ms later there is another tripletap at 1.660299. So at least for this sequence it's indistinguishable from a real 3-finger tap done twice. And that's the sequence coming from the hardware. Created attachment 135702 [details]
libinput-debug-events-20171124-01
Well, then where could the problem lie? If it is not in libinput, why do the double triple-taps appear in the libinput-debug-event log?
sorry, I wasn't clear enough. What I meant in comment 3 was that the hardware itself sends a duplicate triple-tap. libinput interprets it correctly. Because of the long time between the taps (568ms) we cannot easily detect this as a ghost touch because 500ms is a normal time between two triple taps. This is a HW problem. Thanks for clearing that up! Well so if the problem is not in libinput, where could it be? Drivers? Or is there some layer in between? Most likely: firmware of hardware. It's unlikely that it's a kernel issue unless this has only recently started appearing after a kernel update. I can't remember a kernel bug being filed for a triple-tap appearing twice but I'm CC-ing Benjamin in case he's aware of one. Yeah, I don't recall of anything similar. You might have a RMI4 touchpad over SNBus, and the issue might be solved by switching to RMI4. Could you upload your dmesg from the boot so I can have a look and tell you if there is some hope? Created attachment 135813 [details]
dmesg 2017-11-29
Gladly, thanks for helping!
I guess it would make sense for it to be non-faulty hardware because I've had this computer for about a year and neither do I give my touchpad a hardtime (pretty much the opposite) nor had I seen this issue before. I hope it is something else anyway. Try setting psmouse.synaptics_intertouch=1 at boot and see if the problem goes away. That switches the touchpad to RMI4. Created attachment 135835 [details]
dmesg 2017-11-30
I did, but unfortunately it seems as though the behaviour is still present. It seems also from dmesg that SMBus did try to get a handle of the touchpad. How can I verify whether RMI4 mode has been successfully set?
[ 10.924539] psmouse serio1: synaptics: SMbus companion is not ready yet looks like RMI4 doesn't activate here |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.