Did not mean how it is called as who will call it. But as in the way it is called does not match the desired behavior. In any case, as I said, I am happy to work in a downstream POC. My target usecase is very simple and I do not need/want to tie Display Off to CRTC. ie, I will do 2 and 4. I am already familiar with gamescope (including having two sockets open to it at any given time). Then if we get interesting results, we move on from there. As I said I also want to catch the Sleep _DSMs. I do not care about Display On/Off other than calling it properly (where properly = as in Windows + a lot of debouncing) so that these handhelds do not get confused. Antheas On Mon, 23 Sept 2024 at 19:05, Mario Limonciello <mario.limonciello@xxxxxxx> wrote: > > 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
