Bug 91135 - Two-finger scrolling jumpy with Synaptics touchpad
Summary: Two-finger scrolling jumpy with Synaptics touchpad
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-28 16:36 UTC by Milan Bouchet-Valat
Modified: 2016-11-30 20:25 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu recording (106.15 KB, text/plain)
2015-06-28 16:36 UTC, Milan Bouchet-Valat
Details
evemu-record on Fedora 24 (libinput 1.3.3) (40.24 KB, text/plain)
2016-06-29 16:19 UTC, Milan Bouchet-Valat
Details
evemu-record on Fedora 24 (libinput 1.4.2) (59.38 KB, text/x-log)
2016-09-14 12:29 UTC, Milan Bouchet-Valat
Details
0001-touchpad-add-a-quirk-for-the-HP-Pavilion-dm4.patch (3.37 KB, patch)
2016-11-01 23:48 UTC, Peter Hutterer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2015-06-28 16:36:12 UTC
Created attachment 116765 [details]
evemu recording

I have an hp Pavilion dm4 with this touchpad:
# Input device name: "SynPS/2 Synaptics TouchPad"
# Input device ID: bus 0x11 vendor 0x02 product 0x07 version 0x1b1

Two-finger scrolling isn't smooth, which drives me back from libinput to the synaptics X11 driver to use edge scrolling (two-finger scrolling isn't smooth there either).

Attached is an evemu recording in which I move my two fingers up and down three times at a "normal" pace to scroll on a web page. This is with libinput 0.11.0 on Fedora 22.
Comment 1 Milan Bouchet-Valat 2015-07-08 13:38:32 UTC
Actually, the problem also happens when moving the pointer with a single finger, so it's not limited to scrolling.
Comment 2 Juraj Fiala 2015-07-09 13:35:33 UTC
I don't know if this is relevant, but edge-scrolling with libinput is "jumpy" for me too. Sometimes when I scroll it just "jumps" (scrolls instantaneously) quite a lot down/up (depending on the scroll direction).
Comment 3 Peter Hutterer 2015-07-14 01:04:27 UTC
looking at the recording, this looks like a hw issue that synaptics doesn't trigger. the touch points themselves are quite jumpy, a visualization with mtview shows that. but the single-touch data (ABS_X/Y) is fine.

synaptics doesn't really do multitouch and uses the single-finger data for scrolling, hence why it is probably more fluid here (but as you said still not perfect).

This is the same category as Bug 91081, if we can't trust the 2fg touchpad data, we should just not expose 2fg-scrolling as an option. Note that the next version of libinput (0.20.0) will support edge scrolling on clickpads.
Comment 5 Milan Bouchet-Valat 2015-07-31 13:57:50 UTC
Thanks, indeed using edge scrolling is fine.

Do you want evemu recording for simple moves of the pointer? These are jumpy too.
Comment 7 Peter Hutterer 2015-08-03 01:45:18 UTC
(In reply to Milan Bouchet-Valat from comment #5)
> Do you want evemu recording for simple moves of the pointer? These are jumpy
> too.

urgh, seriously? if you only have one finger on the touchpad the movement is jumpy? if so, then yes, I want the recording but please open a separate bug for that though, this bug is about to be fixed upstream with the patch I just linked to.
Comment 8 Peter Hutterer 2015-08-12 04:25:01 UTC
ping?
Comment 9 Milan Bouchet-Valat 2015-08-12 10:31:40 UTC
Sorry for the delay. I've filed Bug 91615.
Comment 10 Peter Hutterer 2015-08-12 23:59:06 UTC
ok, thanks. I'm closing this bug now because the two-finger scroll jump triggered by these devices was fixed. we now use the single-finger data. if that data is bad, that's Bug 91615 instead, but at least we're not any worse now for 2fg scrolling :)

commit 7013a20f8b6a441a5f80b84aa261c32dd8011f95
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jul 30 11:54:38 2015 +1000

    touchpad: pretend the jumpy semi-mt touchpad is a single-touch touchpad
Comment 11 Milan Bouchet-Valat 2016-06-29 16:19:22 UTC
Created attachment 124782 [details]
evemu-record on Fedora 24 (libinput 1.3.3)

Reopening, as two-finger scrolling is still jumpy on Fedora 24 (even if one finger moves are OK). One thing I noticed is that while scrolling up, when the top finger reaches the top of the touchpad, the view suddenly scrolls down. Looks like when the top finger is no longer detected, the driver thinks it has moved to the position of the one at the bottom. See the attached evemu-record log, in which I just move my two fingers up until that jump happens.

This is with libinput 1.3.3-2.
Comment 12 Milan Bouchet-Valat 2016-06-30 08:40:29 UTC
Also, I just realized my system logs contain many occurrences of this message (sometimes about 20 in a row):
> org.gnome.Shell.desktop[6885]: libinput error: libinput bug: invalid tap event when fingers are up
Comment 13 Peter Hutterer 2016-06-30 22:31:46 UTC
please try to get an evemu recording that captures that bug, the previous one doesn't seem to. do you have options changed from the default other than tapping?
Comment 14 Peter Hutterer 2016-07-01 06:05:37 UTC
This event here is the problem:

E: 1.469012 0003 0035 4220      # EV_ABS / ABS_MT_POSITION_X    4220
E: 1.469012 0003 0036 1777      # EV_ABS / ABS_MT_POSITION_Y    1777
E: 1.469012 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 1.469012 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1.469012 0003 0000 4220      # EV_ABS / ABS_X                4220
E: 1.469012 0003 0001 1777      # EV_ABS / ABS_Y                1777
E: 1.469012 0003 001c 0004      # EV_ABS / ABS_TOOL_WIDTH       4
E: 1.469012 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 1.469012 0001 014d 0000      # EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1.469012 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +25ms

before this, slot 0 is on 3481/2721, slot 1 is on 4224/1777. In the event where the slot 1 ends slot 0 jumps to slot 1 positions *for a single event*. In the next event it is back to 3478/2702, i.e. the previous slot 0 position.

Benjamin, is this something we can detect in the kernel or do I need to work around it? This is a semi-mt buttonpad.
Comment 15 Benjamin Tissoires 2016-07-01 07:48:52 UTC
(In reply to Peter Hutterer from comment #14)
> before this, slot 0 is on 3481/2721, slot 1 is on 4224/1777. In the event
> where the slot 1 ends slot 0 jumps to slot 1 positions *for a single event*.
> In the next event it is back to 3478/2702, i.e. the previous slot 0 position.
> 
> Benjamin, is this something we can detect in the kernel or do I need to work
> around it? This is a semi-mt buttonpad.

I can't figure out which code path we manage to trigger here. But it's unlikely the kernel will be able to fix those jumps.
I think the best course of action is to ignore/reset the coordinates when the contact count changes. SEMI_MT are such a pain :(
Comment 16 Peter Hutterer 2016-07-13 00:41:20 UTC
(In reply to Benjamin Tissoires from comment #15)
> I think the best course of action is to ignore/reset the coordinates when
> the contact count changes. SEMI_MT are such a pain :(

we already do that, but I'll see what other paths we trigger here that makes us unhappy. I think I may have had a patch for this at some point in the past
Comment 17 Peter Hutterer 2016-09-12 04:02:03 UTC
can you check this with libinput 1.4.2 or later please? it added some jump detection, not 100% this one is covered too here
Comment 18 Milan Bouchet-Valat 2016-09-14 11:31:00 UTC
AFAICT it's much better with 1.4.2, but there's still a jump when one of the fingers goes beyond the top of the touchpad area. Interestingly, it doesn't happen at the bottom.
Comment 19 Peter Hutterer 2016-09-14 12:07:03 UTC
huh, weird. can you give me an evemu recording of this please?
Comment 20 Milan Bouchet-Valat 2016-09-14 12:29:03 UTC
Created attachment 126515 [details]
evemu-record on Fedora 24 (libinput 1.4.2)

Sure. Here's one where I move two fingers up until one of them reaches the top of the touchpad, and I experience the downward jump.
Comment 21 Peter Hutterer 2016-09-15 00:55:39 UTC
oh, ffs, I hate these touchpads.

event at 0.968621 has a 6.23mm jump in the x axis
event at 2.340838 has a 8.68mm jump in the x axis

Those two account for the horizontal scroll jump you can see in this recording.

event at 2.487409 has a 8.34mm jump in the y axis

That's the vertical jump close to the end of the recording.

This is in the single-touch emulation, we already disabled true multi-finger tracking for the semi-mt touchpads because it's unreliable.

it's a bit unclear why this is happening too. The events leading up to this:


 2.292016: ↖↑ 3215/2774 | ↖↑ 3696/1269 | 
 2.316154: ↖↑ 3215/2728 | ↖↑ 3626/1269 | 
 2.340838: ↖↑ 3215/2721 | ↖← 3218/1269 | 
 2.365007: ↖↑ 3215/2715 |              | 
 2.389629: ↖← 3215/2713 |              | 
 2.415441: ↖← 3215/2711 |              | 
 2.464192: ↖← 3215/2709 |              | 
 2.487409: ↖↑ 3215/2678 | ↓↘ 3219/1778 | 
 2.512015: ↑↗ 3216/2658 | ↓↘ 3220/1778 | 
 2.536274: ↑↗ 3220/2658 | ↓↘ 3221/1778 | 

which is a bit confusing because the way I read the kernel's synaptics_report_semi_mt_data() slot 1 should be the bottom-right touchpoint but that isn't the case here. but either way, the jump is visible in slot 1

and the single touch emulation tracks slot 1 for coordinates:

 2.292016:  *********** | ↖← 3696/1269 | 
 2.316154:  *********** | ↙← 3626/1270 | 
 2.340838:  *********** | ↙← 3218/1270 | 
 2.365007:  *********** |              | 
 2.389629:  *********** | ↖← 3216/1269 | 
 2.415441:  *********** |              | 
 2.464192:  *********** |              | 
 2.487409:  *********** | ↓↘ 3222/1778 | 
 2.512015:  *********** |              | 
 2.536274:  *********** | →↗ 3224/1777 |


so in short: we don't have a warning about this, it's not caused by a finger change and all we get is a sudden jump to some other position. which means we have to find some other heuristics to detect those.
Comment 22 Peter Hutterer 2016-10-28 05:54:40 UTC
question: do you get the 2-finger scroll jumps with synaptics as well?
Comment 23 Milan Bouchet-Valat 2016-11-01 11:04:48 UTC
Indeed, I've just tried, and there's also a jump with the Synaptics driver (I guess I hadn't noticed it because I used edge scrolling with that driver). So maybe the touchpad is just broken with two-finger scrolling?
Comment 24 Peter Hutterer 2016-11-01 21:14:28 UTC
I'd say so. I think I'll put an exception in for this touchpad to force it to edge scroll only, that will make the problem go away.
Comment 25 Peter Hutterer 2016-11-01 23:48:31 UTC
Created attachment 127679 [details] [review]
0001-touchpad-add-a-quirk-for-the-HP-Pavilion-dm4.patch

Please give this one a try and make sure that
a) LIBINPUT_MODEL_HP_PAVILLION_DM4_TOUCHPAD shows up in the udevadm output
b) libinput-list-devices does not list 2-finger scrolling anymore
c) two-finger tapping still works

https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_hwdb_changes
has instructions for the hwdb bits in a)
Comment 26 Milan Bouchet-Valat 2016-11-11 10:03:35 UTC
Thanks. Testing revealed a typo in the hwdb file: it's PAVILION with a single L. Then a) and b) are OK. c) doesn't work, i.e. two-finger tapping no longer triggers a right click.
Comment 27 Milan Bouchet-Valat 2016-11-11 10:25:23 UTC
Sorry, the part about c) in my latest comment is nonsense. I started X with the F24 libinput, so there's no chance it would work. How can I test c) correctly?

BTW, single- and double-finger tapping doesn't work even without the hwdb patch now. Not sure what happened (I'm using another laptop now, so not sure when it stopped working).
Comment 28 Peter Hutterer 2016-11-14 03:13:41 UTC
typo fixed locally, thanks. Tapping should still work though. What's the output of libinput-list-devices for this device?

Do you have tapping enabled? Make sure to check with libinput-debug-events --eanble-tap to make sure it's not the DE interfering.
Comment 29 Milan Bouchet-Valat 2016-11-14 18:35:18 UTC
False alarm, I had mistakenly removed libinput during the different tests. But how can I test the development version?
Comment 30 Peter Hutterer 2016-11-14 21:00:21 UTC
if you build the git tree, you have two tools to test libinput directly: ./tools/event-debug and ./tools/event-gui (the latter requires GTK+ headers installed at configure time). Run either of them as root and look at the output. event-debug is the same binary as libinput-debug-events and you'll see button events float past as you tap. event-gui has a 3 button area at the bottom that highlight whenever a button is pressed. run with:

sudo ./tools/event-debug --enable-tap

and of course make sure that the property is still set before running it.
see also: https://wayland.freedesktop.org/libinput/doc/latest/tools.html


finally, if you ran configure with the right prefix, you can just sudo make install and run it, that'll overwrite your system copy. on fedora, it's:

./configure --prefix=/usr --libdir=/usr/lib64
Comment 31 Milan Bouchet-Valat 2016-11-27 11:36:39 UTC
Sorry for the delay. Looks like tapping indeed triggers a right click:
$ sudo ./tools/event-debug --enable-tap
[...]
 event4 	POINTER_BUTTON    +2.91s	BTN_RIGHT (273) pressed, seat count: 1
 event4 	POINTER_BUTTON    +2.91s	BTN_RIGHT (273) released, seat count: 0
 event4 	POINTER_BUTTON    +4.35s	BTN_LEFT (272) pressed, seat count: 1
 event4 	POINTER_BUTTON    +4.58s	BTN_LEFT (272) released, seat count: 0

(And LIBINPUT_MODEL_HP_PAVILION_DM4_TOUCHPAD=1 was in the udevadm test output.)
Comment 32 Peter Hutterer 2016-11-27 22:55:30 UTC
ok, thanks. patch is on the list, will be pushed soon

https://lists.freedesktop.org/archives/wayland-devel/2016-November/031941.html
Comment 33 Peter Hutterer 2016-11-30 20:25:09 UTC
commit 996b845d68cfa23b7f8a8f9da1bbc40527da562b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Nov 2 09:40:42 2016 +1000

    touchpad: add a quirk for the HP Pavilion dm4


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.