On 23.02.23 20:41, Limonciello, Mario wrote:
Hi,
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.
At least in my version of the series, this is part of the reason that it was
only intended to be used with s2idle.
Yes, that is sensible. If these patches are to be taken at all, that will
be a necessary condition to meet. But it is not sufficient.
The kernel driver is well aware of what power state you're in the suspend
callback (pm_suspend_target_state).
What about if we agreed to treat this one special by examining that?
If the sysfs is set to "enabled"
If user space needs to manipulate sysfs at all, we can have user space
tell kernel space exactly what to do. Hence I see no point in
conditional interpretations values in sysfs at that point.
We are discussing the kernel's default here.
* During suspend if your target is s2idle -> program it
* During suspend if your target is mem -> disable it
* During suspend if your target is hibernate -> disable it
To my mind these defaults make sense.
However, do they make much more sense than what we are doing now?
With that type of policy on how to handle the suspend call in place
perhaps we could set it to enabled by default?
It pains me to say, but I am afraid in that regard the only
decision that will not cause ugly surprises is to follow Windows.
Yet, what is wrong about the current defaults?
Turning on "autosuspend" for USB mice makes them behave pretty
similarly to how they work when they're marked for remote wakeup.
Because it is exactly the same mechanism.
On some mice the lasers turn off, and they only wakeup when you
press a button or roll a wheel.
Yes. And _some_ is the exact problem. If we could tell, _how_ mice
react, this discussion were unnecessary.
Regards
Oliver
