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

Antheas Kapenekakis
2024-09-23T16:43:43Z

> On 9/23/2024 11:15, Antheas Kapenekakis wrote:
> > Does DRM core handle virtual displays like VNC?
> >
>
> You can make use of virtual display connectors in amdgpu. This is how
> drivers for new ASICs are first developed in emulation and also what's
> used for early hardware bring up.

Microsoft specificies all displays "state where all displays—local and
remote, if any—have been turned off"

If any means that no displays = no call perhaps. Would be interesting
when designing a system for disabled people though. Given how it
interacts in Windows, I want to say the target here is inactivity.

> > As mentioned in the cover letter, the _DSM specifies both virtual and
> > actual displays.
> >
> > Also, Windows behavior is like a lockscreen. 5 seconds after screen
> > turns off after inactivity, instantly when you press the power button.
> >
> > I tend towards making a sysfs entry. Not sure.
> >
>
> Who would call this sysfs file? Systemd? The compositor? When?
>
> In Linux the compositor is in charge of doing the modesets that involve
> turning on/off the screen. In most cases if you press the power button
> in Linux systemd-logind picks up the event. It triggers a behavior
> that's controlled by the logind configuration. Typically that's turning
> on a lockscreen and/or starting the suspend sequence.

That's where it gets hairy and an area WIndows uniquely does not have
a problem with because the OS is monolithic.

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