Bug 302309 - Options for tweaking xorg's “predictable pointer acceleration” implementation
Summary: Options for tweaking xorg's “predictable pointer acceleration” implementation
Status: RESOLVED INTENTIONAL
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_mouse (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Marie Loise Nolden
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-21 17:12 UTC by Travis Evans
Modified: 2022-04-26 23:59 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Travis Evans 2012-06-21 17:12:44 UTC
(Version 4.8.4)
Recent versions of xorg have implemented a new mouse pointer acceleration algorithm, activated by setting the “pointer threshold” setting to 0 pixels. The new acceleration model significantly improves mouse usability, especially on newer high-resolution pointing devices.

The settings module allows setting threshold to 0 pixels to take advantage of this feature. However, there are several more available settings beyond this to further tweak the acceleration, such as “Device Accel Constant Deceleration” and “Device Accel Adaptive Deceleration”, which can be configured in xorg.conf or with the xinput utility. It would be nice if System Settings offered a convenient way to adjust some or all of these additional options in the GUI when predictable acceleration is being used.

Reproducible: Always

Steps to Reproduce:
n/a
Actual Results:  
n/a

Expected Results:  
n/a
Comment 1 Nate Graham 2022-04-26 17:04:08 UTC
After 10 years, there doesn't seem to be any interest in implementing this feature. Closing, sorry. :)
Comment 2 Travis Evans 2022-04-26 23:59:16 UTC
It's probably a bit moot now since it was an evdev-specific feature and a lot of distros have seemingly moved to libinput since then anyway. In any case, the mouse acceleration behavior on recent (libinput?) setups I've used seems reasonable by default, or at least a lot more controllable than X's original “dumb” all-or-nothing algorithm. :-)