Bug 395681 - libinput pointer kcm needs 11 ticks on the speed slider so that the middle one can correspond to 0.0
Summary: libinput pointer kcm needs 11 ticks on the speed slider so that the middle on...
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_mouse (show other bugs)
Version: 5.13.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 397747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-06-21 09:22 UTC by grmat
Modified: 2018-08-22 16:39 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.14.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description grmat 2018-06-21 09:22:22 UTC
The new kcm for libinput mouse handling has a slider to set the libinput acceleration factor which has 10 stops, and therefore lacks a centered/neutral position.

It is currently not possible to disable mouse acceleration with libinput via the UI. Many users prefer a 1:1 mapping, and disable acceleration entirely.

A current workaround is to manually change ~/.config/kcminputrc and setting the value to 0.0 and never touch the kcm slider again.

I'd suggest to make it 11 stops, so we'll have 5 negative, a neutral and 5 positive settings, or add a convenience switch to disable acceleration entirely (set flat profile and neutral factor).

Please note that the leftmost setting results in strong deceleration (for the flat profile and for slow speeds in the adaptive profile as well) and not in disabling acceleration. The value given to libinput is not the speed or acceleration factor, but a parameter within [-1,1] that will affect the actual factor. See libinput docs[1] and especially The flat pointer acceleration profile[2] for further info. libinput has chosen bad terminology here and that should not be transferred to a DE's UI settings for usability reasons. You are not setting the "acceleration" with that slider but a parameter that affects the acceleration. And for the flat profile, it doesn't even actually affect acceleration but speed.



IMHO, it should also not override the system-wide settings set in /etc/X11/xorg.conf.d/, at least not initially on installing/upgrading Plasma. It's ok to override the settings, if the user tweaks the actual kcm manually. Two reasons:
 - there are Plasma users which have used libinput on X long before the kcm was updated
 - there are users which have several DEs installed, either due to pragmatism (some things work better here or there) or because they like to try new things at times

Those will most likely set their preferences globally. Now when a user has done that, then upgrades plasma to 5.13 or usually uses Gnome and wants to try plasma, he'll be left confused with weird mouse behaviour. That also includes things like inverse scrolling, middle-click emulation, ... and not only the acceleration factor (which would be bad enough).



[1]: https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
[2]: https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html#ptraccel-profile-flat
Comment 1 Nate Graham 2018-06-21 19:18:33 UTC
One bug per bug report please.

The 11-tick slider is an excellent point, and we'll do that and use this bug report to track it.

The label for the slider has already been changed from "acceleration" to "pointer speed" in the code; that should be released with 5.14.0, I believe.

For the issue about not reading the xorg.conf snippet (if available) to determine the default settings, can you file a separate bug?
Comment 2 Furkan Tokac 2018-06-21 19:53:53 UTC
Working on it.
Comment 3 Nate Graham 2018-06-21 19:56:57 UTC
Thanks Furkan!
Comment 4 Roman Gilg 2018-06-24 19:29:55 UTC
I don't see how an acceleration value of 0.0 would allow you to have a 1:1 mapping directly.

You will still experience an acceleration increase on fast movements, what is shown on your linked page in the first graph: the accel factor for 0.0 starts at 1 and increases linearly up to 2.

What you need is to select the flat pointer acceleration profile to have a 1:1 mapping.

Still it might make sense to have 11 ticks, so the middle one is the default value of 0.0.
Comment 5 Nate Graham 2018-06-24 19:35:38 UTC
(In reply to Roman Gilg from comment #4)
> Still it might make sense to have 11 ticks, so the middle one is the default
> value of 0.0.

Yeah I think that's the goal, and IMHO it makes sense.
Comment 6 grmat 2018-06-24 20:24:52 UTC
(In reply to Roman Gilg from comment #4)
> I don't see how an acceleration value of 0.0 would allow you to have a 1:1
> mapping directly.
> 
> You will still experience an acceleration increase on fast movements, what
> is shown on your linked page in the first graph: the accel factor for 0.0
> starts at 1 and increases linearly up to 2.
> 
> What you need is to select the flat pointer acceleration profile to have a
> 1:1 mapping.
> 
> Still it might make sense to have 11 ticks, so the middle one is the default
> value of 0.0.

Yeah, that's what I wrote. Thanks for the support.
Comment 7 Furkan Tokac 2018-06-26 20:13:45 UTC
Git commit 13b35bd8025a4bcf399670c32ee20327b0ace392 by Furkan Tokac.
Committed on 26/06/2018 at 20:12.
Pushed by furkantokac into branch 'master'.

Mouse KCM Pointer Speed Slider Improvement

Summary:
Slider value to libinput value mapping algorithm is changed. Tested and everything is working fine.
You can test it by changing value on slider and checking the libinput value from ~/.config/kcminputrc

Reviewers: ngraham, romangg, #plasma, mart

Reviewed By: ngraham, romangg, #plasma, mart

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D13672

M  +9    -6    kcms/mouse/kcm/libinput/main.qml
M  +9    -6    kcms/mouse/kcm/libinput/main_deviceless.qml

https://commits.kde.org/plasma-desktop/13b35bd8025a4bcf399670c32ee20327b0ace392
Comment 8 grmat 2018-07-02 09:30:18 UTC
thanks!
Comment 9 Furkan Tokac 2018-07-08 11:39:46 UTC
(In reply to grmat from comment #8)
> thanks!

Welcome. :)
Comment 10 Nate Graham 2018-08-22 16:39:38 UTC
*** Bug 397747 has been marked as a duplicate of this bug. ***