add high resolution scrolling to UHK-80, switch to standard defined implementation

[benedekkupper]

I have modified @rightaditya 's original implementation on the UHK-60, to instead follow the exact MS recommendation as laid out in the specs. Therefore this needs to be retested on UHK-60, especially with Linux host.

[mondalaci]

Now scrolling is surely high resolution on both the UHK 60 and UHK 80. But the multiplier should be adjusted because I have to scroll a mile with my module, which only results in a couple of pixels scrolling on the screen.

[benedekkupper]

We can freely choose what multipliers we use for both high-res and regular scrolling, we can even make it agent configurable. Simply change what VerticalScrollMultiplier() and HorizontalScrollMultiplier() are returning (currently they are 1 for regular and 120 for high-res scrolling).

[mhantsch]

I can test it on Linux, Windows, and MacOS with UHK 60 and UHK 80, but can I ask you to choose a reasonable multiplier first before I do all the tests?

[mhantsch]

It should default to a multiplier which gives it the same scrolling characteristics as before the upgrade to high-res scrolling. I have @rightaditya 's high-res build on one UHK 60, and with these settings it behaves pretty perfectly:

[benedekkupper]

It should default to a multiplier which gives it the same scrolling characteristics as before the upgrade to high-res scrolling. I have @rightaditya 's high-res build on one UHK 60, and with these settings it behaves pretty perfectly:

The multiplier values aren't changed from @rightaditya 's version, so if you see that the two versions (his and this MR) produce different behavior, let me know. The current version's intention is certainly to provide the same feel as before, that's why the scaling up by exactly the increased resolution. But since the scrolling mechanism itself is different, we will probably need some empirical tuning of this value.

[mhantsch]

if you see that the two versions (his and this MR) produce different behavior, let me know

OK, understood. Will test in the next few days and let you know.

[mondalaci]

I retested this, and scrolling is painfully slow on Linux and Windows, but it's a bit too quick on Mac :D Let's optimize for Linux and Windows first. Scrolling speed didn't change when changing scrollMultiplier to 120.f in processMouseKineticState.

@kareltucek Would you look into tweaking the multiplier?

[kareltucek]

Sure!

[benedekkupper]

macOS doesn't support high resolution scrolling, so there should not be a difference with or without this feature (well except for the change in the full scale of the scrolling, but I doubt that that plays a significant role). I also tested on Android, also not supported (somewhat unsurprisingly).

[rightaditya]

Just a note from when I was messing with this: I tried separating the multipliers so that they were independent for vertical and horizontal scrolling, but ultimately it was deemed unnecessary as, in practice, you can really only turn them on and off per-axis in Windows (it has no functionality to set the multiplier to different values, even if the device says it supports this). Turning it off on one axis but not the other ended up needing some adjustments to the axis-locking that were unnecessary complicated, so I ended up reverting the change and using just a single multiplier. Toggling high-res scrolling requires registry editing, and you have to go and look up the device's ID from Device Manager to figure out which entries to modify, so it seemed like it'd be exceptionally rare for anyone to actually use that capability.

Linux has no toggling ability, and IIRC it isn't something that could be fixed in userspace (e.g., by a compositor through libinput, etc.), as the relevant functionality isn't in the kernel either (from my looking through the high-resolution scrolling multiplier code, at any rate).

@benedekkupper's suggestion of making the multiplier Agent-configurable would get around some of this, but might require a device reboot for the OS to pick up on the changed value. The HID spec does have a mechanism for the device to report value changes to the OS, and I did test it out when I was implementing this, but IIRC neither Windows nor Linux did anything with it, so that functionality is likely unimplemented. (And I verified this for Linux.)

[mondalaci]

Assuming a reasonable constant multiplier is used for high-res scrolling with both axes, I don't see the need to adjust it via Agent given that it already allows adjusting scroll speed.