UHKv1 does not wake itself up from autosuspend (and does not poll the trackball)

[chrysn]

When connected to my laptop (Framework 13 Intel i5 13th gen) through a docking station (Dell TB16), my UHKv1 with trackball (and key cluster) goes into autosuspend after about 3 seconds of not being in use.

Consequently, movement on the trackball is not registered unless I press any key, which is annoying.

Also, all LEDs go off in that state -- I have no preference as to whether that is treated as a bug or a feature.

As a workaround, I completely disable autosuspend for that device using echo 'on' > '/sys/bus/usb/devices/3-2.7/power/control' (this is most conveniently done through powertop's Tunables tab, which shows the device name; there, it needs to be turned to "bad").

I don't know who describes the rules of autosuspend, so here are a few suggestions of how I guess this could be enhanced, in roughly decreasing order of preference:

• The UHK could keep the mouse working through autosuspend (possibly at a reduced polling rate).
• The UHK could advertise that it pretty please only be placed on autosuspend when power is limited (and Linux should honor the request).
• The UHK could not advertise autosuspend if the trackball (I'd guess the same goes for the other mice) is connected.
• Distributions could put the UHK on some list of devices where autosuspend should only happen during suspend.

[mondalaci]

No one has reported this issue previously. Has anything changed that triggered this bug? Also, which firmware version?

[chrysn]

I've originally observed this on 11.0 – but updated to 12.2.0 as you asked, and that does already appear to fix it.

Thanks for the quick feedback, and sorry for not checking firmware version first.

[chrysn]

Sorry, premature closing: As long as the agent is connected, this issue goes away. Then again, with 12.2.0 firmware applied, pressing a key is not sufficient to wake up the device any more.

It is unrelated to the docking station: this also happens when I connect the keyboard directly to the PC.

The OS I'm using is Debian testing.

[mhantsch]

I am not seeing this on my Framework 13 laptop running Pop_OS! 22.04. I have used different modules on my UHK60v1: touchpad, touchpoint, and trackball, and I never saw this unexpected autosuspend behaviour.

[chrysn]

@mhantsch, could you run powertop and look at whether the "Autosuspend for USB device UHK 60 v1 [Ultimate Gadget Laboratories]" line is "Bad" or "Good"?

This would help bisect this in "odd circumstances on my system automatically enable autosuspend" and "autospend is normal to be active but behaves weirdly under some circumstances".

[mhantsch]

>> Bad Autosuspend for USB device UHK 60 v1 [Ultimate Gadget Laboratories]

Just checked: it's Bad on my system. At least when I connect the UHK60 directly to the Laptop without any external hub.

[mhantsch]

But you're right: if I change it to Good, then I can see the same behaviour you are describing with the trackpad. After a few seconds of non-usage, the trackpad does not work anymore until I press a key.

This is a UHK60v1 with firmware 11.2.0.

[mondalaci]

If firmware 11.0 (the reported firmware version number is incomplete) was already affected by this issue, how so that only now we received a report about it?

[chrysn]

I've first observed this when I updated my docking station's firmware -- but that it also happens when directly connected to the PC (and mhantsch's reproduction) indicates that it's not the docking station's fault.

I've looked into the kernel documentation and found this:

Nevertheless, the sad fact is that many devices do not support it very well. [...]

For this reason, by default the kernel disables autosuspend (the power/control attribute is initialized to on) for all devices other than hubs. Hubs, at least, appear to be reasonably well-behaved in this regard.

I am unsure as to what is odd on my system that enables autosuspend on all peripherals, but I hope it is immaterial to the matter. It is relevant though to the severity: Unless we find that this setting is becoming more common, this whole issue is more a "quality of implementation" concern than a "there are users for whom things don't work". Nonetheless, I'd hope that the UHK behaves better than what the kernel docs claim are "many devices".

[mondalaci]

I can't reproduce this issue with firmware 12.3.3 on my UHK 60 v2 with Linux Mint 22.1 running on my i9-14900K (Z790) PC using any of the 3 right-hand modules regardless of the state of the Good vs Bad "Autosuspend for USB device UHK 60 v2 [Ultimate Gadget Laboratories]" powertop tunables state.

Suggestions are welcome.

[chrysn]

For the time being I think the best I can do is:

• update firmware to 12.3.3: no change compared to 12.2
• try around with more devices, and play around with power saving options, to find a better characterization of when this happens. (One thing I've tried is disabling autosuspend on the xHCI controller to emulate a controller that is not capable of suspending (just a hunch), but that made no difference).