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

Antheas Kapenekakis
2024-09-23T17:02:08Z

Here I should note that I will not wait for systemd.

As part of adding support for these devices with Handheld Daemon, I
snag the powerbutton already and I only have one userspace app running
anyway, Steam. The idea here would be double tap the powerbutton to
enter a "Download Assistant", custom lockscreen pops up, and two
seconds later DPMS triggers, system enters Sleep state and either when
a battery target is reached or the download finishes, it transitions
to actual suspend.

The challenges here would be if the _DSM calls for Display Off and
Sleep Entry are a nothingburger and do not save much battery and that
Steam uses very heavy compression that does a lot of CPU.

If I find it not useful, maybe I will skip it.

Antheas

On Mon, 23 Sept 2024 at 18:43, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> > 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