| Summary: | mouse kcm, advanced tab, pointer threshold minimum should be 0, not 1 | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Duncan <1i5t5.duncan> |
| Component: | kcm_mouse | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cfeck, kde, mgraesslin, unassigned-bugs |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/plasma-desktop/e92bf1746a211c266bad46eff9f536cef85fa6b1 | Version Fixed In: | |
| Sentry Crash Report: | |||
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. |
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.)