Please attach a (short) recording of the jump, not just the excerpt. easier to debug when I can replay it locally, thanks.

Created attachment 122652 [details]
evemu-record trace of a jump occuring (gzipped)

Trace of the jump occurring.

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.

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.

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.

Created attachment 122703 [details]
evemu-record trace of a jump occuring with libinput (gzipped)

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.

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.

Modalias

dmi:bvnDellInc.:bvr01.01.19:bd01/25/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr:

Kernel:
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.

(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.

Okay, so definitely running on libinput from the output of xinput.  Dimensions are 105 x 80 mm (10.5 x 8.0 cm).

Created attachment 122910 [details] [review]
0001-hwdb-add-touchpad-resolutions-for-the-Dell-XPS-15-95.patch

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 :)

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:

  /lib/udev/hwdb.d/60-evdev.hwdb

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.

Created attachment 123018 [details] [review]
0001-hwdb-add-touchpad-resolutions-for-the-Dell-XPS-15-95.patch

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

Yay, that gets the resolutions set on the ABS_X and ABS_Y events.

Unfortunately, no effect on the jumping of the cursor.

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

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).

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.

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).

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.

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).

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.

-- 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.