Logitech MagSpeed scroll wheel "stepped" mode not working; behaves as fully smooth scrolling in most apps; extremely fast horizontal scrolling

Eiri · August 12, 2026, 1:05pm

Hi! I have a Logitech MX Anywhere 3 mouse, the kind with a scroll wheel that’s stepped by default, but transitions to a smooth scroll if you give it a good yank to scroll a long file. Also, the mouse has a feature where, if you hold the previous and/or back buttons, you scroll horizontally.

Normally, on Windows and Mac OS, you need to install Logi Options+ to get this to work correctly. That is not a thing on Linux, though.

The good news is that on Linux, horizontal scrolling when holding the previous/back buttons seems to be built-in.

The bad news is that I’m having a lot of trouble setting up scroll sensitivity properly.

Vertical scrolling

Vertical scrolling in Firefox is okay. I’ve disabled smooth scrolling in its options, and as expected, one “step” of the scroll wheel scrolls one “chunk” of a page.

But in most other apps (e.g. system settings, Konsole, Kate), it doesn’t seem to “know” that my scroll wheel is stepped, and one “step” of it will scroll several small “chunks” of page quickly. It’s pretty distracting. Plus, just slightly nudging the scroll wheel without actually passing a step (including by accident) is sometimes enough to cause a slight scroll to happen.

Another annoying aspect of this is that currently the total scroll amount is a bit low to me in most apps (fine in Firefox). So I’d like to increase scrolling speed. But doing that would make the “slightly touch the scroll wheel and it scrolls” issue worse.

I’m not sure what Firefox does to make it work differently, but I really wish I could do the same system-wide.

Horizontal scrolling

Horizontal scrolling (when holding the previous and/or back button on the mouse) has all the same issues as vertical scrolling, except that Firefox does NOT restore “notched scroll wheel” functionality. Firefox is as broken as the rest, scrolling one chunk every millimetre of physical movement on my scroll wheel.

Plus, horizontal scrolling is EXTREMELY sensitive. One notch scrolls EXTREMELY far. One “millimeter scrolls a chunk” is already quite a bit of scrolling. Honestly, it scrolls as much per millimeter as I wish it scrolled per full scroll step. Frankly, while this is marginally better than no horizontal scrolling at all, it’s borderline unusable.

Examples

Horizontal scroll - Firefox: MDN page for overflow-x

On this page:

In the example box, use the inspector to modify the text to something longer to be able to see my huge scroll amount. I put in:

qwertyuiopasdfghjklzxcvbnm1234567890qwertyuiopasdfghjklzxcvbnm1234567890qwertyuiopasdfghjklzxcvbnm1234567890qwertyuiopasdfghjklzxcvbnm1234567890qwertyuiopasdfghjklzxcvbnm1234567890

Then, one full “step” of my scrollwheel brings me from this:

to this:

While one of the “millimeter scrolls a chunk” steps taken to scroll, a lot of which are triggered by one scroll wheel notch, already scrolls me this far:

which is a lot already; appropriate (or maybe even a bit too much) for a full notch.

Horizontal scroll - Steam Big Picture

It scrolls by so much I can’t really show it with screenshots, so here’s a video of how much one notch on my scroll wheel scrolls. It’s so much that some games are simply not accessible unless I do “micro-adjustments” by holding my scroll wheel between two steps.

Looks like videos aren’t allowed, so here’s a GIF:

Screencast_20260812_084738

Vertical scroll - Fine on Firefox

On this other KDE Discuss thread: Scroll wheel speed slow on MX Master 3 in certain applications after update to Plasma 6 / Wayland

From this:

One notch of my scrollwheel brings me here, with no intermediary steps:

Vertical scroll - too many steps in System Settings

Here’s another GIF to show the excessive granularity:

Screencast_20260812_090047

Vertical scroll - too many steps in Konsole

In this GIF, I do exactly ONE step on my scrollwheel. Yet you can see it scrolls in several chunks.

Screencast_20260812_090349

System info

Output from ujust device-info: UNTITLED - Pastebin Service

Output from kinfo:

WARNING: radv is not a conformant Vulkan implementation, testing use only.
Operating System: Bazzite 44
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.8-ogc1.1.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 32 GiB of RAM (30.7 GiB usable)
Graphics Processor: AMD Radeon RX 9070 XT

Settings screenshots

skyfishgoo · August 12, 2026, 5:16pm

was this mouse ever connected to a windows session where the proprietary software was used to “customize” any settings?

if so, it probably made firmware changes to the device that you cannot undo/reset without the windows software.

Eiri · August 12, 2026, 11:00pm

Yes, it was. What should I do exactly to “undo” all that?

skyfishgoo · August 13, 2026, 1:18pm

if you still have a windows boot, you will need to go back into that proprietary software and reset the buttons to their factory default.

as i suspected, the firmware was re-written by that software so now the button presses or wheel behavior are not sending the standard HID codes linux expects from a mouse.

had the same thing happen with my logitech keyboard where i had defined function keys to run a maco, but in linux those keys sent keycodes that did not match the keys so they didn’t work at all (just dead).

once if reverted them back to the default programing, they sent the correct key codes and linux was happy.

if you don’t have a windows boot available to you (and can’t borrow a friends windows machine) then you can use a Hirens.BootCD which will run a live windows session where you can download and install that proprietary software and then make the firmware correction.

Eiri · August 21, 2026, 9:42pm

Thanks for the idea! I don’t have a Windows PC anymore, but I do have a Mac laptop for work.

I went into the Logitech thing and reset all options to default… but sadly, back on Linux, I don’t see any changes.

skyfishgoo · August 21, 2026, 11:45pm

unfortunately being on immutable distro, there is not much else you can do.

Eiri · August 22, 2026, 12:59am

So should I try to bring it up with the Bazzite team?

skyfishgoo · August 22, 2026, 2:19pm

or try a different distro where you have more flexibility.

Eiri · August 22, 2026, 3:18pm

I’m only on Linux because immutable gaming distros promised easy-mode Linux. I would be too scared to go on something more “advanced”. It would suck if my personal PC started feeling like work.

But out of curiosity, if I were on a non -immutable distro, what would you be recommending?

skyfishgoo · August 22, 2026, 5:34pm

kubuntu LTS is a workhorse and has the same desktop, nvidia drivers are point and click.

fedora KDE is more cutting edge, but requires more from you to set up.

Eiri · August 25, 2026, 4:08pm

Let’s say I switch to Kubuntu or similar. What advantages would I get when it comes to solving this issue? How would I approach it?

Eiri · August 25, 2026, 4:23pm

Incidentally, while I did it on Mac OS a while ago and it didn’t change anything, I just tried installing Logi Options+ on my mom’s Windows laptop and restoring factory defaults there, just in case..

Didn’t change anything.

skyfishgoo · August 25, 2026, 5:52pm

there is a small chance that it will just work and fedora is more strict about proprietary driver code that kubuntu.

you can try a live USB to see for yourself.

when i run xev | grep button in a terminal and place the cursor inside the back square

my scroll wheel generates the following

when i roll toward me

    state 0x10, button 5, same_screen YES
    state 0x1010, button 5, same_screen YES

and when i roll away from me

    state 0x10, button 4, same_screen YES
    state 0x810, button 4, same_screen YES

perhaps if you go back into windows and reprogram the firmware to generate those codes, it will work as expected.

—

or, if you use input-remapper it can capture the existing scroll wheel event and turn it into something else that will scroll how you expect.

Eiri · August 28, 2026, 1:03pm

Hi! So, I’ve tried a bootable USB of Ubuntu (figured it would have the same drivers as Kubuntu, but would allow me to give Gnome a try), but I saw the same issue.

Command xev doesn’t seem to be available on a lot of distros these days, with X11 being phased out. So instead I found command libinput.

With sudo libinput debug-events | grep WHEEL, I get this result with 1 scroll away from me:

 event5   POINTER_SCROLL_WHEEL         +0.962s  vert -4.00/-32.0* horiz 0.00/0.0 (wheel)
 event5   POINTER_SCROLL_WHEEL      2  +1.010s  vert -2.00/-16.0* horiz 0.00/0.0 (wheel)
 event5   POINTER_SCROLL_WHEEL      3  +1.044s  vert -3.00/-24.0* horiz 0.00/0.0 (wheel)
 event5   POINTER_SCROLL_WHEEL      4  +1.050s  vert -3.00/-24.0* horiz 0.00/0.0 (wheel)
 event5   POINTER_SCROLL_WHEEL      5  +1.058s  vert -2.00/-16.0* horiz 0.00/0.0 (wheel)

With 1 scroll towards me:

-event5   POINTER_SCROLL_WHEEL         +0.006s  vert 11.00/88.0* horiz 0.00/0.0 (wheel)
 event5   POINTER_SCROLL_WHEEL      2  +0.014s  vert 3.00/24.0* horiz 0.00/0.0 (wheel)

With 1 scroll towards me WITH the side button held to trigger horizontal scrolling:

-event5   POINTER_SCROLL_WHEEL         +0.000s  vert 0.00/0.0 horiz 30.00/240.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      2  +0.130s  vert 0.00/0.0 horiz 30.00/240.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      3  +0.154s  vert 0.00/0.0 horiz 45.00/360.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      4  +0.170s  vert 0.00/0.0 horiz 60.00/480.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      5  +0.178s  vert 0.00/0.0 horiz 45.00/360.0* (wheel)

With 1 scroll away from me WITH the side button held to trigger horizontal scrolling:

-event5   POINTER_SCROLL_WHEEL         +0.000s  vert 0.00/0.0 horiz -30.00/-240.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      2  +0.072s  vert 0.00/0.0 horiz -30.00/-240.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      3  +0.114s  vert 0.00/0.0 horiz -45.00/-360.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      4  +0.130s  vert 0.00/0.0 horiz -30.00/-240.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      5  +0.138s  vert 0.00/0.0 horiz -45.00/-360.0* (wheel)
 event5   POINTER_SCROLL_WHEEL      6  +0.146s  vert 0.00/0.0 horiz -45.00/-360.0* (wheel)

The number of increments hit is pretty variable, it seems, but it does seem to lend credence to my initial theory: it’s not that it’s the wrong events, it’s that EVERY micro-increment is being taken into account as if it were a full scroll.

Somehow micro increments and full scroll steps are discernible, otherwise Firefox wouldn’t work as well as it does for vertical scrolling. If we could somehow get the other programs to do whatever Firefox is doing, we would have progress. Although the mystery of the immensely sensitive horizontal scroll would remain.

skyfishgoo · August 28, 2026, 4:11pm

the inconsistency in the number of events generated between measurements indicates to me a hardware fault, perhaps dirty / corroded contacts

it’s also possible that firefox polling is not as sensitive or fast as libinput

when i run that command this is my output from 1 scroll away from me

 event22  POINTER_SCROLL_WHEEL    +0.000s       vert -15.00/-120.0* horiz 0.00/0.0 (wheel)

then 1 scroll towards me gives

 event22  POINTER_SCROLL_WHEEL    +0.000s       vert 15.00/120.0* horiz 0.00/0.0 (wheel)

just one output per detent and the increments are bigger.

this page may be of interest

esp the part about how to file a bug report at the bottom

also might want to compare results from mouse-dpi-tool which you can get by installing sudo apt install libevdev-tools

my est sampling freq is 126Hz

Eiri · September 2, 2026, 12:19am

Ah, the variance doesn’t surprise me. The mouse is designed to be able to scroll smoothly (I can just press a button on the mouse and the magnet that locks the wheel in “stepped” mode is released, making the wheel’s movement completely smooth. Since there are many micro-steps that are physically available to the sensor, it makes sense to me that they would exist. The difference is probably in the fact that the mechanism/magnet isn’t 100% tight, and slight differences in how I move my finger.

My guess is that normally, on Windows / Mac OS, the software from Logitech catches all those and ignores them, only catching the “big” steps and translating those into real scrolls to the OS.

hmm, your results seem normal for a “standard” scrollwheel that isn’t capable of smooth scrolling. Is that what you have? If not, it’s a really interesting difference that I would get the micro-events and not you.

About libinput:

I don’t think I can install that, being on a Fedora-based OS that’s immutable. There doesn’t seem to be a flatpak for libevdev-tools

But I think I may be misunderstanding you. You’re saying maybe my mouse is erroneously triggering debounce when it shouldn’t, right? But isn’t a debounce meant to merge many quick inputs into one with a delay? It feels closer to the reverse of my issue.

But I’m assuming I’m misunderstanding you because what I’m saying isn’t making much sense.

skyfishgoo · September 2, 2026, 12:31pm

yes, my mouse has discrete scroll notches and is well behaved in libinput

what i’m saying is libinput might be getting overwhelmed by out stream of output from your mouse and not even the built in debouce can handle it.

so it’s passing more of the signal than it should for your device.

if you can set your device for discrete notches, does that behave better?

i only mention libevdev-tools as a way to tell what your mouse poling speed is, in case that is having an effect on behavior or how libinput is handling the stream of signal.

if your system is immutable then i’m afraid there is not much to be done about how it reacts to your input device