Created attachment 126540 [details] evemu recording My touchpad is very sensitive to short movements. When I press and release my finger, the cursor moves. In the attached evemu recording, I press my finger then release it. The cursor moves down as my finger lifts up. A similar behavior can be produced by touching the touchpad then rolling the finger tip side to side. The cursor moves as it should, but by too much. With evdev, this barely registers a cursor movement. As a result, I have difficulty stopping on a button and tapping to click it. I usually end up off target. Is there a way to limit cursor movement for very short distances? config ------ Device 'AlpsPS/2 ALPS DualPoint TouchPad': Device Enabled (139): 1 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (290): 1 libinput Tapping Enabled Default (291): 0 libinput Tapping Drag Enabled (292): 1 libinput Tapping Drag Enabled Default (293): 1 libinput Tapping Drag Lock Enabled (294): 0 libinput Tapping Drag Lock Enabled Default (295): 0 libinput Accel Speed (273): 0.000000 libinput Accel Speed Default (274): 0.000000 libinput Natural Scrolling Enabled (278): 1 libinput Natural Scrolling Enabled Default (279): 0 libinput Send Events Modes Available (257): 1, 1 libinput Send Events Mode Enabled (258): 0, 0 libinput Send Events Mode Enabled Default (259): 0, 0 libinput Left Handed Enabled (280): 0 libinput Left Handed Enabled Default (281): 0 libinput Scroll Methods Available (282): 1, 1, 0 libinput Scroll Method Enabled (283): 1, 0, 0 libinput Scroll Method Enabled Default (284): 1, 0, 0 libinput Click Methods Available (296): 1, 1 libinput Click Method Enabled (297): 1, 0 libinput Click Method Enabled Default (298): 1, 0 libinput Disable While Typing Enabled (299): 1 libinput Disable While Typing Enabled Default (300): 1 Device Node (260): "/dev/input/event7" Device Product ID (261): 2, 8 libinput Drag Lock Buttons (289): <no items> libinput Horizonal Scroll Enabled (262): 1 laptop ------ dmi:bvnLENOVO:bvrGJET84WW(2.34):bd06/22/2015:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNotAvailable: Touchpad size ------------- 97.50x53.87mm
quite similar to bug 91097 and bug 94861. Not sure what to do here yet, the problem is that those movements cannot be distinguished from other movements, and preventing them results in a laggy/non-responsive cursor. One odd thing though: you really have a Lenovo T440s with an Alps touchpad??
Yes, it's Alps. I bought it from a Chinese seller on Ebay after getting frustrated by the T440s clickpad. The way it's working on Ubuntu now is that if the distance traveled on the touchpad is very small and the speed is low, the cursor barely moved. If this distance is covered in faster speeds, the cursor moves further. Regular movements aren't affected because my finger touches the pad and starts moving fast towards the direction I want the cursor to go. When it stops and I remove my finger, the cursor moves barely a pixel or two since its a tiny distance. I'm a developer myself and checked out the code, but I couldn't make heads or tails of it. I'd try different fixes myself if I could.
right, if it's some home-built version this means we can't put a generic quirk in for this model given that there may not be anyone else with exactly that combination. (In reply to Sebouh from comment #0) > Touchpad size > ------------- > 97.50x53.87mm did you measure this? I don't think you can get down to sub-mm range with a normal ruler and it matches what the kernel announces. The point of having the touchpad size is to know whether the kernel ranges match reality (they often don't).
You're right. Sorry about that. The measured numbers are 100x57 mm. I came about this issue when trying out Elementary Loki. I reported it and looks like other users shared the same concern. It was however marked "won't fix" since it's a libinput issue.
My understanding is that it's an original touchpad but for the Yoga series (can't remember which model). I used that windows drivers to get it to work on windows.
tested here with the touchpad size corrected, but those few mm didn't make much of a difference. there's a little hook movement at the end that seems to be the problem, but looking at the data it's effectively indistinguishable from normal pointer motion. I guess this could be fixed by increasing the hysteresis but that would result in a more sluggish pointer. please grab evemu from git [1] and re-record the bug, three separate times please. [1] Ubuntu is several releases behind and the recordings lack some of the newly added information to triage in a useful manner. http://cgit.freedesktop.org/evemu/
Created attachment 127751 [details] Evemu rec1
Created attachment 127752 [details] Emevu rec2
Created attachment 127753 [details] Evemu rec3
I attached the test files. I'm not sure if it triggered email notifications. If not, this should do it. Thanks.
record yourself putting the finger down, holding in place for about a second and then moving down. Ideally do it this way: move the pointer to somewhere on the upper part of the screen, lift your finger. Select some random thing on the bottom part of the screen roughly vertically below the pointer position. The target can be a button, just a pixel, doesn't matter. Start the recording, then put your finger down and move the cursor towards that object naturally. The position and target should be fairly far away so you trigger a fast movement down and you don't need to actually hit the target precisely, I just need the fast downward motion to compare movement vectors to the bug itself.
Comment #2 describes exactly the issue I'm having as well, and I have a Synaptics Touchpad with a Thinkpad X1 Carbon (1st Gen). I thought there would've been other settings besides just the acceleration settings as with the Synaptics driver, but that doesn't seem to be the case. Turning the acceleration down to -1.00 has the effect of tiny movements being jarring, but large, fast movements being dampened. I think the converse of this would be ideal. This also has the effect of inaccurate clicking since I use physical clicking, and pressing the touchpad down to click jumps my cursor around, moving away from click targets from time to time. I like the libinput driver since it has support for pixel-by-pixel scrolling (rather than sending "mousewheel" events which trigger lines of scroll at a time), and I really don't want to go back to the synaptics driver. Configuration ---------------- Device 'SynPS/2 Synaptics TouchPad': Device Enabled (139): 1 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (273): 0 libinput Tapping Enabled Default (274): 0 libinput Tapping Drag Enabled (275): 1 libinput Tapping Drag Enabled Default (276): 1 libinput Tapping Drag Lock Enabled (277): 0 libinput Tapping Drag Lock Enabled Default (278): 0 libinput Accel Speed (279): -1.000000 libinput Accel Speed Default (280): 0.000000 libinput Natural Scrolling Enabled (281): 0 libinput Natural Scrolling Enabled Default (282): 0 libinput Send Events Modes Available (257): 1, 1 libinput Send Events Mode Enabled (258): 0, 0 libinput Send Events Mode Enabled Default (259): 0, 0 libinput Left Handed Enabled (283): 0 libinput Left Handed Enabled Default (284): 0 libinput Scroll Methods Available (285): 1, 1, 0 libinput Scroll Method Enabled (286): 1, 0, 0 libinput Scroll Method Enabled Default (287): 1, 0, 0 libinput Click Methods Available (288): 1, 1 libinput Click Method Enabled (289): 0, 1 libinput Click Method Enabled Default (290): 1, 0 libinput Disable While Typing Enabled (291): 1 libinput Disable While Typing Enabled Default (292): 1 Device Node (260): "/dev/input/event5" Device Product ID (261): 2, 7 libinput Drag Lock Buttons (293): <no items> libinput Horizonal Scroll Enabled (262): 1
the libinput 1.7 rcs have pressure-based touch detection which may help fix that issue or at least make it less prevalent. please give them a try
Created attachment 130994 [details] evemu-twofinger-scroll-n-lift I'm using the libinput 1.7.0-1 Arch Linux package, and I still experience this problem. The worst manifestation is when I try to use two finger scrolling in Evince (AKA GNOME Document Viewer), since it has an inertia-like feature, and when I lift my fingers after doing a two finger scroll, Evince often thinks that I just quickly scrolled a certain distance and the document continues to scroll, sometimes for very long distances after I lift up my fingers from the trackpad. I've attached an evemu recording (see the last 27 lines) where I tried to pick up my fingers after two finger scrolling, and the document was scrolled a lot by Evince.
fwiw, I still haven't been able to find out how to fix this, especially since it's one of the issues that requires active reproducing (i.e. someone who experiences the bug to look at it), event recordings only get us so far
This should be a CANTFIX but that status doesn't exist. I'm closing this bug because it's unlikely to get fixed directly, there is not enough information that we can go on. It might be better as part of the pressure thresholds we merged in 1.8 but even that doesn't apply on many current devices that don't provide us with pressure. so, yeah...
How can the closed source driver do this correctly but libinput can't? Doesn't libinput get the necessary information from the driver to determine if the finger is being removed, or does the closed source driver have an algorithm to determine that? Just for the record, I have a Synaptics touchpad on a Lenovo Ideapad Z500. I read you were surprised by a model having a "rare" touchpad, and I would like to tell you that when I purchased this laptop (new, from an official seller) it came with an ELAN/Elantech touchpad; it was so bad that I sent it for repair under warranty and they (a Lenovo contractor from my country) replaced the touchpad for this Synaptics one.
Could be either, but I guess the closed source driver may have some algorithm for it. Or its parameters are generally different, so that the issue is papered over. thx for the info on the replacement, I didn't realise Lenovo sometimes replaced the touchpads with different models.
I have successfully mitigated this by adjusting the touchpad pressure values to something more appropriate following these instructions: https://wayland.freedesktop.org/libinput/doc/latest/touchpad_pressure.html
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.