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@xxxxxxxxxxx> 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
