linux-kernel - Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3142dc60-4a54-45f0-a4e7-c2e55bb7f39b@collabora.com>
Date: Wed, 3 Dec 2025 00:59:46 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Antheas Kapenekakis <lkml@...heas.dev>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 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 12/2/25 12:32, Antheas Kapenekakis wrote:
> 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.
> 
> Two other notes. At this point we tested pretty much devices from all
> manufacturers with my series. These notifications are used to control,
> for sleep: thermal envelope, fan, power button light, for screen off:
> keyboard backlight, device RGB, for lenovo power light as well. Yes,
> DRI should be cc'd, but no-one has used these notifications to do GPU
> specific stuff yet. You can call this ABI with a screen on just fine
> on all known devices.
> 
> Handheld manufacturers typically tie their controllers to them as
> well, as xinput does not implement the new suspend features in Windows
> and blocks restricted modern standby, so they have to be turned off
> beforehand. The exception to that is the Xbox Ally devices. This is
> because with the Ally X, Asus switched to the Xbox GIP protocol which
> does support these suspend features but still kept powering off the
> controller. For the Xbox Allies, they went a step further and no
> longer power off the controller.
> 
> Another difference between those two states and LPS0/DRIPS, is that
> the LPS0/DRIPS specification binds the state to the power state of
> certain onboard devices specified by ACPI (ie when the GPU, XYZ
> components suspend, you enter this state). With Screen Off/Sleep,
> there is no such requirement. For Screen Off, the general idea of a
> screen is used, but sleep is completely arbitrary and in Windows is
> defined by which software inhibitors lapse. This makes more sense
> because even for LPS0/DRIPS in Windows, the way it enters it is
> programmatic now as well (after all software inhibitors lapse). To
> that end, there are three types of inhibitions in Windows, one for
> screen on (such as video), screen off (such as compiling a kernel,
> writing a CD), and sleep (periodic system processes; email
> notifications; low CPU%).
> 
> Antheas
> 
> [1] https://lore.kernel.org/all/20241121172239.119590-1-lkml@antheas.dev/

Thank you very much for the extensive reply. Haven't seen that series of
yours before and haven't considered the sleep state handling. Upon a
quick review, your points sound reasonable. Let me think it over.

-- 
Best regards,
Dmitry