Bug 99268 - With Clickfinger behavior, pointer movement briefly turns into a scroll when a thumb is dropped onto the pad
Summary: With Clickfinger behavior, pointer movement briefly turns into a scroll when ...
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: 1.5.0
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 91097 98799 99703
Blocks:
  Show dependency tree / graph
 
Reported: 2017-01-04 04:40 UTC by Nate Graham
Modified: 2018-06-05 09:58 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments
Clickfinger behavior: pointer movement briefly turns into a scroll when a thumb is dropped onto the pad (32.81 KB, text/plain)
2017-01-04 04:40 UTC, Nate Graham 		Details
Areas behavior: behaves as expected (83.17 KB, text/plain)
2017-01-04 04:41 UTC, Nate Graham 		Details
evemu record with git master and kernel 4.13.0 (35.41 KB, text/plain)
2017-11-16 05:40 UTC, Nate Graham 		Details
View All

Description Nate Graham 2017-01-04 04:40:59 UTC 
Created attachment 128740 [details]
Clickfinger behavior: pointer movement briefly turns into a scroll when a thumb is dropped onto the pad

Hardware: HP Spectre x360 with a Synaptics clickpad
Software: Fedora 25 + GNOME 3.22 + libinput built from git master as of today

1. With your thumb hovering over the pad, Place an index finger on the pad and start moving it
2. While it's still moving, drop your thumb on bottom part of the pad in the "ignored" area

With the "areas" behavior, this works fine and the pointer continues moving as expected even as the thumb hits the bottom of the pad and rests in one place (to click, presumably).

With the "clickfinger" behavior, as soon as the thumb hits the pad, the cursor jarringly stops moving and your finger movement is mis-interpreted as a two-finger scroll. Sometimes after half a second it seems to realize that this was a mistake, it stops scrolling and returns to pointer motion. I have attached evemu recordings that document the issue.


If resolving this issue is dependent on RMI4 support in Kernel 4.10, I have that on my machine and 4.10 is just around the corner, with 4.10-rc2 already out in the wild.
Comment 1 Nate Graham 2017-01-04 04:41:33 UTC 
Created attachment 128741 [details]
Areas behavior: behaves as expected
Comment 2 Peter Hutterer 2017-01-04 05:13:59 UTC 
Attachment 128740 [details] shows that the finger is eventually detected as thumb and that stops the scrolling and switches back to pointer motion. This is likely due to the THUMB_MOVE_TIMEOUT triggered in tp_thumb_detect().

But basically the same issue as bugs 98799 and 91097. We need an area in clickfinger mode where we ignore some pointer motion. Feel free to come up with ideas or patches on how to implement this best :)
Comment 3 Nate Graham 2017-01-04 14:44:51 UTC 
I think the solution here is to adopt the "dead zone" bottom area that the "areas" behavior already uses. Don't put any virtual buttons there; just discard any input when a second, third, or fourth touch appears in that zone. This seems to be what Apple does on their laptops (23-year Apple user here, recently switched to PC + Linux).
Comment 4 Peter Hutterer 2017-01-06 03:48:09 UTC 
Yep. The problem is someone needs to write the patch ;)

There is an additional change though: for software buttons we ignore any movement. For clickfinger that should not happen, some gestures may have to start in the area but should still trigger motion. So we can't just re-use the current software button bits and call it a day.
Comment 5 Peter Hutterer 2017-09-11 00:13:50 UTC 
Closing this because based on comment 0 bug 99703 should fix this issue. There may be more to do, but let's see how we go for now.
Comment 6 Nate Graham 2017-10-26 12:58:03 UTC 
Yup, I can confirm that this is fixed now. Thanks!
Comment 7 Nate Graham 2017-11-16 05:40:36 UTC 
Created attachment 135511 [details]
evemu record with git master and kernel 4.13.0

Correction: I was mistakenly using areas mode when I tested; clickfinger mode still has this issue, I'm afraid, as of tonight's git master and kernel 4.13.0. evemu recording attached.
Comment 8 Peter Hutterer 2017-11-16 23:51:35 UTC 
the current algorithm works: if we have a finger that exceeds the motion threshold for more than 5 events in a row, a new touch will be marked as thumb and ignored. In your recording, the new touch happens at the fourth event, i.e. another 2 events (~25ms later) and the thumb detection would've kicked in.

fixing this is nontrivial because we just don't have enough data and there are many conflicting use-cases (responsive scrolling vs palm detection vs pinch gestures vs thumb detection). Right now, I don't have a good idea on how to fix this beyond "don't drop your thumb on a touchpad if the touchpad isn't capable of detection thumbs". Which is the case here because all we have is pressure and the thumb has the same pressure levels as your moving finger.
Comment 9 Nate Graham 2017-11-16 23:55:17 UTC 
One thing that would help is if the clickfinger method shared the exclusion area at the bottom of the pad that the areas method has. Basically, if there are one or more fingers generating events anywhere above the exclusion zone, just ignore any events inside the exclusion zone.
Comment 10 Nate Graham 2017-11-16 23:59:05 UTC 
Put another way: I would use the Areas method instead if I could turn off the virtual middle and right buttons and use fingers for right and middle click. Some hybrid between the two would be ideal. I want both a bottom exclusion zone and also the ability to two-finger right-click.
Comment 11 Peter Hutterer 2017-11-17 00:29:25 UTC 
fwiw, this behaviour is what macos appears to have but I don't know how hard this would be to integrate into libinput. we'd likely have to figure out the exact behaviour we want too. It's a lot easier to argue that fingers shouldn't move when you have software buttons but that argument is harder with clickfinger because you're taking parts of the touchpad away without any visible benefit.
Comment 12 Nate Graham 2017-11-17 01:55:01 UTC 
The visible benefit is that people can lazily rest their thumb on the bobottom part of the touchpad, which is a very natural way to use it. If it has physical buttons, you rest your thumb on one of them. If it doesn't, you rest your thumb on the bottom part of the pad as if it had them.
Comment 13 Peter Hutterer 2018-03-12 04:12:23 UTC 
Help needed.

Please do not add 'me too' to this bug, we need this feature implemented (or at least ideas on what to implement). see comment #8.
Comment 14 Nate Graham 2018-03-12 04:30:14 UTC 
I think there's a pretty trivial way to resolve this: consider 70px or so strip on the bottom to be where a thumb will land, and completely disregard any touches on that strip while the pointer is moving. Basically, bring the bottom strip from Areas into Clickfinger, but only for the purpose of disregarding thumb activity.
Comment 15 GitLab Migration User 2018-06-05 09:58:13 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/5.

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.