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

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

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