On 9/23/2024 11:43, Antheas Kapenekakis wrote:
If it were me, yes, systemd would switch the system to the inactive
"Screen Off" state 5 seconds after the system displays are off due to
inactivity. If we are talking about implementing something Modern
Standby-like, then pressing the powerbutton would no longer suspend
the device. Instead systemd would use two tiers of activators like
windows (first tier for "Screen Off", second tier for "Sleep"; right
now there is only one tier that mirrors screen off) and once all those
activators are released, suspend the kernel.
Then it would handle the transition from "Active" to "Screen Off" to
"Sleep" through a sysfs endpoint, with the platform responding by
e.g., lowering TDP and using a different fan curve.
If the kernel is asked to suspend outside of the Sleep state, then it
does the transitions to reach that state and references the quirk
table to avoid racing conditions in manufacturer firmware (not with
the kernel), before it suspends.
Important to note; it DOESN'T explicitly turn off displays. If you
configured it to suspend then displays get turned off as part of the
kernel suspend sequence (drm_atomic_helper_disable_all).
If it is configured to trigger a lockscreen then the compositor will
turn off displays after whatever the DPMS configuration is set to.
The problem with a DRM atomic helper is that we cannot control how it
is called and do debouncing. WIndows does debouncing (part of that is
waiting for 5 seconds so that if you move the mouse the call is
skipped). You could have edge conditions that spam the calls.
Antheas
I'm not meaning that anything in userspace SHOULD be calling
`drm_atomic_helper_disable_all`, my point was that this is how it's
normally called in the suspend sequence. Folks who work on the
compositors don't like anyone other than the kernel touching their
configuration at runtime.
I think a lot of what you're looking for is the concept of a systemwide
"userspace only" suspend sequence. A lot of devices already support
runtime PM and will already go into the low power state when not in use.
For example USB4 routers you'll see in D3 until you plug something
into the USB4 port.
IMO your proposal needs to cross at least 3 projects. Here's my
thoughts on it.
1) systemd
* To be able to handle behaviors associates with a dark screen only
suspend/resume. I did start a discussion on dark resume some time
back but it went nowhere. [1]
* Make sure that all devices have been put into runtime PM.
* Notify compositor that screens should be turned off.
* Manage transitions from dark screen to full suspend and vice versa.
2) Kernel
A. To be able to notify the _DSM at the right time that all CRTCs have
been turned off).
B. To be able to notify the _DSM at the right time that at least one
CRTC is now on.
3) Wayland protocols
Introduce a new protocol for requesting userspace suspend.
To notify that dark screen only suspend is being triggered.
4) Compositor use.
All the popular compositors would need to add support for the new
protocol. IE Gamescope, mutter, kwin.
This isn't a trivial effort, there are a lot of people to convince. I
think the lowest effort is to start with kernel. IE having DRM core
call the _DSM when the CRTCs are off. If you get that far, you can at
least get this power saving behavior when DPMS is enacted. Then you can
work with systemd and wayland protocol folks.
[1] https://github.com/systemd/systemd/issues/27077
