Description of problem: I use the Logitech B100 which I think is a super common choice (standard office mouse) - and with mouse speed maxed out under GNOME 3, the mouse is still painful slow on a Dell 4K screen (not sure if that is related or not). It's starting to cause me RSI-like exhaustion symptoms in my hand, so it would be nice if this could be addressed. Also, I would like to remark I feel like filing this same type of bug for different devices and environments at least once a year - therefore, I would again suggest that some way is found to remove the upper speed limit entirely, at least with some sort of hidden gconf option or the like. Version-Release number of selected component (if applicable): 1.10.5-3.fc27 How reproducible: Steps to Reproduce: 1. Use Logitech B100 2. Use 4K screen with 2x interface scaling under gnome-shell / GNOME 3 with no extensions (not sure if this is 4K / interface scaling thing is related, just mentioning it in case it is) Actual results: Even the fully maxed out mouse speed is way too slow. Expected results: Maxed out mouse speed provides a reasonable slightly-too-fast setting that satisfies everyone, allowing a full range of mouse speed preferences for everyone. Additional info:
I just upgraded to Fedora 28 / libinput 1.10.6-1.fc28, which has the same issue.
Same bug when you're running Gnome on Wayland? It should be fixed there because the compositor knows when to scale things. We have Option DPIScaleFactor in Fedora to work around this for the Xorg case (see man 4 libinput) but a good solution is hard to find for the Xorg case tbh.
Yea, you're right, the Xorg mouse speed is pretty much exactly the Wayland mouse speed on 100% UI scale (while on the correct 200%, Wayland is way faster). I would use Wayland, but until https://bugzilla.redhat.com/show_bug.cgi?id=1367666 is fixed I don't have much of a choice... (I tried it for a few weeks, but the session crashes interfere too much with work)
Best to use the DPIScaleFactor option then to work around this. As I said, there is no good solution for Xorg yet, so until we find one we need to use this workaround.
Is there a guide for this option somewhere? I just generated an Xorg config with Xorg :1 -configure and put in Option "DPIScaleFactor" "3.0" in the section for the mouse, but nothing has changed at all. Also, the libinput man page as seen here https://www.mankier.com/4/libinput appears to be wrong / misleading regarding the format: it describes the format as: Option "DPIScaleFactor" float However, Option "DPIScaleFactor" 1.0 leads to an instant abort of the X server. Only the format Option "DPIScaleFactor" "<float>" / Option "DPIScaleFactor" "1.0" appears to allow it to launch (but doesn't do anything for me).
Section "InputClass" Identifier "Scale this thing up up up!" MatchIsPointer "on" MatchDriver "libinput" Option "DPIScaleFactor" "2.0" EndSection Should do the job. It's a factor that gets multiplied with the deltas, so if 1.0 doesn't do anything then it works ;) Check the Xorg.log with journalctl, if the option never appears in the log then no driver parsed it.
Ok that worked, what I did was probably in the wrong section. However, I have 2x interface scaling (200%) and I use this option now to get a speed I actually like: Option "DPIScaleFactor" "3.0" (which is more than it should be to just compensate the UI scaling) Based on this, I would suggest the hwdb stuff for Logitech B100 should be tweaked to allow at least 1.5x the current maximum speed, if not even 2x-3x to what it is now.
Try running the mouse-dpi-tool, a quick google suggests the B100 has 800dpi, so MOUSE_DPI should be set for it in the hwdb. This could/should improve things a bit. libinput still does the right thing here, the coordinates that come out of libinput are in the correct scale for how they are documented. That's why a Wayland compositor can do the right thing when it knows the DPI of the screen doesn't match the DPI of the libinput coordinates. The X situation is a bit unfortunate but the DPIScaleFactor is literally the same as what the wayland compositor does.