Message-ID: 
 <CAGwozwEgfH+QRpBXNGhZG5hxNF28A3ALbrABGYJg7RuFKDrM0A@mail.gmail.com>
Date: Sun, 7 Dec 2025 12:50:55 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Mario Limonciello <superm1@...nel.org>,
	Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org,
	kernel@...labora.com, linux-kernel@...r.kernel.org,
	Sebastian Reichel <sebastian.reichel@...labora.com>,
 Xaver Hugl <xaver.hugl@...il.com>,
	Richard Hughes <richard@...hsie.com>, William Jon McCann <mccann@....edu>,
	"Jaap A . Haitsma" <jaap@...tsma.org>, Benjamin Canou <bookeldor@...il.com>,
	Bastien Nocera <hadess@...ess.net>, systemd-devel@...ts.freedesktop.org,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface

On Sun, 7 Dec 2025 at 12:20, Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Sun, Dec 7, 2025 at 12:06 PM Rafael J. Wysocki <rafael@...nel.org> 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
> > <lkml@...heas.dev> wrote:
> > >
> > > On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > >
> > > > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis <lkml@...heas.dev> wrote:
> > > > >
> > > > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@...nel.org> 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/

Powered by blists - more mailing lists