Bug 94773 - Cursor jumps when clicking while moving
Summary: Cursor jumps when clicking while moving
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: 7.7 (2012.06)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact:
Depends on:
Reported: 2016-04-01 03:27 UTC by Mike C. Fletcher
Modified: 2018-08-10 20:59 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

evemu-record trace of a jump occuring (gzipped) (21.22 KB, application/octet-stream)
2016-04-01 04:03 UTC, Mike C. Fletcher
no flags Details
evemu-record trace of a jump occuring with libinput (gzipped) (22.01 KB, application/x-gzip)
2016-04-04 14:29 UTC, Mike C. Fletcher
no flags Details
0001-hwdb-add-touchpad-resolutions-for-the-Dell-XPS-15-95.patch (994 bytes, patch)
2016-04-14 02:59 UTC, Peter Hutterer
no flags Details | Splinter Review
0001-hwdb-add-touchpad-resolutions-for-the-Dell-XPS-15-95.patch (990 bytes, patch)
2016-04-17 22:11 UTC, Peter Hutterer
no flags Details | Splinter Review
xinput list-props output (1.31 KB, text/plain)
2016-04-18 04:33 UTC, Mike C. Fletcher
no flags Details
Fresh libinput capture of the jump (16.54 KB, application/x-gzip)
2016-04-20 03:24 UTC, Mike C. Fletcher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike C. Fletcher 2016-04-01 03:27:25 UTC
This is running on a Kubuntu 15.10 (using the Neon packages for KDE) with kernel 4.2.0-34-generic and synaptics driver version 1.8.2-1ubuntu1 and xorg version 1:7.7+7ubuntu4 .

This appears to at least be related to #87788, though with different hardware running on a very up-to-date machine (that report is from 2014). This is seen on a Dell XPS 15 9550 (early 2016 model with a fully multi-touch-capable touchpad) with the following reported in dmesg during boot:

[    2.277771] psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
[    2.322865] psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
[    2.412838] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf00123/0x840300/0x12e800/0x0, board id: 3125
, fw id: 1961136
[    2.469331] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6

the issue occurs in the following case:

* move cursor with one finger in the trackpad area (to target a control)
* while moving, rest another finger in the "click button" area at the bottom of the touchpad (preparing to click)
* lift the "moving" finger while clicking the button-area finger

It can also be produced with left-to-right and bottom to top offsets by rapidly switching between fingers used to move (i.e. separate fingers and "rock" between them), but obviously the "click with the mouse button" case is the most common (and frustrating) case. That is, it is possible to have the touchpad register a "jump" without clicking in the "button" area, and the jump can occur in any direction, not just down.

This seems like it could be largely mitigated by looking for a jump of greater than a human would possibly be able to move on the trackpad in a given period of time and resetting the "last position" to current position, or better, issuing a mouse-up-mouse-down sequence for previous and current positions.

While it might still occur in the rare cases where the user was moving at the extreme bottom of the touchpad area, the jump would be far smaller (the jump is generally going all the way to the bottom of the screen in a single step and registering the clicks on the task-bar instead of the control targeted in client windows).

The evemu-record log of a jump looks like this, with the jump happening at 7.674717.

E: 7.635071 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.647477 0003 0036 2637      # EV_ABS / ABS_MT_POSITION_Y    2637
E: 7.647477 0003 003a 0053      # EV_ABS / ABS_MT_PRESSURE      53
E: 7.647477 0003 0001 2637      # EV_ABS / ABS_Y                2637
E: 7.647477 0003 0018 0053      # EV_ABS / ABS_PRESSURE         53
E: 7.647477 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.659907 0003 0035 3289      # EV_ABS / ABS_MT_POSITION_X    3289
E: 7.659907 0003 0036 2639      # EV_ABS / ABS_MT_POSITION_Y    2639
E: 7.659907 0003 003a 0051      # EV_ABS / ABS_MT_PRESSURE      51
E: 7.659907 0003 0000 3289      # EV_ABS / ABS_X                3289
E: 7.659907 0003 0001 2639      # EV_ABS / ABS_Y                2639
E: 7.659907 0003 0018 0051      # EV_ABS / ABS_PRESSURE         51
E: 7.659907 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.674717 0003 0036 2643      # EV_ABS / ABS_MT_POSITION_Y    2643
E: 7.674717 0003 003a 0043      # EV_ABS / ABS_MT_PRESSURE      43
E: 7.674717 0003 0001 2643      # EV_ABS / ABS_Y                2643
E: 7.674717 0003 0018 0043      # EV_ABS / ABS_PRESSURE         43
E: 7.674717 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.694278 0003 0035 2367      # EV_ABS / ABS_MT_POSITION_X    2367
E: 7.694278 0003 0036 4568      # EV_ABS / ABS_MT_POSITION_Y    4568
E: 7.694278 0003 003a 0025      # EV_ABS / ABS_MT_PRESSURE      25
E: 7.694278 0003 0000 2367      # EV_ABS / ABS_X                2367
E: 7.694278 0003 0001 4568      # EV_ABS / ABS_Y                4568
E: 7.694278 0003 0018 0025      # EV_ABS / ABS_PRESSURE         25
E: 7.694278 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.707251 0003 003a 0050      # EV_ABS / ABS_MT_PRESSURE      50
E: 7.707251 0003 0018 0050      # EV_ABS / ABS_PRESSURE         50
E: 7.707251 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 7.719144 0003 0035 2375      # EV_ABS / ABS_MT_POSITION_X    2375
E: 7.719144 0003 0036 4516      # EV_ABS / ABS_MT_POSITION_Y    4516
E: 7.719144 0003 003a 0057      # EV_ABS / ABS_MT_PRESSURE      57
Comment 1 Peter Hutterer 2016-04-01 03:37:21 UTC
Please attach a (short) recording of the jump, not just the excerpt. easier to debug when I can replay it locally, thanks.
Comment 2 Mike C. Fletcher 2016-04-01 04:03:49 UTC
Created attachment 122652 [details]
evemu-record trace of a jump occuring (gzipped)

Trace of the jump occurring.
Comment 3 Peter Hutterer 2016-04-04 03:03:32 UTC
huh, just saw this was filed against synaptics. any chance you can try this with libinput? Not a lot of effort goes into synaptics these days.
Comment 4 Mike C. Fletcher 2016-04-04 03:20:20 UTC
I can try to get libinput installed/configured under KDE. May be a few days, as I need the machine working to complete some projects this week.
Comment 5 Peter Hutterer 2016-04-04 03:24:23 UTC
under fedora simply installing xorg-x11-drv-libinput and rebooting is sufficient (and then removing it again). ubuntu has a similar name and setup but I can't remember the exact name right now.
Comment 6 Mike C. Fletcher 2016-04-04 14:29:24 UTC
Created attachment 122703 [details]
evemu-record trace of a jump occuring with libinput (gzipped)
Comment 7 Peter Hutterer 2016-04-06 04:57:38 UTC
I replayed this here and there are no jumps under libinput. So I think it'll be easier for everyone involved if you can test and switch to libinput :)
fixing things in synaptics is quite painful these days.

I'm surprised that your touchpad doesn't have resolutions though. what kernel version are you on, what's the output of cat /sys/class/dmi/id/modalias and what are the physical dimensions of your touchpad in mm? run the touchpad-edge-detector provided by libevdev so we can fix the hw descriptions if necessary, I'm pretty sure it's needed.
Comment 8 Mike C. Fletcher 2016-04-13 17:34:10 UTC
Hmm, to be clear, that last trace *is* from libinput, and it most definitely is jumping on the screen. At least, I'm pretty sure it is using libinput, as under KDE the trackpad control module shows a different set of configuration options than it did with Synaptics.



4.2.0-34-generic (Kubuntu 15.10 with KDE Neon)

Output from touchpad-edge-detector

Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event7
Move one finger around the touchpad to detect the actual edges
Kernel says:    x [1278..5664], y [1206..4646]
Touchpad sends: x [1278..5665], y [1209..4650]

This has been sitting for days waiting for me to get a ruler to measure it, which never happens while I'm using the laptop... I'll try to get that done ASAP.
Comment 9 Peter Hutterer 2016-04-13 23:30:59 UTC
(In reply to Mike C. Fletcher from comment #8)
> Hmm, to be clear, that last trace *is* from libinput, and it most definitely
> is jumping on the screen. At least, I'm pretty sure it is using libinput, as
> under KDE the trackpad control module shows a different set of configuration
> options than it did with Synaptics.

easiest way to check is run xinput list-props <device name> and check if the property names are prefixed with libinput. 

also note that the trace itself is independent of libinput itself, evemu records kernel events - the same events libinput would otherwise see and process which makes it possible to replay quite easily.
Comment 10 Mike C. Fletcher 2016-04-14 01:16:12 UTC
Okay, so definitely running on libinput from the output of xinput.  Dimensions are 105 x 80 mm (10.5 x 8.0 cm).
Comment 11 Peter Hutterer 2016-04-14 02:59:58 UTC
Created attachment 122910 [details] [review]

Try this one here. It patches the udev hwdb file that fixes up devices, the top of the file has instructions on how to test this locally. Once applied, run sudo udevadm hwdb --update, reboot and check that the device now has a resolution set (with evemu-describe). Then see if it makes any difference :)
Comment 12 Mike C. Fletcher 2016-04-15 14:39:08 UTC
No difference with the patch applied... evemu-describe doesn't *seem* to have picked up the resolutions:

#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value   3075
#       Min     1278
#       Max     5664
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 1 (ABS_Y)
#       Value   4328
#       Min     1206
#       Max     4646
#       Fuzz       0
#       Flat       0
#       Resolution 0

which is where I would have expected to see the resolution show up. Note that I had to patch:


on Ubuntu, so it's *possible* that I'm modifying a different file than the one that will actually be compiled by:

  udevadm hwdb --update

I don't see any obvious indication that the device is matching with udevadm test, but I'm not familiar enough with it to be able to tell if that's because I've screwed up the install or the hwdb rules just aren't matching.
Comment 13 Peter Hutterer 2016-04-17 22:11:55 UTC
Created attachment 123018 [details] [review]

modifying that file is fine, but it'll be overwritten by an update. popping it into /etc/udev/hwdb.d/ means it'll stay around.

I think I found the issue, typo, a duplicate "dmi:dmi:...", try this one here please
Comment 14 Mike C. Fletcher 2016-04-18 01:51:06 UTC
Yay, that gets the resolutions set on the ABS_X and ABS_Y events.

Unfortunately, no effect on the jumping of the cursor.
Comment 15 Peter Hutterer 2016-04-18 04:23:57 UTC
what's the output of xinput list-props <device name>? do you have any configuration options different to the default? when I replayed your recording I didn't get any jumps with libinput
Comment 16 Mike C. Fletcher 2016-04-18 04:33:05 UTC
Created attachment 123019 [details]
xinput list-props output

Here's the output of xinput list-props. There are likely lots of non-default settings, as the trackpad is somewhat unusable without tweaking in KDE's trackpad module (mostly for drag distance and click pressure/duration IIRC).
Comment 17 Peter Hutterer 2016-04-18 05:02:49 UTC
nope, those are all the defaults afaict. click pressure/duration is not something libinput handles, likewise with drag distance.

I replayed the recording again and still can't see a jump (that's libinput master). To figure out what's happening I'll need a recording that reproduces the jump, so please do the following: evemu-record as before, then 
sudo evemu-play /dev/input/eventX < the-recording-file" against the device node.
When you have one that jumped, please attach it here, thanks.
Comment 18 Mike C. Fletcher 2016-04-20 03:24:51 UTC
Created attachment 123082 [details]
Fresh libinput capture of the jump

Okay, so both of the files above produce jumps when played back with evemu-play. The libinput one produces a jump from around the top of the screen all the way down to the bottom of the stream. I'm attaching another one recorded just now, again, it records a jump, and on playback the cursor is seen jumping from near the top of the screen down to the bottom of the screen.

Could there be an issue with the resolution of the screen making it hard to see the effect? The recording is done on a machine with a 3840x2160 screen, and the jump is unmistakable here, particularly in the playback just recorded, where the jump occurs, and then the mouse simply moves back up to the window, clicks and the recording stops. (Timecode is 4.609241 in the file, jumps from 1922 to 4415 in ~26ms).
Comment 19 Peter Hutterer 2016-04-26 05:40:57 UTC
E: 4.595985 0000 0000 0000      # ------------ SYN_REPORT (0) ----------                                               
E: 4.609241 0003 0035 3634      # EV_ABS / ABS_MT_POSITION_X    3634                                                   
E: 4.609241 0003 0036 1922      # EV_ABS / ABS_MT_POSITION_Y    1922                                                   
E: 4.609241 0003 003a 0048      # EV_ABS / ABS_MT_PRESSURE      48
E: 4.609241 0003 0000 3634      # EV_ABS / ABS_X                3634                                                   
E: 4.609241 0003 0001 1922      # EV_ABS / ABS_Y                1922                                                   
E: 4.609241 0003 0018 0048      # EV_ABS / ABS_PRESSURE         48
E: 4.609241 0000 0000 0000      # ------------ SYN_REPORT (0) ----------                                               
E: 4.635553 0003 0035 2601      # EV_ABS / ABS_MT_POSITION_X    2601                                                   
E: 4.635553 0003 0036 4415      # EV_ABS / ABS_MT_POSITION_Y    4415                                                   
E: 4.635553 0003 003a 0061      # EV_ABS / ABS_MT_PRESSURE      61
E: 4.635553 0003 0000 2601      # EV_ABS / ABS_X                2601                                                   
E: 4.635553 0003 0001 4415      # EV_ABS / ABS_Y                4415                                                   
E: 4.635553 0003 0018 0061      # EV_ABS / ABS_PRESSURE         61
E: 4.635553 0000 0000 0000      # ------------ SYN_REPORT (0) ----------   

Yep, this is a kernel issue. Please try a newer kernel, iirc we put something in place in 4.4 for that.
Comment 20 Mike C. Fletcher 2016-04-26 13:01:37 UTC
Same jumping seen from ememu-play and in real world on Kernel 4.4.0-21 (Ubuntu 16.04 current kernel).

Resolution is still picked up for the trackpad. Input is still via libinput (confirmed via xinput).
Comment 21 Mike C. Fletcher 2016-04-26 14:05:57 UTC
From further testing, it seems that the changes in 4.4 work to just ignore the secondary events in some cases?

So, for instance, where before we'd get a jump when clicking with the second finger, now the click just doesn't seem to register sometimes? At least, since the upgrade I'm seeing occasional missed clicks, particularly in that "one finger moving the cursor, other clicking" configuration.

To be clear, we still see the "go to click and the cursor jumps down" events, it's just we sometimes also see the "ignore the input entirely" effect.

Am I right in thinking that what's happening is that the interface can't detect/track multiple-touches, so we're trying to apply heuristics to guess whether we're seeing single or multiple touches? I think a modern Synaptics should support tracking at least two simultaneous touches in the hardware.

There's more going wrong (sometimes it appears that clicks are being interpreted as something weird (maybe triple-clicks? maybe click-and-move?) so that e.g. clicking on a chromium browser tab will close it rather than switch to it. Haven't been able to isolate precisely what's going wrong there yet. Will update when I do.
Comment 22 GitLab Migration User 2018-08-10 20:59:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics/issues/3.

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.