save the below as xorg.conf.d snippet, restart the server and run evemu-record against the device when this happens. Then attach the recording here.

Section "InputClass"
	Identifier "Don't grab synaptics"
	MatchDriver "synaptics"
	Option "GrabEventDevice" "off"
EndSection

Please use evemu from git, _not_ the one shipped in your distribution. http://cgit.freedesktop.org/evemu/

Created attachment 79237 [details]
Output of `sudo evemu-record /dev/input/event10 > mydevice.events`

I ran
sudo evemu-record /dev/input/event10 > mydevice.events
and then reproduced the bug by putting my finger (enough surface of it) on the touchpad and then hit Ctrl+C for the output not being to long.

Created attachment 79238 [details]
Output of `sudo evemu-describe /dev/input/event10 > mydevice.desc`

The bug also occurs when I'm on battery but connected through an ethernet cable.

whoah, that is some massive movement. We'd need some better smoothing here but that's currently not there.

The events themselves look ok in principle, it's not a single event that is the outlier. There are only two big jumps in there, the rest looks like continuous movement. Not sure how to fix this without some larger rework in the smoothing code.

Play around with the noise cancellation though, maybe you can find a setting that makes it bearable:

xinput set-prop "SynPS/2 Synaptics TouchPad" "Synaptics Noise Cancellation" 8 8

8 is the default, increase the numbers (x and y) until you find something useful.

(In reply to comment #5)
> Play around with the noise cancellation though, maybe you can find a setting
> that makes it bearable:

Not the reporter, but on this Dell Latitude E6520 (Alps pad) the cursor warps around even at a cancellation of 30 30. :<

Supplying proto=imps to psmouse obviously dumbs it down to just a generic PS/2 mouse, but the phantom movement stops.

Connecting the adapter to a well-grounded surge protector eliminates this on said Latitude, suggesting current leakage or other hardware design fault. Curious, then, that it only seems to occur when the pad is run with the AlpsPS/2 protocol. Is certain circuitry only used when it's requested to act like more than a generic mouse?

It would obviously be *very* nice if the behaviour could be compensated at a driver level, but solving it outright strikes me as difficult.

(In reply to comment #5)
> The events themselves look ok in principle, it's not a single event that is
> the outlier. There are only two big jumps in there, the rest looks like
> continuous movement. Not sure how to fix this without some larger rework in
> the smoothing code.

I'm not sure I understand you correctly there, so please ignore this if so.

The phantom jumps are only ever along one axis, right? During normal use and a refresh rate of 100hz, what kind of raw movement deltas are common? Based on the finger position reported by the pad, before acceleration etc.

I don't know the code, but if it's using some form of hysteresis to smooth out events then a sudden humanly impossible spike in the second-order derivative (delta of delta of position) should be obvious, aye?

This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.