Bug 99447 - Tap timeout seems too low
Summary: Tap timeout seems too low
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
: 99534 99588 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-18 11:12 UTC by Mathieu Velten
Modified: 2017-06-06 03:35 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Fast tap sample 1 (5.88 KB, text/plain)
2017-01-25 20:54 UTC, hakaa
Details
Fast tap sample 2 (5.64 KB, text/plain)
2017-01-25 20:55 UTC, hakaa
Details
Slow tap sample 1 (9.72 KB, text/plain)
2017-01-25 20:55 UTC, hakaa
Details
Slow tap sample 2 (7.76 KB, text/plain)
2017-01-25 20:56 UTC, hakaa
Details
udevadm output (640 bytes, text/plain)
2017-01-25 20:56 UTC, hakaa
Details
Full description (12.08 KB, text/plain)
2017-01-25 20:57 UTC, hakaa
Details
synaptics tapspeed plot [MM] (16.09 KB, image/png)
2017-01-27 22:45 UTC, Mantas Mikulėnas
Details
elantech tapspeed plot [MM] (17.59 KB, image/png)
2017-01-30 06:08 UTC, Mantas Mikulėnas
Details
TouchpadTapSpeed (2.09 KB, application/gzip)
2017-01-30 08:04 UTC, Ritesh Raj Sarraf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Velten 2017-01-18 11:12:58 UTC
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.
Comment 1 Mantas Mikulėnas 2017-01-23 13:30:50 UTC
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.)
Comment 2 hakaa 2017-01-25 20:54:49 UTC
Created attachment 129148 [details]
Fast tap sample 1
Comment 3 hakaa 2017-01-25 20:55:24 UTC
Created attachment 129149 [details]
Fast tap sample 2
Comment 4 hakaa 2017-01-25 20:55:51 UTC
Created attachment 129150 [details]
Slow tap sample 1
Comment 5 hakaa 2017-01-25 20:56:14 UTC
Created attachment 129151 [details]
Slow tap sample 2
Comment 6 hakaa 2017-01-25 20:56:50 UTC
Created attachment 129152 [details]
udevadm output
Comment 7 hakaa 2017-01-25 20:57:19 UTC
Created attachment 129153 [details]
Full description
Comment 8 hakaa 2017-01-25 20:59:37 UTC
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
Comment 9 hakaa 2017-01-25 21:00:52 UTC
*** Bug 99534 has been marked as a duplicate of this bug. ***
Comment 10 Peter Hutterer 2017-01-27 04:47:07 UTC
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.
Comment 11 Ritesh Raj Sarraf 2017-01-27 18:10:25 UTC
(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 ?
Comment 12 Mantas Mikulėnas 2017-01-27 22:45:29 UTC
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.
Comment 13 Peter Hutterer 2017-01-29 21:49:48 UTC
*** Bug 99588 has been marked as a duplicate of this bug. ***
Comment 14 Peter Hutterer 2017-01-30 00:38:35 UTC
(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.
Comment 15 Mantas Mikulėnas 2017-01-30 06:08:12 UTC
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.
Comment 16 Ritesh Raj Sarraf 2017-01-30 08:04:57 UTC
Created attachment 129224 [details]
TouchpadTapSpeed

Please find attached the output.
Comment 17 Peter Hutterer 2017-02-01 05:08:22 UTC
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"
Comment 18 hakaa 2017-02-01 11:24:57 UTC
(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.
Comment 19 XiaoYan Li 2017-03-01 05:46:55 UTC
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).
Comment 20 Peter Hutterer 2017-03-13 05:07:24 UTC
please record a bunch of taps with evemu-record and attach the output here, thanks.
Comment 21 Paul Johnson 2017-06-06 03:16:01 UTC
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?
Comment 22 Peter Hutterer 2017-06-06 03:35:07 UTC
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.