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
