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.
Created attachment 135966 [details] udevadm info /dev/input/event8
Created attachment 135967 [details] /sys/class/dmi/id/modalias
The physical dimensions of this trackpad are 96mmx56mm (measured by a ruler), the kernel measures it as 91mmx51mm.
Running libinput 1.9.3 on Arch Linux with gnome-shell 3.26.2 under wayland.
Created attachment 135968 [details] Start touch near middle of trackpad, move finger to the right.
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.
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.
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 :)
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?)
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 :)
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 (:
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.
*** Bug 104264 has been marked as a duplicate of this bug. ***
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.
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.