High-resolution scrolling

[rightaditya]

This is a feature request for high-resolution scrolling via the trackball module.

Because the trackball module is (relatively) high-DPI, it should theoretically be possible for it to provide high-resolution scroll events. Changing scrollSpeedDivisor from the default of 8 to 1 sends 8 times the events, and of course the default interpretation by the OS is to scroll 8 times as much for a given physical distance.

Scroll speed can't always be adjusted sufficiently (if it can at all) to account for this; plus simply reducing scroll speed in the OS (when it's an option, that is) might not truly indicate to the OS that a fine-grained level of scrolling is possible; I'm not 100% sure on this but it even at lower scroll speeds it might still default to scrolling in larger discrete steps (e.g. never going lower than one line, even if a view can support scrolling fractions of lines).

AFAICT the "right" way to do this is to use the resolution multiplier control in the USB HID protocol (see, e.g., https://usb.org/sites/default/files/hut1_13.pdf). This functionality was developed in part by Microsoft, so it's how Windows does it, and AIUI the Linux support for high-resolution scrolling follows it as well, including some software-side conventions adopted in Windows (specifically, the 120 value assigned to a "standard" scroll detent). FWICT if a resolution multiplier is specified, the Linux kernel will just use that as a divisor for the scroll "amount", and clients that support the corresponding libinput events will handle the scroll accordingly (and there is a legacy event for those that don't).

(The only way I could find to change this value other than through the kernel—which does it via reading the resolution multiplier from the device—is using libinput-config, but that works globally and so affects all scroll devices.)

[rightaditya]

Just adding that I'd be happy to work on this myself, but would need some guidance as it's been ~15 years since I've done any kind of programming at this low a level (and never with USB).

[mondalaci]

Thanks for letting me know about the resolution multiplier control of USB! I didn't know about it. Assuming it works cross-OS, we should pick a fine-grained value that allows per-pixel scrolling and make the UHK firmware multiple scroll values accordingly.

@kareltucek Can you implement this or do we need Benedek for the USB part?

[kareltucek]

I fear we will need Benedek for this, as this is likely to violate the boot protocol compatibility.

[mondalaci]

I'm summoning @benedekkupper for a short comment about this issue. This is not a priority.

[rightaditya]

In case it's of use or interest: Peter Hutterer, who's been involved in the implementation of high-resolution scrolling throughout the Linux stack, has written a couple blog posts about how things work ^1.

[benedekkupper]

The boot protocol mode of the mouse is s farce, we should actually either disable the mouse boot support, or implement the report layout changing. Since until now noone noticed that it's broken, it's a safe bet to disable it.

Regarding the implementation it seems to me that we need to add an HID feature report to the mouse interface, with this resolution multiplier usage as the single element. The questions to clarify is:

1. what is the supported range of this value
2. what should be the default value
3. how this value is used in the mouse input report calculation
4. whether this value needs to be stored in non-volatile memory on the device, or the OS takes care of it

[mondalaci]

@benedekkupper I don't have solid answers, but regarding 1 to 3, can we have sensible defaults? Then we could tweak them. I don't understand question 4, so please elaborate.

[rightaditya]

I had a bit of time the last few weekends to look into this, and I have an implementation working (branched from the v11.1.1 tag) here. I've only tested it on Linux thus far.

For a more visual demonstration, here are some screen recordings:

• High-res scrolling, running my modified firmware
• Low-res scrolling, running stock v11.1.1 firmware

[mondalaci]

@rightaditya I'm very interested in this and your screencast is very promising, but I don't experience any change when testing your branch. Would you please open a PR and possibly provide instructions for testing? I'm on the latest Linux Mint.

[rightaditya]

@mondalaci Sure, I take it you'd prefer the PR be rebased to master first (rather than the v11.1.1 tag)?

As for testing—yeah, there are a couple of caveats (for Linux). The first is that not every application actually listens to the high-res wheel events, and so there will be no difference in those cases. Firefox is (for me) the most notable of these, followed closely by GNOME Terminal (even though both can scroll smoothly with my laptop's touchpad). Chromium, GNOME Web (aka Epiphany), and GNOME Files (aka Nautilus) all do use the high-res wheel events, though for some reason the former two feel like they have some kind of lag involved. But Nautilus works quite smoothly, and my recordings are from it.

I'm not too sure how much of an issue this might be, but one potential issue I can think of is the whole X11/Wayland mess. All of my tests have been with GNOME on Wayland (on Manjaro). I'm not totally sure if/how the high-res stuff gets handled on X11. evdev should still produce the relevant events, I think, since the kernel is really where they're ultimately coming from, but I don't know what happens with them beyond that. The patches to the kernel date back to before Wayland was as highly-used as it is now, so I think it should still work, possibly without libinput. Even if libinput turns out to be required, it's possible for Xorg to use libinput, and I think this is done by default in some distros/DEs.

So I guess that means:

1. Try it in an app that uses the high-res events (Nautilus, Chromium, Epiphany, and I'm sure there must be others).
2. If that doesn't work, try it in the same app(s) but on Wayland rather than X11. I think the most recent release of Linux Mint has added experimental Wayland support to Cinnamon.
3. If that doesn't work, try it in the same app but on GNOME on Wayland. Even running it in a live USB environment should work to avoid disturbing an installed system too much.

I'm sure there are other app/DE combinations that will work but haven't tested anything else just yet.

The final caveat is that, even in Nautilus, the scrolling is a little janky due to the wheel value accumulation that libinput applies to high-res scroll events. Essentially it waits for a value of 60 (which is equal to half a normal scroll detent) to be accumulated before issuing scroll events, and has a 500ms timeout on this. They do this to avoid small scroll events being issued when high-res wheels are pushed down to press a button, or just from being bumped accidentally. I'm running a patched version of libinput to get around this (it's just a one-line sed call to change the accumulation value from 60 to 1—I can point you to the relevant line if desired). There is a discussion going on about this on their Gitlab. My recordings were made with this patched version of libinput.

[mondalaci]

@rightaditya Thanks for elaborating; I really appreciate it! I'll test this with all three OSes and I'll try to test the suggested applications and environments.

Yes, I'd prefer the PR to be rebased to master.

[mhantsch]

Would this change also enable hires-scrolling using the touchpad, or is it currently only addressing the trackball? I mostly use the touchpad, and I've mapped mod+touchpad to scrolling. When I compare my laptop's built-in touchpad scrolling to UHK touchpad scrolling, the difference between hires and non-hires scrolling becomes really obvious.

If needed, I can test this with Linux (Pop_OS!, Wayland) and Windows 11.

[rightaditya]

@mhantsch I don't have the touchpad module, so I haven't tested it. But there's nothing in my branch that limits the changes to the trackball. I suspect it should work for the touchpad module too, since its resolution is high enough to use for controlling the cursor. (It won't do anything for the little ball on the key cluster, since that uses a much lower-resolution sensor.)

If you want to give it a shot, I've just uploaded binaries here. Just beware the potential caveats on Linux I mentioned above. For me in GNOME on Wayland, it works in Nautilus, Epiphany, and Chromium, but not in Firefox and GNOME Terminal.

[mhantsch]

@rightaditya Try to set MOZ_USE_XINPUT2=1 before launching Firefox and see if that makes a difference. I just checked my setup notes, and they say I added this:

echo "MOZ_USE_XINPUT2=1" >/etc/environment.d/99moz-maexxx.conf 

when I set up my Laptop. Don't ask me how I found out about this, I'm just trying to be good at documenting for my future self.

[rightaditya]

@mhantsch I remember trying that setting to no effect quite some time ago (months? years?). I don't think it does anything under Wayland.

[mhantsch]

@rightaditya I run Firefox under Wayland (Pop_OS! 22.04, a variant of Ubuntu) and it made scrolling smooth in both Firefox and Thunderbird, at least when using the built-in Laptop touchpad. I can scroll my Firefox page by pixel.

I'll try your build in the next day or two.

[mondalaci]

On Linux Mint 21.3, scrolling is much smoother in Nemo and Gnome Terminal, but there's no difference in Chrome and Firefox. I'll try Linux Mint 22 as soon as it's possible to upgrade.

On Windows 11, scrolling is much smoother in browsers, especially in Edge and Chrome. I can't notice a difference in Explorer.

On the latest OSX, I can't notice any difference in Safari, Chrome, and the built-in file manager.

Where it's supported, hi-res scrolling already makes a huge difference, and I reckon the firmware can be optimized to better use of it regarding mouse keys and modules. @kareltucek should be able to comment on the details when he gets home from vacation.

@benedekkupper Feel free to look into the USB implementation and suggest possible improvements, although this issue is currently not a priority.

Excellent work, @rightaditya!

[rightaditya]

I run Firefox under Wayland (Pop_OS! 22.04, a variant of Ubuntu) and it made scrolling smooth in both Firefox and Thunderbird, at least when using the built-in Laptop touchpad. I can scroll my Firefox page by pixel.

@mhantsch Huh, that's interesting. Setting that environment variable makes no difference for me, whether for the UHK trackball or my laptop's touchpad (the latter scrolls 1:1 either way).

[rightaditya]

On Linux Mint 21.3, scrolling is much smoother in Nemo and Gnome Terminal, but there's no difference in Chrome and Firefox. I'll try Linux Mint 22 as soon as it's possible to upgrade.

My guess is that X11/Wayland accounts for at least some of the discrepancies with my results (difference for Chromium but not GNOME Terminal). Unfortunately I couldn't test under X11, likely because of a broken X11 config on my system. I don't imagine it'd affect anything though, since your results show that it does at least have an effect for some applications under X11 (I'm assuming that's the case for you based on Mint's Wayland port/readiness status).

On Windows 11, scrolling is much smoother in browsers, especially in Edge and Chrome. I can't notice a difference in Explorer.

Just tested this and got the same results as you in Edge and Explorer. I've also now got the firmware responding to individual axis settings as configurable by registry keys according to

On the latest OSX, I can't notice any difference in Safari, Chrome, and the built-in file manager.

It's totally possible that their HID driver doesn't support the resolution multiplier feature, in which case this won't work, at least OOTB. The good news is that the firmware seems to be behaving correctly and not activating high-res mode unless the relevant HID request is sent. (Otherwise you would've seen the scrolling become 120x more sensitive with the build from my branch.)

Excellent work, @rightaditya!

Thank you!

[mhantsch]

@mhantsch Huh, that's interesting. Setting that environment variable makes no difference for me

I might have set it while I was still running under X11. At some point in time, I switched my login from X11 to Wayland, but I might have chosen that setting before. It definitely made a difference when I first configured it.

Anyway, let me run some tests on what we have now.

[mhantsch]

If you want to give it a shot, I've just uploaded binaries

I finally got to test your build, and I don't see any difference on Pop_OS! 22.04. I tried Firefox, Chrome, the Files browser and a number of other apps that scroll smoothly with the built-in trackpad of my Laptop, but still exhibit jumpy scrolling with the UHK. I tried the trackball, trackpoint and touchpad modules. Everything seems to behave the same way as with the regular UHK firmware.

Except for one thing: Mouse Scroll actions do not work anymore when triggered from keys.

When I tap the corresponding key, the mouse scroll action no longer works (when using your firmware).

[rightaditya]

I finally got to test your build, and I don't see any difference on Pop_OS! 22.04.

That's weird... any chance you could give it a shot in a fresh environment (live USB would do)? Since we know it's worked (as much as it can) on Mint 21.3 and Manjaro, either of those would be good choices, but I expect the results should be similar for others (I'm particularly thinking of Ubuntu—and maybe more so Ubuntu GNOME—but I'd be surprised if things were different on, e.g., Fedora or Arch). Windows 11 would also be a good candidate.

Except for one thing: Mouse Scroll actions do not work anymore when triggered from keys.

That's definitely not great. I'm unfortunately out of town at the moment and thus AFUHK, so I can't try to reproduce this myself until I'm back. If you manage to try things out in a fresh environment, please try the mouse scroll actions there as well.

[mhantsch]

Let me try it on a Windows laptop, but I didn't have it with me when I tried your firmware. I'm still surprised I wouldn't see any change on Pop_OS! (since it's based on Ubuntu, it's usually pretty standard).

[rightaditya]

I'm still surprised I wouldn't see any change on Pop_OS!

As am I, but the surprisal is muted somewhat given that we got different outcomes with MOZ_USE_XINPUT2=1.

[mhantsch]

@rightaditya I now tried it under Windows, and yes, butterly smooth scrolling in browsers, Outlook etc. when scrolling with the UHK Touchpad module. Very nice.

Regarding the Mouse Scroll Action: with your software, it still scrolls, but only by 1 pixel per tap. With the regular firmware it scrolls by the same amount as 1 mouse wheel notch.

I haven't change any of my UHK configuration other than updating to your firmware.

So I think for Windows this is working well, just the Mouse Scroll Action needs to be adapted.

For Linux I am not yet satisfied. I'll do some more experiments when I get a bit more time. I need to switch back to X11 and see how that behaves as opposed to Wayland.

[rightaditya]

@mhantsch Thanks for testing!

I now tried it under Windows, and yes, butterly smooth scrolling in browsers, Outlook etc. when scrolling with the UHK Touchpad module. Very nice.

It should be even smoother if you adjust the speed/acceleration settings :) Just beware that changing them affects the whole trackball module, so it affects cursor speed as well. I found setting the base speed to 0.2, speed to 0.8, acceleration to 0.9, and scroll speed divisor to 12 to be reasonably close to the default settings (0.5, 0.5, 1, 8) for the cursor while increasing granularity of scrolling, especially when scrolling smoothly.

Regarding the Mouse Scroll Action: with your software, it still scrolls, but only by 1 pixel per tap.

That makes clear what I missed, thanks. Fixing this will require updates to my firmware. I'm still out of town and won't be back to my UHK for another week, so I won't be able to test anything until then. I think by default it makes sense to have the scroll keys (and scrolling via macros) have the same behaviour as stock, but it might also be useful to allow high-res control. I'll have to play around with this when I get back.

For Linux I am not yet satisfied. I'll do some more experiments when I get a bit more time. I need to switch back to X11 and see how that behaves as opposed to Wayland.

Yeah, I'm still surprised that you got the results you did. I think I know why scroll keys don't work for you—since I didn't scale those values accordingly in the firmware, the OS ends up spitting out tiny values, which must be accumulated to a minimum value before libinput lets them through. If I'm right, the scroll key should work on Linux if you hold it down (after which it will proceed the same larger chunks as you get with trackball scrolling, though of course much slower than reasonable).

You can try setting mouseKeys.scroll.initialSpeed, mouseKeys.scroll.baseSpeed (and possibly mouseKeys.scroll.{acceleratedSpeed,deceleratedSpeed}—I haven't figured out what exactly these two do) in the meanwhile. But they're limited to a maximum value of 255, which will still yield a slower scroll than the stock firmware.

I don't use the scroll keys much, if at all, so I'm curious: when you want to scroll further than you'd get with a single press, do you tend to hold them down, or mash the keys (or both, varying by situation; etc.)?

[mhantsch]

I'm curious: when you want to scroll further than you'd get with a single press, do you tend to hold them down, or mash the keys (or both, varying by situation; etc.)?

@rightaditya Depends on the situation: normally I hit the key once or twice, and if that's not far enough I hold it down to keep going for a while.

[rightaditya]

@mhantsch I've just uploaded a fix (that works for me, anyway). You can download the build here. Let me know how it goes—hopefully that fixes it for you too.

[mhantsch]

@rightaditya I finally tried your latest build, and yes, under Windows this works beautifully.

1. Scrolling with touchpad module is butterly smooth.
2. Mouse scroll action (bound to a key) now also scrolls properly.

Will test this on Linux another day.

[mhantsch]

@rightaditya @mondalaci I tested the build now under Windows, Linux, and MacOS. On Windows and on MacOS the scrolling is hires and smooth. On Linux, I don't see any difference from the regular firmware, it still scrolls in steps.

The issue with Mouse scroll action has been resolved. Mouse scroll actions triggered by keys work normally.

Because this build is an improvement at least for Win+Mac, I think the change should be merged.

It might be my particular Linux setup that prevents hires scrolling for whatever reason. I can hires-scroll with the built-in Laptop touchpad, but for whatever reason, not with the UHK. I will keep investigating.

[mhantsch]

And btw, it makes no difference on Linux whether I test this under X11 or Wayland; I just don't get hires scrolling.

I am a little lost how I can better trace this, or track down why it's not doing hires scrolling. Any suggestions gladly appreciated!

[rightaditya]

@mhantsch I'm definitely no expert, but let's see what we can figure out... I guess the first thing to check is whether the kernel is even issuing high-res scroll events. You can use evtest for this. For me the UHK device for the trackball is the second of the four presented. I think this should be consistent but you can try the other devices if you get no outputs. If the kernel is issuing high-res scroll events you should see REL_WHEEL_HI_RES (REL_HWHEEL_HI_RES for horizontal scroll) events in the output, with corresponding values that change depending on how much scrolling you're doing. When total accumulated values on an axis add up to 120 (or -120) there should then also be a REL_WHEEL (REL_HWHEEL for horizontal) event issued.

On Windows and on MacOS the scrolling is hires and smooth.

I'm surprised about MacOS given @mondalaci found no change! :thinking:

[mondalaci]

I just wanted to merge this, but then I noticed that mouse key movement is crazy fast on Linux and Windows 11 (but not on macOS). This must be fixed before the merge.

[rightaditya]

@mondalaci I've just pushed a fix. Binary here in case you want to verify that way quickly. My Windows install is misbehaving at the moment so I wasn't able to test it there, but I did verify both the broken behaviour before the fix and the restored behaviour afterwards on my Linux install. Scrolling via mouse keys is still high-res.

I'm surprised your macOS test showed no difference, though. The keyboard should've been sending the same increased values to it. I coded the high-res support to only be enabled if it seems clear that the OS is enabling it, so maybe your macOS isn't doing what I accounted for and so the high-res support stays disabled. Maybe there's some configuration somewhere since @mhantsch found the high-res scrolling to work on macOS. If I ever get a Mac I'll see if I can look into it further, but no one should hold their breath for this ;)

[rightaditya]

For anyone interested, Linux scrolling can be made smoother still by altering libinput's scroll accumulation threshold. Unfortunately they don't have this as a configurable option (yet) and so making this change requires recompiling it. Fortunately it's a super-easy change to make. Without it, there's a slight delay before scrolling starts when there hasn't been any scrolling for some timeout or when changing scroll directions; in the latter case especially it can feel pretty janky next to the otherwise very smooth scrolling. I've set up a package in the AUR that should help for anyone who's on an Arch-derived distro.

Another recommendation (this one regardless of OS) is to alter the speed settings for the trackball a bit as I described in this comment. It's technically possible to go even smoother still, but IMO that would make regular movement difficult to use. Properly supporting this I think would require separate settings for scrolling vs. movement, and TBH the settings I found are already very smooth.

[mhantsch]

Yes, I overlooked the bug in the mouse key movement.

I can confirm that this new build rightaditya/uhkfirmware: 11.2.0 #highres-2024-10-15 fixes the problem, and works fine on Windows 11.

I will test later on Linux and MacOS.

[mondalaci]

@mhantsch Do you still want to this this? If not, I'd merge it.

[mhantsch]

@mondalaci I'll get you some feedback today.

We have a public holiday today and I finally have some time to check some of the issues and questions that have piled up in the past weeks.

[mhantsch]

OK, I now installed rightaditya/uhkfirmware: 11.2.0 #highres-2024-10-15 on my UHK60v2 and will give it a go with Linux and MacOS. I already know it works well with Windows.

[mhantsch]

@mhantsch I'm definitely no expert, but let's see what we can figure out... I guess the first thing to check is whether the kernel is even issuing high-res scroll events. You can use evtest for this. For me the UHK device for the trackball is the second of the four presented. I think this should be consistent but you can try the other devices if you get no outputs. If the kernel is issuing high-res scroll events you should see REL_WHEEL_HI_RES (REL_HWHEEL_HI_RES for horizontal scroll) events in the output, with corresponding values that change depending on how much scrolling you're doing. When total accumulated values on an axis add up to 120 (or -120) there should then also be a REL_WHEEL (REL_HWHEEL for horizontal) event issued.

Yes, I am definitely getting hires events from the kernel (sudo evtest /dev/input/event27):

Event: time 1730479556.161948, -------------- SYN_REPORT ------------
Event: time 1730479556.186988, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -7
Event: time 1730479556.186988, -------------- SYN_REPORT ------------
Event: time 1730479556.229941, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -7
Event: time 1730479556.229941, -------------- SYN_REPORT ------------
Event: time 1730479556.313948, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -7
Event: time 1730479556.313948, -------------- SYN_REPORT ------------
Event: time 1730479556.363924, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -7
Event: time 1730479556.363924, -------------- SYN_REPORT ------------
Event: time 1730479556.372860, type 2 (EV_REL), code 12 (REL_HWHEEL_HI_RES), value -3
Event: time 1730479556.372860, -------------- SYN_REPORT ------------
Event: time 1730479556.507952, type 2 (EV_REL), code 12 (REL_HWHEEL_HI_RES), value -7

I tried a number of trace tools, and fired up different browsers (Chrome, Firefox) and other applications, but it seems they all just scroll in jumps. I don't know why on my Pop_OS the hires events are not reaching the applications.

Anyway, I can see that hires events reach the kernel, so the UHK must be doing things right.

On Windows and on MacOS the scrolling is hires and smooth. I'm surprised about MacOS given @mondalaci found no change! 🤔

Well, I just tested it again on my wife's Macbook Air running MacOS Sonoma 14.5. The smoothest of scrolling in Chrome; it's beautiful.

@mondalaci I am pretty sure now that my issues on Linux are somehow related to my PopOS installation. I can see the keyboard is emitting hires events, and it works beautifully in Windows and MacOS. I think this should be merged to become part of the mainstream UHK firmware releases.

[rightaditya]

@mhantsch If you want to dig a bit further, I think the next step would be to see if libinput is handling the high-res events as we want. What do you get if you do libinput debug-events /dev/input/event27 (assuming the evdev device number is the same) and then do some scrolling? What do the values for the POINTER_SCROLL_WHEEL events look like?

[rightaditya]

@mhantsch It just occurred to me—you mentioned you mostly use the touchpad module. Have these tests been on that or the trackball?

[mhantsch]

TouchPad module most of the time. But since I was seeing the Hires scroll events I am pretty confident the issue is with my laptop and not the UHK.

I'll send you some snippets from evdev logs when I get to it again (likely tomorrow).

[rightaditya]

TouchPad module most of the time.

Hmm, I was considering that this might be the reason, in case libinput is detecting the device as a touchpad and if (for some reason). I'm not sure this is possible though. What does libinput list-devices show for the UHK devices?

[mhantsch]

@rightaditya I just retested it with the trackball module, and it's the same. No hires scrolling on my Linux.

Here's libinput list-devices for the relevant devices (with the trackball module attached):

Device:           Ultimate Gadget Laboratories UHK 60 v2
Kernel:           /dev/input/event19
Group:            7
Seat:             seat0, default
Capabilities:     keyboard 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

Device:           Ultimate Gadget Laboratories UHK 60 v2
Kernel:           /dev/input/event27
Group:            7
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

Device:           Ultimate Gadget Laboratories UHK 60 v2
Kernel:           /dev/input/event28
Group:            7
Seat:             seat0, default
Capabilities:     keyboard pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

Device:           Ultimate Gadget Laboratories UHK 60 v2
Kernel:           /dev/input/event29
Group:            7
Seat:             seat0, default
Capabilities:     keyboard 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

If I run libinput debug-events /dev/input/event27 and turn the trackball very slowly to scroll, I get this:

2944: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2947: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
  ... event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
 event27  POINTER_SCROLL_WHEEL    +95.129s  vert -2.12/-17.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +95.129s  vert 0.00/0.0 horiz -7.75/-62.0* (wheel)
2948: event27 - wheel state WHEEL_STATE_SCROLLING → WHEEL_EVENT_SCROLL_TIMEOUT → WHEEL_STATE_NONE
2949: event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2954: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
 event27  POINTER_SCROLL_WHEEL    +98.371s  vert -8.25/-66.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +98.658s  vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +99.135s  vert -1.88/-15.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +99.422s  vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +99.822s  vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
2959: event27 - wheel state WHEEL_STATE_SCROLLING → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2960: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2965: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2966: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2967: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_ACCUMULATED → WHEEL_STATE_SCROLLING
 event27  POINTER_SCROLL_WHEEL    +102.947s vert -8.12/-65.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +102.947s vert 0.00/0.0 horiz -0.75/-6.0* (wheel)
 event27  POINTER_SCROLL_WHEEL    +103.196s vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +103.568s vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +103.810s vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +104.161s vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
 event27  POINTER_SCROLL_WHEEL    +104.364s vert -0.88/-7.0* horiz 0.00/0.0 (wheel)
2973: event27 - wheel state WHEEL_STATE_SCROLLING → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL
2974: event27 - wheel state WHEEL_STATE_ACCUMULATING_SCROLL → WHEEL_EVENT_SCROLL_DIR_CHANGED → WHEEL_STATE_NONE
  ... event27 - wheel state WHEEL_STATE_NONE → WHEEL_EVENT_SCROLL → WHEEL_STATE_ACCUMULATING_SCROLL

[rightaditya]

@mhantsch So it looks like libinput is indeed passing the events on properly. Some of this may be perceptual because of libinput's scroll accumulation... it looks like what you're doing is moving the trackball slowly, seeing no scrolling happening on-screen, and then stopping very soon after it finally moves. If that's the case, try scrolling in a single direction only for longer. You want to avoid those WHEEL_EVENT_SCROLL_DIR_CHANGED and WHEEL_STATE_ACCUMULATING_SCROLL events, because each of those means you have to move the wheel roughly the same distance as half of a scroll in low-res scrolling before anything happens. That would feel a lot like there's no high-res scrolling, especially if you stop very soon after that.

Maybe just open nautilus and browse to a directory with lots of files, like /etc, and try scrolling down slowly, but still fast enough to prevent WHEEL_STATE_ACCUMULATING_SCROLL events after the first bunch of them. If you're paying close attention it will still seem like it's going in steps, but the steps will be way smaller than without the high-res scrolling patch. You can accentuate the difference by changing your module speed/acceleration/divisor settings to the ones I provided above.

The values you're getting show that libinput is definitely handling the high-res scroll events. IIRC with low-res scrolling you'd only see values of -120 instead of the -7.0, -15.0, etc. that you're getting. With my speed/acceleration/divisor settings, the smallest magnitude I see is -2.0 (or 2.0 if scrolling upwards).

The other thing you can do is to compile and install a patched version of libinput, replacing the stock one provided by your distro. The change to libinput is minimal: just change the value for ACC_V120_THRESHOLD from 60 to 1 in src/evdev-wheel.c. This will get rid of that initial janky pause when you start scrolling.