| Summary: | With Clickfinger behavior, pointer movement briefly turns into a scroll when a thumb is dropped onto the pad | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Nate Graham <nate> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | nate, peter.hutterer |
| Version: | 1.5.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 91097, 98799, 99703 | ||
| Bug Blocks: | |||
| Attachments: |
Clickfinger behavior: pointer movement briefly turns into a scroll when a thumb is dropped onto the pad
Areas behavior: behaves as expected evemu record with git master and kernel 4.13.0 |
||
Created attachment 128741 [details]
Areas behavior: behaves as expected
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 :)
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). 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. 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. Yup, I can confirm that this is fixed now. Thanks! 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.
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. 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. 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. 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. 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. 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. 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. -- 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.
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.