On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <[email protected]> wrote: > > On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko > <[email protected]> wrote: > > > > On 12/3/25 17:58, Rafael J. Wysocki wrote: > > >> Add `/sys/power/lps0_screen_off` interface to allow userspace to control > > >> Display OFF/ON DSM notifications at runtime. > > > Why? > > > > > >> Writing "1" to this file triggers the OFF notification, and "0" triggers > > >> the ON notification. > > >> > > >> Userspace should write "1" after turning off all physical and remote > > >> displays. It should write "0" before turning on any of displays. > > > This sets a limitation on the correct/expected usage of this > > > interface. How can the kernel ensure that the limitation is taken > > > into account? In principle, it should not allow OFF to be triggered > > > if any displays are "on", for example. > > > > > > And what exactly do you mean by "turning off a display". Cutting > > > power from it or something else? > > > > The common lowest level denominator for the "turned off display" should > > be that all display CRTCs are disabled and there are no active remote > > desktop sessions. > > > > For example, firmware of Intel laptops tracks state of a built-in > > display internally and treats display being tuned off when either > > display's CRTC is disabled or when backlight level is set to 0. This may > > be not the same for AMD firmware. > > > > Display On/Off notification is a hint to firmware that it's allowed to > > put machine into a lower power state where UI presented to a user may > > become non-interactive.
Jumping in for some more context The display on/off notifications do not put the hw into a low power state. It purely affects the presentation of the device. Specifically, the keyboard backlight/RGB, and for some devices the power button light/built-in controller for handhelds. Although devices that pulse the power button light due to it are very limited. In particular, I think it is Lenovo only. I have not run into another manufacturer that uses it. Specifically, their consumer revision. I would have to retest my thinkpad. Most manufacturers hook into the sleep DSMs for the power button or, e.g. Asus, with the LPS0 _DSMs. If you think about it, it makes sense. Turning off the display does not mean the device is not doing intensive work, such as rendering a video. So CPU/GPU/power envelope are unaffected and that's true for the ~7 manufacturers I tested. A lot of manufacturers do limit the power envelope as a response to the sleep _DSMs. Specifically, this is true for both Lenovo and Asus consumer divisions. For a device such as the Go S, it also completely turns off the fan. Typical power envelope is ~7W for this. This is also why there is a _DSM for speeding up resume and why I had a faux resume state in my series. > > To be precise, that's what MSDN has to say about it: > > "This _DSM Function will be invoked when the operating system has > entered a state where all displays—local and remote, if any—have been > turned off. This could occur based on some user action, e.g. a button > press or lid close event, or expiration of some display power down > timer." > > The "Intel Low-power S0 Idle" specification > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf) > says almost the same thing. > > None of them says what kind of hint this is to the firmware and what > the firmware is expected to do in response to it. It is true that online documentation does not list the firmware response. There is additional documentation that lists the exact entry conditions for display on/off [1] Specifically, while it is a prerequisite of the CRTCs, local/remote, being turned off, the actual condition mirrors when userspace would present a lockscreen to the user. I.e., if it is due to inactivity, those notifications fire 5 seconds after displays turn off, and if it is due to explicit action, e.g., power button, it is instant. "However, the system continues to run and all applications continue to operate normally as if the display was powered on." also implies that no hw is powered off as part of this notification. [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers > > In practice, entering this lower power state makes device to pretend > > that it has been suspended. On a laptop, keyboard backlight will be > > turned off and power button LED will start blinking. This allows us to > > implement the "resume to a dark mode", mentioned in the cover letter. > > Maybe, depending on what the firmware actually does. > > > It's up to userspace to make decision when and what DSM notification > > should be issued, thus the new sysfs control. > > Why would it be up to user space? > > > There is no strict requirement on having displays to be turned off when > > Display OFF notification is issued. Machine won't blow up when display > > is enabled and OFF notification is set. Hence, it should be unnecessary > > for kernel to be extra cautious RE trusting userspace. > > That is until one of them actually blows up when that happens. > > As it stands, I'm totally unconvinced. > > I generally think that allowing user space to trigger evaluation of > AML via sysfs is risky, pretty much regardless of what the given AML > has been designed for. Turning that into kernel ABI is asking for > trouble. I would tentatively agree, specifically in the way this series/ABI is phrased. My suggestion would be a more generalizable ABI that is not x86/ms specific. This way it can be bounded as appropriate to be safe and then expanded to other devices/drivers, including those that do not have an accompanying modern standby implementation. The risks for this are a bit overblown. A proper userspace implementation would always ensure that the displays have turned off, so in the case a niche device malfunctions with a display off notification and an enabled CRTC would leave ample time for the 2-3 DRM patches required to block it on the kernel side to be merged. Moreover, I have personally tested these DSMs on around ~9 devices by ~7 manufacturers, and we have been shipping a modified version of the series I sent in 2024 to around 200k users. That series pulls the notification firing above the place where DRM suspends the CRTCs and there haven't been any issues due to it. > Now, AFAIK this particular _DSM interface has been designed to be part > of the "modern standby" (or equivalent) flows, not to be used > separately, so assuming that it will always work the way you think it > will when used separately is kind of walking on thin ice IMV. In Windows, the modern standby flow is implemented in userspace as a coalescing function of different programs through their power manager and exposed to hardware through three notifications (DIsplay On/Off, Sleep, LPS0)[2]. My current understanding is that when it comes to the Linux desktop, it is also the responsibility of userspace to handle these different states, so for userspace to be able to implement this, it would need an ABI to configure the device into a similar state. What would be the way forward for this? I do not think it is realistic to defer implementing these features because they are only supposed to work with Windows. [2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications > And there is also a concern regarding all of the systems where this > firmware interface is not present or not supported that will not get > the "dark resume" experience associated with it. If you want "dark > resume" to be a feature of Linux, it should not depend on whether or > not a particular firmware is there and actually works the way you > like. > There are two implications here: 1) all hardware should support a "dark resume" feature, 2) this feature should not be locked behind a specific firmware/UEFI implementation. First one is not true. Legacy hardware that is not built with the ability to wake up periodically without turning on its fan, backlight, power light and with a reduced power envelope will never get the full benefit of such a feature set. Second one is tenable with a proper ABI that can be implemented also through e.g., EC platform drivers. In addition, pretty much all laptops post ~2021 support a subset or all of these DSMs and S3 support has been retired, when it comes to AMD since the ~7000 series APUs. This is not to say that all of it will work equally well though. Antheas
