Am Donnerstag, den 22.08.2019, 21:23 +0800 schrieb Kai-Heng Feng:
at 18:38, Oliver Neukum <oneukum@xxxxxxxx> wrote:
Well, sort of. The USB spec merely states how to enter and exit
a suspended state and that device state must not be lost.
It does not tell you what a suspended device must be able to do.
But shouldnât remote wakeup signaling wakes the device up and let it exit
Yes. Have you tested using a button? If they indeed do not work, then
the device lies about supporting remote wakeup. That would warrant a
quirk, but for remote wakeup.
Or itâs okay to let the device be suspended when remote wakeup is needed
Again, the HID spec does not specify what should trigger a remote
wakeup. Limiting this to mouse buttons but not movements is
inconvinient, but not buggy.
This is indeed what Windows does. The device is suspended when the
screen saver switches on. That we do not do that is a deficiency
To use runtime PM regularly you need an .ini file
In other words, if on your system it is on, you need to look
at udev, not the kernel.
So if a device is broken when âpower/controlâ is flipped by user, we should
deal it at userspace? That doesnât sound right to me.
If it is broken, as in crashing we could talk about it. If it merely
does not do what you want, then, yes, that is for user space to deal
Well, no. Runtime PM is a trade off. You lose something if you use
it. If it worked just as well as full power, you would never use
full power, would you?
I am not asking the suspended state to work as full power, but to prevent a
device enters suspend state because of broken remote wakeup.
What then would be the difference between suspended and active? A small
delay in data transfer?
Whether the loss of functionality or performance is worth the energy
savings is a policy decision. Hence it belongs into udev.
Ideally the kernel would tell user space what will work in a
suspended state. Unfortunately HID does not provide support for that.
I really donât think âloss of functionallyâ belongs to policy decision. But
thatâs just my opinion.
That is just what we do if, for example, you choose between the configs
of a USB device or when you use authorization.
Maybe just calling usb_autopm_put_interface() in usbhid_close() to balance
No, the refcount is good. If remote wakeup is totally broken, you need
to introduce a quirk that will prevent the kernel from believing the
device when it claims to support it.