Message-ID: 
 <CAGwozwHi_U_R3ueJaYDaR_Pa6JntNbEh1dpwwbZW7jtrs5mbQw@mail.gmail.com>
Date: Tue, 2 Dec 2025 16:17:31 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mario Limonciello <superm1@...nel.org>
Cc: Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 "Rafael J. Wysocki" <rafael@...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 Tue, 2 Dec 2025 at 15:30, Mario Limonciello <superm1@...nel.org> wrote:
>
> On 12/2/25 3:32 AM, Antheas Kapenekakis wrote:
> > On Tue, 2 Dec 2025 at 05:36, Dmitry Osipenko
> > <dmitry.osipenko@...labora.com> wrote:
> >>
> >> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
> >> Display OFF/ON DSM notifications at runtime. 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.
> >>
> >> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
> >> ---
> >>   Documentation/ABI/testing/sysfs-power |  13 +++
> >>   drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
> >>   2 files changed, 145 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> >> index d38da077905a..af7c81ae517c 100644
> >> --- a/Documentation/ABI/testing/sysfs-power
> >> +++ b/Documentation/ABI/testing/sysfs-power
> >> @@ -470,3 +470,16 @@ Description:
> >>
> >>                   Minimum value: 1
> >>                   Default value: 3
> >> +
> >> +What:          /sys/power/lps0_screen_off
> >
> > Hi,
> > thanks for having a second stab at this. My initial series for this
> > was kind of complicated, I would need to rewrite it anyway [1].
> >
> > I will second Mario on the integer values. The main.c file provides
> > the capabilities used in other power sysfs values and an ABI for doing
> > string options.
> >
> > For me, I have a bit of a problem with the ABI. I kind of prefer the
> > one in [1]. There are three sleep states in Modern Standby: Screen
> > Off, Sleep, and LPS0/DRIPS (and a fake resume one I added). The only
> > one the kernel is suspended in is LPS0.
> >
> > So the ABI should ideally be able to cover all three, even if at first
> > you only do screen off. This means the name kind of becomes a problem.
> > lps0_screen_off implies lps0 (is not the state, is also an ACPI x86
> > specific term) and is limited to screen_off (cannot add sleep).
> >
> > I used /sys/power/standby in my series, which I think was fine because
> > you'd be able to add hooks to it for general drivers in the future.
> > This way, it would not be limited to ACPI devices and the name implies
> > that.
>
> Why would you want to expose all those states to userspace?  I feel like
> it is going to be risky to have userspace changing the state machine for
> suspend like that.

The reasoning is that if userspace is to be made able to run while the
device is in those states it should be able to command the device to
enter them. Right now the sleep _DSMs are tucked above the LPS0 call
after userspace is frozen. Specifically for the sleep _DSM I am not
suggesting that all software should be able to run after it is called.
But this limitation responsibility is placed on the init system
currently for the Linux desktop (android has wakelocks).

In the case of systemd, this would be potentially two-tier freezer
groups. The first freezer group for userspace apps is implemented
already to improve hibernation behavior. A second freezer group could
be introduced for crucial lightweight services that are able to run
and hold locks under this sleep state. In addition,
suspend-then-hibernate/spurious wakeup checks* can also run in this
sleep state, to avoid powering on the power LED of a device/fan for
certain manufacturers when checks happen.

*non-existent currently-but newer Modern Standby devices like to wake
up randomly due to e.g. charge state change

> Since the _DSM call that is interesting here is focusing specifically on
> screen off I have a slightly different proposal on how this could work.

Both Sleep and Screen Off DSM are interesting but let's focus on
Screen Off for now.

> What about if instead of an explicit userspace calling interface it's an
> inhibition/voting interface:
>
> While in screen on:
> * By default no inhibitions are set.
> * If no inhibitions are set and all physical displays go into DPMS then
> DRM can do an call (using an exported symbol) to enter screen off.
> * If userspace is using a remote display it could set an inhibition.
> * When the inhibition is cleared (IE userspace indicates that a remote
> display is no longer in use) then:
>    * if all physical displays are already off call screen off.
>    * if at least one physical display is on do nothing (turning off
> physical displays would call screen off)
>
> While in screen off
> * When a physical display is turned DRM would use exported symbol to
> call screen on.
>   * When  an inhibitor is added call screen ON.

I think we have discussed some of the limitations of this approach in
a previous thread.

Userspace software that renders external displays would not have
rootful access to this API, it would use a dbus lock implemented by
systemd, in which case there is no need for a kernel side api

Exporting these symbols to DRM would cause potential timing issues if
a CRTC is turned on and off rapidly. The calls in Windows are
debounced, specifically to after 5 seconds the screen turns off due to
inactivity.

An inhibitor process in logind can handle this gracefully very simply.
Involving the DRM subsystem just adds a lot of complexity and it is
not clear what the benefit would be. There are no known devices that
hook DRM components into that DSM.

> By doing it this way userspace still has control, but it's not
> *mandatory* for userspace to be changed.

On that note, the screen off calls/userspace implementations are
optional under both patch series. If userspace is not aware of them,
they are still called by the kernel when suspending.

Current userland also duplicates the functionality of the screen off
call, which is primarily turning off the keyboard backlight. So along
implementing this call, userspace software like powerdevil/upower
needs to be tweaked to avoid doing that if the screen off state is
available.

Both need to happen concurrently in order for there to be a user
benefit. If we try to implement it on the kernel side with a DRM hook,
we would just cause an inconsistency with userspace keyboard
brightness control.

You should try this series or mine in [1] on any Modern Standby Device
such as any Thinkpad newer than e.g. 2020 to see how it works. Screen
off controls the kbd backlight and sleep controls the power button
light (Asus/OneXPlayer still use the AMD LPS0 for that; Certain Lenovo
products such as the Go S use the screen off state for it)

Antheas

Powered by blists - more mailing lists