Messages in this thread | | | Date | Thu, 23 Feb 2023 13:01:54 +0100 | Subject | Re: [PATCH] HID: usbhid: enable remote wakeup for mice | From | Oliver Neukum <> |
| |
On 23.02.23 12:23, Greg KH wrote:
>> I just want to explain the background of my patch, to prove we could use a >> similar way to avoid such a "disturbing" situation. >> To reduce the influence, my patch enables remote wakeup for USB mouse >> devices refer to what keyboard do. > > Keyboards are not mice :) >
OK, let me explain, why I never proposed switching on autosuspend for mice or using them as a system wakeup source. The reasons are very similar.
Basically the standard gives us no way to ask a device what constitutes a wakeup event for it. We just get the blanket statement of support or no support.
For runtime PM I would want my mouse to generate a remote wakeup whenever a button is pressed or the mouse is moved. Under this premise runtime PM with a mouse works wonderfully. Testing that, however, is a challenge. It turns out that mice that claim that they support remote wakeup by and large deactivate their LED/laser when you send them into suspension. Hence they react only to buttons being pressed or mouse wheels moved.
As a system wakeup source a mouse that generates events when it is moved, however, would make the system unsuspendable, whenever even a bit of vibration is acting on the system. And as S4 is used in many setups to prevent an uncontrolled shutdown at low power, this must work.
I suspect that most, but _not_ _all_ mice, are designed for use with a system that ties power management to the screen saver. That is a mode of operation that due to the lack of coupling between GUI and kernel is hard to copy.
Frankly given these constraints the only default safe in every case seems to me to leave the kernel's default at off and put the work into udev's hwdb. Not that that is a good solution, merely the best I can come up with.
Regards Oliver
| |