Why would you want to expose all those states to userspace? I feel like
it is going to be risky to have userspace changing the state machine for
suspend like that.
The reasoning is that if userspace is to be made able to run while the
device is in those states it should be able to command the device to
enter them. Right now the sleep _DSMs are tucked above the LPS0 call
after userspace is frozen. Specifically for the sleep _DSM I am not
suggesting that all software should be able to run after it is called.
But this limitation responsibility is placed on the init system
currently for the Linux desktop (android has wakelocks).
I see. This is a pretty big change you're proposing, I think we should
see what Rafael has to say.
In the case of systemd, this would be potentially two-tier freezer
groups. The first freezer group for userspace apps is implemented
already to improve hibernation behavior. A second freezer group could
be introduced for crucial lightweight services that are able to run
and hold locks under this sleep state. In addition,
suspend-then-hibernate/spurious wakeup checks* can also run in this
sleep state, to avoid powering on the power LED of a device/fan for
certain manufacturers when checks happen.
OK I get the concept of two cgroups of frozen processes. In your mind
what are some samples processes that would actually be in the other group?
And do you really need the LPS0 _DSM callback to be active at this time?
*non-existent currently-but newer Modern Standby devices like to wake
up randomly due to e.g. charge state change
I wouldn't expect anything to be random here - I would describe this as
unhandled wakeup reasons.
Since the _DSM call that is interesting here is focusing specifically on
screen off I have a slightly different proposal on how this could work.
Both Sleep and Screen Off DSM are interesting but let's focus on
Screen Off for now.
What about if instead of an explicit userspace calling interface it's an
inhibition/voting interface:
While in screen on:
* By default no inhibitions are set.
* If no inhibitions are set and all physical displays go into DPMS then
DRM can do an call (using an exported symbol) to enter screen off.
* If userspace is using a remote display it could set an inhibition.
* When the inhibition is cleared (IE userspace indicates that a remote
display is no longer in use) then:
* if all physical displays are already off call screen off.
* if at least one physical display is on do nothing (turning off
physical displays would call screen off)
While in screen off
* When a physical display is turned DRM would use exported symbol to
call screen on.
* When an inhibitor is added call screen ON.
I think we have discussed some of the limitations of this approach in
a previous thread.
Userspace software that renders external displays would not have
rootful access to this API, it would use a dbus lock implemented by
systemd, in which case there is no need for a kernel side api
This is a solvable problem in userspace. It's the same problem no
matter you have a sysfs interface that does enable/disable or that inhibits.
Exporting these symbols to DRM would cause potential timing issues if
a CRTC is turned on and off rapidly. The calls in Windows are
debounced, specifically to after 5 seconds the screen turns off due to
inactivity.
What's wrong with it going quickly? If there is a problem, sure a
workqueue is just fine.
An inhibitor process in logind can handle this gracefully very simply.
Involving the DRM subsystem just adds a lot of complexity and it is
not clear what the benefit would be. There are no known devices that
hook DRM components into that DSM.
By doing it this way userspace still has control, but it's not
*mandatory* for userspace to be changed.
On that note, the screen off calls/userspace implementations are
optional under both patch series. If userspace is not aware of them,
they are still called by the kernel when suspending.
With the proposal I mentioned you can get the LPS0 _DSM called on a
handheld when the screen gets called without changing userspace.
Current userland also duplicates the functionality of the screen off
call, which is primarily turning off the keyboard backlight. So along
implementing this call, userspace software like powerdevil/upower
needs to be tweaked to avoid doing that if the screen off state is
available.
Sure Any hooking for turning off LEDs manually based off the screen off
_DSM is totally feasible.
