Can't enable hires scrolling on MX Master 2S

[krzysztofsroga]

Hires scrolling does not work on my MX Master 2S, the mouse scrolls by full increments.

Setting hires: false; target: false; makes scrolling very slow, unusable. Setting hires: true; target: false; works basically like the regular mouse, no smooth scrolling. Here's the xinput log(hires enabled):

...
button release 5 
motion a[3]=16530 
button press   5 
button release 5 
motion a[3]=16545 
button press   5 
button release 5 
motion a[3]=16560 
button press   5 
button release 5 
motion a[3]=16575 
...

The motion value increments always my 15 and happen rarely. The button is emulated every motion event.

And here's what I would expect(this is generated by my touchpad):

...
motion a[3]=14032 
motion a[3]=14033 
motion a[3]=14034 
motion a[3]=14035 
motion a[3]=14036 
motion a[3]=14037 
motion a[3]=14038 
motion a[3]=14040 
button press   5 
button release 5 
motion a[3]=14041 
motion a[3]=14042 
motion a[3]=14043 
motion a[3]=14045 
motion a[3]=14045 
...

So I would expect it to scroll quickly by little increments and update motion event multiple times per button emulation.

When I set target: true, no events are generated at all and mouse scrolling does not work.

Can I somehow make the mouse scroll smooth like it is on Windows? Or does hires scroll mean something else?

I'm running Manjaro KDE, Xorg, linux 5.5.

[krzysztofsroga]

Small update: Hires works when the mouse is connected by Bluetooth and not the unifying receiver. However it still sends button press instead of motion event and hence it's extremely sensitive - one wheel step scrolls by about one full screen.

[rhtenhove]

I came across the same issue. I have hi res scrolling working now on USB using Solaar. Haven't tested bluetooth. There the fast scrolling issue also happens, I've written a short piece on how to enable hi-res scrolling using Solaar and how to fix vertical scrolling here. It does however make horizontal scrolling awfully slow. Don't have a solution for that yet.

How to for per-pixel scrolling

Create a new udev hwdb file: sudo nano /etc/udev/hwdb.d/71-logitech-mouse.hwdb, and enter the following information:

mouse:*:name:*Logitech*:
    MOUSE_WHEEL_CLICK_ANGLE=1
    MOUSE_WHEEL_CLICK_COUNT=360

This will match all your Logitech mice, which might not be what you want. In that case replace Logitech with a more specific name, such as MX Master 3.

Now reload these rules to give them a try using the following commands.

sudo systemd-hwdb update
sudo udevadm trigger

[krzysztofsroga]

@rhtenhove It does not work for me on MX Master 2S. After creating the file, the behavior is quite different however. Now the scrolling occurs correctly by single pixels. But it's one pixel per wheel step. Awfully slow. If I disable highres, it's like one pixel every 10 wheel steps. It does not matter if I use logid or solaar - the same behavior.

Edit: And here comes another hack. For some reason sub-step wheel rotations are correctly detected only when I connect the mouse by bluetooth. Hence I decided to change 'Logitech' to 'Master' (Mouse connected by bluetooth does not have 'Logitech' in its name).

It finally works correctly! At least when the mouse is connected by bluetooth. I also changed 'click_count' to 120 so it's a little faster. Thanks!

Edit2: For some reason horizontal scrolling still work fine for me. Maybe that's because of bluetooth connection. Anyway, I'm happy with it. You can check it out too.

Edit3: Yes, horizontal scrolling is not affected only when the mouse is connected by bluetooth. Definitely check it out yourself if you look for solution to this issue :)

I think it should be added to readme until it's fixed in logid.

[krzysztofsroga]

Anyway, hires scrolling creates another issue. Clicking with the wheel without accidentally scrolling a little bit is virtually impossible. Hence to easily open links I had to remap other button to do it. Unfortunately I don't think it's possible to fix. I think on Windows it's solved in a way that hires scrolling is enabled only when the wheel is in free rotation mode.

[kris7t]

@krzysztofsroga How did you manage to make the scrolling actually hires? I am also using bluetooth, added the config file to hwdb.d, but I can only manage to get one pixel of scrolling per wheel step (if I set hires: false, it's even worse, just like the first time you tried).

[krzysztofsroga]

@kris7t Honestly... I don't know. I experience the same behavior as you described when I use solaar or connect the mouse by usb receiver(It works fine only using logid and bluetooth). On some other thread I have read that there were some changes to MX Master in the kernel 5.5.

[rhtenhove]

Did some more digging around.

To find out if hi-res scrolling actually works, you can use xinput test-xi2 --root (no sudo required). With hi-res you'll see events such as:

EVENT type 6 (Motion)
    device: 18 (18)
    detail: 0
    flags: 
    root: 330.91/611.97
    event: 330.91/611.97
    buttons:
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        3: 1971.00
    windows: root 0x227 event 0x227 child 0x260000a
EVENT type 17 (RawMotion)
    device: 2 (18)
    detail: 0
    flags: 
    valuators:
          3: 2.00 (2.00)

The second valuator will be a sum of scroll pixels that will be sent to the OS (if you scroll fast, that number grows quickly). For a quick and dirty view, xinput test-xi2 --root | grep 3: will only show this valuator value.

Without hi-res you'll see

EVENT type 6 (Motion)
    device: 18 (18)
    detail: 0
    flags: 
    root: 534.03/645.45
    event: 534.03/645.45
    buttons:
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        3: 1616.00
    windows: root 0x227 event 0x227 child 0x260000a
EVENT type 13 (RawKeyPress)
    device: 3 (12)
    detail: 37
    valuators:

Here each time it will scroll only one pixel, regardless of the valuator amount as shown in the previous block. As such scrolling will seem slow with just one pixel at a time.

Horizontal

I also found there's a separate setting for horizontal scrolling, so it isn't influenced by the high resolution we set the vertical wheel to. The following settings work like a charm for me:

# USB
mouse:*:name:Logitech MX Master 3:
    MOUSE_WHEEL_CLICK_ANGLE=1
    MOUSE_WHEEL_CLICK_COUNT=360
    MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
    MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14

# Bluetooth
mouse:*:name:MX Master 3 Mouse:
    MOUSE_WHEEL_CLICK_ANGLE=1
    MOUSE_WHEEL_CLICK_COUNT=360
    MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
    MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14

The 26 and 14 values are based on the systemd values mentioned here for the MX Master 2S.

Strangely I can't use :usb: or :bluetooth: as the settings then just won't apply. So I just use the names given through each protocol.

I think the behaviour you see over bluetooth is the same, as it just doesn't use hi-res. That's why horizontal doesn't seem affected, and you need to set MOUSE_WHEEL_CLICK_COUNT to a lower number.

I have yet to try enabling hi-res over bluetooth, I might do that when I find some time. Solaar won't do that since it only functions for USB.

[krzysztofsroga]

@rhtenhove No, I lowered MOUSE_WHEEL_CLICK_COUNT just because I liked it faster, it works well. And MX Master 2S gives 8 reads each step of a wheel so it needs count set to 180 to match non-hires scrolling. Currently that's what xinput returns and that's what I need:

3: 5880.00
3: 3.00 (3.00)
3: 5883.00
3: 3.00 (3.00)
3: 5886.00
3: 3.00 (3.00)
3: 5889.00

(8 times 3 for each wheel step, 24 pixels in total) When I plug in USB receiver, hires does not work. I mean I get 3 pixels per event but it's one event per wheel step instead of 8 when connected by bluetooth.

It looks like we get exactly opposite behavior - for me it works only on bluetooth, for you only on usb receiver...

[kris7t]

@krzysztofsroga Yeah, since Linux 5.5, I have to run with hires: true, otherwise scrolling is incredibly slow. Before 5.5., hires: true was incredibly fast, and hires: false was normal.

Despite having hires: true enabled (and the mouse connected over bluetooth, I am only getting ButtonPress and ButtonRelease events in xinput test-xi2. Complicating the matters, I am running under Wayland with sway, so xinput is running against XWayland. That means xinput test-xi2 --root does not receive any events for me.

I should maybe look into the source code for sway input handling, maybe it does some post-processing to mouse scroll events...

[krzysztofsroga]

@kris7t Wayland might be the reason why it does not work for you... I mean it changes a lot in how I/O devices are handled.

[kris7t]

Ah yeah, it seems libinput and sway may still lack the required patches: https://github.com/swaywm/wlroots/pull/1628

[CSpencerND]

This has worked for me for a long time, but suddenly stopped. It just doesn't do anything now.

[paolomainardi]

having the very same issues with an mx master 3s, enabling hires becomes incredibly fast and almost unusable, not yet tested with bluetooth.

[2ndBillGates]

Same