Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

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