Bug 98799 - "Clickfinger" behavior interferes with normal operation when a thumb is resting on the bottom of the touchpad
Summary: "Clickfinger" behavior interferes with normal operation when a thumb is resti...
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: 1.5.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 99268
  Show dependency treegraph
 
Reported: 2016-11-21 05:00 UTC by Nate Graham
Modified: 2017-10-26 05:58 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu recording of my thumb sitting on various places on the touchpad (172.85 KB, text/plain)
2016-11-22 06:54 UTC, Nate Graham
Details
evemu recording of my thumb resting on the bottom of the pad and my fingers pointing and scrolling (241.83 KB, text/plain)
2016-11-22 06:55 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2016-11-21 05:00:47 UTC
I have an HP Spectre x360 (Kaby Lake) with a touchpad, running Fedora 25, GNOME 3.22, Wayland, and libinput 1.5.1 (release 1.fc25).

When I set the touchpad clicking behavior to "Areas", I am able to rest my thumb on the bottom edge of the pad without it interfering with touchpad operation, as described in https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html. In particular, when the thumb is resting there, I can use my index finger to move the pointer without removing my thumb.

However, when I change the click behavior to "Clickfinger" to enable two-finger right-clicking, suddenly the thumb's presence interferes with operation, and when the thumb is on the bottom of the pad, sometimes causes basic index finger cursor movement feel "stickier" and not trigger sometimes, or two-finger scrolling to be incorrectly triggered. Thumb ignoring seems to be vastly more reliable with "Areas" mode.
Comment 1 Peter Hutterer 2016-11-22 01:26:49 UTC
Please record your touchpad with evemu-record and rest your thumb on the touchpad a few times (only the thumb, no other fingers to avoid interference). Then do the same thing again with normal finger operation. That should give us an idea of how to detect the thumb.
Comment 2 Nate Graham 2016-11-22 06:53:25 UTC
Gladly! One thing that I notice from the recordings is that I get pressure values that are around 40-60 when the thumb is resting on the bottom edge, but 80-110 when the thumb is resting somewhere away from an edge. Fingers, by contrast, register as 40-60 when away from an edge. That might be a good way to detect a resting thumb.

The recordings I'm about to attach show the problem: with the thumb resting on the bottom of the pad, pointing occasionally triggers two-finger scroll behavior, and two-finger sctolling almost always does nothing (perhaps it's interpreting it as some kind of three-finger gesture?)
Comment 3 Nate Graham 2016-11-22 06:54:12 UTC
Created attachment 128133 [details]
evemu recording of my thumb sitting on various places on the touchpad
Comment 4 Nate Graham 2016-11-22 06:55:08 UTC
Created attachment 128134 [details]
evemu recording of my thumb resting on the bottom of the pad and my fingers pointing and scrolling
Comment 5 Nate Graham 2016-11-24 03:24:33 UTC
Here is a use case that illustrates the problem 100% of the time for me:

1. Move just your pointer finger horizontally along the pad.
2. While the finger is moving, put your thumb on the bottom of the pad, in the area that should be ignoring thumbs.

With "Areas" behavior, the cursor continues moving, albeit with a slight stutter the moment the thumb hits the bad (boo)

With "Clickfinger" behavior, the cursor stops moving the moment the thumb hits the pad.
Comment 6 Peter Hutterer 2016-11-25 03:44:23 UTC
(In reply to Nate Graham from comment #5)
> Here is a use case that illustrates the problem 100% of the time for me:
> 
> 1. Move just your pointer finger horizontally along the pad.
> 2. While the finger is moving, put your thumb on the bottom of the pad, in
> the area that should be ignoring thumbs.

fwiw, this work here on my T440, as long as the thumb is on the very edge/bottom of the touchpad. Run libinput-debug-events --verbose --set-click-method=clickfinger and it'll show when the thumb is detected.

Admittedly, there's a short scroll event if the thumb is put down while the other finger is moving, but it works. if the finger is held still until thumb detection kicks in. That's a separate bug we should address at some point.

(In reply to Nate Graham from comment #3)
> Created attachment 128133 [details]
> evemu recording of my thumb sitting on various places on the touchpad

I ran a touch-pressure from here https://github.com/whot/input-data-analysis/:
./touch-pressure-deltas.py ~/tmp/today/thumb.evemu | cut -d ' ' -f 1,2 | sort | uniq

The values start at 24 and top out at 102. between 40 and 98 almost every value is present. your second recording has values from 19 to 71. So there's likely some overlap between the pressure values. but I don't have the script to analyse this just yet. Note that pressure is just a function of contact surface area, so it's less at the edges because your thumb hangs off the touchpad then.

meanwhile feel free to tinker with tp_init_thumb(), there's a comment about the pressure. Your level is clearly lower, if you tweak that your thumb detection should work better too.
Comment 7 Peter Hutterer 2016-11-29 07:39:12 UTC
a script to print a 3d graph of pressure values on a touchpad recording is here:
https://github.com/whot/input-data-analysis/blob/master/touch-pressure/touch-pressure.py

run it against a long-term touchpad data recording and it should show you the various pressure values in a mesh graph. Not perfect, but good enough to recognise the interesting ranges.
Comment 8 Nate Graham 2017-01-04 14:46:52 UTC
FWIW changing the thumb detection pressure value to 70 works great for me. But this doesn't solve the true problem: https://bugs.freedesktop.org/show_bug.cgi?id=99268

We can probably close this out in favor of that, since if that solution I proposed there gets implemented, then the problem in this bug disappears.

Or the reverse. Probably don't need two bugs tracking the same thing.
Comment 9 Peter Hutterer 2017-10-26 05:58:02 UTC
Closing this because of comment #8 and bug 99268 that is closed now, please re-open if there are leftover issues.


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.