Description of problem: Mouse cursor movement and acceleration appear to be about twice as fast on GNOME on Wayland sessions compared to GNOME on X11 sessions. Without turning the mouse speed way down in gnome-control-center, it's almost unusably fast in GNOME on Wayland sessions. But then, logging out and back in with a GNOME on X11 session, mouse speed is way too slow again - so the difference definitely lies somewhere between X11 vs. Wayland. The mouse cursor speed is also the same under the GDM session as in the X11 session (both use X11, I run on proprietary NVidia drivers - given that it's impossible to buy AMD cards right now). In both Wayland and X.org cases, mouse input should be handled by libinput (I think?), so the only moving piece here is different code paths in the mutter compositor. If I'm wrong there and reported this bug against the wrong component, feel free to reassign as appropriate. Version-Release number of selected component (if applicable): mutter-41.0-3.fc35.x86_64 gnome-session-40.1.1-3.fc35.x86_64 libinput-1.19.1-1.fc35.x86_64 (up-to-date Fedora 35 install, with updates-testing enabled, as of Oct. 14 2021, plus the "pending -> stable" gnome-session bodhi update that fixes GNOME on Wayland support with NVidia driver) How reproducible: Always. Steps to Reproduce: 1. log into "GNOME on Wayland" session, experience way too fast mouse 2. log out 3. log into "GNOME (on X.org)" session, experience normal mouse speed Actual results: Mouse speed depends on the chosen desktop environment / windowing system. Expected results: The mapping of physical mouse movement speed to cursor movement speed should not be affected by switching between GNOME on X11 and GNOME on Wayland. Additional info: I have set the display scaling factor to 200%, since I'm using a 4K monitor. I don't know if that contributes to the issue, but since the 200% scaling would approximately coincide with the ~2x cursor movement speed on Wayland, I thought it worth mentioning. (I have also set font scaling factor to 75%, but I don't think that is relevant here.)
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).
This bug appears to still exist, and the bug report to Mutter on GitLab seems to remain inactive: https://gitlab.gnome.org/GNOME/mutter/-/issues/2311 It seems that, with mouse acceleration enabled (which I want to keep using and can't on Wayland) and DPI set to 200%, the cursor moves by 2 pixels at a time, skipping one pixel along the way, even when the mouse is moved very slowly. Visual evidence in the form of images is available in the above GitLab report. I am using GNOME 45
I have also encountered this bug on GNOME 45 (Ubuntu 23.10). I've experienced this on a laptop touchpad instead of a mouse, specifically the Lenovo Slim Pro 9i. I just figured out that this bug was caused by my scaling factor today. I also just discovered this bug report today. I had previously opened a bug report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/2041732. I did some research, and the relative mouse movement seems to be multiplied by the scaling factor here: https://github.com/GNOME/mutter/blob/9fd0f3f2dcf776368105c002672105806abf8f55/src/backends/native/meta-seat-impl.c#L1333-L1335. And this comment implies that this code should only be running on Wayland: https://gitlab.gnome.org/GNOME/mutter/-/issues/179. Specifically it says "that bug and resolution only applies to the Wayland back end."
I just patched out that code on my system and it fixed the bug for me! diff -u a/src/backends/native/meta-seat-impl.c b/src/backends/native/meta-seat-impl.c --- a/src/backends/native/meta-seat-impl.c +++ b/src/backends/native/meta-seat-impl.c @@ -1227,12 +1227,11 @@ MetaVector2 intersection; MetaDisplayDirection direction; MtkRectangle rect; - float scale; - meta_viewport_info_get_view_info (viewports, cur_view, &rect, &scale); + meta_viewport_info_get_view_info (viewports, cur_view, &rect, NULL); - target_x = x + (dx * scale); - target_y = y + (dy * scale); + target_x = x + (dx); + target_y = y + (dy); motion = (MetaLine2) { .a = { x, y }, @@ -1293,7 +1292,7 @@ float *dy) { int view, dest_view; - float new_dx, new_dy, scale; + float new_dx, new_dy; if (!seat_impl->viewports) return; @@ -1304,9 +1303,9 @@ if (view < 0) return; - meta_viewport_info_get_view_info (seat_impl->viewports, view, NULL, &scale); - new_dx = (*dx) * scale; - new_dy = (*dy) * scale; + meta_viewport_info_get_view_info (seat_impl->viewports, view, NULL, NULL); + new_dx = (*dx); + new_dy = (*dy); dest_view = meta_viewport_info_get_view_at (seat_impl->viewports, x + new_dx,
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
The issue is still present with GNOME 46 on Fedora 40 using 2x HiDPI scaling. Turning on the "Mouse acceleration" setting makes the pointer move *way too fast* to be usable.
This issue is still present on Fedora 42 with 1.5x scaling on Wayland.