Message-ID: 
 <CAGwozwG39oUYxLMm3638GxnS-n=yXU-ZypK7wJDwPXv2w=ZDjQ@mail.gmail.com>
Date: Sun, 7 Dec 2025 12:42:09 +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:07, 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).

a) is already implemented for AMD devices. I have not done a lot of
intel testing. Compositors just need to fire DPMS themselves.
b) already implemented by systemd
c) systemd has a binary called systemd-sleep[1]. After inactivity,
this script is called and is responsible for implementing the current
suspend target, whether that is sleep, suspend-then-hibernate.

It is currently pretty basic, and only handles one type of wake-up
event. This is the RTC timer/Battery alarm and only if in a
suspend-then-hibernate flow. Everything else is assumed to resume the
system and unfreezes userspace/turns on the displays.

But an initial "dark resume" feature/the sleep notification would go
in that file. For a more complete implementation, more userspace
refactoring would be needed, e.g., a secondary state after systemctl
suspend with some services that can mark to run periodically and are
frozen separately.

[1] https://github.com/systemd/systemd/blob/80cfe9abf267e9e51049e9d6200f02b7922bd4d7/src/sleep/sleep.c

> I'm not sure what the LPS0 _DSM role is in that.

Nothing, these _DSMs just contain vendor code for configuring device
appearance that is out of scope for kernel drivers.

> > 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.

1: Currently, it is fine for userspace to wake up and mine bitcoin in
a user's bag. My Nvidia thinkpad does that currently, it wakes up,
fails to hibernate and drains the battery. Sigh. So I am not sure why
in this case the kernel would need to be stricter.

2: Even if it "cheats", or e.g., does nothing, for the sleep state
that would mean an unbound power envelope. If the userspace
implementation is a bit reserved and e.g., handles wake-ups that
should not be a problem. For more advanced use-cases years down the
line perhaps it would be more of a problem.

3: Already done in the kernel side

4: Even if they unsync, I've tested them thoroughly in that state and
I have not found a device that malfunctions yet. So the implementation
of the check could be deferred.

> > 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?

When it comes to the kernel side, I do not think it is much work. The
draft series I had was around 12 kernel patches and could be condensed
a bit.

> 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?

Can't be delayed arbitrarily. Since it controls the suspend
light/keyboard backlight to have correct behavior it needs to fire at
exact moments to look correct. When it comes to resuming through user
input, the faster the better.

> 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"
> 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.
>

Yeah, that is a fair way forward. Moving the notifications for
sleep/display on to after userspace freeze, before userspace unfreeze.
Then optionally hooking drm to turn off crtcs before the notifications
(I did not follow the patches for that; it might already be the case).

Antheas

Powered by blists - more mailing lists