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