Bug 1575406 - Maximum mouse speed with Logitech B100 on 4K screen is way too low
Summary: Maximum mouse speed with Logitech B100 on 4K screen is way too low
Alias: None
Product: Fedora
Classification: Fedora
Component: libinput
Version: 28
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-06 16:04 UTC by ell1e
Modified: 2018-05-10 03:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-10 01:25:18 UTC
Type: Bug

Attachments (Terms of Use)

Description ell1e 2018-05-06 16:04:37 UTC
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):

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:

Comment 1 ell1e 2018-05-06 18:45:48 UTC
I just upgraded to Fedora 28 / libinput 1.10.6-1.fc28, which has the same issue.

Comment 2 Peter Hutterer 2018-05-09 09:23:01 UTC
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.

Comment 3 ell1e 2018-05-09 13:09:55 UTC
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)

Comment 4 Peter Hutterer 2018-05-10 01:25:18 UTC
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.

Comment 5 ell1e 2018-05-10 01:33:17 UTC
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).

Comment 6 Peter Hutterer 2018-05-10 01:40:03 UTC
Section "InputClass"
  Identifier "Scale this thing up up up!"
  MatchIsPointer "on"
  MatchDriver "libinput"
  Option "DPIScaleFactor" "2.0"

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.

Comment 7 ell1e 2018-05-10 01:53:19 UTC
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.

Comment 8 Peter Hutterer 2018-05-10 03:20:35 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.