High-resolution scrolling breaks on Linux when waking from suspend

[rightaditya]

It seems that, when the system is woken from suspend, the Linux kernel doesn't do the full setup for the keyboard. Inspecting the USB packets shows that it does read the report descriptors, but it doesn't send the relevant SET_REPORT request that would inform the UHK to use high-resolution scrolling.

Unfortunately the kernel remembers the high-resolution setting from pre-suspend, while the UHK defaults to low-resolution scrolling since it never got the activation packet. This means scrolling scrolling is extremely slow, since there is a mismatch in the multiplier each side uses.

(Windows doesn't exhibit this issue.)

I don't see any way for the UHK to distinguish between initialization after wake vs. regular init. It looks like the kernel does send a SET_FEATURE before suspending. Potential solutions (on the UHK side):

1. If there's a low-power state used when the host suspends that maintains some volatile memory, the resolution multiplier could be stored there and read on init to restore proper behaviour. On proper shutdown/power loss/unplug (not just suspend), that memory would get wiped, making sure that the subsequent init work as it should.
2. Add a user-configurable setting to always use high-resolution scrolling. This would make sense for users where the UHK is always attached to the same device (or devices, where they all work properly with high-resolution scrolling). If the UHK is ever plugged into a device that doesn't work well with high-resolution scrolling, the user would have to disable the forced setting.

I can work on this, but I'm not sure if there is the requisite volatile memory maintained during a low-power suspend-type state required for the first option; and if not, I'm not sure if the second option is a desirable one (as a user, I'd be fine with it, but every device I use supports the high-res scrolling).

I'd be happy to contribute to another solution as well—the above two options are just all I've come up with for the moment.

[kareltucek]

When computer is suspended, uhk60 runs normally, just leds get turned off and some features get suppressed, so RAM state is remembered, so 1 shouldn't be a problem ;-).

For uhk 80, there are some nuances - if battery is pressent, it doesn't get powercycled between being reconnected to another computer, although detecting usb state should still be possible-ish. (Although we still don't have fully sorted out how these states are reported from c2usb.)

[benedekkupper]

#1155 is probably the same issue. I intend to continue working on this soon, there was some progress in #1216 but not complete yet.

[mhantsch]

I would not mind a "force high-res scrolling" setting. I would turn it on.

Could be a smart macro setting that can be thrown into $onInit...

[kareltucek]

@benedekkupper @rightaditya bump.

While relatively minor, this still is pretty annoying ;-).

[rightaditya]

Oof, I've definitely lost track of things over the last few weeks... or months... or years if we're being honest...

When computer is suspended, uhk60 runs normally, just leds get turned off and some features get suppressed, so RAM state is remembered, so 1 shouldn't be a problem ;-).

@benedekkupper Oh, hmm, if RAM is kept then it's less clear why this would be an issue at all. If it's in high-res mode before suspending, there's not much reason for that to change. Maybe the new packets on wake trigger something... 🤔

[rightaditya]

bump.

@kareltucek Just submitted a PR that fixed the issue for me.

It'd help if someone could double-check that it doesn't break anything for other OSes, though. It's a simple fix, so I really doubt it, but it'd be prudent to make sure :)