Bug 389870

Summary:	Mouse KCM > Advanced: Add "Pointer deceleration"
Product:	[Applications] systemsettings	Reporter:	Gregor Mi <codestruct>
Component:	kcm_mouse	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	nate, unassigned-bugs
Priority:	NOR
Version:	5.11.5
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	The unfinished patch for reference

Description Gregor Mi 2018-02-04 12:48:27 UTC

For some users it would be helpful to easily set a "Deceleration" value for the mouse.

In former times, I could accomplish this by using a startup script like this:

1. Find out pointer device id: $ xinput list (e.g. "13")
2. List properties for device: $ xinput list-props 13
3. Set the device deceleration: $ xinput --set-prop 13 'Device Accel Constant Deceleration' 2

Roughly since 2017, this method does not work anymore, see e.g. https://www.linuxquestions.org/questions/slackware-14/xinput-and-mouse-deceleration-dude-4175617417

There is another method by creating a suitable file here /etc/X11/xorg.conf.d (see https://wiki.archlinux.org/index.php/Mouse_acceleration) which I did not try.

WISH: It would be nice to have a setting "Pointer deceleration" alongside the "Pointer acceleration" setting in the Mouse KCM "Advanced" Tab.

Three years ago, I tried to create a patch for this, but I did not succeed, see https://git.reviewboard.kde.org/r/117811/diff/

Comment 1 Gregor Mi 2018-02-04 12:53:40 UTC

Created attachment 110332 [details]
The unfinished patch for reference

Attach patch. Description from reviewboard:

```
Add new option for "constant deceleration" in KDE Control Module Input/Mouse.

OPEN ISSUE: setting is not stored or at least not restored from config and messes with other config values which will be reset to default. Why?

Testing with: $ kcmshell5 mouse
```

Comment 2 Christoph Feck 2018-02-22 22:16:18 UTC

Thanks for the patch! I am unsure if we should add features to the old xinput support code, when the future is libinput.

I still suggest to try your luck via a phabricator request to get feedback from Plasma developers.

Comment 3 Nate Graham 2019-08-01 17:02:39 UTC

I must agree with Christoph. Libinput is the future, and most users don't see the non-Libinput version anymore. I would recommend bringing this up with the Libinput developer Peter Hutterer, who I have found to be very reasonable.

https://gitlab.freedesktop.org/libinput/libinput/issues