[regression] Mouse speed in Unity8 is much lower than elsewhere (to the point of useless)

[Albert Astals Cid]

Running unity8 as a session on the desktop.

The mouse is so "slow" (i.e a movement in reality moves it very few pixels on screen) that i can't really use it since i need to lift it and restart the movement a few times if i want to go to the other side of the screen.

[Daniel d'Andrada (dandrader)]

The fix for this is having mir including mouse acceleration and sensitivity also on its relative mouse axes, which is what qtmir/unity8 uses to move the QML mouse.

[Daniel d'Andrada (dandrader)]

IINM this will happen once the input backend moves to libinput

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.18.0

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Hmm, the mouse moving faster in Mir 0.18.0 is a bug (see bug 1524145).

So I suggest you should aim to fix this bug in Unity8/QtMir. Especially since it only affects Unity8.

[Daniel van Vugt (vanvugt)]

Note Mir did not change to cause this bug. Something other than Mir did.

[Daniel van Vugt (vanvugt)]

Actually, regardless of whether we land Mir fixes for bug 1524145 and bug 1522295, the Unity8 mouse speed is still going to be unusable.

Right now (Mir 0.17 installed on xenial) you're getting 1:1 device kernel motion data. So Unity8 should be able to deal with that much better than it is and not require such a huge effort to move the mouse around.

So this is entirely a Unity8 bug. Unity8 should ensure as a sane default that it is moving the cursor by about 1px when the motion event gives a dx==1. But right now it seems to be a long way from that. Other Mir shells don't have a problem.

[Daniel van Vugt (vanvugt)]

Furthermore, when a configuration GUI is available, many users will configure and want mouse accuracy to be exactly what it is right now in Mir 0.17. So please make sure Unity8 works with that and does not rely on the spuriously large acceleration that libinput introduces.

[Daniel van Vugt (vanvugt)]

Put another way; even if you disagree with me and prefer the the faster mouse in Mir 0.18, you're still going to find in some cases that's not enough to counter-act the slow cursor problem in Unity8. So Unity8 still needs fixing.

[Daniel van Vugt (vanvugt)]

Additionally, balancing a slowdown with an acceleration where accuracy has already been lost due to acceleration (bug 1522295) makes for a sub-optimal user experience. The user should have the benefit of being able to use the full precision of their device rather than having some of it lost in software.

[Andreas Pokorny (andreas-pokorny)]

You can see this bug from various perspectives. For common mice mouse, movement of the cursor on a high dpi screen is just slow. But since you still need accuracy you cannot just scale the movement. To allow exact cursor placement, movement dependent cceleration is the proper solution for this problem.

The fact that the android input stack did not offer acceleration was not a decision we made for versions prior to 0.18, but rather a bug in the velocity tracker for some reason it queried and tracked a non existent touch id. Fixing that required refactoring our tests to not rely on that bug. Which happened in the course of this year. In the end we just switched to libinuput.

[Daniel van Vugt (vanvugt)]

I agree abolishing acceleration is not a final answer, and there will be configurations where it is needed.

However, the acceleration introduced in Mir 0.18 is insufficient and inappropriate to address this bug. The slow-down recently introduced in Untiy8 is too pronounced, and needs to be fixed in Unity8.

[Daniel van Vugt (vanvugt)]

Wow. Even more weird, it seems the cursor moves more slowly the faster you move the mouse. For fastest cursor movement in Unity8 you have to move the mouse more slowly.

Feels like pointer acceleration done backwards. Although the underlying Mir version is still 0.17 so nothing's changed there. It's only Unity8 that's a problem.

[Daniel van Vugt (vanvugt)]

Correction: What it really feels like is that Unity8 has hardcoded dx and dy to be only one of {0,-1,+1}. So it feels like it's ignoring the motion delta (distance and velocity) information provided by Mir.

[Daniel van Vugt (vanvugt)]

So comment #1 is starting to make sense now. Although I won't discount #14 just yet. Need to wait and retest with Unity8 when Mir 0.18 hits xenial.

[kevin gunn (kgunn72)]

also worthy of pointing out in this topic is this idea from tvoss
https://code.launchpad.net/~thomas-voss/mir/test_an_idea/+merge/280353
currently built here
https://requests.ci-train.ubuntu.com/#/ticket/779
just need to install silo and add
initctl set-env --global MIR_CLIENT_INPUT_RATE=0
to /usr/share/upstart/sessions/unity8.conf then reboot of course

Secondarily, from alberta adding
initctl set-env --global QML_NO_TOUCH_COMPRESSION=1
also results in snappier touch input reaction

[Daniel van Vugt (vanvugt)]

tvoss' branch is off topic, and undesirable as mentioned in the MP.

Also, I already added QML_NO_TOUCH_COMPRESSION=1 to the whole ubuntu touch image a couple of months ago. Not sure why it would be missing anywhere now...

[Daniel van Vugt (vanvugt)]

This bug was never fixed. I rediscovered it yesterday and now logged as --> bug 1539009

[Daniel van Vugt (vanvugt)]

Won't Fix. Discussion moved to bug 1539009 instead.