Bug 2014222

Changing the scale to 200% effectively doubles the mouse cursor speed relative to the device deltas sent by your device. This is in the vast majority of cases the right thing to do. What is the exact model for your mouse device? It might need an entry to the libinput device quirk database.

Oh wow, that is very weird.

To confirm your suspicion, I tried changing toggling the display scaling factor (GNOME Settings / Displays / Scale) between 100% and 200% and comparing the cursor speed.

Under a GNOME Wayland session, changing the display scaling factor immediately impacts the speed the mouse moves at. (Why would anybody want that? The cursor should move across the width of the display at the same speed if I move it across my desk with the same speed, regardless of display settings ...)

On the other hand, changing the scale from 200% to 100% and back on a "GNOME on X.org" session did not impact the speed the mouse cursor moved at at all.

But after logging out and back in several times to check different scenarios, I needed to turn the mouse speed (GNOME Settings / Mouse & Touchpad / Mouse Speed) *all the way down* to something like 10% or it would race across the screen faster than ever before, at like 4x or 8x speed.

So *something* is definitely not right here ...

The mouse in question is a Logitech MX Anywhere 2S.

But I have no idea why Wayland acts so weird, while behaviour on X.org (regardless of display scaling factor), and on Windows 10, for that matter, consistent.

I also tried connecting this mouse to my laptop (same display resolution, same 200% scaling, but smaller screen), and there the issue is the same:
Mouse moves very fast on Wayland, but with consistent speed on X.org.

Checking back: I've upgraded to Fedora 36, and I'm still seeing this issue.
I tried to gather some data to quantify the problem.

Setting the GNOME on Xorg session as reference point:
/org/gnome/desktop/peripherals/mouse speed 0.00
This is comfortable to use, and click targets are easy to hit.

To achieve approximately the same behaviour under wayland:
/org/gnome/desktop/peripherals/mouse speed -0.75
Without this setting, the desktop is almost completely unusable on Wayland, as I'm unable to hit any click targets unless I gently poke the mouse with a feather.

I still wonder why behaviour can be so different between Xorg and Wayland.
I thought both mutter + Xorg and the mutter wayland compositor used libinput?

The affected hardware: Logitech MX Anywhere 2S connected via USB Receiver (i.e. not via Bluetooth)

$ dmesg | grep Logitech
[    1.238364] usb 3-2: Manufacturer: Logitech
[    1.276437] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.0/0003:046D:C52B.0001/input/input2
[    1.328405] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:07:00.3-2/input0
[    1.333466] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.1/0003:046D:C52B.0003/input/input4
[    1.380454] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.1/0003:046D:C52B.0003/input/input5
[    1.432371] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.1/0003:046D:C52B.0003/input/input6
[    1.432417] hid-generic 0003:046D:C52B.0003: input,hiddev96,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:07:00.3-2/input1
[    1.437500] hid-generic 0003:046D:C52B.0005: hiddev97,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:07:00.3-2/input2
[    2.309039] logitech-djreceiver 0003:046D:C52B.0005: hiddev96,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:07:00.3-2/input2
[    2.415515] input: Logitech Wireless Device PID:406a Keyboard as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.2/0003:046D:C52B.0005/0003:046D:406A.0007/input/input10
[    2.415630] input: Logitech Wireless Device PID:406a Mouse as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.2/0003:046D:C52B.0005/0003:046D:406A.0007/input/input11
[    2.415675] hid-generic 0003:046D:406A.0007: input,hidraw2: USB HID v1.11 Keyboard [Logitech Wireless Device PID:406a] on usb-0000:07:00.3-2/input2:1
[    5.173396] input: Logitech MX Anywhere 2S as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2:1.2/0003:046D:C52B.0005/0003:046D:406A.0007/input/input15
[    5.173501] logitech-hidpp-device 0003:046D:406A.0007: input,hidraw2: USB HID v1.11 Keyboard [Logitech MX Anywhere 2S] on usb-0000:07:00.3-2/input2:1

Lets change component to libinput, it's likely some quirk needed to make the motion events from the device more sensible.

Thanks!

BTW, this issue also appears to affect the newer model (MX Anywhere 3) in the same way:

$ dmesg | grep "MX Anywhere"
[    2.856101] input: Logitech MX Anywhere 3 as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-1/3-1:1.2/0003:046D:C52B.0005/0003:046D:4090.0007/input/input14
[    2.856150] logitech-hidpp-device 0003:046D:4090.0007: input,hidraw3: USB HID v1.11 Mouse [Logitech MX Anywhere 3] on usb-0000:07:00.3-1/input2:1

Those models of mice are rather popular, I wonder why nobody complained about this earlier.

as a first reaction: I doubt this is libinput. libinput doesn't know whether it's X or Wayland that's providing the display stack so it cannot change behaviour. It also doesn't know about the display scaling (since it doesn't know displays exist).

These Logitech devices are programmable, so if this was consistent across everything I'd say: check your DPI and whether it's too high. The mouse-dpi-tool from libevdev-utils.rpm can help you there. *Maybe* the bug is in the other direction - it is simply at too high a DPI and "correct" under Wayland but off under X, but because it's too high it feels the other way round. Having said that, that's a bit of a wild guess.

Thanks, I didn't know about this tool, it at least seems to have printed useful information:

$ sudo mouse-dpi-tool /dev/input/event2
Mouse Logitech MX Anywhere 3 on /dev/input/event2
Move the device 250mm/10in or more along the x-axis.
Pause 3 seconds before movement to reset, Ctrl+C to exit.
Covered distance in device units:    12171 at frequency 166.7Hz |       \^C
Estimated sampling frequency: 166Hz (mean 124Hz)
WARNING: Max frequency is more than 30% higher than mean frequency. Manual verification required!
To calculate resolution, measure physical distance covered
and look up the matching resolution in the table below
     772mm	   30.43in	     400dpi
     515mm	   20.29in	     600dpi
     386mm	   15.21in	     800dpi
     309mm	   12.17in	    1000dpi
     257mm	   10.14in	    1200dpi
     220mm	    8.69in	    1400dpi
     193mm	    7.61in	    1600dpi
     171mm	    6.76in	    1800dpi
     154mm	    6.09in	    2000dpi
     140mm	    5.53in	    2200dpi
     128mm	    5.07in	    2400dpi
If your resolution is not in the list, calculate it with:
	resolution=12171/inches, or
	resolution=12171 * 25.4/mm

Entry for hwdb match (replace XXX with the resolution in DPI):
mouse:usb:v046dp4090:name:Logitech MX Anywhere 3:
 MOUSE_DPI=XXX@166

I moved the mouse along the long edge of an A4 paper, so ~300 mm, which would correspond almost exactly to 1000 dpi.

If it helps, I have another data point:

After upgrading to Fedora 38, I noticed that there's a new "Mouse Acceleration" Switch in the GNOME Settings GUI ... after disabling that, the mouse speed now feels perfect at 1.00 Pointer Speed setting.

I'd consider this "solved" for myself (i.e. I now have found a workaround that works perfectly), so feel free to close this bug (unless you want to keep it open and add hardware quirks for the MX Anywhere 2S and MX Anywhere 3).