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: <479b4a5a-a792-4d3d-8bf1-59ef296b7e96@collabora.com>
Date: Thu, 4 Dec 2025 18:03:44 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: 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>,
 Antheas Kapenekakis <lkml@...heas.dev>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface

On 12/3/25 17:58, Rafael J. Wysocki wrote:
>> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
>> Display OFF/ON DSM notifications at runtime.
> Why?
> 
>> 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.
> This sets a limitation on the correct/expected usage of this
> interface.  How can the kernel ensure that the limitation is taken
> into account?  In principle, it should not allow OFF to be triggered
> if any displays are "on", for example.
> 
> And what exactly do you mean by "turning off a display".  Cutting
> power from it or something else?

The common lowest level denominator for the "turned off display" should
be that all display CRTCs are disabled and there are no active remote
desktop sessions.

For example, firmware of Intel laptops tracks state of a built-in
display internally and treats display being tuned off when either
display's CRTC is disabled or when backlight level is set to 0. This may
be not the same for AMD firmware.

Display On/Off notification is a hint to firmware that it's allowed to
put machine into a lower power state where UI presented to a user may
become non-interactive.

In practice, entering this lower power state makes device to pretend
that it has been suspended. On a laptop, keyboard backlight will be
turned off and power button LED will start blinking. This allows us to
implement the "resume to a dark mode", mentioned in the cover letter.

It's up to userspace to make decision when and what DSM notification
should be issued, thus the new sysfs control.

There is no strict requirement on having displays to be turned off when
Display OFF notification is issued. Machine won't blow up when display
is enabled and OFF notification is set. Hence, it should be unnecessary
for kernel to be extra cautious RE trusting userspace.

-- 
Best regards,
Dmitry