Bug 99383 - libinput 1.5.901 regression: touchpad too slow on Dell XPS & Pixel Chromebook
Summary: libinput 1.5.901 regression: touchpad too slow on Dell XPS & Pixel Chromebook
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard:
Keywords:
: 99379 99404 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-12 11:15 UTC by François Guerraz
Modified: 2017-01-30 10:45 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-filter-normalize-deltas-before-returning-them.patch (1.68 KB, patch)
2017-01-18 08:21 UTC, Peter Hutterer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description François Guerraz 2017-01-12 11:15:53 UTC
I've just installed libinput-git 1.5.901.r3.g72e0148-1 to test the
awesomeness of the new touchpad pointer acceleration. I'm using
gnome/wayland one a DELL XPS 2016 (DLL0704:01 06CB:76AE Touchpad).

Acceleration works, finally, which is great. However, I don't know if
it's because I'm on a HiDPI screen or not but even with touchpad speed
cranked to the max in gnome-settings, it's still a bit slow. Way slower
than with v. 1.5.
Comment 1 Peter Hutterer 2017-01-13 08:14:58 UTC
*** Bug 99379 has been marked as a duplicate of this bug. ***
Comment 2 Peter Hutterer 2017-01-13 08:17:42 UTC
based on this IRC log below, I'm going to blame this on gnome. Any chance you can test weston?


17:05 < jadahl> whot: I suspect the slow-mouse-on-hidpi could be that we don't speed up the mouse on hidpi (easiest way to test on weston, which does that IIRC)
17:56 < whot> jadahl: oh? I thought it did get multiplied on the hidpi screens?
18:02 < jadahl> on weston it is implicitly, mutter on the other hand
18:02  * jadahl checks
18:04 < jadahl> whot: I can't see that we do. the input backend is in clutter, which has no clue about monitors and hidpi scales etc
Comment 3 Cole Mickens 2017-01-13 09:11:04 UTC
This is a summary of my observations from the the discussion in IRC.

In this comment, Weston is running with Scale=2.

In 1.5, GNOME and Weston feel about the same. Comfortable. Maybe a tiny bit on the fast side compared to what I'd expect as a default, but it's comfortable to me.

In 1.5.901, GNOME and Weston again feel about the same, but are much too slow.

If I keep Weston running, and then plug in a non-HiDPI monitor, the touchpad feels the same ("too slow") on the external monitor. There is no change in speed the cursor on screen when crossing from one display to the other.
Comment 4 Mathieu Velten 2017-01-13 11:17:19 UTC
Same here with the new code it is too slow for me.
XPS 13 9360, but with the full hd screen so I guess it is unrelated to the HiDPI screen.

Let me know if you need more infos.
Comment 5 John Obaterspok 2017-01-14 12:24:01 UTC
*** Bug 99404 has been marked as a duplicate of this bug. ***
Comment 6 Thorsten Leemhuis 2017-01-15 14:37:32 UTC
Two additional data points:
- I'm seeing this also on my XPS13 (9360), but I have only an FHD (1920x1080) panel (running Fedora 25 with Gnome Wayland)
- Darrell Pfeifer sees the Problem in KDE (https://bugzilla.redhat.com/show_bug.cgi?id=1413306#1) (also an XPS13)
Comment 7 François Guerraz 2017-01-17 09:10:44 UTC
So can we agree this is not a Gnome bug (as it's reproducible on KDE and Weston) and not HiDPI related? (I just want to know if we need to open bug reports upstream)
Comment 8 Mathieu Velten 2017-01-17 09:19:51 UTC
Changing TP_MAGIC_SLOWDOWN to 0.6 allows for a broader range of speeds that match my needs.
Comment 9 Peter Hutterer 2017-01-18 03:46:53 UTC
ok, reproduced this here on a RMI4 device (T450p). works fine on PS/2, terrible on RMI4. I suspect this may be the resolution difference, but I'm not sure yet. Either way, definitely not a gnome bug.
Comment 10 Peter Hutterer 2017-01-18 08:21:20 UTC
Created attachment 129016 [details] [review]
0001-filter-normalize-deltas-before-returning-them.patch

ok, this fixes the issue, just a stupid mistake of forgetting to actually normalize coordinates. Please test it and let me know how you go, I need to do some more testing tomorrow with different mice - this affects the current low-dpi acceleration as well and while I think it fixes a long-standing bug there too, it does need more testing before I can send it to the list.
Comment 11 Mathieu Velten 2017-01-18 09:09:35 UTC
Works great ! Thanks
Comment 12 François Guerraz 2017-01-18 10:42:03 UTC
Comment on attachment 129016 [details] [review]
0001-filter-normalize-deltas-before-returning-them.patch

Review of attachment 129016 [details] [review]:
-----------------------------------------------------------------

Works For Me.
Comment 13 Peter Hutterer 2017-01-19 02:36:14 UTC
ok, patch is out now. Looks different to avoid affecting other devices, so re-testing would be appreciated, thanks.

https://lists.freedesktop.org/archives/wayland-devel/2017-January/032731.html
Comment 14 Cole Mickens 2017-01-19 03:08:55 UTC
Tried the 2-part patch from the ML on top of 1.5.901 -- it works well for me.
Comment 15 François Guerraz 2017-01-19 09:19:56 UTC
Patch from the ML works better! (more acceleration it seems) problem fixed for me.
Comment 16 Peter Hutterer 2017-01-19 09:48:27 UTC
That's confirmation bias :) the code for touchpads remained identical, it's just handling mice etc. differently now
Comment 17 Peter Hutterer 2017-01-19 21:42:01 UTC
commit 5f0d310ead52b953bd4c92403877000f3ce9714d
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Jan 18 17:58:36 2017 +1000

    filter: normalize deltas before processing or returning them
Comment 18 Adam Williamson 2017-01-30 10:45:08 UTC
Several people have reported that the speed is still 'too slow' (that's subjective, but at least significantly slower than 1.5) in 1.6, and the downstream bug - https://bugzilla.redhat.com/show_bug.cgi?id=1413306 - was re-opened. Not sure if you want to re-open this one too.


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.