[regression] Mouse movement is non-linear (annoyingly so) since introducing libinput

Bug #1524145 reported by Daniel van Vugt on 2015-12-09
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Won't Fix
mir (Ubuntu)

Bug Description

[regression] Mouse moves too fast since introducing libinput.

See also possibly related bugs under the 'pointer-events' tag.

Related branches

Could you describe under which conditions the pointer movement is to fast?
I suspect that we have to scale the acceleration down for low dpi screens - or to take the viewing distance into account: scale the acceleration bias with the viewing angle between two adjacent pixels...

Daniel van Vugt (vanvugt) wrote :

Zero acceleration please. Constant velocity.

Daniel van Vugt (vanvugt) wrote :

Although cursor velocity is something most operating systems get wrong (because of the large variation in peripherals and personal preference), I am suggesting that maximum precision (one kernel event motion unit == one pixel) is probably a good default. I think that's what we have in Mir 0.17 and earlier(?). So I'd like Mir to return to that, which should also solve bug 1522295.

Having a good default would be less important if an easy-to-reach GUI was available for the user to modify the speed. However even in Unity7 we have not achieved that, as the controls are inadequate (often slowest setting is still too fast), and some mice cause the speed setting bar to vanish completely.

Changed in mir:
milestone: none → 0.19.0
Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
Daniel van Vugt (vanvugt) wrote :

Figured out an awkward workaround to convince libinput to output nice motion data. Follow these instructions but tweak the final numbers (I use MOUSE_DPI=1000@1000) ...

but 1000 sounds like the default?

Oh and thumbs up for leaving out essential information...

Daniel van Vugt (vanvugt) wrote :

I think we can do better than the approach in comment #4 though. It seems a user-local config file or even an environment variable would be more practical. But those are enhancement requests for libinput.

Changed in mir:
status: In Progress → Triaged
milestone: 0.19.0 → none
assignee: Daniel van Vugt (vanvugt) → nobody
Daniel van Vugt (vanvugt) wrote :

> but 1000 sounds like the default?

Yeah, I know it's weird. Haven't looked at the libinput code in enough detail but despite the hard-coded default being 1000 DPI in libinput, a setting of 1000@1000 solves the speed issue for me (this bug). Although it requires a system-wide change by root, which is not ideal.

Daniel van Vugt (vanvugt) wrote :

See related bug 1528109

Changed in mir:
milestone: none → 0.19.0
Changed in mir:
milestone: 0.19.0 → 0.20.0
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision 3256, scheduled for release in mir, milestone 0.20.0

Changed in mir:
status: Triaged → Fix Committed
Daniel van Vugt (vanvugt) wrote :

That's not a fix that landed, but a handy workaround.

Changed in mir:
status: Fix Committed → Triaged
summary: - [regression] Mouse moves too fast since introducing libinput
+ [regression] Mouse moves too fast in Mir demo servers since introducing
+ libinput
Changed in mir:
milestone: 0.20.0 → none
tags: added: libinput
Daniel van Vugt (vanvugt) wrote :

Clarified the description because we also came to realize that libinput's acceleration curve slows down cursor movement (too much) for small user movements, as well as speeding up cursor movement for larger physical movements.

summary: - [regression] Mouse moves too fast in Mir demo servers since introducing
- libinput
+ [regression] Mouse movement is non-linear (annoyingly so) since
+ introducing libinput
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers