Re: [PATCH v2 2/5] acpi/x86: s2idle: handle Display On/Off calls outside of suspend sequence

[Mario Limonciello <mario.limonciello@amd.com>]

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