Bug 235630 - pointer acceleration in KDE should be optional
Summary: pointer acceleration in KDE should be optional
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_mouse (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Marie Loise Nolden
URL:
Keywords:
: 345549 (view as bug list)
Depends on:
Blocks: 327674
  Show dependency tree / graph
 
Reported: 2010-04-28 15:00 UTC by Simon Thum
Modified: 2020-03-19 14:17 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Thum 2010-04-28 15:00:24 UTC 
Version:            (using KDE 4.4.2)
OS:                Linux
Installed from:    Unspecified Linux

As the X.org server has a revamped pointer acceleration, KDE's habit of calling up
  xset m <mouse settings from system panel>
increasingly gets in the way. It might actually be the corresponding Xlib call, I don't know, but it has the same drawbacks.

More specifically, the X.org Server 1.8 and above allow to specify all supported pointer acceleration options as device options, which (together with InputClass sections) can match against hotplugged devices. However, on startup KDE will overwrite any such settings due to the mentioned behaviour.

So I request an option to suppress this behaviour, simply leaving the mouse settings to whoever cares.
Comment 1 Simon Thum 2010-04-28 15:09:43 UTC 
To clarify, I made it a bug not a wish since when 1.8 servers get common it will arguably be buggy behaviour.
Comment 2 Simon Thum 2015-01-05 20:08:40 UTC 
Sorry, wrong bin.
Comment 3 Simon Thum 2015-01-07 13:50:31 UTC 
Added corresponding user bug report as blocks. IMO this is a confirmation too.
Comment 4 Simon Thum 2015-01-07 15:04:36 UTC 
As of KDE 4.12.5 there is still no way of avoiding the change to pointer feedback on KDE startup. There is now a user bug as expected.

Should it, for some reason, not be OK to switch this to confirmed then please let me know the reason.
Comment 5 Simon Thum 2015-01-07 15:35:18 UTC 
Readding blocker bug. Sorry for the noise.
Comment 6 Simon Thum 2015-01-07 16:20:40 UTC 
Christoph,

I developed the new pointer acceleration. I am quite confident that KDE startup in 4.12.5 does modify the "pointer feedback class" using any of the means xset m, xinput set-ptr-feedback, or XChangeFeedbackControl. There is, since some time, a user bug report that I am very confident is confirmation for this bug, as expected.

Please let me know why you think "UNCONFIRMED" is an appropriate status.
Comment 7 Christoph Feck 2015-01-08 01:03:22 UTC 
Rather tell me why you keep closing the bug (RESOLVED or VERIFIED) if it is still to be investigated.

We use the CONFIRMED status if a KDE developer has confirmed in which KDE module the bug is. Until then it stays UNCONFIRMED.
Comment 8 Simon Thum 2015-01-08 10:51:09 UTC 
Well, I have only unconfirmed, resolved and needsinfo available to me. And unconfiremd seems wrong since there is confirmation. RESOLVED REMIND just seemd the most appropriate from the options I can see.

I leave it to you to pick the proper status, I just wanted to make sure this is not a misunderstanding.
Comment 9 Christoph Feck 2015-03-26 22:03:27 UTC 
*** Bug 345549 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2020-03-19 14:17:48 UTC 
There is now a flat acceleration setting in the libinput KCM.