I often miss clicks because of the timeout between finger down and up. It is currently using 100ms and by looking at a evemu-record trace I can see that I often go over this limit. It is especially noticable when you click without a movement before (clicking next when looking at pictures for example) : my finger seems to take a longer "click rest" in this use case. Bumping to 200ms makes it ok for me. I am using a XPS13 9360.
Can confirm. I remember the blog post said "Some users may see a drop in tap detection rate. This is hopefully a subconscious enough effect that those users learn to tap faster or with less movement"... But, well, it's very noticeable. (At first there were occassions where it'd only pick up every 3rd or 4th tap, so instinctually I kept trying to tap *harder*, but that of course doesn't help when the driver wants shorter taps... Now I'm pretending that the touchpad is lava.) That said: I did some evemu|awk to report the BTN_TOUCH duration and noticed that a very large part of my taps show up as being ~83 ms, ~93 ms, ~104 ms, ~114 ms, or [rarely] ~124 ms long. (For example, I got 114.174, 114.439, 114.010, 114.458, and 114.538 *in a row*). Could it be that the touchpad or the kernel only reports every ~10 ms, because I don't think my tapping was *that* precise? So while I haven't tested it yet, I'd probably be fine with 120 ms as the threshold. (This is Dell Inspiron 5547, with Synaptics over I2C. Haven't tested the update on my old Asus yet.)
Created attachment 129148 [details] Fast tap sample 1
Created attachment 129149 [details] Fast tap sample 2
Created attachment 129150 [details] Slow tap sample 1
Created attachment 129151 [details] Slow tap sample 2
Created attachment 129152 [details] udevadm output
Created attachment 129153 [details] Full description
After diagnosing the problem and preparing a bug report, I realised that similar bugs were already submitted (99447, 99534). However, I'll go ahead and paste/attach my finding, as it might help the developer further, here is my was-to-be bug report: [Description] Simply, when I "tap-to-click" fast enough, everything works as expected, however, when I tap slowly, it won't register as a click. See below, it seems as if libinput thinks it is a "click-and-hold". Note, the slow tap is really not that slow, say sub 200ms, also, the exact behaviour works under version 1.5.4 Attached is a recordings using evemu to reproduce the behaviour. [Command I ran] sudo libinput-debug-events --enable-tap --verbose [Simplified events] [[When the tap is missed]] tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH tap state: TAP_STATE_TOUCH → TAP_EVENT_TIMEOUT → TAP_STATE_HOLD tap state: TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE [[When the tap is registered]] tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH tap state: TAP_STATE_TOUCH → TAP_EVENT_RELEASE → TAP_STATE_TAPPED event15 POINTER_BUTTON +66.16s BTN_LEFT (272) pressed, seat count: 1 tap state: TAP_STATE_TAPPED → TAP_EVENT_TIMEOUT → TAP_STATE_IDLE event15 POINTER_BUTTON +66.39s BTN_LEFT (272) released, seat count: 0
*** Bug 99534 has been marked as a duplicate of this bug. ***
fwiw, struggling for time atm, there is a tool to measure and visualise tap sequences here: https://github.com/whot/input-data-analysis/tree/master/touchpad-tap-speed please consider running this against your measurements to get a clearer picture.
(In reply to Peter Hutterer from comment #10) > fwiw, struggling for time atm, there is a tool to measure and visualise tap > sequences here: > https://github.com/whot/input-data-analysis/tree/master/touchpad-tap-speed > > please consider running this against your measurements to get a clearer > picture. That script has an odd module named 'shared'. Can you please point the correct python module name, that provides the module ?
Created attachment 129185 [details] synaptics tapspeed plot [MM] (In reply to Peter Hutterer from comment #10) > fwiw, struggling for time atm, there is a tool to measure and visualise tap > sequences here: > https://github.com/whot/input-data-analysis/tree/master/touchpad-tap-speed > > please consider running this against your measurements to get a clearer > picture. Ran this on both of my laptops, not entirely sure how to interpret it but on the synaptics laptop it seems to match the awk results: everything seems to be concentrated around 73/83/94/104/115 ms.
*** Bug 99588 has been marked as a duplicate of this bug. ***
(In reply to Ritesh Raj Sarraf from comment #11) > That script has an odd module named 'shared'. > > Can you please point the correct python module name, that provides the > module ? it's in the same tree, look for the shared/ directory (In reply to Mantas Mikulėnas from comment #12) > Ran this on both of my laptops, not entirely sure how to interpret it but on > the synaptics laptop it seems to match the awk results: everything seems to > be concentrated around 73/83/94/104/115 ms. the points are the tap times grouped by ms, so in your case you have e.g. 9 taps counted at (what I think is) 60ms. the vert lines are the mean, 50 percentile, 90 and 95 percentile. So 90% of your taps come in at 104ms which is above the current limit of 100ms. That would mean that you have a bit over 10% detection failure. Instead of downgrading, try to revert d0ba1e2b383acaac and see how you go with that.
Created attachment 129222 [details] elantech tapspeed plot [MM] (In reply to Peter Hutterer from comment #14) > (In reply to Mantas Mikulėnas from comment #12) > > Ran this on both of my laptops, not entirely sure how to interpret it but on > > the synaptics laptop it seems to match the awk results: everything seems to > > be concentrated around 73/83/94/104/115 ms. > > the points are the tap times grouped by ms, so in your case you have e.g. 9 > taps counted at (what I think is) 60ms. the vert lines are the mean, 50 > percentile, 90 and 95 percentile. So 90% of your taps come in at 104ms which > is above the current limit of 100ms. That would mean that you have a bit > over 10% detection failure. Right, and this might be caused by hardware (similar to that other bug report by an XPS user) – for comparison, on my other laptop (with an old Elantech touchpad) the 95% line is around ~70ms and everything is much more evenly spread out.
Created attachment 129224 [details] TouchpadTapSpeed Please find attached the output.
recorded myself as well to add some data sets. From the above, the 95 percentile is 124, 72, 140 and 107. Last one is mine. From Ritesh' data set at least I can gather that the reduction of the motion threshold (e80873ca6fa) isn't a problem. Increasing that timeout or reverting it seems thus sensible enough. But the data also points to 50% of the taps higher than the current 100ms threshold. So no wonder it doesn't work. I'm going to revert this one for now until we find a better solution. commit e86fdd588315ab13f44d2575c12bc167a9947173 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Feb 1 14:48:11 2017 +1000 Revert "touchpad: reduce the initial timeout for tapping after touch"
(In reply to Peter Hutterer from comment #17) > recorded myself as well to add some data sets. From the above, the 95 > percentile is 124, 72, 140 and 107. Last one is mine. > > From Ritesh' data set at least I can gather that the reduction of the motion > threshold (e80873ca6fa) isn't a problem. Increasing that timeout or > reverting it seems thus sensible enough. But the data also points to 50% of > the taps higher than the current 100ms threshold. So no wonder it doesn't > work. > > I'm going to revert this one for now until we find a better solution. > > commit e86fdd588315ab13f44d2575c12bc167a9947173 > Author: Peter Hutterer <peter.hutterer@who-t.net> > Date: Wed Feb 1 14:48:11 2017 +1000 > > Revert "touchpad: reduce the initial timeout for tapping after touch" Thanks Pete, Only if you can push a point release ASAP, as I and others probably encountered this issue by using Arch or other cutting edge distro. Once Ubuntu and the likes (main stream disro) pick it up, it'll effect a large number of average users. Regards.
It's still not working well on my XPS, but both libinput 1.5 and libinput-hith in AUR (https://aur.archlinux.org/packages/libinput-hith/) works fine for me. Seems libinput-hith also revert another commit which changed DEFAULT_TAP_MOVE_THRESHOLD from 3 to 1.3 (https://bugs.freedesktop.org/show_bug.cgi?id=98844).
please record a bunch of taps with evemu-record and attach the output here, thanks.
This is marked as fixed, but where? Which version?. I see it now in Ubuntu 17.04 with libinput 1.6.3. Tap to click events are often ignored if they follow a touchpad cursor movement. This is mostly noticable when using a web browser, to move cursor to hit a button. If you don't move "just so" (I still can't tell exactly what it wants), the tap has no effect. If I tap a few more times, it gets recognized. Do I have same problem described here? Which version has the correction that fixes this?
Paul: the patch that introduced the issue was reverted 1.6.1, see comment 17. Please file a new issue, you could be affected by e80873ca6fad5aa
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.