Hello, I am using a Synaptics touchpad (recognized as SynPS/2 Synaptics TouchPad) on a Lenovo Thinkpad W530. I am frequently experiencing the touchpad not reacting to touch while moving. I have to lift my fingers and retry to get a reaction. This happens especially often when attempting to use two-finger-scrolling. (two-finger-scrolling also often mistakenly moves the cursor instead, as if only detecting one finger, but I think that's a different issue) I suspect that the palm detection is detecting lots of false positives. Unfortunately xinput does not list any props related to palm detection for this device, so I cannot test this hypothesis. Is there anything I can do? Thanks a lot!
Create a few short evemu recordings with the various issues that you found, one issue per recording please. Attach them here (one-by-one, not a zip) and it should be easy enough to identify the issue.
Created attachment 137117 [details] one-finger pointer movement fails Thanks, Peter. Here's one recording. I am moving the mouse with one finger. During the last 5 seconds or so fo the log, the pointer refused to move twice in a row, despite me moving the finger on the touchpad.
fwiw, best way to figure out what libinput is doing is running sudo libinput-debug-events --verbose, it will show things like palm edge detection. and indeed, there are two messages in the form "palm: palm detected (edge)" in the log which likely correspond to the two you mentioned. viewing the recording in mtview matches that assumption. first thing I'd check though is whether the touchpad dimensions are correct, run the touchpad-edge-detector tool as root and attach the output here please, thanks. I wonder if the touches are detected as too close to the edge.
Created attachment 137155 [details] touchpad-edge-detector output Thanks! Output of touchpad-edge-detector is attached. The edges were mostly already correct. I can get Y ever so slightly lower by hitting the upper left corner of the touchpad tho. The size was also slightly incorrcet, I verified 76mm x 45mm with a pair of calipers. I notice that I can trigger palm detection a lot, by coming from one of the edges with a single finger. Quick movement makes it recognize it as a valid event after a a bit, but moving slowly causes it to continue to misdetect it, even when the finger moves beyond the middle. I would really prefer an option to disable palm detection altogether.
fwiw, this is intended behaviour, see the description here: https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html the 2mm difference could be fixed with the given hwdb entry, but do you notice a difference when you put it in /etc/udev/hwdb.d/99-touchpad-edges.hwdb? [1] Also, note that on your device the edges are less than 6mm wide, we do adjust the size of the edge based on the size of the touchpad. Anything smaller than that is unlikely to pick up actual palm interactions. I'm not really fond of adding configuration options for this, it makes changing things a lot harder down the track. Really what we need is something more intelligent than the current timeout-based approach. Something that uses better heuristics and detects a finger moving in from the side based on the real movement, rather than the first few hundred ms. Something I could definitely need help with. [1] see https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_hwdb_changes
I see. Tests with the 2mm difference yield no different results. I've now understood why this happens. I tend to use the uppermost portion of the touchpad a lot, as this is the most comfortable position. When I two-finger-scroll slowly (e.g. when reading text), it's often too slow to clear the timeout. In evdev-mt-touchpad.c, function tp_palm_detect_move_out_of_edge() there is const int PALM_TIMEOUT = ms2us(200), is this the relevant timeout? I also want to thank you for libinput in general. It's obvious you're investing a lot of time into supporting a lot of devices, doing so well, improving it whenever possible, writing documentation, and being very responsive to questions and bug reports. It really is a great "driver".
(In reply to main.haarp from comment #6) > In evdev-mt-touchpad.c, function tp_palm_detect_move_out_of_edge() there is > const int PALM_TIMEOUT = ms2us(200), is this the relevant timeout? yep, that's the one. that function in general is currently responsible for detecting if a finger is still a palm when it was first detected as an edge palm. now that I look at that code though: tp_palm_detect_multifinger() should disable palm detection for exactly your case - when one finger is in the edge zone and you're two-finger scrolling. why is this not working? Are both detected as palm? thanks for the compliments, it's nice to read about something other than things not working for a change ;)
(In reply to Peter Hutterer from comment #7) > now that I look at that code though: tp_palm_detect_multifinger() should > disable palm detection for exactly your case - when one finger is in the > edge zone and you're two-finger scrolling. why is this not working? Are both > detected as palm? Yes, indeed. I am getting two of these events when two-finger scrolling from the edge: event12 - palm: palm detected (edge)
I've also figured out why 2f-scrolling sometimes moves the pointer instead. It seems to be a stray thumb detection, as libinput debug-events reports: event12 - touch is speed-based thumb
how do you 2fg scroll? one finger moving on the touchpad, then the other placed down? Or do you put them down at roughly the same time? I'll need an evemu-record for that to reproduce it.
Created attachment 137500 [details] 2-finger scrolling blocked recording of two-finger-scrolling getting blocked, probably due to palm detection
Created attachment 137501 [details] recording of two-finger scrolling moving the cursor instead, likely due to false thumb-detection I've attached the two cases. Let me know if you need better recordings, although these should be pretty short. I scroll by putting both fingers down at the same time, then start moving them. btw, how do you use mtview to view recordings? It only opens devices, not logfiles (error: could not grab the device.)
(In reply to main.haarp from comment #11) > Created attachment 137500 [details] > 2-finger scrolling blocked > > recording of two-finger-scrolling getting blocked, probably due to palm > detection afaict this one doesn't trigger any palm detection here, at least not with git master, sorry. looking at the touch sequence in mtview shows nothing out of the ordinary either, you're not that close to the edge that it should trigger. But it contains a bunch of sequences and I don't know which one *should* trigger the bug, I'll need a more succinct recording please. (In reply to main.haarp from comment #12) > Created attachment 137501 [details] > recording of two-finger scrolling moving the cursor instead, likely due to > false thumb-detection > > I've attached the two cases. Let me know if you need better recordings, > although these should be pretty short. > > I scroll by putting both fingers down at the same time, then start moving > them. fwiw, in this recording I get a few non-2fg sequences in the evemu output already, these obviously can't be detected as two-finger scrolling. Is this a HW issue? The only potential libinput issue here is event19 - touch 1 is speed-based thumb which would be a bug. And I just noticed this a semi-mt device, we shouldn't do anything fancy on those because they're terrible devices. definitely not speed-based thumb detection. I filed bug 105265 for that, let's see how we go once that is fixed. > btw, how do you use mtview to view recordings? It only opens devices, not > logfiles (error: could not grab the device.) run sudo evemu-play <recording>, then mtview against the newly created device. There's no direct visualisation. There's also https://github.com/bentiss/mtdiag-qt which was built for a different need and can be useful to debug too.
Created attachment 137641 [details] recording of two-finger scrolling being blocked > afaict this one doesn't trigger any palm detection here, at least not with > git master, sorry. looking at the touch sequence in mtview shows nothing out > of the ordinary either, you're not that close to the edge that it should > trigger. But it contains a bunch of sequences and I don't know which one > *should* trigger the bug, I'll need a more succinct recording please. No problem, I've attached a new recording. In this I attempted 2f-scrolled three times. the first two attempts were blocked, the third succeeded in scrolling.
> fwiw, in this recording I get a few non-2fg sequences in the evemu output > already, these obviously can't be detected as two-finger scrolling. Is this > a HW issue? No, it's possible that I was actually intentionally moving the pointer in this recording. I'll try to focus future recordings on just the problematic movements. > The only potential libinput issue here is > event19 - touch 1 is speed-based thumb > which would be a bug. And I just noticed this a semi-mt device, we shouldn't > do anything fancy on those because they're terrible devices. definitely not > speed-based thumb detection. I filed bug 105265 for that, let's see how we > go once that is fixed. Thanks, I've recompiled with the patch in that bug, but it might take a while before I can restart X :) I don't suppose there's a way to simply "reload" libinput without restarting? On an unrelated note, this being a semi-mt device would explain that gestures are unavailable, correct?
easiest is to test with libinput debug-events first directly in the build tree, that's the quickest way to make sure something works or doesn't work. https://wayland.freedesktop.org/libinput/doc/latest/tools.html and yes - semi-mt devices don't get gestures because the MT data they provide is somewhere between unreliable and terrible, sorry.
Tests with the patch from bug 105265 reveal that speed-based thumb detection problem is resolved. No more pointer movement when I want to scroll instead :) Thank you! What remains is false-positive palm detection when slowly 2f-scrolling from the top of the touchpad.
Thank you, I've marked this as dupe for easier archiving :) *** This bug has been marked as a duplicate of bug 105265 ***
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.