What laptop device is this? You filed the bug for ALPS but the recording says it's a Synaptics device?

either way, this looks like serious garbage from the kernel:

E: 8.849835 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 8.849835 0003 0035 3125      # EV_ABS / ABS_MT_POSITION_X    3125
E: 8.849835 0003 0036 2503      # EV_ABS / ABS_MT_POSITION_Y    2503
E: 8.849835 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 8.849835 0003 0036 2502      # EV_ABS / ABS_MT_POSITION_Y    2502
E: 8.849835 0003 0000 3125      # EV_ABS / ABS_X                3125
E: 8.849835 0003 0001 2503      # EV_ABS / ABS_Y                2503
E: 8.849835 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 8.874811 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 8.874811 0003 0035 2416      # EV_ABS / ABS_MT_POSITION_X    2416
E: 8.874811 0003 0036 4578      # EV_ABS / ABS_MT_POSITION_Y    4578
E: 8.874811 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 8.874811 0003 0035 3125      # EV_ABS / ABS_MT_POSITION_X    3125
E: 8.874811 0003 0036 2507      # EV_ABS / ABS_MT_POSITION_Y    2507
E: 8.874811 0003 0001 2507      # EV_ABS / ABS_Y                2507
E: 8.874811 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 8.900256 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 8.900256 0003 0035 3124      # EV_ABS / ABS_MT_POSITION_X    3124
E: 8.900256 0003 0036 2513      # EV_ABS / ABS_MT_POSITION_Y    2513
E: 8.900256 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 8.900256 0003 0035 4214      # EV_ABS / ABS_MT_POSITION_X    4214
E: 8.900256 0003 0036 2512      # EV_ABS / ABS_MT_POSITION_Y    2512
E: 8.900256 0003 0000 3124      # EV_ABS / ABS_X                3124
E: 8.900256 0003 0001 2513      # EV_ABS / ABS_Y                2513
E: 8.900256 0000 0000 0000      # ------------ SYN_REPORT (0) ----------


so the first finger does indeed jump from 2503 to 4578 back to 2513. 
happens again later at
E: 12.409375 0003 0036 5410	# EV_ABS / ABS_MT_POSITION_Y    5410


punting this to the kernel, please attach your dmesg here

(In reply to Peter Hutterer from comment #1)
> either way, this looks like serious garbage from the kernel:

well, yes and no. The device is flagged as INPUT_PROP_SEMI_MT, so there is no guarantees that the slots are consistent.
 
> punting this to the kernel, please attach your dmesg here

Yep, please do so.

Erm, why does the summary / subject of this bug say ALPS, while the evemu recording is for a synaptics device? I'm confused now ...

Created attachment 1042776 [details]
dmesg

Sorry about ALPS/Synaptics confusion - brainfade caused by reading similar bug report prior to filing this one...

(In reply to Neil Romig from comment #5)
> Sorry about ALPS/Synaptics confusion - brainfade caused by reading similar
> bug report prior to filing this one...

Thanks for the clarification.

If you don't mind (being a guinea pig actually), I'd like to request some more logs using our latest debug tool currently in progress. (Chandler is still working on it so I do not have easier installation instructions right now.)

Could you run the following commands in a terminal:
$ sudo dnf install -y git autoconf automake gcc glib2-devel make
$ cd /tmp/
$ git clone https://github.com/Lyude/ps2emu.git
$ cd ps2emu
$ ./autogen.sh
$ make
$ sudo ./src/ps2emu-record | tee synaptics_semi_mt.ps2

***** /!\ WARNING /!\ *****

Please be aware that starting the moment the tool is launched (when it outputs a lot of data), all your key presses are recorded in dmesg. So if you type your password, it will be stored in the journal. The tool however does not record key presses, so the key presses will only be stored in your local hard drive, *if* you type while ps2emu-record is up.

***************************

ps2emu-record should output a lot of lines with "# (interrupt, 1, 12)" or "# (parameter)" at the end.
When things settle a little, can you:
- touch the touchpad with one finger first, release,
- wait few seconds
- then touch with 2 fingers, move a little (as if you are scrolling) and release,
- wait few seconds
- then one finger and release
- wait few seconds
- finally try to trigger the bug you are seeing by scrolling on the touchpad
- once you observed it, please tap your finger on the touchpad to empty the buffer queue
- hit Ctrl-C

And then, please attach the resulting /tmp/ps2emu/synaptics_semi_mt.ps2
With this file, we should be able to replay your record on our machine and eventually figure out if the kernel needs to be fixed or if this is really a libinput bug not handling properly the SMEI_MT bit.

Created attachment 1042806 [details]
ps2emu-record

Hope this is useful, the bug definitely manifested towards the end of the scrolling (I used the mouse/trackpad test screen in Gnome settings to produce it).

Many thanks for the logs. The good news is that we are able to reproduce with this file, so we should be able to figure out if something can be done at the kernel level.
The bad news is that Chandler's kernel module hangs at the second attempt (he will fix it I guess), and that I will take next week off. So we might come with a solution tomorrow or you will have to wait 2 weeks.

That's OK, I will carry on with the synaptics driver which gives me tap-to-click at the login screen and edge scrolling which I prefer...

Created attachment 1043198 [details]
synaptics_semi_mt_processed.txt

OK, writing down my progress so that I (or someone else) can take over from it later on.

The ps2 logs shows the requested sequence (thanks much for following it) and in the first dual finger events sequence, there is already some jumps.

I extracted this sequence and then processed it with a custom script to mimic the current kernel processing.
The result is attached in synaptics_semi_mt_processed.txt:

The SGM packets seem fine all along the trace (good news).
However, the AGM packets shows a weird behavior:
there are some jumps in x,y at 11.077947, 11.453220, 11.526044 & 11.999434.

I will have to check if there is not a missing bit in the report that we forget to check in the AGM packet that would explain why the value is jumping from time to time.

If not, then that means that we are already receiving the best we can do from the kernel point of view, and that we will have to filter this jumps in libinput and/or have a special case for this particular device.

Created attachment 1043199 [details]
synaptics_semi_mt_with_comments.ps2

Adding also a post-processing I made in the original file to corner out the event sequences

The hardware sends garbage, so it will be hard to fix that in the kernel.

eb146677eb5abb7951af4ead80874c992915b90d in libinput tree simply disable 2fg scrolling for Synaptics semi-mt devices, which are unreliable to provide correct data.

Re-assigning back to libinput, once this commit hit Fedora, we could close the bug.

libinput-0.20.0-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.20.0-4.fc22

libinput-0.20.0-5.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.20.0-5.fc22

The synaptics driver is able to give smooth two-finger scrolling. Is it not possible to filter the garbage as the synaptics driver does? Sorry if this question is naive!

libinput-0.20.0-6.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.20.0-6.fc22

actually, no, that's a really good point. The background here is that synaptics doesn't actually do multi-touch, it looks at the single-touch emulation from the kernel and merely uses the BTN_TOOL_DOUBLETAP flag to check if a second finger is down.

libinput otoh handles touchpoints separately, which allows for a couple of other features (thumb detection and pinch gestures, for example).

On semi-mt touchpads like yours, the first touchpoint is precise but the second one only provides coarse data. which is where the jumps come from in libinput and it explains why synaptics doesn't suffer from that.

We should be able to fix that in libinput by simply treating the device as if it was a single-touch device. This means losing on gestures, but scrolling is more important.

Hi,

(In reply to Peter Hutterer from comment #17)
> actually, no, that's a really good point. The background here is that
> synaptics doesn't actually do multi-touch, it looks at the single-touch
> emulation from the kernel and merely uses the BTN_TOOL_DOUBLETAP flag to
> check if a second finger is down.
> 
> libinput otoh handles touchpoints separately, which allows for a couple of
> other features (thumb detection and pinch gestures, for example).
> 
> On semi-mt touchpads like yours, the first touchpoint is precise but the
> second one only provides coarse data. which is where the jumps come from in
> libinput and it explains why synaptics doesn't suffer from that.
> 
> We should be able to fix that in libinput by simply treating the device as
> if it was a single-touch device. This means losing on gestures, but
> scrolling is more important.

Hmm, this sounds a bit like the issue with alps semi-mt touchpads. With older kernel versions those will report accurate coordinates in the old-style single-touch events where as the mt events are coarse grained. When I cleaned up the code switching it over to use drivers/input/input-mt.c pointer emulation for old style devices, this resulted in the accurate single touch events getting lost completely. Even newer kernels now use the accurate single touch coordinates for slot 0, and when multiple fingers are down use the inaccurate semi-mt coordinates for the second finger only.

This, combined with only looking at slot 0 for semi-mt devices when doing 2fg scrolling fixes things for alps touchpads.

So I believe that for synaptics touchpads we need to first look at the kernel. Is it reporting the accurate first touch info in old-style single touch events only, like alps used to to ? Or has it in the mean time be cleaned up to to drivers/input/input-mt.c pointer emulation, causing the accurate touch info to not be reported anymore at all, since the emulation uses the inaccurate bounding box coordinates set in the mt slots for the old style single-touch events ?

Regards,

Hans

(In reply to Hans de Goede from comment #18)
> (In reply to Peter Hutterer from comment #17)
> So I believe that for synaptics touchpads we need to first look at the
> kernel. Is it reporting the accurate first touch info in old-style single
> touch events only, like alps used to to ? Or has it in the mean time be
> cleaned up to to drivers/input/input-mt.c pointer emulation, causing the
> accurate touch info to not be reported anymore at all, since the emulation
> uses the inaccurate bounding box coordinates set in the mt slots for the old
> style single-touch events ?

The current synpatics.ko code makes no use of the pointer emulation from input-mt.c. It is using the correct SGM packet (first finger detected) for the ABS_X/ABS_Y but use a min/max for slot 0 and 1 (as specified by the semi-mt protocol). And this min/max introduce jumps between the coordinates (without counting the hardware errors on the second reported finger).
So here, the slot 0 is bogus, but the single touch emulation is fine. That's why the xorg-synaptics driver performs better than libinput.

Peter was saying that for synaptics semi-mt device, we would then ignore the mt data and treat it as xorg-synaptics does. This won't apply for all semi-mt devices, only the Synaptics (the manufacturer) ones.

Hi,

(In reply to Benjamin Tissoires from comment #19)
> (In reply to Hans de Goede from comment #18)
> > (In reply to Peter Hutterer from comment #17)
> > So I believe that for synaptics touchpads we need to first look at the
> > kernel. Is it reporting the accurate first touch info in old-style single
> > touch events only, like alps used to to ? Or has it in the mean time be
> > cleaned up to to drivers/input/input-mt.c pointer emulation, causing the
> > accurate touch info to not be reported anymore at all, since the emulation
> > uses the inaccurate bounding box coordinates set in the mt slots for the old
> > style single-touch events ?
> 
> The current synpatics.ko code makes no use of the pointer emulation from
> input-mt.c. It is using the correct SGM packet (first finger detected) for
> the ABS_X/ABS_Y but use a min/max for slot 0 and 1 (as specified by the
> semi-mt protocol). And this min/max introduce jumps between the coordinates
> (without counting the hardware errors on the second reported finger).
> So here, the slot 0 is bogus, but the single touch emulation is fine. That's
> why the xorg-synaptics driver performs better than libinput.
> 
> Peter was saying that for synaptics semi-mt device, we would then ignore the
> mt data and treat it as xorg-synaptics does. This won't apply for all
> semi-mt devices, only the Synaptics (the manufacturer) ones.

Ok, I see, in that case we indeed need a fix for this in libinput, and the kernel side is fine. I'll discuss this further with Peter on the wayland-devel list. Peter has posted a fix there, but I believe that it is incomplete.

Package libinput-0.20.0-6.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libinput-0.20.0-6.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12431/libinput-0.20.0-6.fc22
then log in and leave karma (feedback).

libinput-0.20.0-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

follow-up for the archives: the 0.20.0-4 package (and thus -6 as well) disable 2fg scrolling on this device. Upstream patches will re-enable it with custom behaviour like outlined in comment #17. I won't re-open the bugreport for that though, just keep updating libinput and eventually it'll come back.

fwiw, this is fixed with libinput-0.21.0-1 and later.

*** Bug 1251265 has been marked as a duplicate of this bug. ***

OK, I have received the updated libinput-0.20.0-6.fc22.x86_64 with comment stating 2fg scrolling disabled for my Synaptics semi-mt device but confusingly I can enable 2fg scrolling in the Gnome settings and it still shows the same jumpy behaviour! Not sure in what way it has been disabled?

Neil:
run udevadm info /sys/class/input/eventX against the touchpad device and check if LIBINPUT_MODEL_JUMPING_SEMI_MT is set. if not, something is off and libinput doesn't detect the touchpad correctly. Attach the output of udevadm info --export-db then so we can figure out what's going on.