feat: hi-res scroll action

[xieve]

Closes #3123.

I don't know if Xorg has support for hi-res scrolling, but this will still make the adjustment of scroll wheel sensitivity much more granular even there, since the regular scroll events are emitted every 120 hi-res ticks as well, as per the kernel docs. Perhaps the info text regarding this could be improved, although I couldn't come up with a succinct description of this on the spot.

[pfps]

Would this work in X11 if uinput is used?

[xieve]

Would this work in X11 if uinput is used?

Pretty surely, yes. I can confirm that it is working in electron running on XWayland, at the very least.

[pfps]

Can you give some examples of rules with this extension?

[pfps]

There are style guidelines that are required in Solaar. Please look at the failing check and fix the non-conforming code.

[xieve]

I've fixed the code style, and changed the priority of the input simulation methods to use uinput first, and only fall back to xtest if it is not available.

Here's an example rule:

- Feature: THUMB WHEEL
- Rule:
  - Test: thumb_wheel_up
  - MouseScrollHiRes: [16, 0]
- Rule:
  - Test: thumb_wheel_down
  - MouseScrollHiRes: [-16, 0]

Tested on the MX Master 3, I would now describe the thumbwheel scrolling as "High Resolution".

[xieve]

Now the accumulator is global, across all instances of the MouseScrollHiRes class. I think this matches the expected behavior more closely, since a config such as the one above includes two instances of the class, one for each direction. If the directions are summed independently, this doesn't produce regular scroll events at regular angle intervals when switching directions often.

Interdiff for all changes

[pfps]

I don't understand the need for the accumulation.

[pfps]

uinput might exist but not be writable

[xieve]

I don't understand the need for the accumulation.

From the Linux Kernel Documentation:

If a vertical scroll wheel supports high-resolution scrolling, this code will be emitted in addition to REL_WHEEL or REL_HWHEEL.

I don't see any other way to do this than to keep track of the high-resolution data.

I think this event still needs to be emitted since not all programs support the newer high-res scrolling, and it wouldn't make sense for some, e.g. spreadsheets.

[pfps]

OK. The documentation isn't all that clear, though.

[xieve]

uinput might exist but not be writable

I tested this case:

2026-01-28 20:10:40,665,665     INFO [MainThread] logitech_receiver.diversion: MouseScrollHiRes action: [16, 0] True [16, 0]
2026-01-28 20:10:40,666,666  WARNING [MainThread] logitech_receiver.diversion: cannot create uinput device: "/dev/uinput" cannot be opened for writing
2026-01-28 20:10:40,666,666  WARNING [MainThread] logitech_receiver.diversion: no way to simulate scrolling

Since I am on Wayland, it doesn't try to use xtest, but you can still see that the uinput check fails as it's supposed to.

I've also used evtest to confirm that the events sent by my implementation look and behave similarly to those sent by the vertical scroll wheel when using hi-res scrolling.