In the mouse kcm, on the advanced tab, for the pointer threshold setting... The current minimum threshold is 1 pixel. It should be 0 pixels. The documentation I know of for this is the xset (1) manpage. Under option mouse (m), it says this about the threshold setting: >>>>> If the `threshold' parameter is provided and 0, the `acceleration' parameter will be used in the exponent of a more natural and continuous formula, giving precise control for slow motion but big reach for fast motion, and a progressive transition for motions in between. Recommended `acceleration' value in this case is 3/2 to 3, but not limited to that range. <<<<< That's exactly what I wanted, so I had my threshold set to 0 here... until I tried to adjust some other setting in the mouse kcm and set its minimum 1 px threshold instead. Now every time I restart kde/plasma I have a mouse that appears to be stuck in molasses, and while I can xset m 31/10 0 to get the speed back, it's back stuck in molasses when I restart kde again, because the 1 px minimum that plasma's mouse kcm sets apparently stuck! =:^( And indeed, xset q reports 31/10 1. So the mouse kcm needs to allow a 0 threshold, in ordered to enable people to set the "natural and continuous formula" acceleration by setting a 0 threshold. I guess I'll try to patch it myself, here, and will attach the patch here as well, if I get to it before someone from plasma does. Meanwhile, I suppose I'll have to dig thru thru the config files to find that setting and manually kill it, to get my 0 threshold "natural" acceleration formula back. =:^( (I'm running KF5/plasma live-git. kcmshell5 --version reports 5.8.90, ATM, but that's not an available choice in the version field above... and chances are it has had a 1 px minimum for some time, anyway, and I just got snared by it today.)
Interesting. We have bug 312379 that tells exactly the opposite, and I am not even sure we changed something (the mouse kcm is unmaintained since several years).
Indeed, commit https://commits.kde.org/plasma-desktop/8bee1a78b04aba4e07b27c7249c7fa7ff7e7a852 changed minimum value from 0 to 1, without referencing bug 312379. To me, it looks like a porting mistake instead of an intended fix. Additionally, https://wiki.archlinux.org/index.php/Mouse_acceleration says the threshold can be 0.
Git commit e92bf1746a211c266bad46eff9f536cef85fa6b1 by Christoph Feck. Committed on 11/11/2016 at 14:32. Pushed by cfeck into branch 'master'. Fix minimum value for mouse pointer threshold Regression caused by commit 8bee1a78b04aba4e07b27c7249c7fa7ff7e7a852 M +1 -1 kcms/input/mouse.cpp http://commits.kde.org/plasma-desktop/e92bf1746a211c266bad46eff9f536cef85fa6b1
That changes the situation for Wayland which I think Martin based on the assumption of being [1,20]
I see no discussion related to that change on https://phabricator.kde.org/D2853 Also, these settings have no effect on Wayland, see first line in MouseSettings::apply()
The settings apply for Wayland as KWin reads the config file. I think Kai's concern is not an issues as I used the protocol spec as source, not the code.