GNOME Bugzilla – Bug 762889
Maximum mouse speed is way too slow (Mouse & Touchpad settings)
Last modified: 2021-06-09 16:06:09 UTC
I am using the trackpoint of a Thinkpad Yoga 260 with 12.5 inch at 1920x1080 screen res, and I turned up the mouse pointer and touchpad pointer speed to the maximum. This makes using the trackpoint mouse a barely usable average speed, but not anything close to being actually comfortable to use for me with my higher speed preference. I know I'm probably above the average user with my usual pointer speed expectations, but with the larger pixel density of this new laptop the problem has gotten even worse than with the previous machine and it's barely tolerable anymore. It just seems so arbitrary and frustrating that I can't make the mouse fast enough because someone decided that this medium'ish not-very-fast speed shall be the maximum for everyone.. Therefore, a raise to at least 2x of the current maximum, preferably 3x or more would be very much appreciated.
Which version of libinput are you using, and what's the output of: gsettings get org.gnome.desktop.peripherals.touch speed and gsettings get org.gnome.desktop.peripherals.touchpad speed 1.0 is the maximum value for those, and if that's too slow, we don't have a faster value for it I'm afraid, so changes would need to be made in libinput. It's possible that the algorithms don't take the DPI into account though.
jonas@localhost:~$ ls /usr/lib64 | grep libinput libinput.so.10 libinput.so.10.6.8 jonas@localhost:~$ gsettings get org.gnome.desktop.peripherals.touch speed No such schema 'org.gnome.desktop.peripherals.touch' jonas@localhost:~$ gsettings get org.gnome.desktop.peripherals.mouse speed 1.0 jonas@localhost:~$ gsettings get org.gnome.desktop.peripherals.touchpad speed 1.0 jonas@localhost:~$ And yes, that maximum is still way too slow. It was already unsatisfactory on my previous laptop, but on this one it's much more problematic
Peter, is this a libinput or mutter problem? Right now, the setting itself (both in the UI and the backend) is clamped between -1.0 and 1.0.
Jonas, look at https://github.com/systemd/systemd/blob/master/hwdb/70-pointingstick.hwdb. I suspect your laptop too needs an entry in that file to bring the default pointingstick speed to something normal. from then on, the libinput adjustment can make it faster/slower than the default. look at your /sys/class/dmi/id/modalias to find the match string, then try to just add that to the existing list. reboot, check if the speed makes more sense then. If not, please file a bug against libinput in the freedesktop bugzilla and assign it to me.
A friend of mine has the same issue (he prefers a quick mouse, but the input prefs "Fast" isn't that fast) and he has the X230t which is listed. Also, this comment seems a bit suspicious to me: # Note these come with 2 revisions of keyboard, with the trackpoints having a # different sensitivity in the different revisions. 1.25 is a bit slow for the # least sensitive revision, but it is better to be a bit slow than too fast. This comment refers to the default speed you mention, and apparently maintainers would rather err of it being on the slow side. So if you say I need to get that higher, that will probably just fix the issue as a hack for myself but not for others. I appears to me as if the true problem here is that just because someone decided on a slower default speed, the clamp to 1.0 prevents people from tuning it to their preferred multiplicator. Why can't I have 2.0 or 3.0? It just doesn't make much sense. Look at how GIMP does it with their brush size slider which allows much higher inputs than the displayed regular range. And if the libinput api internally requires an arbitrary 1.0 limit, then it seems like that API needs to be fixed..
Well I'm probably the wrong person to file a bug with libinput for their general API design since I have absolutely no idea how their API looks like. But I sure do think that if a user wants their mouse to be 2x, 3x or 100x as fast as their intended default, it should be allowed. What is the point of arbitrary limits on mouse speed??
(In reply to Jonas Thiem from comment #6) > Well I'm probably the wrong person to file a bug with libinput for their > general API design since I have absolutely no idea how their API looks like. libinput exposes a "speed" configuration toggle that has a double range of -1 (slowest) to 1 (fastest) > But I sure do think that if a user wants their mouse to be 2x, 3x or 100x as > fast as their intended default, it should be allowed. What is the point of > arbitrary limits on mouse speed?? mouse speed is not a simple multiplier, it's a combination of acceleration and threshold where the acceleration kicks in. Have a look through the documentation here: https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html You're welcome to improve on the acceleration curves, I'm happy to discuss this and guide you to get started.
Well all I was saying is I don't understand why I can't make my mouse speed e.g. twice as fast as my current 1.0 maximum speed. Like, why would there need to be such an upper limit? Just to explain my current line of thought from an end-user perspective Basically this bug report can be summed up as the suggestion of: Please consider a change in a way that would allow at least some sort of dconf-editor multiplier to speed up things beyond the currently regularly intended maximum limit or something. Whether you think that idea is actually something that should be accepted or rejected as developers of gnome or libinput is of course another matter, and I guess not really something I can influence much..
Also I don't fully understand why the detailed graphs matter..? Fact is in front of it all appears to be a -1 to 1 setting with a hard 1 upper limit and the upper limit can often be a bit too slow. Is it that hard mathematically to simply remove the upper limit and allow increasing with no upper limit other than the numeric limits of the floating point numbers? It seems like a no-brainer change to me..
Seriously, there's nothing to multiply, the maximum value accepted by libinput is 1.0. Passing a greater value would either be rejected, or clamped to 1.0, so it wouldn't help your problem. Comment 7 already contains information on how you should proceed if you want the acceleration curve to be different.
I was speaking mainly to Peter Hutterer, assuming he was from libinput. I'm just an end user, and while it sounds interesting it's a bit beyond my time commitment to read up on being an expert in the acceleration curves for a what appears to be a rather simple problem (I'm not saying the solution is!) of the api having an upper limit clamping where there shouldn't be one. I guess I could file a bug report somewhere else e.g. with libinput, although I'm not sure I'm the best person given how I just understand the symptom (clamping to 1.0) and not so much why this was done.
I tried myself at a libinput bug report now: https://bugs.freedesktop.org/show_bug.cgi?id=94953 I hope this will assist in moving this issue forward in a useful way
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.