> 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
