| Summary: | Two-finger scrolling jumpy with Synaptics touchpad | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Milan Bouchet-Valat <nalimilan> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, jurf, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu recording
evemu-record on Fedora 24 (libinput 1.3.3) evemu-record on Fedora 24 (libinput 1.4.2) 0001-touchpad-add-a-quirk-for-the-HP-Pavilion-dm4.patch |
||
Actually, the problem also happens when moving the pointer with a single finger, so it's not limited to scrolling. 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). 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. Thanks, indeed using edge scrolling is fine. Do you want evemu recording for simple moves of the pointer? These are jumpy too. (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. ping? 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 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.
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
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? 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. (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 :( (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 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 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. huh, weird. can you give me an evemu recording of this please? 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.
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. question: do you get the 2-finger scroll jumps with synaptics as well? 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? 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. 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) 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. 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). 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. False alarm, I had mistakenly removed libinput during the different tests. But how can I test the development version? 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 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.) ok, thanks. patch is on the list, will be pushed soon https://lists.freedesktop.org/archives/wayland-devel/2016-November/031941.html 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. How we collect and use information is described in our Privacy Policy.
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.