Message-ID: <02103d95-7bca-4db0-81c6-ac36429ea0bb@kernel.org>
Date: Tue, 2 Dec 2025 15:25:26 -0600
From: "Mario Limonciello (AMD) (kernel.org)" <superm1@...nel.org>
To: Antheas Kapenekakis <lkml@...heas.dev>,
 Lennart Poettering <lennart@...ttering.net>
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
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface


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

I see.  This is a pretty big change you're proposing, I think we should 
see what Rafael has to say.

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

OK I get the concept of two cgroups of frozen processes.  In your mind 
what are some samples processes that would actually be in the other group?

And do you really need the LPS0 _DSM callback to be active at this time?

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

I wouldn't expect anything to be random here - I would describe this as 
unhandled wakeup reasons.

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

This is a solvable problem in userspace.  It's the same problem no 
matter you have a sysfs interface that does enable/disable or that inhibits.

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

What's wrong with it going quickly?  If there is a problem, sure a 
workqueue is just fine.

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

With the proposal I mentioned you can get the LPS0 _DSM called on a 
handheld when the screen gets called without changing userspace.

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

Sure Any hooking for turning off LEDs manually based off the screen off 
_DSM is totally feasible.

Powered by blists - more mailing lists