On Sun, 7 Dec 2025 at 12:20, Rafael J. Wysocki <[email protected]> wrote: > > On Sun, Dec 7, 2025 at 12:06 PM Rafael J. Wysocki <[email protected]> wrote: > > > > GMail did something silly to my reply to this message, so resending it > > in case it didn't make it to the lists. Sorry for duplicates. > > > > On Fri, Dec 5, 2025 at 11:52=E2=80=AFPM Antheas Kapenekakis > > <[email protected]> wrote: > > > > > > On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <[email protected]> wrote: > > > > > > > > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis > > > > <[email protected]> wrote: > > > > > > > > > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <[email protected]> > > > > > wrote: > > > > > > > > > > [cut] > > > > > > > > > > In Linux, making the system look like it is suspended even though in > > > > fact it isn't may be quite confusing, as a user may think that it is > > > > now safe to put a laptop in a bag, for example, but in fact it isn't. > > > > > > My thesis would be a proper userspace implementation running on a > > > laptop with a properly configured platform, it should be safe for the > > > user to put the laptop in their bag, even if it wakes up briefly > > > multiple times per hour without their knowledge or being perceivable. > > > > That's what Android phones/tablets do, but that's a vertical software stack. > > > > To implement something like this you need (a) support from the GFX driver > > in the kernel to go into system suspend back and forth without turning > > displays on and off, and (b) a mechanism to trigger system suspend > > automatically after a period of inactivity while in the "displays off, no > > GUI activity" state, and (c) support for system wakeup events in (b). > > > > I'm not sure what the LPS0 _DSM role is in that. > > > > > It is also a very valid point that this is a _very fine_ line that > > > Windows crossed with its userspace implementation and soured the > > > perception of Modern Standby for a lot of users. Buggy platform > > > firmware/insufficient tooling/control for OEMs, early on also > > > contributed to this. > > > > > > > > > > > > > > > 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=E2=80=94local and remote, if > > > > > > any==E2=80=94have 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 t= > > o > > > > > 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 > > > > > > > > Wouldn't just turning the display off be sufficient here? Why do you > > > > want to go for platform notification in addition to it? > > > > [cut] > > > > > There is a tendency by Microsoft to add OEM tooling that avoids the > > > need for creating platform drivers. > > > > > > This includes the WMI implementation which allows Windows userspace to > > > talk to hardware without having a signed platform driver, and now this > > > standardized set of notifications. Maintaining a signed > > > vulnerability-free driver is expensive. > > > > > > The Display On/Off notifications provide hooks for OEMs to customize > > > the inactive appearance of their device. Mostly, this is through > > > turning off auxiliary lights, such as the keyboard backlight. > > > > > > The sleep notifications provide a way for OEMs to limit the thermal > > > envelope of their machine and make it look like it is asleep, so that > > > it is safe for that device to wake up multiple times per hour, > > > including in a bag, without looking like it is awake. > > > > This is based on a very optimistic assumption that generally cannot be > > verified I'm afraid. > > > > (1) User space must not do anything silly like Bitcoin mining while > > this is done. > > (2) The firmware must not be cheating. > > (3) The GFX driver needs to be able to transition transparently > > between the "displays off" graphics state and the system suspend and > > resume flows. > > (4) The GFX driver activity needs to be coordinated at least somewhat > > with whatever user space entity would be responsible for triggering > > the notifications so they do not get completely out of sync. > > > > > Here is an example with how these DSMs would work with thinkpads. > > > > > > Windows does not have a Thinkpad backlight driver. There is auxiliary > > > and optional software, Vantage, which provides some of this. Assume it > > > is not installed. Then, in Linux, assume you disable the thinkpad > > > backlight driver, so upower loses control of the thinkpad keyboard > > > backlight. The thinkpad keyboard backlight is automatically controlled > > > by the EC through keyboard shortcuts. So are the power modes, via Fn+L > > > M H. > > > > > > Then, assume that Linux implements these _DSMs, and hooks them via > > > systemd as following: display on/off is hooked to occur when logind > > > would lock the session, i.e. after 5 seconds of inactivity or pressing > > > the power button. The sleep notifications are triggered by > > > systemd-sleep, before suspend-then-hibernate begins. > > > > > > The end result is that after the display turns off, the keyboard > > > backlight of the device will also turn off automatically without a > > > platform driver. This is true for all modern standby laptops at least > > > post ~2021. A lot of these do not have kernel drivers in linux. > > > > > > Then, if the sleep state is supported (spotty in thinkpads but > > > available in a lot of other hw), when the RTC Wake Alarm/battery alarm > > > wakes the device and systemd briefly checks whether it should > > > hibernate, it will still look like it is asleep, and it will have a > > > reduced power envelope, reducing the risk of overheating if it is in a > > > bag and lowering standby power consumption. > > > > > > I.e., without requiring vendor software, platform drivers, both > > > Windows and Linux present a full feature set out of the box. > > > > I guess it would be rather useful to start the discussion with this > > proposed flow, some time might have been saved by everyone. > > > > IIUC, the point is to make the system look "suspended" if it goes out > > of suspend briefly in response to a wakeup event (the other potential > > "benefits" of what the notifications can possibly do are in the domain > > of marketing IMV), but is it really worth the hassle? > > > > Assuming that the answer is "yes", which I'm not convinced about at > > all, can't the kernel simply defer the "screen on" notification to > > some time after thawing user space, so it can avoid doing it and the > > corresponding "screen off" one if the system is suspended again > > quickly enough? Perhaps so long as the GFX driver opts in? > > > > And now we get to the most important thing: even before trying to do > > the above, let alone exposing anything to user space, the existing > > suspend-to-idle flow in the kernel needs to be adjusted to do the > > "screen off" notification much earlier and the "screen off" > > The second one obviously should be "screen on", sorry for the typo. > > > notification much later than they are done today. I think that you > > should be able to argue convincingly for making this change. > > > > If this doesn't universally work for whatever reason, anything more > > will be out of the question. > > So let me repeat for extra clarity. > > The only change related to the LPS0 "screen off" and "screen on" > notifications that would be tentatively acceptable to me ATM, would be > to modify the suspend-to-idle flow to do the "screen off" notification > earlier (possibly even at the start of it) and the corresponding > "screen on" notification later (possibly at the end of it), provided > that one can convincingly argue that this should not introduce > regressions. >
>From what I recall that was my original plan. Yeah, it is a fair way forward. @Dmitry how would you like to approach this? SInce you re-started the discussion. What is your timeline/KPIs for this. I could personally try to whip up a small series after the merge window by rewriting what I have[1]. I have more experience now in drafting this kind of thing and that series added some cruft to the pm core with multiple additions to platform_s2idle_ops There is a _small_ quantitative difference due to moving the calls. Specifically, the power light responds a tad slower when waking a device. For the legion go (non-s) devices, Lenovo added a dummy 5 second timer to resuming the controllers because of some Windows bugs, and moving the calls causes the timer to start later. But that's the OEM intended behavior... Antheas [1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/
