Bug 81278 - Click and drag behavior is incorrect on synaptics clickpad
Summary: Click and drag behavior is incorrect on synaptics clickpad
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-13 01:38 UTC by Andrew Morsillo
Modified: 2017-02-03 03:57 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log (1.03 MB, text/plain)
2014-07-13 01:38 UTC, Andrew Morsillo
no flags Details
evemu-describe (3.34 KB, text/plain)
2014-07-22 15:34 UTC, Andrew Morsillo
no flags Details
evemu-record of cursor jumping when lifting a finger during click drag (100.50 KB, text/plain)
2014-07-22 15:35 UTC, Andrew Morsillo
no flags Details

Description Andrew Morsillo 2014-07-13 01:38:42 UTC
Created attachment 102684 [details]
xorg log

On a Dell Inspiron 15 7000 series laptop with clickpad. Clicking and dragging is almost impossible because as soon as the dragging finger is lifted the cursor jumps a long distance toward the location of the clicking finger. This usually results in any attempt to click and drag jumping to the bottom left corner of the screen.

As a workaround I tried to set AreaBottomEdge to ignore the area in which I usually click. This workaround fails because AreaBottomEdge does not ignore input in the following two cases:

1) When a finger is dragged from outside of the excluded area into the excluded area the movement doesn't always stop (sometimes it just slows, sometimes it stops after some activity in the excluded area)
2) And more importantly when clicking to drag as soon as the dragging finger touches the pad then input events are sent from the clicking finger even if it is within the zone excluded by AreaBottomEdge.

So it seems to me that there are two incorrect behaviors here. First is that AreaBottomEdge does not exclude movement input in all cases. The second is that click and drag behavior does not keep movement from different points on the pad mapped to the location of the dragging cursor. For example the behavior of the Windows driver is two allow both the clicking and the dragging finger to move the pointer but the pointer never "jumps" regardless of which finger is lifted off of the pad during a drag.
Comment 1 Peter Hutterer 2014-07-22 02:14:03 UTC
please record an event sequence like this with evemu-record and attach it here.
http://www.freedesktop.org/wiki/Evemu

Try to keep the recording as short as reasonable, and constrained to just the bug you're triggering so it's easier to reproduce and debug. Thanks.
Comment 2 Andrew Morsillo 2014-07-22 15:34:25 UTC
Created attachment 103287 [details]
evemu-describe
Comment 3 Andrew Morsillo 2014-07-22 15:35:34 UTC
Created attachment 103288 [details]
evemu-record of cursor jumping when lifting a finger during click drag

Attached evemu-describe and evemu-record of the cursor jumping when lifting a finger off of the pad during a click and drag.
Comment 4 Andrew Morsillo 2014-10-23 23:30:50 UTC
Is there anything else I can do to help move this bug along?
Comment 5 Peter Hutterer 2014-10-29 21:24:40 UTC
This looks to be a HW issue. At E: 1.57652 (line 934), the touch in slot 0 jumps from 2551/2316 to 1677/4527. BTN_TOOL_DOUBLETAP is set, and in the next frame the touch in slot 1 continues from where slot 0 was previously. That causes the jump.

We can't meaningfully work around this, though commit 41b2312c006fca1f24e1a366174d3203a63fa04a goes somewhere towards helping with that.

Benjamin is working on fixing the kernel for this, CC-ing him. This is also effectively a duplicate of 76722, but until the kernel fix is in place I'll leave both open.
Comment 6 Peter Hutterer 2017-02-03 03:57:07 UTC
iirc the kernel fix for this was pushed a while ago and we have pointer jump detection in synaptics and libinput now.


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.