Bug 104101

Summary: Cursor does not move when starting touch from side of touchpad
Product: Wayland Reporter: Jamie Macdonald <jamie.alban>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: h, peter.hutterer
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Start touch on left side of trackpad, move finger to the right.
udevadm info /dev/input/event8
/sys/class/dmi/id/modalias
Start touch near middle of trackpad, move finger to the right.

Description Jamie Macdonald 2017-12-05 11:31:18 UTC
Created attachment 135965 [details]
Start touch on left side of trackpad, move finger to the right.

If I start a touch from either the left or the right sides of my trackpad (about a 10mm strip on either side), my cursor does not move in gnome-shell running under wayland.
Comment 1 Jamie Macdonald 2017-12-05 11:32:24 UTC
Created attachment 135966 [details]
udevadm info /dev/input/event8
Comment 2 Jamie Macdonald 2017-12-05 11:33:43 UTC
Created attachment 135967 [details]
/sys/class/dmi/id/modalias
Comment 3 Jamie Macdonald 2017-12-05 11:37:14 UTC
The physical dimensions of this trackpad are 96mmx56mm (measured by a ruler), the kernel measures it as 91mmx51mm.
Comment 4 Jamie Macdonald 2017-12-05 11:38:50 UTC
Running libinput 1.9.3 on Arch Linux with gnome-shell 3.26.2 under wayland.
Comment 5 Jamie Macdonald 2017-12-05 11:40:54 UTC
Created attachment 135968 [details]
Start touch near middle of trackpad, move finger to the right.
Comment 6 Jamie Macdonald 2017-12-05 11:43:49 UTC
When I start the touch near the center of the trackpad, the cursor moves (see attachment 135968 [details])

I notice that in the second evemu-record (the one that moves), there is an "ABS_MT_TOUCH_MAJOR" event, whereas in the first evemu-record (the problem), there is none.
Comment 7 Jamie Macdonald 2017-12-05 12:10:23 UTC
I believe the "ABS_MT_TOUCH_MAJOR" event is a red herring - was able to replicate the issue with that event reporting similar to a successful cursor move.
Comment 8 Peter Hutterer 2017-12-08 01:10:45 UTC
most likely: https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

that's a feature, not a bug, although it can appear as either :)
Comment 9 Jamie Macdonald 2017-12-08 23:04:56 UTC
aha - thanks for pointing me to that page. It does behave as that page describes...

I can indeed get the cursor to move when starting a touch in an exclusion zone if I move my finger fast enough, also as that page describes. Why is it that speed is the metric used to classify the touch as not-a-palm? 

Comparing to the way my MacBook Pro touchpad behaves on MacOS, there seems to be an equivalent "exclusion area" where the cursor will not move as you slide towards the center of the trackpad from the outside, but the cursor starts moving simply once your finger has moved far enough (i.e. once the finger is outside the exclusion area, wouldn't it make sense to start moving the cursor, regardless of the speed?)
Comment 10 Peter Hutterer 2017-12-10 22:23:15 UTC
speed is *one* metric for palm detection, but doesn't apply in this case. Here it's a simple timeout, not the movement speed itself. IOW if you move out of the area quickly enough, we assume this was a real movement. This is needed because large left<->right movements frequently start with a finger in the edge area.

Palms often move around a bit but less so than a finger, hence the timeout - if it stays within the edge for long enough we assume it's a palm.

There's room for improvement as usual, e.g. we should have a maximum motion towards the center at which we should un-palm the touch again. But no-one's found the time to work on that yet.

Also, it's always hard to compare to macos - the apple touchpads are *very* good, if I'd have to write libinput so it only works for those life would be a lot easier :)
Comment 11 Jamie Macdonald 2017-12-11 03:26:27 UTC
Out of curiosity, how long is that timeout? it seems I have to be *really* fast to get the cursor to move when I've started in the exclusion area. I feel like if the timeout were higher, I wouldn't run into this issue as much.

In your opinion, how large should such a motion be to 'un-palm' the touch which started and hung out for too long in an exclusion zone? (i.e. if someone found time to add such an enhancement :)

Finally, it seems that my left and right exclusion zones take up about 10mm on either side, so more like 10% of the touchpad which is more than what the expected behaviour on the linked page describes, no? - is this expected or configurable?

Thanks for your knowledge (:
Comment 12 Peter Hutterer 2017-12-11 03:45:28 UTC
timeout is 200ms, see tp_palm_detect_move_out_of_edge() in the source. That seems fast enough for quick swipes.

as of 1.9.1, the edges are a maximum of 8mm, provided the touchpad dimensions are correct. the theory goes that after 8mm we *should* be able to detect a palm based on other data, e.g. pressure or touch size. not that this is reliable on all touchpads yet, but one can hope.

> In your opinion, how large should such a motion be to 'un-palm' the touch which
> started and hung out for too long in an exclusion zone? (i.e. if someone found
> time to add such an enhancement :)

honestly, I don't know. It's a lot of trial and error until you eventually find something that seems to work. That's the best answer I can give you here, your guess is as good as mine.
Comment 13 Peter Hutterer 2017-12-17 23:07:18 UTC
*** Bug 104264 has been marked as a duplicate of this bug. ***
Comment 14 Peter Hutterer 2018-03-12 04:10:11 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 #12.
Comment 15 Peter Hutterer 2018-05-25 05:38:44 UTC
shrug, unchanged for 5 months, no takers for 2 months, this won't get fixed unless someone steps up to it. Closing

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.