Mir

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

Bug #1524145 reported by Daniel van Vugt
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mir
Triaged
Medium
Unassigned
0.18
Won't Fix
Medium
Unassigned
mir (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

[regression] Mouse moves too fast since introducing libinput.

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

Related branches

lp://staging/~vanvugt/mir/disable-libinput-pointer-acceleration
Rejected for merging into lp://staging/mir
PS Jenkins bot (community): Approve (continuous-integration)
Andreas Pokorny (community): Disapprove
Daniel d'Andrada (community): Needs Information
Diff: 71 lines (+18/-2)
4 files modified
src/platforms/evdev/libinput_device.cpp (+2/-2)
tests/include/mir/test/doubles/mock_libinput.h (+2/-0)
tests/mir_test_doubles/mock_libinput.cpp (+10/-0)
tests/unit-tests/input/evdev/test_libinput_device.cpp (+4/-0)
lp://staging/~andreas-pokorny/mir/add-option-to-disable-acceleration
PS Jenkins bot (community): Approve (continuous-integration)
Daniel van Vugt: Approve
Mir CI Bot: Approve (continuous-integration)
Kevin DuBois (community): Approve
Diff: 454 lines (+118/-45)
11 files modified
examples/server_example_input_device_config.cpp (+30/-11)
examples/server_example_input_device_config.h (+2/-8)
include/client/mir_toolkit/mir_input_device.h (+15/-0)
include/platform/mir/input/pointer_settings.h (+4/-0)
include/server/mir/input/pointer_configuration.h (+10/-4)
src/platforms/evdev/libinput_device.cpp (+16/-9)
src/server/input/default_device.cpp (+4/-2)
tests/include/mir/test/doubles/mock_libinput.h (+2/-0)
tests/mir_test_doubles/mock_libinput.cpp (+12/-0)
tests/mir_test_framework/fake_input_device_impl.cpp (+7/-4)
tests/unit-tests/input/evdev/test_libinput_device.cpp (+16/-7)
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

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...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Zero acceleration please. Constant velocity.

Revision history for this message
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
Daniel van Vugt (vanvugt)
Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
Revision history for this message
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) ...
http://who-t.blogspot.com.au/2014/12/building-a-dpi-database-for-mice.html

Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

but 1000 sounds like the default?

Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

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

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

See related bug 1528109

Changed in mir:
milestone: none → 0.19.0
Brandon Schaefer (brandontschaefer)
Changed in mir:
milestone: 0.19.0 → 0.20.0
Revision history for this message
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
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
status: Fix Committed → Triaged
Daniel van Vugt (vanvugt)
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
Daniel van Vugt (vanvugt)
tags: added: libinput
Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.