Bug 99383

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

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

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.

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.

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

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)

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)

Changing TP_MAGIC_SLOWDOWN to 0.6 allows for a broader range of speeds that match my needs.

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.

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.

Works great ! Thanks

Comment on attachment 129016 [details] [review]
0001-filter-normalize-deltas-before-returning-them.patch

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

Works For Me.

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

Tried the 2-part patch from the ML on top of 1.5.901 -- it works well for me.

Patch from the ML works better! (more acceleration it seems) problem fixed for me.

That's confirmation bias :) the code for touchpads remained identical, it's just handling mice etc. differently now

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

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.