[RFC PATCH v1 0/1] ACPI: s2idle: Add /sys/power/lps0_screen_off

[RFC PATCH v1 0/1] ACPI: s2idle: Add /sys/power/lps0_screen_off

[Dmitry Osipenko]

Introduce the `/sys/power/lps0_screen_off` sysfs interface, enabling
userspace control over ACPI LPS0 Display Off/On notifications [1].

These notifications are a part of a Modern Standby [2]. The Display Off
notification signals the firmware when all displays (physical and remote)
are off, allowing it to enter lower power states that makes device pretend
it has been suspended while the system remains operational.

Future work will involve integrating this new sysfs control support into
userspace services like power-profiles-daemon, adding a new `idle_screen_off`
inhibitor type to logind and updating power managers with the new
functionality that may improve power savings for idling devices.

Display notifications will allow to support "resume to a dark mode"
feature where the device wakes briefly, performs actions, and then
re-enters into suspended state.

[1] https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
[2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications

Dmitry Osipenko (1):
  ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

 Documentation/ABI/testing/sysfs-power |  13 +++
 drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
 2 files changed, 145 insertions(+), 17 deletions(-)

-- 
2.51.1

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

[Dmitry Osipenko]

Add `/sys/power/lps0_screen_off` interface to allow userspace to control
Display OFF/ON DSM notifications at runtime. 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.

Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 Documentation/ABI/testing/sysfs-power |  13 +++
 drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
 2 files changed, 145 insertions(+), 17 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index d38da077905a..af7c81ae517c 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -470,3 +470,16 @@ Description:
 
                 Minimum value: 1
                 Default value: 3
+
+What:		/sys/power/lps0_screen_off
+Date:		November 2025
+Contact:	Dmitrii Osipenko <dmitry.osipenko@collabora.com>
+Description:
+		This file is available if the ACPI/OSPM system supports
+		Display Off/On DSM notifications. It controls state of the
+		notification.
+
+		Writing a "1" to this file invokes Display Off Notification.
+		Writing a "0" to this file invokes Display On Notification.
+
+		Notifications are only triggered on state transitions.
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 6d4d06236f61..d5cb5e22431d 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -18,7 +18,10 @@
 #include <linux/acpi.h>
 #include <linux/device.h>
 #include <linux/dmi.h>
+#include <linux/kobject.h>
+#include <linux/mutex.h>
 #include <linux/suspend.h>
+#include <linux/sysfs.h>
 
 #include "../sleep.h"
 
@@ -61,6 +64,11 @@ static guid_t lps0_dsm_guid_microsoft;
 static int lps0_dsm_func_mask_microsoft;
 static int lps0_dsm_state;
 
+static DEFINE_MUTEX(lps0_dsm_screen_off_lock);
+static bool lps0_dsm_screen_state_off;
+static bool lps0_screen_off_suspended;
+static bool lps0_screen_off_sysfs_inhibit;
+
 /* Device constraint entry structure */
 struct lpi_device_info {
 	char *name;
@@ -513,6 +521,76 @@ static struct acpi_scan_handler lps0_handler = {
 	.attach = lps0_device_attach,
 };
 
+static bool lps0_has_screen_off_dsm(void)
+{
+	int id = acpi_s2idle_vendor_amd() ?
+		 ACPI_LPS0_SCREEN_ON_AMD : ACPI_LPS0_SCREEN_OFF;
+
+	if (lps0_dsm_func_mask_microsoft > 0 &&
+	    (lps0_dsm_func_mask & BIT(ACPI_LPS0_SCREEN_OFF)))
+		return true;
+
+	if (lps0_dsm_func_mask > 0 && (lps0_dsm_func_mask & BIT(id)))
+		return true;
+
+	return false;
+}
+
+static void lps0_dsm_screen_off(void)
+{
+	if (lps0_dsm_screen_state_off)
+		return;
+
+	if (lps0_dsm_func_mask > 0)
+		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
+					ACPI_LPS0_SCREEN_OFF_AMD :
+					ACPI_LPS0_SCREEN_OFF,
+					lps0_dsm_func_mask, lps0_dsm_guid);
+
+	if (lps0_dsm_func_mask_microsoft > 0)
+		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
+					lps0_dsm_func_mask_microsoft,
+					lps0_dsm_guid_microsoft);
+
+	lps0_dsm_screen_state_off = true;
+}
+
+static void lps0_dsm_screen_on(void)
+{
+	if (!lps0_dsm_screen_state_off)
+		return;
+
+	if (lps0_dsm_func_mask_microsoft > 0)
+		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
+					lps0_dsm_func_mask_microsoft,
+					lps0_dsm_guid_microsoft);
+
+	if (lps0_dsm_func_mask > 0)
+		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
+					ACPI_LPS0_SCREEN_ON_AMD :
+					ACPI_LPS0_SCREEN_ON,
+					lps0_dsm_func_mask, lps0_dsm_guid);
+
+	lps0_dsm_screen_state_off = false;
+}
+
+static void lps0_dsm_screen_off_set(int sysfs_off, int suspended)
+{
+	mutex_lock(&lps0_dsm_screen_off_lock);
+
+	if (sysfs_off > -1)
+		lps0_screen_off_sysfs_inhibit = sysfs_off;
+	if (suspended > -1)
+		lps0_screen_off_suspended = suspended;
+
+	if (lps0_screen_off_suspended || lps0_screen_off_sysfs_inhibit)
+		lps0_dsm_screen_off();
+	else
+		lps0_dsm_screen_on();
+
+	mutex_unlock(&lps0_dsm_screen_off_lock);
+}
+
 static int acpi_s2idle_begin_lps0(void)
 {
 	if (pm_debug_messages_on && !lpi_constraints_table) {
@@ -543,15 +621,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
 		lpi_check_constraints();
 
 	/* Screen off */
-	if (lps0_dsm_func_mask > 0)
-		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
-					ACPI_LPS0_SCREEN_OFF_AMD :
-					ACPI_LPS0_SCREEN_OFF,
-					lps0_dsm_func_mask, lps0_dsm_guid);
-
-	if (lps0_dsm_func_mask_microsoft > 0)
-		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
-				lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
+	lps0_dsm_screen_off_set(-1, true);
 
 	/* LPS0 entry */
 	if (lps0_dsm_func_mask > 0 && acpi_s2idle_vendor_amd())
@@ -618,14 +688,7 @@ static void acpi_s2idle_restore_early_lps0(void)
 	}
 
 	/* Screen on */
-	if (lps0_dsm_func_mask_microsoft > 0)
-		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
-				lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
-	if (lps0_dsm_func_mask > 0)
-		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
-					ACPI_LPS0_SCREEN_ON_AMD :
-					ACPI_LPS0_SCREEN_ON,
-					lps0_dsm_func_mask, lps0_dsm_guid);
+	lps0_dsm_screen_off_set(-1, false);
 }
 
 static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
@@ -673,4 +736,56 @@ void acpi_unregister_lps0_dev(struct acpi_s2idle_dev_ops *arg)
 }
 EXPORT_SYMBOL_GPL(acpi_unregister_lps0_dev);
 
+static ssize_t lps0_screen_off_store(struct kobject *kobj,
+				     struct kobj_attribute *attr,
+				     const char *buf, size_t count)
+{
+	unsigned long val;
+
+	if (kstrtoul(buf, 10, &val))
+		return -EINVAL;
+
+	if (val > 1)
+		return -EINVAL;
+
+	lps0_dsm_screen_off_set(val, -1);
+
+	return count;
+}
+
+static ssize_t lps0_screen_off_show(struct kobject *kobj,
+				    struct kobj_attribute *attr,
+				    char *buf)
+{
+	return sprintf(buf, "%d\n", lps0_screen_off_sysfs_inhibit);
+}
+
+static struct kobj_attribute lps0_screen_off_attr =
+	__ATTR(lps0_screen_off, 0644,
+	       lps0_screen_off_show, lps0_screen_off_store);
+
+static struct attribute *lps0_screen_off_attrs[] = {
+	&lps0_screen_off_attr.attr,
+	NULL,
+};
+
+static struct attribute_group lps0_screen_off_attr_group = {
+	.attrs = lps0_screen_off_attrs,
+};
+
+static int lps0_dsm_screen_off_init(void)
+{
+	int ret;
+
+	if (!lps0_has_screen_off_dsm())
+		return 0;
+
+	ret = sysfs_create_group(power_kobj, &lps0_screen_off_attr_group);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+late_initcall(lps0_dsm_screen_off_init);
+
 #endif /* CONFIG_SUSPEND */
-- 
2.51.1

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

[Mario Limonciello (AMD) (kernel.org)]

++ dri-devel

On 12/1/2025 10:34 PM, Dmitry Osipenko wrote:
> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
> Display OFF/ON DSM notifications at runtime. 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.

As this has to do with actions when displays are off I think you should 
also CC dri-devel on the next submission.

> 
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
>   Documentation/ABI/testing/sysfs-power |  13 +++
>   drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
>   2 files changed, 145 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> index d38da077905a..af7c81ae517c 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -470,3 +470,16 @@ Description:
>   
>                   Minimum value: 1
>                   Default value: 3
> +
> +What:		/sys/power/lps0_screen_off
> +Date:		November 2025

This should be matching the kernel you're targeting this to land, which 
is definitely not in the past.

> +Contact:	Dmitrii Osipenko <dmitry.osipenko@collabora.com>
> +Description:
> +		This file is available if the ACPI/OSPM system supports
> +		Display Off/On DSM notifications. It controls state of the
> +		notification.
> +
> +		Writing a "1" to this file invokes Display Off Notification.
> +		Writing a "0" to this file invokes Display On Notification.
> +
> +		Notifications are only triggered on state transitions.
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index 6d4d06236f61..d5cb5e22431d 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -18,7 +18,10 @@
>   #include <linux/acpi.h>
>   #include <linux/device.h>
>   #include <linux/dmi.h>
> +#include <linux/kobject.h>
> +#include <linux/mutex.h>
>   #include <linux/suspend.h>
> +#include <linux/sysfs.h>
>   
>   #include "../sleep.h"
>   
> @@ -61,6 +64,11 @@ static guid_t lps0_dsm_guid_microsoft;
>   static int lps0_dsm_func_mask_microsoft;
>   static int lps0_dsm_state;
>   
> +static DEFINE_MUTEX(lps0_dsm_screen_off_lock);
> +static bool lps0_dsm_screen_state_off;
> +static bool lps0_screen_off_suspended;
> +static bool lps0_screen_off_sysfs_inhibit;
> +
>   /* Device constraint entry structure */
>   struct lpi_device_info {
>   	char *name;
> @@ -513,6 +521,76 @@ static struct acpi_scan_handler lps0_handler = {
>   	.attach = lps0_device_attach,
>   };
>   
> +static bool lps0_has_screen_off_dsm(void)
> +{
> +	int id = acpi_s2idle_vendor_amd() ?
> +		 ACPI_LPS0_SCREEN_ON_AMD : ACPI_LPS0_SCREEN_OFF;
> +
> +	if (lps0_dsm_func_mask_microsoft > 0 &&
> +	    (lps0_dsm_func_mask & BIT(ACPI_LPS0_SCREEN_OFF)))
> +		return true;
> +
> +	if (lps0_dsm_func_mask > 0 && (lps0_dsm_func_mask & BIT(id)))
> +		return true;
> +
> +	return false;
> +}
> +
> +static void lps0_dsm_screen_off(void)
> +{
> +	if (lps0_dsm_screen_state_off)
> +		return;
> +
> +	if (lps0_dsm_func_mask > 0)
> +		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> +					ACPI_LPS0_SCREEN_OFF_AMD :
> +					ACPI_LPS0_SCREEN_OFF,
> +					lps0_dsm_func_mask, lps0_dsm_guid);
> +
> +	if (lps0_dsm_func_mask_microsoft > 0)
> +		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> +					lps0_dsm_func_mask_microsoft,
> +					lps0_dsm_guid_microsoft);
> +
> +	lps0_dsm_screen_state_off = true;
> +}
> +
> +static void lps0_dsm_screen_on(void)
> +{
> +	if (!lps0_dsm_screen_state_off)
> +		return;
> +
> +	if (lps0_dsm_func_mask_microsoft > 0)
> +		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> +					lps0_dsm_func_mask_microsoft,
> +					lps0_dsm_guid_microsoft);
> +
> +	if (lps0_dsm_func_mask > 0)
> +		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> +					ACPI_LPS0_SCREEN_ON_AMD :
> +					ACPI_LPS0_SCREEN_ON,
> +					lps0_dsm_func_mask, lps0_dsm_guid);
> +
> +	lps0_dsm_screen_state_off = false;
> +}
> +
> +static void lps0_dsm_screen_off_set(int sysfs_off, int suspended)

I don't really like passing in arbitrary integers, it makes this code 
hard to follow.

Could you perhaps use an enum instead?

> +{
> +	mutex_lock(&lps0_dsm_screen_off_lock);
> +

I'd use a guard(mutex) here instead.

> +	if (sysfs_off > -1)
> +		lps0_screen_off_sysfs_inhibit = sysfs_off;
> +	if (suspended > -1)
> +		lps0_screen_off_suspended = suspended;
> +
> +	if (lps0_screen_off_suspended || lps0_screen_off_sysfs_inhibit)
> +		lps0_dsm_screen_off();
> +	else
> +		lps0_dsm_screen_on();
> +
> +	mutex_unlock(&lps0_dsm_screen_off_lock);
> +}
> +
>   static int acpi_s2idle_begin_lps0(void)
>   {
>   	if (pm_debug_messages_on && !lpi_constraints_table) {
> @@ -543,15 +621,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
>   		lpi_check_constraints();
>   
>   	/* Screen off */
> -	if (lps0_dsm_func_mask > 0)
> -		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> -					ACPI_LPS0_SCREEN_OFF_AMD :
> -					ACPI_LPS0_SCREEN_OFF,
> -					lps0_dsm_func_mask, lps0_dsm_guid);
> -
> -	if (lps0_dsm_func_mask_microsoft > 0)
> -		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> -				lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> +	lps0_dsm_screen_off_set(-1, true);
>   
>   	/* LPS0 entry */
>   	if (lps0_dsm_func_mask > 0 && acpi_s2idle_vendor_amd())
> @@ -618,14 +688,7 @@ static void acpi_s2idle_restore_early_lps0(void)
>   	}
>   
>   	/* Screen on */
> -	if (lps0_dsm_func_mask_microsoft > 0)
> -		acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> -				lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> -	if (lps0_dsm_func_mask > 0)
> -		acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> -					ACPI_LPS0_SCREEN_ON_AMD :
> -					ACPI_LPS0_SCREEN_ON,
> -					lps0_dsm_func_mask, lps0_dsm_guid);
> +	lps0_dsm_screen_off_set(-1, false);
>   }
>   
>   static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
> @@ -673,4 +736,56 @@ void acpi_unregister_lps0_dev(struct acpi_s2idle_dev_ops *arg)
>   }
>   EXPORT_SYMBOL_GPL(acpi_unregister_lps0_dev);
>   
> +static ssize_t lps0_screen_off_store(struct kobject *kobj,
> +				     struct kobj_attribute *attr,
> +				     const char *buf, size_t count)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	if (val > 1)
> +		return -EINVAL;

Based upon how you are using this maybe just use kstrtobool() instead.

> +
> +	lps0_dsm_screen_off_set(val, -1);
> +
> +	return count;
> +}
> +
> +static ssize_t lps0_screen_off_show(struct kobject *kobj,
> +				    struct kobj_attribute *attr,
> +				    char *buf)
> +{
> +	return sprintf(buf, "%d\n", lps0_screen_off_sysfs_inhibit);

You should use sysfs_emit().

> +}
> +
> +static struct kobj_attribute lps0_screen_off_attr =
> +	__ATTR(lps0_screen_off, 0644,
> +	       lps0_screen_off_show, lps0_screen_off_store);
> +
> +static struct attribute *lps0_screen_off_attrs[] = {
> +	&lps0_screen_off_attr.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group lps0_screen_off_attr_group = {
> +	.attrs = lps0_screen_off_attrs,
> +};
> +
> +static int lps0_dsm_screen_off_init(void)
> +{
> +	int ret;
> +
> +	if (!lps0_has_screen_off_dsm())
> +		return 0;
> +
> +	ret = sysfs_create_group(power_kobj, &lps0_screen_off_attr_group);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +late_initcall(lps0_dsm_screen_off_init);
> +
>   #endif /* CONFIG_SUSPEND */

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

[Dmitry Osipenko]

On 12/2/25 07:43, Mario Limonciello (AMD) (kernel.org) wrote:
> ++ dri-devel
> 
> On 12/1/2025 10:34 PM, Dmitry Osipenko wrote:
>> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
>> Display OFF/ON DSM notifications at runtime. 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.
> 
> As this has to do with actions when displays are off I think you should
> also CC dri-devel on the next submission.
> 
>>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> ---
>>   Documentation/ABI/testing/sysfs-power |  13 +++
>>   drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
>>   2 files changed, 145 insertions(+), 17 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/
>> ABI/testing/sysfs-power
>> index d38da077905a..af7c81ae517c 100644
>> --- a/Documentation/ABI/testing/sysfs-power
>> +++ b/Documentation/ABI/testing/sysfs-power
>> @@ -470,3 +470,16 @@ Description:
>>                     Minimum value: 1
>>                   Default value: 3
>> +
>> +What:        /sys/power/lps0_screen_off
>> +Date:        November 2025
> 
> This should be matching the kernel you're targeting this to land, which
> is definitely not in the past.
> 
>> +Contact:    Dmitrii Osipenko <dmitry.osipenko@collabora.com>
>> +Description:
>> +        This file is available if the ACPI/OSPM system supports
>> +        Display Off/On DSM notifications. It controls state of the
>> +        notification.
>> +
>> +        Writing a "1" to this file invokes Display Off Notification.
>> +        Writing a "0" to this file invokes Display On Notification.
>> +
>> +        Notifications are only triggered on state transitions.
>> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
>> index 6d4d06236f61..d5cb5e22431d 100644
>> --- a/drivers/acpi/x86/s2idle.c
>> +++ b/drivers/acpi/x86/s2idle.c
>> @@ -18,7 +18,10 @@
>>   #include <linux/acpi.h>
>>   #include <linux/device.h>
>>   #include <linux/dmi.h>
>> +#include <linux/kobject.h>
>> +#include <linux/mutex.h>
>>   #include <linux/suspend.h>
>> +#include <linux/sysfs.h>
>>     #include "../sleep.h"
>>   @@ -61,6 +64,11 @@ static guid_t lps0_dsm_guid_microsoft;
>>   static int lps0_dsm_func_mask_microsoft;
>>   static int lps0_dsm_state;
>>   +static DEFINE_MUTEX(lps0_dsm_screen_off_lock);
>> +static bool lps0_dsm_screen_state_off;
>> +static bool lps0_screen_off_suspended;
>> +static bool lps0_screen_off_sysfs_inhibit;
>> +
>>   /* Device constraint entry structure */
>>   struct lpi_device_info {
>>       char *name;
>> @@ -513,6 +521,76 @@ static struct acpi_scan_handler lps0_handler = {
>>       .attach = lps0_device_attach,
>>   };
>>   +static bool lps0_has_screen_off_dsm(void)
>> +{
>> +    int id = acpi_s2idle_vendor_amd() ?
>> +         ACPI_LPS0_SCREEN_ON_AMD : ACPI_LPS0_SCREEN_OFF;
>> +
>> +    if (lps0_dsm_func_mask_microsoft > 0 &&
>> +        (lps0_dsm_func_mask & BIT(ACPI_LPS0_SCREEN_OFF)))
>> +        return true;
>> +
>> +    if (lps0_dsm_func_mask > 0 && (lps0_dsm_func_mask & BIT(id)))
>> +        return true;
>> +
>> +    return false;
>> +}
>> +
>> +static void lps0_dsm_screen_off(void)
>> +{
>> +    if (lps0_dsm_screen_state_off)
>> +        return;
>> +
>> +    if (lps0_dsm_func_mask > 0)
>> +        acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
>> +                    ACPI_LPS0_SCREEN_OFF_AMD :
>> +                    ACPI_LPS0_SCREEN_OFF,
>> +                    lps0_dsm_func_mask, lps0_dsm_guid);
>> +
>> +    if (lps0_dsm_func_mask_microsoft > 0)
>> +        acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
>> +                    lps0_dsm_func_mask_microsoft,
>> +                    lps0_dsm_guid_microsoft);
>> +
>> +    lps0_dsm_screen_state_off = true;
>> +}
>> +
>> +static void lps0_dsm_screen_on(void)
>> +{
>> +    if (!lps0_dsm_screen_state_off)
>> +        return;
>> +
>> +    if (lps0_dsm_func_mask_microsoft > 0)
>> +        acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
>> +                    lps0_dsm_func_mask_microsoft,
>> +                    lps0_dsm_guid_microsoft);
>> +
>> +    if (lps0_dsm_func_mask > 0)
>> +        acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
>> +                    ACPI_LPS0_SCREEN_ON_AMD :
>> +                    ACPI_LPS0_SCREEN_ON,
>> +                    lps0_dsm_func_mask, lps0_dsm_guid);
>> +
>> +    lps0_dsm_screen_state_off = false;
>> +}
>> +
>> +static void lps0_dsm_screen_off_set(int sysfs_off, int suspended)
> 
> I don't really like passing in arbitrary integers, it makes this code
> hard to follow.
> 
> Could you perhaps use an enum instead?
> 
>> +{
>> +    mutex_lock(&lps0_dsm_screen_off_lock);
>> +
> 
> I'd use a guard(mutex) here instead.
> 
>> +    if (sysfs_off > -1)
>> +        lps0_screen_off_sysfs_inhibit = sysfs_off;
>> +    if (suspended > -1)
>> +        lps0_screen_off_suspended = suspended;
>> +
>> +    if (lps0_screen_off_suspended || lps0_screen_off_sysfs_inhibit)
>> +        lps0_dsm_screen_off();
>> +    else
>> +        lps0_dsm_screen_on();
>> +
>> +    mutex_unlock(&lps0_dsm_screen_off_lock);
>> +}
>> +
>>   static int acpi_s2idle_begin_lps0(void)
>>   {
>>       if (pm_debug_messages_on && !lpi_constraints_table) {
>> @@ -543,15 +621,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
>>           lpi_check_constraints();
>>         /* Screen off */
>> -    if (lps0_dsm_func_mask > 0)
>> -        acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
>> -                    ACPI_LPS0_SCREEN_OFF_AMD :
>> -                    ACPI_LPS0_SCREEN_OFF,
>> -                    lps0_dsm_func_mask, lps0_dsm_guid);
>> -
>> -    if (lps0_dsm_func_mask_microsoft > 0)
>> -        acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
>> -                lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
>> +    lps0_dsm_screen_off_set(-1, true);
>>         /* LPS0 entry */
>>       if (lps0_dsm_func_mask > 0 && acpi_s2idle_vendor_amd())
>> @@ -618,14 +688,7 @@ static void acpi_s2idle_restore_early_lps0(void)
>>       }
>>         /* Screen on */
>> -    if (lps0_dsm_func_mask_microsoft > 0)
>> -        acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
>> -                lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
>> -    if (lps0_dsm_func_mask > 0)
>> -        acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
>> -                    ACPI_LPS0_SCREEN_ON_AMD :
>> -                    ACPI_LPS0_SCREEN_ON,
>> -                    lps0_dsm_func_mask, lps0_dsm_guid);
>> +    lps0_dsm_screen_off_set(-1, false);
>>   }
>>     static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
>> @@ -673,4 +736,56 @@ void acpi_unregister_lps0_dev(struct
>> acpi_s2idle_dev_ops *arg)
>>   }
>>   EXPORT_SYMBOL_GPL(acpi_unregister_lps0_dev);
>>   +static ssize_t lps0_screen_off_store(struct kobject *kobj,
>> +                     struct kobj_attribute *attr,
>> +                     const char *buf, size_t count)
>> +{
>> +    unsigned long val;
>> +
>> +    if (kstrtoul(buf, 10, &val))
>> +        return -EINVAL;
>> +
>> +    if (val > 1)
>> +        return -EINVAL;
> 
> Based upon how you are using this maybe just use kstrtobool() instead.
> 
>> +
>> +    lps0_dsm_screen_off_set(val, -1);
>> +
>> +    return count;
>> +}
>> +
>> +static ssize_t lps0_screen_off_show(struct kobject *kobj,
>> +                    struct kobj_attribute *attr,
>> +                    char *buf)
>> +{
>> +    return sprintf(buf, "%d\n", lps0_screen_off_sysfs_inhibit);
> 
> You should use sysfs_emit().
> 
>> +}
>> +
>> +static struct kobj_attribute lps0_screen_off_attr =
>> +    __ATTR(lps0_screen_off, 0644,
>> +           lps0_screen_off_show, lps0_screen_off_store);
>> +
>> +static struct attribute *lps0_screen_off_attrs[] = {
>> +    &lps0_screen_off_attr.attr,
>> +    NULL,
>> +};
>> +
>> +static struct attribute_group lps0_screen_off_attr_group = {
>> +    .attrs = lps0_screen_off_attrs,
>> +};
>> +
>> +static int lps0_dsm_screen_off_init(void)
>> +{
>> +    int ret;
>> +
>> +    if (!lps0_has_screen_off_dsm())
>> +        return 0;
>> +
>> +    ret = sysfs_create_group(power_kobj, &lps0_screen_off_attr_group);
>> +    if (ret)
>> +        return ret;
>> +
>> +    return 0;
>> +}
>> +late_initcall(lps0_dsm_screen_off_init);
>> +
>>   #endif /* CONFIG_SUSPEND */

Thanks a lot for the quick code review. All the comments sound good,
will address in v2.

-- 
Best regards,
Dmitry

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

[Antheas Kapenekakis]

On Tue, 2 Dec 2025 at 05:36, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
> Display OFF/ON DSM notifications at runtime. 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.
>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
>  Documentation/ABI/testing/sysfs-power |  13 +++
>  drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
>  2 files changed, 145 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> index d38da077905a..af7c81ae517c 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -470,3 +470,16 @@ Description:
>
>                  Minimum value: 1
>                  Default value: 3
> +
> +What:          /sys/power/lps0_screen_off

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/

> +Date:          November 2025
> +Contact:       Dmitrii Osipenko <dmitry.osipenko@collabora.com>
> +Description:
> +               This file is available if the ACPI/OSPM system supports
> +               Display Off/On DSM notifications. It controls state of the
> +               notification.
> +
> +               Writing a "1" to this file invokes Display Off Notification.
> +               Writing a "0" to this file invokes Display On Notification.
> +
> +               Notifications are only triggered on state transitions.
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index 6d4d06236f61..d5cb5e22431d 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -18,7 +18,10 @@
>  #include <linux/acpi.h>
>  #include <linux/device.h>
>  #include <linux/dmi.h>
> +#include <linux/kobject.h>
> +#include <linux/mutex.h>
>  #include <linux/suspend.h>
> +#include <linux/sysfs.h>
>
>  #include "../sleep.h"
>
> @@ -61,6 +64,11 @@ static guid_t lps0_dsm_guid_microsoft;
>  static int lps0_dsm_func_mask_microsoft;
>  static int lps0_dsm_state;
>
> +static DEFINE_MUTEX(lps0_dsm_screen_off_lock);
> +static bool lps0_dsm_screen_state_off;
> +static bool lps0_screen_off_suspended;
> +static bool lps0_screen_off_sysfs_inhibit;
> +
>  /* Device constraint entry structure */
>  struct lpi_device_info {
>         char *name;
> @@ -513,6 +521,76 @@ static struct acpi_scan_handler lps0_handler = {
>         .attach = lps0_device_attach,
>  };
>
> +static bool lps0_has_screen_off_dsm(void)
> +{
> +       int id = acpi_s2idle_vendor_amd() ?
> +                ACPI_LPS0_SCREEN_ON_AMD : ACPI_LPS0_SCREEN_OFF;
> +
> +       if (lps0_dsm_func_mask_microsoft > 0 &&
> +           (lps0_dsm_func_mask & BIT(ACPI_LPS0_SCREEN_OFF)))
> +               return true;
> +
> +       if (lps0_dsm_func_mask > 0 && (lps0_dsm_func_mask & BIT(id)))
> +               return true;
> +
> +       return false;
> +}
> +
> +static void lps0_dsm_screen_off(void)
> +{
> +       if (lps0_dsm_screen_state_off)
> +               return;
> +
> +       if (lps0_dsm_func_mask > 0)
> +               acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> +                                       ACPI_LPS0_SCREEN_OFF_AMD :
> +                                       ACPI_LPS0_SCREEN_OFF,
> +                                       lps0_dsm_func_mask, lps0_dsm_guid);
> +
> +       if (lps0_dsm_func_mask_microsoft > 0)
> +               acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> +                                       lps0_dsm_func_mask_microsoft,
> +                                       lps0_dsm_guid_microsoft);
> +
> +       lps0_dsm_screen_state_off = true;
> +}
> +
> +static void lps0_dsm_screen_on(void)
> +{
> +       if (!lps0_dsm_screen_state_off)
> +               return;
> +
> +       if (lps0_dsm_func_mask_microsoft > 0)
> +               acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> +                                       lps0_dsm_func_mask_microsoft,
> +                                       lps0_dsm_guid_microsoft);
> +
> +       if (lps0_dsm_func_mask > 0)
> +               acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> +                                       ACPI_LPS0_SCREEN_ON_AMD :
> +                                       ACPI_LPS0_SCREEN_ON,
> +                                       lps0_dsm_func_mask, lps0_dsm_guid);
> +
> +       lps0_dsm_screen_state_off = false;
> +}
> +
> +static void lps0_dsm_screen_off_set(int sysfs_off, int suspended)
> +{
> +       mutex_lock(&lps0_dsm_screen_off_lock);
> +
> +       if (sysfs_off > -1)
> +               lps0_screen_off_sysfs_inhibit = sysfs_off;
> +       if (suspended > -1)
> +               lps0_screen_off_suspended = suspended;
> +
> +       if (lps0_screen_off_suspended || lps0_screen_off_sysfs_inhibit)
> +               lps0_dsm_screen_off();
> +       else
> +               lps0_dsm_screen_on();
> +
> +       mutex_unlock(&lps0_dsm_screen_off_lock);
> +}
> +
>  static int acpi_s2idle_begin_lps0(void)
>  {
>         if (pm_debug_messages_on && !lpi_constraints_table) {
> @@ -543,15 +621,7 @@ static int acpi_s2idle_prepare_late_lps0(void)
>                 lpi_check_constraints();
>
>         /* Screen off */
> -       if (lps0_dsm_func_mask > 0)
> -               acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> -                                       ACPI_LPS0_SCREEN_OFF_AMD :
> -                                       ACPI_LPS0_SCREEN_OFF,
> -                                       lps0_dsm_func_mask, lps0_dsm_guid);
> -
> -       if (lps0_dsm_func_mask_microsoft > 0)
> -               acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_OFF,
> -                               lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> +       lps0_dsm_screen_off_set(-1, true);
>
>         /* LPS0 entry */
>         if (lps0_dsm_func_mask > 0 && acpi_s2idle_vendor_amd())
> @@ -618,14 +688,7 @@ static void acpi_s2idle_restore_early_lps0(void)
>         }
>
>         /* Screen on */
> -       if (lps0_dsm_func_mask_microsoft > 0)
> -               acpi_sleep_run_lps0_dsm(ACPI_LPS0_SCREEN_ON,
> -                               lps0_dsm_func_mask_microsoft, lps0_dsm_guid_microsoft);
> -       if (lps0_dsm_func_mask > 0)
> -               acpi_sleep_run_lps0_dsm(acpi_s2idle_vendor_amd() ?
> -                                       ACPI_LPS0_SCREEN_ON_AMD :
> -                                       ACPI_LPS0_SCREEN_ON,
> -                                       lps0_dsm_func_mask, lps0_dsm_guid);
> +       lps0_dsm_screen_off_set(-1, false);
>  }
>
>  static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
> @@ -673,4 +736,56 @@ void acpi_unregister_lps0_dev(struct acpi_s2idle_dev_ops *arg)
>  }
>  EXPORT_SYMBOL_GPL(acpi_unregister_lps0_dev);
>
> +static ssize_t lps0_screen_off_store(struct kobject *kobj,
> +                                    struct kobj_attribute *attr,
> +                                    const char *buf, size_t count)
> +{
> +       unsigned long val;
> +
> +       if (kstrtoul(buf, 10, &val))
> +               return -EINVAL;
> +
> +       if (val > 1)
> +               return -EINVAL;
> +
> +       lps0_dsm_screen_off_set(val, -1);
> +
> +       return count;
> +}
> +
> +static ssize_t lps0_screen_off_show(struct kobject *kobj,
> +                                   struct kobj_attribute *attr,
> +                                   char *buf)
> +{
> +       return sprintf(buf, "%d\n", lps0_screen_off_sysfs_inhibit);
> +}
> +
> +static struct kobj_attribute lps0_screen_off_attr =
> +       __ATTR(lps0_screen_off, 0644,
> +              lps0_screen_off_show, lps0_screen_off_store);
> +
> +static struct attribute *lps0_screen_off_attrs[] = {
> +       &lps0_screen_off_attr.attr,
> +       NULL,
> +};
> +
> +static struct attribute_group lps0_screen_off_attr_group = {
> +       .attrs = lps0_screen_off_attrs,
> +};
> +
> +static int lps0_dsm_screen_off_init(void)
> +{
> +       int ret;
> +
> +       if (!lps0_has_screen_off_dsm())
> +               return 0;
> +
> +       ret = sysfs_create_group(power_kobj, &lps0_screen_off_attr_group);
> +       if (ret)
> +               return ret;
> +
> +       return 0;
> +}
> +late_initcall(lps0_dsm_screen_off_init);
> +
>  #endif /* CONFIG_SUSPEND */
> --
> 2.51.1
>
>

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

[Mario Limonciello]

On 12/2/25 3:32 AM, Antheas Kapenekakis wrote:
> On Tue, 2 Dec 2025 at 05:36, Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
>> Display OFF/ON DSM notifications at runtime. 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.
>>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> ---
>>   Documentation/ABI/testing/sysfs-power |  13 +++
>>   drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
>>   2 files changed, 145 insertions(+), 17 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
>> index d38da077905a..af7c81ae517c 100644
>> --- a/Documentation/ABI/testing/sysfs-power
>> +++ b/Documentation/ABI/testing/sysfs-power
>> @@ -470,3 +470,16 @@ Description:
>>
>>                   Minimum value: 1
>>                   Default value: 3
>> +
>> +What:          /sys/power/lps0_screen_off
> 
> 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.

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.

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.

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.

By doing it this way userspace still has control, but it's not 
*mandatory* for userspace to be changed.

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

[Antheas Kapenekakis]

On Tue, 2 Dec 2025 at 15:30, Mario Limonciello <superm1@kernel.org> wrote:
>
> On 12/2/25 3:32 AM, Antheas Kapenekakis wrote:
> > On Tue, 2 Dec 2025 at 05:36, Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> wrote:
> >>
> >> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
> >> Display OFF/ON DSM notifications at runtime. 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.
> >>
> >> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> >> ---
> >>   Documentation/ABI/testing/sysfs-power |  13 +++
> >>   drivers/acpi/x86/s2idle.c             | 149 +++++++++++++++++++++++---
> >>   2 files changed, 145 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
> >> index d38da077905a..af7c81ae517c 100644
> >> --- a/Documentation/ABI/testing/sysfs-power
> >> +++ b/Documentation/ABI/testing/sysfs-power
> >> @@ -470,3 +470,16 @@ Description:
> >>
> >>                   Minimum value: 1
> >>                   Default value: 3
> >> +
> >> +What:          /sys/power/lps0_screen_off
> >
> > 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.
>
> 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).

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.

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

> 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

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.

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.

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.

Both need to happen concurrently in order for there to be a user
benefit. If we try to implement it on the kernel side with a DRM hook,
we would just cause an inconsistency with userspace keyboard
brightness control.

You should try this series or mine in [1] on any Modern Standby Device
such as any Thinkpad newer than e.g. 2020 to see how it works. Screen
off controls the kbd backlight and sleep controls the power button
light (Asus/OneXPlayer still use the AMD LPS0 for that; Certain Lenovo
products such as the Go S use the screen off state for it)

Antheas

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

[Mario Limonciello (AMD) (kernel.org)]

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

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

[Dmitry Osipenko]

On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
>> 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.

It's not that trivial to add screen on/off hooks to DRM, there is no one
central place for that from what I can tell. I'm seeing variant with DRM
hooks as unnecessary complexity that doesn't solve any practical problem.

A week ago in a private conversation, Daniel Stone gave an example of
laptop's lid-close handling that is done purely in userspace.
Technically, kernel could have DRM hooks for that too, but it doesn't.

Userspace would need to be taught about new power modes in any case.
Addition of DRM hooks should require a well-defined justification, which
is currently absent.

-- 
Best regards,
Dmitry

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

[Mario Limonciello (AMD) (kernel.org)]

On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
>>> 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.
> 
> It's not that trivial to add screen on/off hooks to DRM, there is no one
> central place for that from what I can tell. I'm seeing variant with DRM
> hooks as unnecessary complexity that doesn't solve any practical problem.

Is it really that hard?  I figured that any time
connector->dpms != mode from drm_atomic_connector_commit_dpms() could 
walk through all the connectors and make a judgement call whether to 
notify the potentially exported symbol.

> 
> A week ago in a private conversation, Daniel Stone gave an example of
> laptop's lid-close handling that is done purely in userspace.
> Technically, kernel could have DRM hooks for that too, but it doesn't.

All the way into hardware sleep?  There are certain requirements needed 
for hardware sleep that kernel drivers are normally used to put devices 
into the right state.  I guess PCIe devices you can hack around with 
userspace PCI config space writes but you're going to confuse the kernel 
pretty badly.

> 
> Userspace would need to be taught about new power modes in any case.
> Addition of DRM hooks should require a well-defined justification, which
> is currently absent.
> 

Why does userspace need to know about them?  Besides the inhibitor can't 
this be invisible to userspace?  I thought this mostly is for the 
firmware to flash some LEDs and maybe change some power limits.

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

[Dmitry Osipenko]

On 12/3/25 05:12, Mario Limonciello (AMD) (kernel.org) wrote:
> 
> 
> On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
>> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
>>>> 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.
>>
>> It's not that trivial to add screen on/off hooks to DRM, there is no one
>> central place for that from what I can tell. I'm seeing variant with DRM
>> hooks as unnecessary complexity that doesn't solve any practical problem.
> 
> Is it really that hard?  I figured that any time
> connector->dpms != mode from drm_atomic_connector_commit_dpms() could
> walk through all the connectors and make a judgement call whether to
> notify the potentially exported symbol.

- drm_atomic_connector_commit_dpms() is used only for atomic ioctl path
- there is another legacy kms path
- AFAICT, DRM takes a different path when display is enabled initially
by kernel

Here we have 3 places where to plug the hook. Gives a strong feeling of
a red flag, IMO.

>> A week ago in a private conversation, Daniel Stone gave an example of
>> laptop's lid-close handling that is done purely in userspace.
>> Technically, kernel could have DRM hooks for that too, but it doesn't.
> 
> All the way into hardware sleep?  There are certain requirements needed
> for hardware sleep that kernel drivers are normally used to put devices
> into the right state.  I guess PCIe devices you can hack around with
> userspace PCI config space writes but you're going to confuse the kernel
> pretty badly.

- Userspace gets notification for a changed lid state
- Userspace takes action of turning display on/off
- Kernel DRM doesn't know and doesn't care about lid state,
force-disabling display on machine suspension

Don't see how this is different for the case of the LPS0 notifications.
Maybe I'm not getting your point well, in that case please clarify more.

>> Userspace would need to be taught about new power modes in any case.
>> Addition of DRM hooks should require a well-defined justification, which
>> is currently absent.
>>
> 
> Why does userspace need to know about them?  Besides the inhibitor can't
> this be invisible to userspace?  I thought this mostly is for the
> firmware to flash some LEDs and maybe change some power limits.

What I was saying is that LPS0 inhibitors would represent the power mode
controls by themselves. Userspace would have to know how to drive them.

Userspace power managers are already driving displays DPMS. Combining
this with knowledge about the LPS0 inhibitors gives userspace ability to
support the new device power states. Hence, there is no practical need
to bother kernel DRM with the LPS0 burden.

-- 
Best regards,
Dmitry

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

[Antheas Kapenekakis]

On Wed, 3 Dec 2025 at 07:47, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 12/3/25 05:12, Mario Limonciello (AMD) (kernel.org) wrote:
> >
> >
> > On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
> >> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
> >>>> 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.
> >>
> >> It's not that trivial to add screen on/off hooks to DRM, there is no one
> >> central place for that from what I can tell. I'm seeing variant with DRM
> >> hooks as unnecessary complexity that doesn't solve any practical problem.
> >
> > Is it really that hard?  I figured that any time
> > connector->dpms != mode from drm_atomic_connector_commit_dpms() could
> > walk through all the connectors and make a judgement call whether to
> > notify the potentially exported symbol.
>
> - drm_atomic_connector_commit_dpms() is used only for atomic ioctl path
> - there is another legacy kms path
> - AFAICT, DRM takes a different path when display is enabled initially
> by kernel
>
> Here we have 3 places where to plug the hook. Gives a strong feeling of
> a red flag, IMO.
>
> >> A week ago in a private conversation, Daniel Stone gave an example of
> >> laptop's lid-close handling that is done purely in userspace.
> >> Technically, kernel could have DRM hooks for that too, but it doesn't.
> >
> > All the way into hardware sleep?  There are certain requirements needed
> > for hardware sleep that kernel drivers are normally used to put devices
> > into the right state.  I guess PCIe devices you can hack around with
> > userspace PCI config space writes but you're going to confuse the kernel
> > pretty badly.
>
> - Userspace gets notification for a changed lid state
> - Userspace takes action of turning display on/off
> - Kernel DRM doesn't know and doesn't care about lid state,
> force-disabling display on machine suspension
>
> Don't see how this is different for the case of the LPS0 notifications.
> Maybe I'm not getting your point well, in that case please clarify more.
>
> >> Userspace would need to be taught about new power modes in any case.
> >> Addition of DRM hooks should require a well-defined justification, which
> >> is currently absent.
> >>
> >
> > Why does userspace need to know about them?  Besides the inhibitor can't
> > this be invisible to userspace?  I thought this mostly is for the
> > firmware to flash some LEDs and maybe change some power limits.
>
> What I was saying is that LPS0 inhibitors would represent the power mode
> controls by themselves. Userspace would have to know how to drive them.
>
> Userspace power managers are already driving displays DPMS. Combining
> this with knowledge about the LPS0 inhibitors gives userspace ability to
> support the new device power states. Hence, there is no practical need
> to bother kernel DRM with the LPS0 burden.

_Technically_ DPMS is driven by the compositor, not by any power manager.

However, I think for Gnome and KDE they link to logind's inactivity
hook so practically you are correct for inactivity.

Moreover, traditionally, compositors do not fire DPMS for suspend, the
kernel does. I think KDE fixed that recently though. This is why the
display used to wake up twice during hibernation, and why you get a
frozen display when suspending/resuming. This also complicates
suspend-then-hibernate checks because the display wakes up. i.e., they
should fire DPMS for suspend but a lot for them don't

With compositors such as gamescope that do not have a dbus API it gets
more hairy. And it also means that the power manager/kernel cannot
control DPMS without the compositor's consent. If they do that, the
compositor will crash due to rejected commits. We have a suspend hook
for gamescope on Bazzite though, it improves suspend appearance.

Just throwing in this for context, although it builds more of a case
of not involving DRM.

Best,
Antheas

> --
> Best regards,
> Dmitry
>

On Wed, 3 Dec 2025 at 07:47, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 12/3/25 05:12, Mario Limonciello (AMD) (kernel.org) wrote:
> >
> >
> > On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
> >> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
> >>>> 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.
> >>
> >> It's not that trivial to add screen on/off hooks to DRM, there is no one
> >> central place for that from what I can tell. I'm seeing variant with DRM
> >> hooks as unnecessary complexity that doesn't solve any practical problem.
> >
> > Is it really that hard?  I figured that any time
> > connector->dpms != mode from drm_atomic_connector_commit_dpms() could
> > walk through all the connectors and make a judgement call whether to
> > notify the potentially exported symbol.
>
> - drm_atomic_connector_commit_dpms() is used only for atomic ioctl path
> - there is another legacy kms path
> - AFAICT, DRM takes a different path when display is enabled initially
> by kernel
>
> Here we have 3 places where to plug the hook. Gives a strong feeling of
> a red flag, IMO.
>
> >> A week ago in a private conversation, Daniel Stone gave an example of
> >> laptop's lid-close handling that is done purely in userspace.
> >> Technically, kernel could have DRM hooks for that too, but it doesn't.
> >
> > All the way into hardware sleep?  There are certain requirements needed
> > for hardware sleep that kernel drivers are normally used to put devices
> > into the right state.  I guess PCIe devices you can hack around with
> > userspace PCI config space writes but you're going to confuse the kernel
> > pretty badly.
>
> - Userspace gets notification for a changed lid state
> - Userspace takes action of turning display on/off
> - Kernel DRM doesn't know and doesn't care about lid state,
> force-disabling display on machine suspension
>
> Don't see how this is different for the case of the LPS0 notifications.
> Maybe I'm not getting your point well, in that case please clarify more.
>
> >> Userspace would need to be taught about new power modes in any case.
> >> Addition of DRM hooks should require a well-defined justification, which
> >> is currently absent.
> >>
> >
> > Why does userspace need to know about them?  Besides the inhibitor can't
> > this be invisible to userspace?  I thought this mostly is for the
> > firmware to flash some LEDs and maybe change some power limits.
>
> What I was saying is that LPS0 inhibitors would represent the power mode
> controls by themselves. Userspace would have to know how to drive them.
>
> Userspace power managers are already driving displays DPMS. Combining
> this with knowledge about the LPS0 inhibitors gives userspace ability to
> support the new device power states. Hence, there is no practical need
> to bother kernel DRM with the LPS0 burden.
>
> --
> Best regards,
> Dmitry
>

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

[Mario Limonciello]

On 12/3/25 4:12 AM, Antheas Kapenekakis wrote:
> On Wed, 3 Dec 2025 at 07:47, Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> On 12/3/25 05:12, Mario Limonciello (AMD) (kernel.org) wrote:
>>>
>>>
>>> On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
>>>> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
>>>>>> 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.
>>>>
>>>> It's not that trivial to add screen on/off hooks to DRM, there is no one
>>>> central place for that from what I can tell. I'm seeing variant with DRM
>>>> hooks as unnecessary complexity that doesn't solve any practical problem.
>>>
>>> Is it really that hard?  I figured that any time
>>> connector->dpms != mode from drm_atomic_connector_commit_dpms() could
>>> walk through all the connectors and make a judgement call whether to
>>> notify the potentially exported symbol.
>>
>> - drm_atomic_connector_commit_dpms() is used only for atomic ioctl path
>> - there is another legacy kms path
>> - AFAICT, DRM takes a different path when display is enabled initially
>> by kernel
>>
>> Here we have 3 places where to plug the hook. Gives a strong feeling of
>> a red flag, IMO.

It could easily be a symbol that all 3 places call which enumerates 
connectors and decides whether to call the LPS0 symbol.

But yeah; you might be right it's too complex.

>>
>>>> A week ago in a private conversation, Daniel Stone gave an example of
>>>> laptop's lid-close handling that is done purely in userspace.
>>>> Technically, kernel could have DRM hooks for that too, but it doesn't.
>>>
>>> All the way into hardware sleep?  There are certain requirements needed
>>> for hardware sleep that kernel drivers are normally used to put devices
>>> into the right state.  I guess PCIe devices you can hack around with
>>> userspace PCI config space writes but you're going to confuse the kernel
>>> pretty badly.
>>
>> - Userspace gets notification for a changed lid state
>> - Userspace takes action of turning display on/off
>> - Kernel DRM doesn't know and doesn't care about lid state,
>> force-disabling display on machine suspension
>>
>> Don't see how this is different for the case of the LPS0 notifications.
>> Maybe I'm not getting your point well, in that case please clarify more.

I thought you were talking about total sleep handling, but you're just 
talking about other userspace events related to a lid.  This is much 
different.

>>
>>>> Userspace would need to be taught about new power modes in any case.
>>>> Addition of DRM hooks should require a well-defined justification, which
>>>> is currently absent.
>>>>
>>>
>>> Why does userspace need to know about them?  Besides the inhibitor can't
>>> this be invisible to userspace?  I thought this mostly is for the
>>> firmware to flash some LEDs and maybe change some power limits.
>>
>> What I was saying is that LPS0 inhibitors would represent the power mode
>> controls by themselves. Userspace would have to know how to drive them.
>>
>> Userspace power managers are already driving displays DPMS. Combining
>> this with knowledge about the LPS0 inhibitors gives userspace ability to
>> support the new device power states. Hence, there is no practical need
>> to bother kernel DRM with the LPS0 burden.
> 
> _Technically_ DPMS is driven by the compositor, not by any power manager.
> 
> However, I think for Gnome and KDE they link to logind's inactivity
> hook so practically you are correct for inactivity.
> 
> Moreover, traditionally, compositors do not fire DPMS for suspend, the
> kernel does. I think KDE fixed that recently though. This is why the
> display used to wake up twice during hibernation, and why you get a
> frozen display when suspending/resuming. This also complicates
> suspend-then-hibernate checks because the display wakes up. i.e., they
> should fire DPMS for suspend but a lot for them don't
> 
> With compositors such as gamescope that do not have a dbus API it gets
> more hairy. And it also means that the power manager/kernel cannot
> control DPMS without the compositor's consent. If they do that, the
> compositor will crash due to rejected commits. We have a suspend hook
> for gamescope on Bazzite though, it improves suspend appearance.

It's OT and tangential to this thread; but Gamescope should probably 
grow native DPMS control for this particular case.

> 
> Just throwing in this for context, although it builds more of a case
> of not involving DRM.
> 

I don't feel it's appropriate to build new API in the kernel to work 
around shortcomings of an individual compositor.

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

[Antheas Kapenekakis]

On Wed, 3 Dec 2025 at 15:34, Mario Limonciello <superm1@kernel.org> wrote:
>
> On 12/3/25 4:12 AM, Antheas Kapenekakis wrote:
> > On Wed, 3 Dec 2025 at 07:47, Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> wrote:
> >>
> >> On 12/3/25 05:12, Mario Limonciello (AMD) (kernel.org) wrote:
> >>>
> >>>
> >>> On 12/2/2025 4:35 PM, Dmitry Osipenko wrote:
> >>>> On 12/3/25 00:25, Mario Limonciello (AMD) (kernel.org) wrote:
> >>>>>> 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.
> >>>>
> >>>> It's not that trivial to add screen on/off hooks to DRM, there is no one
> >>>> central place for that from what I can tell. I'm seeing variant with DRM
> >>>> hooks as unnecessary complexity that doesn't solve any practical problem.
> >>>
> >>> Is it really that hard?  I figured that any time
> >>> connector->dpms != mode from drm_atomic_connector_commit_dpms() could
> >>> walk through all the connectors and make a judgement call whether to
> >>> notify the potentially exported symbol.
> >>
> >> - drm_atomic_connector_commit_dpms() is used only for atomic ioctl path
> >> - there is another legacy kms path
> >> - AFAICT, DRM takes a different path when display is enabled initially
> >> by kernel
> >>
> >> Here we have 3 places where to plug the hook. Gives a strong feeling of
> >> a red flag, IMO.
>
> It could easily be a symbol that all 3 places call which enumerates
> connectors and decides whether to call the LPS0 symbol.
>
> But yeah; you might be right it's too complex.
>
> >>
> >>>> A week ago in a private conversation, Daniel Stone gave an example of
> >>>> laptop's lid-close handling that is done purely in userspace.
> >>>> Technically, kernel could have DRM hooks for that too, but it doesn't.
> >>>
> >>> All the way into hardware sleep?  There are certain requirements needed
> >>> for hardware sleep that kernel drivers are normally used to put devices
> >>> into the right state.  I guess PCIe devices you can hack around with
> >>> userspace PCI config space writes but you're going to confuse the kernel
> >>> pretty badly.
> >>
> >> - Userspace gets notification for a changed lid state
> >> - Userspace takes action of turning display on/off
> >> - Kernel DRM doesn't know and doesn't care about lid state,
> >> force-disabling display on machine suspension
> >>
> >> Don't see how this is different for the case of the LPS0 notifications.
> >> Maybe I'm not getting your point well, in that case please clarify more.
>
> I thought you were talking about total sleep handling, but you're just
> talking about other userspace events related to a lid.  This is much
> different.
>
> >>
> >>>> Userspace would need to be taught about new power modes in any case.
> >>>> Addition of DRM hooks should require a well-defined justification, which
> >>>> is currently absent.
> >>>>
> >>>
> >>> Why does userspace need to know about them?  Besides the inhibitor can't
> >>> this be invisible to userspace?  I thought this mostly is for the
> >>> firmware to flash some LEDs and maybe change some power limits.
> >>
> >> What I was saying is that LPS0 inhibitors would represent the power mode
> >> controls by themselves. Userspace would have to know how to drive them.
> >>
> >> Userspace power managers are already driving displays DPMS. Combining
> >> this with knowledge about the LPS0 inhibitors gives userspace ability to
> >> support the new device power states. Hence, there is no practical need
> >> to bother kernel DRM with the LPS0 burden.
> >
> > _Technically_ DPMS is driven by the compositor, not by any power manager.
> >
> > However, I think for Gnome and KDE they link to logind's inactivity
> > hook so practically you are correct for inactivity.
> >
> > Moreover, traditionally, compositors do not fire DPMS for suspend, the
> > kernel does. I think KDE fixed that recently though. This is why the
> > display used to wake up twice during hibernation, and why you get a
> > frozen display when suspending/resuming. This also complicates
> > suspend-then-hibernate checks because the display wakes up. i.e., they
> > should fire DPMS for suspend but a lot for them don't
> >
> > With compositors such as gamescope that do not have a dbus API it gets
> > more hairy. And it also means that the power manager/kernel cannot
> > control DPMS without the compositor's consent. If they do that, the
> > compositor will crash due to rejected commits. We have a suspend hook
> > for gamescope on Bazzite though, it improves suspend appearance.
>
> It's OT and tangential to this thread; but Gamescope should probably
> grow native DPMS control for this particular case.

It does have native DPMS control now for the inactivity case, not for
the suspend path, but it is managed by the Steam Client.

> >
> > Just throwing in this for context, although it builds more of a case
> > of not involving DRM.
> >
>
> I don't feel it's appropriate to build new API in the kernel to work
> around shortcomings of an individual compositor.
>

Well with wayland compositors the environment is more fragmented. But
in general it is the responsibility of the compositor to control
monitor state incl. DPMS. Of course, that is informed by the
inactivity state of the device, which is again the shared
responsibility of the input handling part of the compositor and
logind.

For SteamOS, that would be the steam client + gamescope. KDE is
kwin+logind+powerdevil.

I do not see why there would be a need to tie that responsibility to
the screen off state to the graphics component of the compositor,
which e.g. controls the keyboard backlight.

Even in Windows that is not the case, this screen off state is
controlled independently and there is something like a 5 second
inactivity buffer before it toggles after the displays switch off.

Antheas

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

[Dmitry Osipenko]

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

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

[Rafael J. Wysocki]

On Tue, Dec 2, 2025 at 5:36 AM Dmitry Osipenko
<dmitry.osipenko@collabora.com> 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?

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

[Dmitry Osipenko]

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

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

[Rafael J. Wysocki]

On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> 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.

To be precise, that's what MSDN has to say about it:

"This _DSM Function will be invoked when the operating system has
entered a state where all displays—local and remote, if any—have been
turned off. This could occur based on some user action, e.g. a button
press or lid close event, or expiration of some display power down
timer."

The "Intel Low-power S0 Idle" specification
(https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf)
says almost the same thing.

None of them says what kind of hint this is to the firmware and what
the firmware is expected to do in response to it.

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

Maybe, depending on what the firmware actually does.

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

Why would it be up to user space?

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

That is until one of them actually blows up when that happens.

As it stands, I'm totally unconvinced.

I generally think that allowing user space to trigger evaluation of
AML via sysfs is risky, pretty much regardless of what the given AML
has been designed for.  Turning that into kernel ABI is asking for
trouble.

Now, AFAIK this particular _DSM interface has been designed to be part
of the "modern standby" (or equivalent) flows, not to be used
separately, so assuming that it will always work the way you think it
will when used separately is kind of walking on thin ice IMV.

And there is also a concern regarding all of the systems where this
firmware interface is not present or not supported that will not get
the "dark resume" experience associated with it.  If you want "dark
resume" to be a feature of Linux, it should not depend on whether or
not a particular firmware is there and actually works the way you
like.

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

[Antheas Kapenekakis]

On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
> >
> > 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.

Jumping in for some more context

The display on/off notifications do not put the hw into a low power
state. It purely affects the presentation of the device. Specifically,
the keyboard backlight/RGB, and for some devices the power button
light/built-in controller for handhelds.

Although devices that pulse the power button light due to it are very
limited. In particular, I think it is Lenovo only. I have not run into
another manufacturer that uses it. Specifically, their consumer
revision. I would have to retest my thinkpad.

Most manufacturers hook into the sleep DSMs for the power button or,
e.g. Asus, with the LPS0 _DSMs.

If you think about it, it makes sense. Turning off the display does
not mean the device is not doing intensive work, such as rendering a
video. So CPU/GPU/power envelope are unaffected and that's true for
the ~7 manufacturers I tested.

A lot of manufacturers do limit the power envelope as a response to
the sleep _DSMs. Specifically, this is true for both Lenovo and Asus
consumer divisions. For a device such as the Go S, it also completely
turns off the fan. Typical power envelope is ~7W for this. This is
also why there is a _DSM for speeding up resume and why I had a faux
resume state in my series.

>
> To be precise, that's what MSDN has to say about it:
>
> "This _DSM Function will be invoked when the operating system has
> entered a state where all displays—local and remote, if any—have been
> turned off. This could occur based on some user action, e.g. a button
> press or lid close event, or expiration of some display power down
> timer."
>
> The "Intel Low-power S0 Idle" specification
> (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf)
> says almost the same thing.
>
> None of them says what kind of hint this is to the firmware and what
> the firmware is expected to do in response to it.

It is true that online documentation does not list the firmware
response. There is additional documentation that lists the exact entry
conditions for display on/off [1]

Specifically, while it is a prerequisite of the CRTCs, local/remote,
being turned off, the actual condition mirrors when userspace would
present a lockscreen to the user. I.e., if it is due to inactivity,
those notifications fire 5 seconds after displays turn off, and if it
is due to explicit action, e.g., power button, it is instant.

"However, the system continues to run and all applications continue to
operate normally as if the display was powered on." also implies that
no hw is powered off as part of this notification.

[1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers

> > 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.
>
> Maybe, depending on what the firmware actually does.
>
> > It's up to userspace to make decision when and what DSM notification
> > should be issued, thus the new sysfs control.
>
> Why would it be up to user space?
>
> > 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.
>
> That is until one of them actually blows up when that happens.
>
> As it stands, I'm totally unconvinced.
>
> I generally think that allowing user space to trigger evaluation of
> AML via sysfs is risky, pretty much regardless of what the given AML
> has been designed for.  Turning that into kernel ABI is asking for
> trouble.

I would tentatively agree, specifically in the way this series/ABI is
phrased. My suggestion would be a more generalizable ABI that is not
x86/ms specific. This way it can be bounded as appropriate to be safe
and then expanded to other devices/drivers, including those that do
not have an accompanying modern standby implementation.

The risks for this are a bit overblown. A proper userspace
implementation would always ensure that the displays have turned off,
so in the case a niche device malfunctions with a display off
notification and an enabled CRTC would leave ample time for the 2-3
DRM patches required to block it on the kernel side to be merged.

Moreover, I have personally tested these DSMs on around ~9 devices by
~7 manufacturers, and we have been shipping a modified version of the
series I sent in 2024 to around 200k users. That series pulls the
notification firing above the place where DRM suspends the CRTCs and
there haven't been any issues due to it.

> Now, AFAIK this particular _DSM interface has been designed to be part
> of the "modern standby" (or equivalent) flows, not to be used
> separately, so assuming that it will always work the way you think it
> will when used separately is kind of walking on thin ice IMV.

In Windows, the modern standby flow is implemented in userspace as a
coalescing function of different programs through their power manager
and exposed to hardware through three notifications (DIsplay On/Off,
Sleep, LPS0)[2]. My current understanding is that when it comes to the
Linux desktop, it is also the responsibility of userspace to handle
these different states, so for userspace to be able to implement this,
it would need an ABI to configure the device into a similar state.

What would be the way forward for this? I do not think it is realistic
to defer implementing these features because they are only supposed to
work with Windows.

[2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications

> And there is also a concern regarding all of the systems where this
> firmware interface is not present or not supported that will not get
> the "dark resume" experience associated with it.  If you want "dark
> resume" to be a feature of Linux, it should not depend on whether or
> not a particular firmware is there and actually works the way you
> like.
>

There are two implications here: 1) all hardware should support a
"dark resume" feature, 2) this feature should not be locked behind a
specific firmware/UEFI implementation.

First one is not true. Legacy hardware that is not built with the
ability to wake up periodically without turning on its fan, backlight,
power light and with a reduced power envelope will never get the full
benefit of such a feature set.

Second one is tenable with a proper ABI that can be implemented also
through e.g., EC platform drivers. In addition, pretty much all
laptops post ~2021 support a subset or all of these DSMs and S3
support has been retired, when it comes to AMD since the ~7000 series
APUs. This is not to say that all of it will work equally well though.

Antheas

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

[Rafael J. Wysocki]

On Thu, Dec 4, 2025 at 7:31 PM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> wrote:
> > >
> > > 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.
>
> Jumping in for some more context
>
> The display on/off notifications do not put the hw into a low power
> state. It purely affects the presentation of the device. Specifically,
> the keyboard backlight/RGB, and for some devices the power button
> light/built-in controller for handhelds.
>
> Although devices that pulse the power button light due to it are very
> limited. In particular, I think it is Lenovo only. I have not run into
> another manufacturer that uses it. Specifically, their consumer
> revision. I would have to retest my thinkpad.
>
> Most manufacturers hook into the sleep DSMs for the power button or,
> e.g. Asus, with the LPS0 _DSMs.
>
> If you think about it, it makes sense. Turning off the display does
> not mean the device is not doing intensive work, such as rendering a
> video. So CPU/GPU/power envelope are unaffected and that's true for
> the ~7 manufacturers I tested.
>
> A lot of manufacturers do limit the power envelope as a response to
> the sleep _DSMs. Specifically, this is true for both Lenovo and Asus
> consumer divisions. For a device such as the Go S, it also completely
> turns off the fan. Typical power envelope is ~7W for this. This is
> also why there is a _DSM for speeding up resume and why I had a faux
> resume state in my series.

Well, this is all in "modern standby" context AFAICS, but in Linux it
is different because Linux doesn't do "modern standby" now and it is
unlikely to do "modern standby" going forward.

In Linux, making the system look like it is suspended even though in
fact it isn't may be quite confusing, as a user may think that it is
now safe to put a laptop in a bag, for example, but in fact it isn't.

> >
> > To be precise, that's what MSDN has to say about it:
> >
> > "This _DSM Function will be invoked when the operating system has
> > entered a state where all displays—local and remote, if any—have been
> > turned off. This could occur based on some user action, e.g. a button
> > press or lid close event, or expiration of some display power down
> > timer."
> >
> > The "Intel Low-power S0 Idle" specification
> > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf)
> > says almost the same thing.
> >
> > None of them says what kind of hint this is to the firmware and what
> > the firmware is expected to do in response to it.
>
> It is true that online documentation does not list the firmware
> response. There is additional documentation that lists the exact entry
> conditions for display on/off [1]
>
> Specifically, while it is a prerequisite of the CRTCs, local/remote,
> being turned off, the actual condition mirrors when userspace would
> present a lockscreen to the user. I.e., if it is due to inactivity,
> those notifications fire 5 seconds after displays turn off, and if it
> is due to explicit action, e.g., power button, it is instant.
>
> "However, the system continues to run and all applications continue to
> operate normally as if the display was powered on." also implies that
> no hw is powered off as part of this notification.
>
> [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers

Wouldn't just turning the display off be sufficient here?  Why do you
want to go for platform notification in addition to it?

> > > 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.
> >
> > Maybe, depending on what the firmware actually does.
> >
> > > It's up to userspace to make decision when and what DSM notification
> > > should be issued, thus the new sysfs control.
> >
> > Why would it be up to user space?
> >
> > > 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.
> >
> > That is until one of them actually blows up when that happens.
> >
> > As it stands, I'm totally unconvinced.
> >
> > I generally think that allowing user space to trigger evaluation of
> > AML via sysfs is risky, pretty much regardless of what the given AML
> > has been designed for.  Turning that into kernel ABI is asking for
> > trouble.
>
> I would tentatively agree, specifically in the way this series/ABI is
> phrased. My suggestion would be a more generalizable ABI that is not
> x86/ms specific.

That would be less objectionable I think, but see below.

> This way it can be bounded as appropriate to be safe
> and then expanded to other devices/drivers, including those that do
> not have an accompanying modern standby implementation.
>
> The risks for this are a bit overblown. A proper userspace
> implementation would always ensure that the displays have turned off,
> so in the case a niche device malfunctions with a display off
> notification and an enabled CRTC would leave ample time for the 2-3
> DRM patches required to block it on the kernel side to be merged.
>
> Moreover, I have personally tested these DSMs on around ~9 devices by
> ~7 manufacturers, and we have been shipping a modified version of the
> series I sent in 2024 to around 200k users. That series pulls the
> notification firing above the place where DRM suspends the CRTCs and
> there haven't been any issues due to it.

So what value is added by this, if I may ask?

> > Now, AFAIK this particular _DSM interface has been designed to be part
> > of the "modern standby" (or equivalent) flows, not to be used
> > separately, so assuming that it will always work the way you think it
> > will when used separately is kind of walking on thin ice IMV.
>
> In Windows, the modern standby flow is implemented in userspace as a
> coalescing function of different programs through their power manager
> and exposed to hardware through three notifications (DIsplay On/Off,
> Sleep, LPS0)[2]. My current understanding is that when it comes to the
> Linux desktop, it is also the responsibility of userspace to handle
> these different states, so for userspace to be able to implement this,
> it would need an ABI to configure the device into a similar state.

As I said, Linux doesn't do "modern standby" and for a reason.

Windows is a vertical OS with user space and the kernel tied together
more tightly.  There is even a "modern standby" API for applications
IIUC.

In Linux, the kernel may work with many different user space stacks,
from Android to things like OpenWRT and it needs to accommodate all of
them.  Moreover, applications may be totally oblivious to anything
related to power management.

> What would be the way forward for this? I do not think it is realistic
> to defer implementing these features because they are only supposed to
> work with Windows.
>
> [2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications

I first need to be convinced that there is any value in allowing user
space to trigger LPS0 _DSM functions.  So far, I see no such value.

> > And there is also a concern regarding all of the systems where this
> > firmware interface is not present or not supported that will not get
> > the "dark resume" experience associated with it.  If you want "dark
> > resume" to be a feature of Linux, it should not depend on whether or
> > not a particular firmware is there and actually works the way you
> > like.
> >
>
> There are two implications here: 1) all hardware should support a

I guess you mean "options"?

> "dark resume" feature, 2) this feature should not be locked behind a
> specific firmware/UEFI implementation.
>
> First one is not true. Legacy hardware that is not built with the
> ability to wake up periodically without turning on its fan, backlight,
> power light and with a reduced power envelope will never get the full
> benefit of such a feature set.

I guess by "hardware" you mean "platforms"?

Anyway, this isn't about hardware/platform capabilities but mostly
about how system suspend is implemented in the kernel.  In principle,
"dark resume" should be possible on any platform where suspend-to-idle
is supported if all device drivers support runtime PM and if it
integrates properly with system suspend/resume.

> Second one is tenable with a proper ABI that can be implemented also
> through e.g., EC platform drivers. In addition, pretty much all
> laptops post ~2021 support a subset or all of these DSMs and S3
> support has been retired, when it comes to AMD since the ~7000 series
> APUs. This is not to say that all of it will work equally well though.

No, this won't work.  You cannot generally rely on the platform
firmware to handle things behind the kernel's back via some magic
_DSM.

I'm honestly unsure if the "dark resume in Linux" idea has been
thought through sufficiently at the conceptual level.

IMV, the whole benefit from "dark resume" would be related to the
handling of system wakeup events.

Namely, in Linux, there is this concept of freezing user space which
allows applications to not care about system suspend, so after user
space has been frozen and before it is thawed on the way back from
system suspend, there is nothing user space can do.  It is all handled
by the kernel.

When the system is resuming, the kernel decides what parts of the
system will be powered up and whether or not displays will be turned
on etc.  Basically, device drivers have suspend and resume callbacks
that cause things to happen and everything depends on what they do.
Nowadays, the majority of drivers follow the rule to power up
everything on the way back from system suspend and this needs to be
changed in the first place for "dark resume" to be viable.

What they can do instead (again, in principle) is to allow the devices
handled by them to stay in runtime suspend after a system resume, so
they will get powered up only after the first access attempt from user
space.  If that's what they do, the majority of devices may stay in
runtime suspend at the point when user space is thawed and, ideally,
only those needed for processing any new data will be resumed.  When
this processing is over, the system may be suspended again without
resuming all of the devices left in runtime suspend during the
preceding system resume (and in this case it is better to go straight
for full system suspend because that's how energy is saved).

Accordingly, if a wakeup event occurs, it may be handled without
"reviving" the entire system even though full-fledged system suspend
and resume transitions are carried out every time.

That would be my approach to making the "dark resume" concept work and
honestly I don't see any different way to make it work in Linux.

I would start with the graphics stacks and teach them to
runtime-suspend the HW when the displays go off.  No firmware
notifications are needed for this to work.  Then, I would teach
graphics drivers to leave the devices in runtime-suspend if they are
runtime-suspended when system suspend starts and to leave them in
runtime-suspend throughout the system suspend and resume, so they are
still runtime-suspended whey system resume is complete.  I'm not sure
how far away graphics stacks are from this, but at least some of them
support runtime PM, so maybe the fruits don't hang very high.  With
that, you'd just need a way to trigger a system suspend after a period
of inactivity when the displays are off and you have your "dark mode".

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

[Mario Limonciello (AMD) (kernel.org)]

> I would start with the graphics stacks and teach them to
> runtime-suspend the HW when the displays go off.  No firmware
> notifications are needed for this to work.  

Well the problem with this is there is a sizable latency to runtime 
suspend hardware when displays go off.  For example you would need to 
redo link training when you spin the hardware back up.

What we do today (AMD *dGPU* centric) is runtime suspend the hardware 
when no displays are connected and nothing else is using the GPU (for 
offload purposes).

On AMD APU we don't use runtime suspend.  If you ignore the latency I 
could see an argument for proxying the status of displays to indicate 
runtime suspended, but I don't know what it really buys you.

> Then, I would teach
> graphics drivers to leave the devices in runtime-suspend if they are
> runtime-suspended when system suspend starts and to leave them in
> runtime-suspend throughout the system suspend and resume, so they are
> still runtime-suspended whey system resume is complete.  I'm not sure
> how far away graphics stacks are from this, but at least some of them
> support runtime PM, so maybe the fruits don't hang very high.  With
> that, you'd just need a way to trigger a system suspend after a period
> of inactivity when the displays are off and you have your "dark mode".

I think even without kernel changes this can be accomplished today with 
userspace.

There will be change events when the displays are turned off and you can 
listen to and set a timer to enter system suspend based upon how long 
they are off.

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

[Rafael J. Wysocki]

On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
<superm1@kernel.org> wrote:
>
> > I would start with the graphics stacks and teach them to
> > runtime-suspend the HW when the displays go off.  No firmware
> > notifications are needed for this to work.
>
> Well the problem with this is there is a sizable latency to runtime
> suspend hardware when displays go off.  For example you would need to
> redo link training when you spin the hardware back up.
>
> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> when no displays are connected and nothing else is using the GPU (for
> offload purposes).

The latency problem can be addressed by using autosuspend instead of
synchronous suspend.  Just set the autosuspend timer when displays go
off.

> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> could see an argument for proxying the status of displays to indicate
> runtime suspended, but I don't know what it really buys you.

Well, the lack of runtime PM is a problem and I don't see how it can
be overcome easily.

The main issue is that when the system is resuming and there is no
runtime PM support, the device in question must be powered up during
the system resume flow.

> > Then, I would teach
> > graphics drivers to leave the devices in runtime-suspend if they are
> > runtime-suspended when system suspend starts and to leave them in
> > runtime-suspend throughout the system suspend and resume, so they are
> > still runtime-suspended whey system resume is complete.  I'm not sure
> > how far away graphics stacks are from this, but at least some of them
> > support runtime PM, so maybe the fruits don't hang very high.  With
> > that, you'd just need a way to trigger a system suspend after a period
> > of inactivity when the displays are off and you have your "dark mode".
>
> I think even without kernel changes this can be accomplished today with
> userspace.
>
> There will be change events when the displays are turned off and you can
> listen to and set a timer to enter system suspend based upon how long
> they are off.

True, but that's just about suspending.  To avoid powering up devices
on the way back from system suspend, runtime PM support and
integration of it with system suspend-resume is necessary.

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

[Mario Limonciello]

On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> <superm1@kernel.org> wrote:
>>
>>> I would start with the graphics stacks and teach them to
>>> runtime-suspend the HW when the displays go off.  No firmware
>>> notifications are needed for this to work.
>>
>> Well the problem with this is there is a sizable latency to runtime
>> suspend hardware when displays go off.  For example you would need to
>> redo link training when you spin the hardware back up.
>>
>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
>> when no displays are connected and nothing else is using the GPU (for
>> offload purposes).
> 
> The latency problem can be addressed by using autosuspend instead of
> synchronous suspend.  Just set the autosuspend timer when displays go
> off.

Sorry I probably confused the problem by saying latency to suspend the 
hardware.  That doesn't matter.  It's a problem of latency when they 
*come back up*.  Let me give a hypothetical that will demonstrate.

Let's say I have the following:
* Desktop with a dGPU connected to it.
* My DE has a setting for compositor to blank the monitor after 5 minutes.
* My DE has a setting to starting system suspend after 10 minutes.
* You set up auto-suspend on the dGPU for 15 seconds.
* No non-display work running.

You walk away for 6 minutes.  The dGPU will have entered runtime PM from 
the auto-suspend.  You come back to the machine and you wiggle the 
mouse.  Because the dGPU was auto-suspended you gotta wait for it to 
spin back up, you have to wait for link training again etc.

This is pretty much the same that would have happened if you walked away 
for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute 
turn off dGPU".

> 
>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
>> could see an argument for proxying the status of displays to indicate
>> runtime suspended, but I don't know what it really buys you.
> 
> Well, the lack of runtime PM is a problem and I don't see how it can
> be overcome easily.
> 
> The main issue is that when the system is resuming and there is no
> runtime PM support, the device in question must be powered up during
> the system resume flow.

I don't think this is actually a problem.  The reason is in my below 
comment.

> 
>>> Then, I would teach
>>> graphics drivers to leave the devices in runtime-suspend if they are
>>> runtime-suspended when system suspend starts and to leave them in
>>> runtime-suspend throughout the system suspend and resume, so they are
>>> still runtime-suspended whey system resume is complete.  I'm not sure
>>> how far away graphics stacks are from this, but at least some of them
>>> support runtime PM, so maybe the fruits don't hang very high.  With
>>> that, you'd just need a way to trigger a system suspend after a period
>>> of inactivity when the displays are off and you have your "dark mode".
>>
>> I think even without kernel changes this can be accomplished today with
>> userspace.
>>
>> There will be change events when the displays are turned off and you can
>> listen to and set a timer to enter system suspend based upon how long
>> they are off.
> 
> True, but that's just about suspending.  To avoid powering up devices
> on the way back from system suspend, runtime PM support and
> integration of it with system suspend-resume is necessary.

Yes and no.  For most device types I would agree; but the compositor 
controls DPMS on each CRTC which impacts whether anything is displayed.

If the compositor chooses to turn off the displays the GPU hardware will 
remain active but display IP will be off or in a low power state.  This 
will still have significant power savings by the displays being off.

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

[Rafael J. Wysocki]

On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.org> wrote:
>
> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> > On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> > <superm1@kernel.org> wrote:
> >>
> >>> I would start with the graphics stacks and teach them to
> >>> runtime-suspend the HW when the displays go off.  No firmware
> >>> notifications are needed for this to work.
> >>
> >> Well the problem with this is there is a sizable latency to runtime
> >> suspend hardware when displays go off.  For example you would need to
> >> redo link training when you spin the hardware back up.
> >>
> >> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> >> when no displays are connected and nothing else is using the GPU (for
> >> offload purposes).
> >
> > The latency problem can be addressed by using autosuspend instead of
> > synchronous suspend.  Just set the autosuspend timer when displays go
> > off.
>
> Sorry I probably confused the problem by saying latency to suspend the
> hardware.  That doesn't matter.  It's a problem of latency when they
> *come back up*.  Let me give a hypothetical that will demonstrate.
>
> Let's say I have the following:
> * Desktop with a dGPU connected to it.
> * My DE has a setting for compositor to blank the monitor after 5 minutes.
> * My DE has a setting to starting system suspend after 10 minutes.
> * You set up auto-suspend on the dGPU for 15 seconds.
> * No non-display work running.
>
> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
> the auto-suspend.  You come back to the machine and you wiggle the
> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
> spin back up, you have to wait for link training again etc.

Yes.

> This is pretty much the same that would have happened if you walked away
> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
> turn off dGPU".

Well, the wakeup latency is the cost of saving energy.

> >
> >> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> >> could see an argument for proxying the status of displays to indicate
> >> runtime suspended, but I don't know what it really buys you.
> >
> > Well, the lack of runtime PM is a problem and I don't see how it can
> > be overcome easily.
> >
> > The main issue is that when the system is resuming and there is no
> > runtime PM support, the device in question must be powered up during
> > the system resume flow.
>
> I don't think this is actually a problem.  The reason is in my below
> comment.
>
> >
> >>> Then, I would teach
> >>> graphics drivers to leave the devices in runtime-suspend if they are
> >>> runtime-suspended when system suspend starts and to leave them in
> >>> runtime-suspend throughout the system suspend and resume, so they are
> >>> still runtime-suspended whey system resume is complete.  I'm not sure
> >>> how far away graphics stacks are from this, but at least some of them
> >>> support runtime PM, so maybe the fruits don't hang very high.  With
> >>> that, you'd just need a way to trigger a system suspend after a period
> >>> of inactivity when the displays are off and you have your "dark mode".
> >>
> >> I think even without kernel changes this can be accomplished today with
> >> userspace.
> >>
> >> There will be change events when the displays are turned off and you can
> >> listen to and set a timer to enter system suspend based upon how long
> >> they are off.
> >
> > True, but that's just about suspending.  To avoid powering up devices
> > on the way back from system suspend, runtime PM support and
> > integration of it with system suspend-resume is necessary.
>
> Yes and no.  For most device types I would agree; but the compositor
> controls DPMS on each CRTC which impacts whether anything is displayed.
>
> If the compositor chooses to turn off the displays the GPU hardware will
> remain active but display IP will be off or in a low power state.  This
> will still have significant power savings by the displays being off.

OK, so you basically want the GPU to avoid turning displays on during
resume from system suspend if they were off before the suspend
transition has started.  This still needs to be handled by the GPU
driver in the kernel IIUC.

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

[Mario Limonciello]

On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.org> wrote:
>>
>> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
>>> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
>>> <superm1@kernel.org> wrote:
>>>>
>>>>> I would start with the graphics stacks and teach them to
>>>>> runtime-suspend the HW when the displays go off.  No firmware
>>>>> notifications are needed for this to work.
>>>>
>>>> Well the problem with this is there is a sizable latency to runtime
>>>> suspend hardware when displays go off.  For example you would need to
>>>> redo link training when you spin the hardware back up.
>>>>
>>>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
>>>> when no displays are connected and nothing else is using the GPU (for
>>>> offload purposes).
>>>
>>> The latency problem can be addressed by using autosuspend instead of
>>> synchronous suspend.  Just set the autosuspend timer when displays go
>>> off.
>>
>> Sorry I probably confused the problem by saying latency to suspend the
>> hardware.  That doesn't matter.  It's a problem of latency when they
>> *come back up*.  Let me give a hypothetical that will demonstrate.
>>
>> Let's say I have the following:
>> * Desktop with a dGPU connected to it.
>> * My DE has a setting for compositor to blank the monitor after 5 minutes.
>> * My DE has a setting to starting system suspend after 10 minutes.
>> * You set up auto-suspend on the dGPU for 15 seconds.
>> * No non-display work running.
>>
>> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
>> the auto-suspend.  You come back to the machine and you wiggle the
>> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
>> spin back up, you have to wait for link training again etc.
> 
> Yes.
> 
>> This is pretty much the same that would have happened if you walked away
>> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
>> turn off dGPU".
> 
> Well, the wakeup latency is the cost of saving energy.
> 
>>>
>>>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
>>>> could see an argument for proxying the status of displays to indicate
>>>> runtime suspended, but I don't know what it really buys you.
>>>
>>> Well, the lack of runtime PM is a problem and I don't see how it can
>>> be overcome easily.
>>>
>>> The main issue is that when the system is resuming and there is no
>>> runtime PM support, the device in question must be powered up during
>>> the system resume flow.
>>
>> I don't think this is actually a problem.  The reason is in my below
>> comment.
>>
>>>
>>>>> Then, I would teach
>>>>> graphics drivers to leave the devices in runtime-suspend if they are
>>>>> runtime-suspended when system suspend starts and to leave them in
>>>>> runtime-suspend throughout the system suspend and resume, so they are
>>>>> still runtime-suspended whey system resume is complete.  I'm not sure
>>>>> how far away graphics stacks are from this, but at least some of them
>>>>> support runtime PM, so maybe the fruits don't hang very high.  With
>>>>> that, you'd just need a way to trigger a system suspend after a period
>>>>> of inactivity when the displays are off and you have your "dark mode".
>>>>
>>>> I think even without kernel changes this can be accomplished today with
>>>> userspace.
>>>>
>>>> There will be change events when the displays are turned off and you can
>>>> listen to and set a timer to enter system suspend based upon how long
>>>> they are off.
>>>
>>> True, but that's just about suspending.  To avoid powering up devices
>>> on the way back from system suspend, runtime PM support and
>>> integration of it with system suspend-resume is necessary.
>>
>> Yes and no.  For most device types I would agree; but the compositor
>> controls DPMS on each CRTC which impacts whether anything is displayed.
>>
>> If the compositor chooses to turn off the displays the GPU hardware will
>> remain active but display IP will be off or in a low power state.  This
>> will still have significant power savings by the displays being off.
> 
> OK, so you basically want the GPU to avoid turning displays on during
> resume from system suspend if they were off before the suspend
> transition has started.  This still needs to be handled by the GPU
> driver in the kernel IIUC.

Yes.  To be clear (in case you didn't see from my comments in this 
thread) I'm not a fan of this being a userspace interface to the LPS0 
screen off.

I feel if this state is to exist in the Linux state machine this should 
be DRM core entering it when displays are off.

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

[Rafael J. Wysocki]

On Fri, Dec 5, 2025 at 8:42 PM Mario Limonciello <superm1@kernel.org> wrote:
>
> On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> > On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.org> wrote:
> >>
> >> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> >>> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> >>> <superm1@kernel.org> wrote:
> >>>>
> >>>>> I would start with the graphics stacks and teach them to
> >>>>> runtime-suspend the HW when the displays go off.  No firmware
> >>>>> notifications are needed for this to work.
> >>>>
> >>>> Well the problem with this is there is a sizable latency to runtime
> >>>> suspend hardware when displays go off.  For example you would need to
> >>>> redo link training when you spin the hardware back up.
> >>>>
> >>>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> >>>> when no displays are connected and nothing else is using the GPU (for
> >>>> offload purposes).
> >>>
> >>> The latency problem can be addressed by using autosuspend instead of
> >>> synchronous suspend.  Just set the autosuspend timer when displays go
> >>> off.
> >>
> >> Sorry I probably confused the problem by saying latency to suspend the
> >> hardware.  That doesn't matter.  It's a problem of latency when they
> >> *come back up*.  Let me give a hypothetical that will demonstrate.
> >>
> >> Let's say I have the following:
> >> * Desktop with a dGPU connected to it.
> >> * My DE has a setting for compositor to blank the monitor after 5 minutes.
> >> * My DE has a setting to starting system suspend after 10 minutes.
> >> * You set up auto-suspend on the dGPU for 15 seconds.
> >> * No non-display work running.
> >>
> >> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
> >> the auto-suspend.  You come back to the machine and you wiggle the
> >> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
> >> spin back up, you have to wait for link training again etc.
> >
> > Yes.
> >
> >> This is pretty much the same that would have happened if you walked away
> >> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
> >> turn off dGPU".
> >
> > Well, the wakeup latency is the cost of saving energy.
> >
> >>>
> >>>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> >>>> could see an argument for proxying the status of displays to indicate
> >>>> runtime suspended, but I don't know what it really buys you.
> >>>
> >>> Well, the lack of runtime PM is a problem and I don't see how it can
> >>> be overcome easily.
> >>>
> >>> The main issue is that when the system is resuming and there is no
> >>> runtime PM support, the device in question must be powered up during
> >>> the system resume flow.
> >>
> >> I don't think this is actually a problem.  The reason is in my below
> >> comment.
> >>
> >>>
> >>>>> Then, I would teach
> >>>>> graphics drivers to leave the devices in runtime-suspend if they are
> >>>>> runtime-suspended when system suspend starts and to leave them in
> >>>>> runtime-suspend throughout the system suspend and resume, so they are
> >>>>> still runtime-suspended whey system resume is complete.  I'm not sure
> >>>>> how far away graphics stacks are from this, but at least some of them
> >>>>> support runtime PM, so maybe the fruits don't hang very high.  With
> >>>>> that, you'd just need a way to trigger a system suspend after a period
> >>>>> of inactivity when the displays are off and you have your "dark mode".
> >>>>
> >>>> I think even without kernel changes this can be accomplished today with
> >>>> userspace.
> >>>>
> >>>> There will be change events when the displays are turned off and you can
> >>>> listen to and set a timer to enter system suspend based upon how long
> >>>> they are off.
> >>>
> >>> True, but that's just about suspending.  To avoid powering up devices
> >>> on the way back from system suspend, runtime PM support and
> >>> integration of it with system suspend-resume is necessary.
> >>
> >> Yes and no.  For most device types I would agree; but the compositor
> >> controls DPMS on each CRTC which impacts whether anything is displayed.
> >>
> >> If the compositor chooses to turn off the displays the GPU hardware will
> >> remain active but display IP will be off or in a low power state.  This
> >> will still have significant power savings by the displays being off.
> >
> > OK, so you basically want the GPU to avoid turning displays on during
> > resume from system suspend if they were off before the suspend
> > transition has started.  This still needs to be handled by the GPU
> > driver in the kernel IIUC.
>
> Yes.  To be clear (in case you didn't see from my comments in this
> thread) I'm not a fan of this being a userspace interface to the LPS0
> screen off.

So we agree here, good.

> I feel if this state is to exist in the Linux state machine this should
> be DRM core entering it when displays are off.

Something like that.

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

[Antheas Kapenekakis]

On Fri, 5 Dec 2025 at 21:06, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 5, 2025 at 8:42 PM Mario Limonciello <superm1@kernel.org> wrote:
> >
> > On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> > > On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.org> wrote:
> > >>
> > >> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> > >>> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> > >>> <superm1@kernel.org> wrote:
> > >>>>
> > >>>>> I would start with the graphics stacks and teach them to
> > >>>>> runtime-suspend the HW when the displays go off.  No firmware
> > >>>>> notifications are needed for this to work.
> > >>>>
> > >>>> Well the problem with this is there is a sizable latency to runtime
> > >>>> suspend hardware when displays go off.  For example you would need to
> > >>>> redo link training when you spin the hardware back up.
> > >>>>
> > >>>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> > >>>> when no displays are connected and nothing else is using the GPU (for
> > >>>> offload purposes).
> > >>>
> > >>> The latency problem can be addressed by using autosuspend instead of
> > >>> synchronous suspend.  Just set the autosuspend timer when displays go
> > >>> off.
> > >>
> > >> Sorry I probably confused the problem by saying latency to suspend the
> > >> hardware.  That doesn't matter.  It's a problem of latency when they
> > >> *come back up*.  Let me give a hypothetical that will demonstrate.
> > >>
> > >> Let's say I have the following:
> > >> * Desktop with a dGPU connected to it.
> > >> * My DE has a setting for compositor to blank the monitor after 5 minutes.
> > >> * My DE has a setting to starting system suspend after 10 minutes.
> > >> * You set up auto-suspend on the dGPU for 15 seconds.
> > >> * No non-display work running.
> > >>
> > >> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
> > >> the auto-suspend.  You come back to the machine and you wiggle the
> > >> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
> > >> spin back up, you have to wait for link training again etc.
> > >
> > > Yes.
> > >
> > >> This is pretty much the same that would have happened if you walked away
> > >> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
> > >> turn off dGPU".
> > >
> > > Well, the wakeup latency is the cost of saving energy.
> > >
> > >>>
> > >>>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> > >>>> could see an argument for proxying the status of displays to indicate
> > >>>> runtime suspended, but I don't know what it really buys you.
> > >>>
> > >>> Well, the lack of runtime PM is a problem and I don't see how it can
> > >>> be overcome easily.
> > >>>
> > >>> The main issue is that when the system is resuming and there is no
> > >>> runtime PM support, the device in question must be powered up during
> > >>> the system resume flow.
> > >>
> > >> I don't think this is actually a problem.  The reason is in my below
> > >> comment.
> > >>
> > >>>
> > >>>>> Then, I would teach
> > >>>>> graphics drivers to leave the devices in runtime-suspend if they are
> > >>>>> runtime-suspended when system suspend starts and to leave them in
> > >>>>> runtime-suspend throughout the system suspend and resume, so they are
> > >>>>> still runtime-suspended whey system resume is complete.  I'm not sure
> > >>>>> how far away graphics stacks are from this, but at least some of them
> > >>>>> support runtime PM, so maybe the fruits don't hang very high.  With
> > >>>>> that, you'd just need a way to trigger a system suspend after a period
> > >>>>> of inactivity when the displays are off and you have your "dark mode".
> > >>>>
> > >>>> I think even without kernel changes this can be accomplished today with
> > >>>> userspace.
> > >>>>
> > >>>> There will be change events when the displays are turned off and you can
> > >>>> listen to and set a timer to enter system suspend based upon how long
> > >>>> they are off.
> > >>>
> > >>> True, but that's just about suspending.  To avoid powering up devices
> > >>> on the way back from system suspend, runtime PM support and
> > >>> integration of it with system suspend-resume is necessary.
> > >>
> > >> Yes and no.  For most device types I would agree; but the compositor
> > >> controls DPMS on each CRTC which impacts whether anything is displayed.
> > >>
> > >> If the compositor chooses to turn off the displays the GPU hardware will
> > >> remain active but display IP will be off or in a low power state.  This
> > >> will still have significant power savings by the displays being off.
> > >
> > > OK, so you basically want the GPU to avoid turning displays on during
> > > resume from system suspend if they were off before the suspend
> > > transition has started.

This is already the case for AMD. For Intel, it's more complicated...

But it is true that it should be handled kernel side. I also think
that it was fixed for hibernation, again for AMD, already.

> > > This still needs to be handled by the GPU
> > > driver in the kernel IIUC.
> >
> > Yes.  To be clear (in case you didn't see from my comments in this
> > thread) I'm not a fan of this being a userspace interface to the LPS0
> > screen off.
>
> So we agree here, good.
>
> > I feel if this state is to exist in the Linux state machine this should
> > be DRM core entering it when displays are off.
>
> Something like that.
>

Why should unplugging the HDMI cable from my desktop or changing
display configuration cause the case RGB/keyboard backlight to turn
off?

I will reply to the earlier reply from Rafael with more context, but
runtime suspend of the GPU is not part of or related to these
notifications.

CRPC DPMS latency is higher when initiated by userspace instead of the
early resume hooks of the kernel and adds wake-up latency. Not being
able to fire the intent to turn display on notification as part of
early resume to boost the thermal envelope also adds latency. Both of
these issues, while not related to this series, are a valid tangential
discussion and center around the fact that the kernel cannot classify
certain wake-up sources as being able to turn on the display
currently, so it can make a judgement call itself.

Antheas

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

[Rafael J. Wysocki]

On Fri, Dec 5, 2025 at 10:52 PM Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Fri, 5 Dec 2025 at 21:06, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Fri, Dec 5, 2025 at 8:42 PM Mario Limonciello <superm1@kernel.org> wrote:
> > >
> > > On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> > > > On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.org> wrote:
> > > >>
> > > >> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> > > >>> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> > > >>> <superm1@kernel.org> wrote:
> > > >>>>
> > > >>>>> I would start with the graphics stacks and teach them to
> > > >>>>> runtime-suspend the HW when the displays go off.  No firmware
> > > >>>>> notifications are needed for this to work.
> > > >>>>
> > > >>>> Well the problem with this is there is a sizable latency to runtime
> > > >>>> suspend hardware when displays go off.  For example you would need to
> > > >>>> redo link training when you spin the hardware back up.
> > > >>>>
> > > >>>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> > > >>>> when no displays are connected and nothing else is using the GPU (for
> > > >>>> offload purposes).
> > > >>>
> > > >>> The latency problem can be addressed by using autosuspend instead of
> > > >>> synchronous suspend.  Just set the autosuspend timer when displays go
> > > >>> off.
> > > >>
> > > >> Sorry I probably confused the problem by saying latency to suspend the
> > > >> hardware.  That doesn't matter.  It's a problem of latency when they
> > > >> *come back up*.  Let me give a hypothetical that will demonstrate.
> > > >>
> > > >> Let's say I have the following:
> > > >> * Desktop with a dGPU connected to it.
> > > >> * My DE has a setting for compositor to blank the monitor after 5 minutes.
> > > >> * My DE has a setting to starting system suspend after 10 minutes.
> > > >> * You set up auto-suspend on the dGPU for 15 seconds.
> > > >> * No non-display work running.
> > > >>
> > > >> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
> > > >> the auto-suspend.  You come back to the machine and you wiggle the
> > > >> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
> > > >> spin back up, you have to wait for link training again etc.
> > > >
> > > > Yes.
> > > >
> > > >> This is pretty much the same that would have happened if you walked away
> > > >> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
> > > >> turn off dGPU".
> > > >
> > > > Well, the wakeup latency is the cost of saving energy.
> > > >
> > > >>>
> > > >>>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> > > >>>> could see an argument for proxying the status of displays to indicate
> > > >>>> runtime suspended, but I don't know what it really buys you.
> > > >>>
> > > >>> Well, the lack of runtime PM is a problem and I don't see how it can
> > > >>> be overcome easily.
> > > >>>
> > > >>> The main issue is that when the system is resuming and there is no
> > > >>> runtime PM support, the device in question must be powered up during
> > > >>> the system resume flow.
> > > >>
> > > >> I don't think this is actually a problem.  The reason is in my below
> > > >> comment.
> > > >>
> > > >>>
> > > >>>>> Then, I would teach
> > > >>>>> graphics drivers to leave the devices in runtime-suspend if they are
> > > >>>>> runtime-suspended when system suspend starts and to leave them in
> > > >>>>> runtime-suspend throughout the system suspend and resume, so they are
> > > >>>>> still runtime-suspended whey system resume is complete.  I'm not sure
> > > >>>>> how far away graphics stacks are from this, but at least some of them
> > > >>>>> support runtime PM, so maybe the fruits don't hang very high.  With
> > > >>>>> that, you'd just need a way to trigger a system suspend after a period
> > > >>>>> of inactivity when the displays are off and you have your "dark mode".
> > > >>>>
> > > >>>> I think even without kernel changes this can be accomplished today with
> > > >>>> userspace.
> > > >>>>
> > > >>>> There will be change events when the displays are turned off and you can
> > > >>>> listen to and set a timer to enter system suspend based upon how long
> > > >>>> they are off.
> > > >>>
> > > >>> True, but that's just about suspending.  To avoid powering up devices
> > > >>> on the way back from system suspend, runtime PM support and
> > > >>> integration of it with system suspend-resume is necessary.
> > > >>
> > > >> Yes and no.  For most device types I would agree; but the compositor
> > > >> controls DPMS on each CRTC which impacts whether anything is displayed.
> > > >>
> > > >> If the compositor chooses to turn off the displays the GPU hardware will
> > > >> remain active but display IP will be off or in a low power state.  This
> > > >> will still have significant power savings by the displays being off.
> > > >
> > > > OK, so you basically want the GPU to avoid turning displays on during
> > > > resume from system suspend if they were off before the suspend
> > > > transition has started.
>
> This is already the case for AMD. For Intel, it's more complicated...
>
> But it is true that it should be handled kernel side. I also think
> that it was fixed for hibernation, again for AMD, already.
>
> > > > This still needs to be handled by the GPU
> > > > driver in the kernel IIUC.
> > >
> > > Yes.  To be clear (in case you didn't see from my comments in this
> > > thread) I'm not a fan of this being a userspace interface to the LPS0
> > > screen off.
> >
> > So we agree here, good.
> >
> > > I feel if this state is to exist in the Linux state machine this should
> > > be DRM core entering it when displays are off.
> >
> > Something like that.
> >
>
> Why should unplugging the HDMI cable from my desktop or changing
> display configuration cause the case RGB/keyboard backlight to turn
> off?

I'm not sure what you are talking about here, sorry.

We clearly are not on the same page with this and you need to get
everyone on the same page if you want this to get anywhere.  As I said
before, as it stands today, it's going nowhere.

> I will reply to the earlier reply from Rafael with more context, but
> runtime suspend of the GPU is not part of or related to these
> notifications.

Of course it isn't.

What we were talking about was how to get from the "displays off, no
GUI activity" user space smoothly into system suspend and back.

You are saying that this has been done already on AMD, so I'm not sure
why you want more.

> CRPC DPMS latency is higher when initiated by userspace instead of the
> early resume hooks of the kernel and adds wake-up latency. Not being
> able to fire the intent to turn display on notification as part of
> early resume to boost the thermal envelope also adds latency. Both of
> these issues, while not related to this series, are a valid tangential
> discussion and center around the fact that the kernel cannot classify
> certain wake-up sources as being able to turn on the display
> currently, so it can make a judgement call itself.

The last paragraph doesn't add anything useful IMV.

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

[Mario Limonciello]

>> I will reply to the earlier reply from Rafael with more context, but
>> runtime suspend of the GPU is not part of or related to these
>> notifications.
> 
> Of course it isn't.
> 
> What we were talking about was how to get from the "displays off, no
> GUI activity" user space smoothly into system suspend and back.
> 
> You are saying that this has been done already on AMD, so I'm not sure
> why you want more.
> 

I'm not aware this existing in any unique way for AMD.  The decision of 
displays off; start a timer and enter suspend would be the same for any 
vendor.

But GPUs aren't only used for display.  If you're actively running a 
different workload (for example an LLM) using the GPU and happen to turn 
off all the displays you wouldn't want it to suspend.

What you would want is to key off:

1) All displays are off.
2) All GPUs are unsused.
3) Some time has passed.

I feel that if userspace is going to adopt a policy like this kernel 
drivers need to use runtime PM when displays are off and the GPUs aren't 
being used for anything else.

At least for AMD this doesn't happen today and would require driver 
work.  But the same kind of work would be needed by any GPU driver.

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

[Antheas Kapenekakis]

On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@kernel.org> wrote:
>
> >> I will reply to the earlier reply from Rafael with more context, but
> >> runtime suspend of the GPU is not part of or related to these
> >> notifications.
> >
> > Of course it isn't.
> >
> > What we were talking about was how to get from the "displays off, no
> > GUI activity" user space smoothly into system suspend and back.
> >
> > You are saying that this has been done already on AMD, so I'm not sure
> > why you want more.
> >
>
> I'm not aware this existing in any unique way for AMD.  The decision of
> displays off; start a timer and enter suspend would be the same for any
> vendor.

AMD retains CRTC DPMS state from userspace to s0ix currently, and you
fixed hibernation recently too. Intel sometimes doesn't, the screen
will sometimes flash while entering suspend.

There is also runtime suspend on most components. Is there a case for
powering off the iGPU completely to improve energy use?

The most expensive component in this process is unfreezing, then
runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
it two seconds later to perform runtime checks and freezing it again.
So for multiple exits from suspend where the IP is inactive this will
keep repeating.

> But GPUs aren't only used for display.  If you're actively running a
> different workload (for example an LLM) using the GPU and happen to turn
> off all the displays you wouldn't want it to suspend.
>
> What you would want is to key off:
>
> 1) All displays are off.
> 2) All GPUs are unsused.
> 3) Some time has passed.
>
> I feel that if userspace is going to adopt a policy like this kernel
> drivers need to use runtime PM when displays are off and the GPUs aren't
> being used for anything else.
>
> At least for AMD this doesn't happen today and would require driver
> work.  But the same kind of work would be needed by any GPU driver.
>

You could potentially do that, first you'd need to show that there is
a latency benefit to powering off the GPU over entering s0ix (as
userspace will be frozen in both cases for the GPU to suspend). Then,
you'd need to show that there is an energy benefit over just staying
unsuspended with userspace frozen and the GPU being in runtime
suspend. WIth both of these, a case could be made for powering off the
GPU completely for a marginal latency/energy benefit.

These notifications do not affect runtime pm though so this discussion
is a bit tangential.

Antheas

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

[Mario Limonciello]

On 12/6/25 5:35 PM, Antheas Kapenekakis wrote:
> On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@kernel.org> wrote:
>>
>>>> I will reply to the earlier reply from Rafael with more context, but
>>>> runtime suspend of the GPU is not part of or related to these
>>>> notifications.
>>>
>>> Of course it isn't.
>>>
>>> What we were talking about was how to get from the "displays off, no
>>> GUI activity" user space smoothly into system suspend and back.
>>>
>>> You are saying that this has been done already on AMD, so I'm not sure
>>> why you want more.
>>>
>>
>> I'm not aware this existing in any unique way for AMD.  The decision of
>> displays off; start a timer and enter suspend would be the same for any
>> vendor.
> 
> AMD retains CRTC DPMS state from userspace to s0ix currently, and you
> fixed hibernation recently too. Intel sometimes doesn't, the screen
> will sometimes flash while entering suspend.

I was talking about what Rafael said.  "What we were talking about was 
how to get from the displays off no guid activity user space smoothly 
into system suspend and back".

> 
> There is also runtime suspend on most components. Is there a case for
> powering off the iGPU completely to improve energy use?
> 

I don't really *think& there will be much of a difference.  We already 
go into GFXOFF when GC is idle, and SDMA, VCN, JPEG and VPE will be 
clock gated when not in use.

Someone would have to do power profiling to see if it's significant 
enough difference to justify it.  The easiest way to check would be:
1) Turn off all displays
2) Connect over SSH
3) Collect a RAPL power measurement for the package.
4) Unbind the PCI device from amdgpu
5) Collect a RAPL power measurement for the package.
6) Compare 3 and 5.

> The most expensive component in this process is unfreezing, then
> runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
> it two seconds later to perform runtime checks and freezing it again.
> So for multiple exits from suspend where the IP is inactive this will
> keep repeating.

I think we would set the auto-suspend delay appropriately if we did this 
and use DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME in this case.

> 
>> But GPUs aren't only used for display.  If you're actively running a
>> different workload (for example an LLM) using the GPU and happen to turn
>> off all the displays you wouldn't want it to suspend.
>>
>> What you would want is to key off:
>>
>> 1) All displays are off.
>> 2) All GPUs are unsused.
>> 3) Some time has passed.
>>
>> I feel that if userspace is going to adopt a policy like this kernel
>> drivers need to use runtime PM when displays are off and the GPUs aren't
>> being used for anything else.
>>
>> At least for AMD this doesn't happen today and would require driver
>> work.  But the same kind of work would be needed by any GPU driver.
>>
> 
> You could potentially do that, first you'd need to show that there is
> a latency benefit to powering off the GPU over entering s0ix (as
> userspace will be frozen in both cases for the GPU to suspend). Then,
> you'd need to show that there is an energy benefit over just staying
> unsuspended with userspace frozen and the GPU being in runtime
> suspend. WIth both of these, a case could be made for powering off the
> GPU completely for a marginal latency/energy benefit.
> 
> These notifications do not affect runtime pm though so this discussion
> is a bit tangential.
> 

I'm not worried about the latency.  We can change the policy for the 
autosuspend delay if latency is a problem.

If we added runtime suspend support to integrated GPUs this sounds like 
a really good thing to key off for that "display off notification" that 
started this whole thread.

Some infrastructure could be added so DRM core could monitor runtime 
status for all GPUs on the system.  If they're all in runtime PM it 
could use an exported symbol to send LPS0 screen off and when any one of 
them exits then send LPS0 screen on.

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

[Antheas Kapenekakis]

On Sun, 7 Dec 2025 at 01:31, Mario Limonciello <superm1@kernel.org> wrote:
>
>
>
> On 12/6/25 5:35 PM, Antheas Kapenekakis wrote:
> > On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@kernel.org> wrote:
> >>
> >>>> I will reply to the earlier reply from Rafael with more context, but
> >>>> runtime suspend of the GPU is not part of or related to these
> >>>> notifications.
> >>>
> >>> Of course it isn't.
> >>>
> >>> What we were talking about was how to get from the "displays off, no
> >>> GUI activity" user space smoothly into system suspend and back.
> >>>
> >>> You are saying that this has been done already on AMD, so I'm not sure
> >>> why you want more.
> >>>
> >>
> >> I'm not aware this existing in any unique way for AMD.  The decision of
> >> displays off; start a timer and enter suspend would be the same for any
> >> vendor.
> >
> > AMD retains CRTC DPMS state from userspace to s0ix currently, and you
> > fixed hibernation recently too. Intel sometimes doesn't, the screen
> > will sometimes flash while entering suspend.
>
> I was talking about what Rafael said.  "What we were talking about was
> how to get from the displays off no guid activity user space smoothly
> into system suspend and back".

CRPC DPMS state is the most important user-perceptible factor in that
and it works at least.

> >
> > There is also runtime suspend on most components. Is there a case for
> > powering off the iGPU completely to improve energy use?
> >
>
> I don't really *think& there will be much of a difference.  We already
> go into GFXOFF when GC is idle, and SDMA, VCN, JPEG and VPE will be
> clock gated when not in use.
>
> Someone would have to do power profiling to see if it's significant
> enough difference to justify it.  The easiest way to check would be:
> 1) Turn off all displays
> 2) Connect over SSH
> 3) Collect a RAPL power measurement for the package.
> 4) Unbind the PCI device from amdgpu
> 5) Collect a RAPL power measurement for the package.
> 6) Compare 3 and 5.

Yes. Seems it would add complexity without much benefit from first glance.

> > The most expensive component in this process is unfreezing, then
> > runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
> > it two seconds later to perform runtime checks and freezing it again.
> > So for multiple exits from suspend where the IP is inactive this will
> > keep repeating.
>
> I think we would set the auto-suspend delay appropriately if we did this
> and use DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME in this case.
>
> >
> >> But GPUs aren't only used for display.  If you're actively running a
> >> different workload (for example an LLM) using the GPU and happen to turn
> >> off all the displays you wouldn't want it to suspend.
> >>
> >> What you would want is to key off:
> >>
> >> 1) All displays are off.
> >> 2) All GPUs are unsused.
> >> 3) Some time has passed.
> >>
> >> I feel that if userspace is going to adopt a policy like this kernel
> >> drivers need to use runtime PM when displays are off and the GPUs aren't
> >> being used for anything else.
> >>
> >> At least for AMD this doesn't happen today and would require driver
> >> work.  But the same kind of work would be needed by any GPU driver.
> >>
> >
> > You could potentially do that, first you'd need to show that there is
> > a latency benefit to powering off the GPU over entering s0ix (as
> > userspace will be frozen in both cases for the GPU to suspend). Then,
> > you'd need to show that there is an energy benefit over just staying
> > unsuspended with userspace frozen and the GPU being in runtime
> > suspend. WIth both of these, a case could be made for powering off the
> > GPU completely for a marginal latency/energy benefit.
> >
> > These notifications do not affect runtime pm though so this discussion
> > is a bit tangential.
> >
>
> I'm not worried about the latency.  We can change the policy for the
> autosuspend delay if latency is a problem.
>
> If we added runtime suspend support to integrated GPUs this sounds like
> a really good thing to key off for that "display off notification" that
> started this whole thread.
>
> Some infrastructure could be added so DRM core could monitor runtime
> status for all GPUs on the system.  If they're all in runtime PM it
> could use an exported symbol to send LPS0 screen off and when any one of
> them exits then send LPS0 screen on.
>

But that notification is mostly used for the keyboard backlight.
Hooking it to DRM core will just cause unpredictable behavior with the
keyboard backlight (such as it turning off when reconfiguring the
displays). It is very easy to just have a little inactivity ABI for
userspace for it and avoid all of the complexity of that. Such an ABI
is backward compatible, as not using the ABI would produce the same
behavior the kernel has currently.

If not for energy efficiency, I would see a benefit in configuring
DPM_FLAG_* for certain common devices to reduce the latency of the
sleep script for resuming. That would make "dark resume" wake-ups have
less total time-span and power use.

For reducing resume latency, an important factor is for the kernel to
know that a wake-up source will "turn on the displays" where "turn on
the displays" equates to "the user initiated the wake-up and is ready
to interact with the device" and not something obscure related to DRM.
In the same way, the display on/off notifications are not related to
DRM but to whether the user is currently interacting with the device.

This is for two reasons: first, the DPMS delay for turning on a
monitor is 500ms-1s. Second, modern standby provides a firmware
notification to boost the thermal envelope of the device for user
interaction. Currently, if userspace initiates DPMS before suspend,
then the kernel will unsuspend with DPMS applied, leaving it up to
userspace to turn on the monitors. This means that the 500ms-1s delay
of resuming the monitors begins at the point userspace is unfrozen,
where it could begin when amdgpu resumes ~300ms earlier. Then, the
"intent for display to turn on" notification (which is rare-I do not
have a device with it) could marginally speed up kernel resume if it
is applied in lps0 exit, instead of e.g., a "dark resume" userspace
script 300ms later.

So there could be a potential 100ms savings there. But for that to
happen there would need to be some refactorings to classify wake-up
sources in-kernel-a substantial effort. In addition, kernel resume is
pretty light, most CPU use comes from unfreezing the fs and userspace.
Since the bulk of userspace unfreeze is now initiated by systemd, and
prior to initiating it, systemd could trigger the "intent to turn
displays on" notification/DPMS* itself, this would yield most of the
benefit.

I should note that while the "lps0 exit"->"sleep exit"->"display on"
notifications are squished together prior to resume beginning**, the
"intent to turn display on" notification which is meant to fire before
"sleep exit" so that the device looks like it is asleep while having a
boosted thermal envelope is irrelevant. "sleep exit"->"display on"
would first have to be pushed to userspace, so that userspace can wake
up in the "sleep" state, classify the wake-up source as e.g. a wake
rtc or the user interacting with the device, and only if the user is
interacting with it, fire the "intent to turn on display"
notification, unfreeze the rest of userspace, then fire "sleep exit",
"display on" together.

* For systemd to initiate DPMS, the compositor would need to be part
of the initial unfreeze and notified to resume early.

** This squishing together and firing before the kernel resumes is
a source of numerous obscure bugs in MS devices

Antheas

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

[Antheas Kapenekakis]

On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Dec 4, 2025 at 7:31 PM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko
> > > <dmitry.osipenko@collabora.com> wrote:
> > > >
> > > > 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.
> >
> > Jumping in for some more context
> >
> > The display on/off notifications do not put the hw into a low power
> > state. It purely affects the presentation of the device. Specifically,
> > the keyboard backlight/RGB, and for some devices the power button
> > light/built-in controller for handhelds.
> >
> > Although devices that pulse the power button light due to it are very
> > limited. In particular, I think it is Lenovo only. I have not run into
> > another manufacturer that uses it. Specifically, their consumer
> > revision. I would have to retest my thinkpad.
> >
> > Most manufacturers hook into the sleep DSMs for the power button or,
> > e.g. Asus, with the LPS0 _DSMs.
> >
> > If you think about it, it makes sense. Turning off the display does
> > not mean the device is not doing intensive work, such as rendering a
> > video. So CPU/GPU/power envelope are unaffected and that's true for
> > the ~7 manufacturers I tested.
> >
> > A lot of manufacturers do limit the power envelope as a response to
> > the sleep _DSMs. Specifically, this is true for both Lenovo and Asus
> > consumer divisions. For a device such as the Go S, it also completely
> > turns off the fan. Typical power envelope is ~7W for this. This is
> > also why there is a _DSM for speeding up resume and why I had a faux
> > resume state in my series.
>
> Well, this is all in "modern standby" context AFAICS, but in Linux it
> is different because Linux doesn't do "modern standby" now and it is
> unlikely to do "modern standby" going forward.
>
> In Linux, making the system look like it is suspended even though in
> fact it isn't may be quite confusing, as a user may think that it is
> now safe to put a laptop in a bag, for example, but in fact it isn't.

My thesis would be a proper userspace implementation running on a
laptop with a properly configured platform, it should be safe for the
user to put the laptop in their bag, even if it wakes up briefly
multiple times per hour without their knowledge or being perceivable.

It is also a very valid point that this is a _very fine_ line that
Windows crossed with its userspace implementation and soured the
perception of Modern Standby for a lot of users. Buggy platform
firmware/insufficient tooling/control for OEMs, early on also
contributed to this.

> > >
> > > To be precise, that's what MSDN has to say about it:
> > >
> > > "This _DSM Function will be invoked when the operating system has
> > > entered a state where all displays—local and remote, if any—have been
> > > turned off. This could occur based on some user action, e.g. a button
> > > press or lid close event, or expiration of some display power down
> > > timer."
> > >
> > > The "Intel Low-power S0 Idle" specification
> > > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf)
> > > says almost the same thing.
> > >
> > > None of them says what kind of hint this is to the firmware and what
> > > the firmware is expected to do in response to it.
> >
> > It is true that online documentation does not list the firmware
> > response. There is additional documentation that lists the exact entry
> > conditions for display on/off [1]
> >
> > Specifically, while it is a prerequisite of the CRTCs, local/remote,
> > being turned off, the actual condition mirrors when userspace would
> > present a lockscreen to the user. I.e., if it is due to inactivity,
> > those notifications fire 5 seconds after displays turn off, and if it
> > is due to explicit action, e.g., power button, it is instant.
> >
> > "However, the system continues to run and all applications continue to
> > operate normally as if the display was powered on." also implies that
> > no hw is powered off as part of this notification.
> >
> > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers
>
> Wouldn't just turning the display off be sufficient here?  Why do you
> want to go for platform notification in addition to it?

For this, see*

> > > > 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.
> > >
> > > Maybe, depending on what the firmware actually does.
> > >
> > > > It's up to userspace to make decision when and what DSM notification
> > > > should be issued, thus the new sysfs control.
> > >
> > > Why would it be up to user space?
> > >
> > > > 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.
> > >
> > > That is until one of them actually blows up when that happens.
> > >
> > > As it stands, I'm totally unconvinced.
> > >
> > > I generally think that allowing user space to trigger evaluation of
> > > AML via sysfs is risky, pretty much regardless of what the given AML
> > > has been designed for.  Turning that into kernel ABI is asking for
> > > trouble.
> >
> > I would tentatively agree, specifically in the way this series/ABI is
> > phrased. My suggestion would be a more generalizable ABI that is not
> > x86/ms specific.
>
> That would be less objectionable I think, but see below.
>
> > This way it can be bounded as appropriate to be safe
> > and then expanded to other devices/drivers, including those that do
> > not have an accompanying modern standby implementation.
> >
> > The risks for this are a bit overblown. A proper userspace
> > implementation would always ensure that the displays have turned off,
> > so in the case a niche device malfunctions with a display off
> > notification and an enabled CRTC would leave ample time for the 2-3
> > DRM patches required to block it on the kernel side to be merged.
> >
> > Moreover, I have personally tested these DSMs on around ~9 devices by
> > ~7 manufacturers, and we have been shipping a modified version of the
> > series I sent in 2024 to around 200k users. That series pulls the
> > notification firing above the place where DRM suspends the CRTCs and
> > there haven't been any issues due to it.
>
> So what value is added by this, if I may ask?

*here

There is a tendency by Microsoft to add OEM tooling that avoids the
need for creating platform drivers.

This includes the WMI implementation which allows Windows userspace to
talk to hardware without having a signed platform driver, and now this
standardized set of notifications. Maintaining a signed
vulnerability-free driver is expensive.

The Display On/Off notifications provide hooks for OEMs to customize
the inactive appearance of their device. Mostly, this is through
turning off auxiliary lights, such as the keyboard backlight.

The sleep notifications provide a way for OEMs to limit the thermal
envelope of their machine and make it look like it is asleep, so that
it is safe for that device to wake up multiple times per hour,
including in a bag, without looking like it is awake.

Here is an example with how these DSMs would work with thinkpads.

Windows does not have a Thinkpad backlight driver. There is auxiliary
and optional software, Vantage, which provides some of this. Assume it
is not installed. Then, in Linux, assume you disable the thinkpad
backlight driver, so upower loses control of the thinkpad keyboard
backlight. The thinkpad keyboard backlight is automatically controlled
by the EC through keyboard shortcuts. So are the power modes, via Fn+L
M H.

Then, assume that Linux implements these _DSMs, and hooks them via
systemd as following: display on/off is hooked to occur when logind
would lock the session, i.e. after 5 seconds of inactivity or pressing
the power button. The sleep notifications are triggered by
systemd-sleep, before suspend-then-hibernate begins.

The end result is that after the display turns off, the keyboard
backlight of the device will also turn off automatically without a
platform driver. This is true for all modern standby laptops at least
post ~2021. A lot of these do not have kernel drivers in linux.

Then, if the sleep state is supported (spotty in thinkpads but
available in a lot of other hw), when the RTC Wake Alarm/battery alarm
wakes the device and systemd briefly checks whether it should
hibernate, it will still look like it is asleep, and it will have a
reduced power envelope, reducing the risk of overheating if it is in a
bag and lowering standby power consumption.

I.e., without requiring vendor software, platform drivers, both
Windows and Linux present a full feature set out of the box.

> > > Now, AFAIK this particular _DSM interface has been designed to be part
> > > of the "modern standby" (or equivalent) flows, not to be used
> > > separately, so assuming that it will always work the way you think it
> > > will when used separately is kind of walking on thin ice IMV.
> >
> > In Windows, the modern standby flow is implemented in userspace as a
> > coalescing function of different programs through their power manager
> > and exposed to hardware through three notifications (DIsplay On/Off,
> > Sleep, LPS0)[2]. My current understanding is that when it comes to the
> > Linux desktop, it is also the responsibility of userspace to handle
> > these different states, so for userspace to be able to implement this,
> > it would need an ABI to configure the device into a similar state.
>
> As I said, Linux doesn't do "modern standby" and for a reason.
>
> Windows is a vertical OS with user space and the kernel tied together
> more tightly.  There is even a "modern standby" API for applications
> IIUC.
>
> In Linux, the kernel may work with many different user space stacks,
> from Android to things like OpenWRT and it needs to accommodate all of
> them.  Moreover, applications may be totally oblivious to anything
> related to power management.

Sure, but since the majority of this lies in desktop userspace, those
applications are not affected. All the kernel needs is to provide an
ABI for these notifications just for desktop devices when the ACPI
notifications are present/a platform driver implements them.

> > What would be the way forward for this? I do not think it is realistic
> > to defer implementing these features because they are only supposed to
> > work with Windows.
> >
> > [2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications
>
> I first need to be convinced that there is any value in allowing user
> space to trigger LPS0 _DSM functions.  So far, I see no such value.

See *

> > > And there is also a concern regarding all of the systems where this
> > > firmware interface is not present or not supported that will not get
> > > the "dark resume" experience associated with it.  If you want "dark
> > > resume" to be a feature of Linux, it should not depend on whether or
> > > not a particular firmware is there and actually works the way you
> > > like.
> > >
> >
> > There are two implications here: 1) all hardware should support a
>
> I guess you mean "options"?

Implications, as in that paragraph carries those two assumptions.

> > "dark resume" feature, 2) this feature should not be locked behind a
> > specific firmware/UEFI implementation.
> >
> > First one is not true. Legacy hardware that is not built with the
> > ability to wake up periodically without turning on its fan, backlight,
> > power light and with a reduced power envelope will never get the full
> > benefit of such a feature set.
>
> I guess by "hardware" you mean "platforms"?

I would tend towards "hardware", as legacy hardware that is part of
the same platform can have different behavior. E.g., not implementing
a sleep state.

> Anyway, this isn't about hardware/platform capabilities but mostly
> about how system suspend is implemented in the kernel.  In principle,
> "dark resume" should be possible on any platform where suspend-to-idle
> is supported if all device drivers support runtime PM and if it
> integrates properly with system suspend/resume.

There are certain hardware requirements for modern standby, such as a
modem that can stay connected to Wifi while suspended, having a
reduced power envelope for sleep, an EC that supports battery alarms,
charge notifications, etc.

The absence of some of these components will make certain parts of
"dark resume" less practical for older hardware, while in principle it
would work.

> > Second one is tenable with a proper ABI that can be implemented also
> > through e.g., EC platform drivers. In addition, pretty much all
> > laptops post ~2021 support a subset or all of these DSMs and S3
> > support has been retired, when it comes to AMD since the ~7000 series
> > APUs. This is not to say that all of it will work equally well though.
>
> No, this won't work.  You cannot generally rely on the platform
> firmware to handle things behind the kernel's back via some magic
> _DSM.

These notifications are not related to powering off certain hardware
components. It is not a prerequisite for certain hw to be powered off
before they are called (unlike LPS0) nor do they power off hardware**.

Instead, they provide OEMs with a way to tune their hardware for certain cases.

**handhelds and their controllers, this is a later discussion

> I'm honestly unsure if the "dark resume in Linux" idea has been
> thought through sufficiently at the conceptual level.
>
> IMV, the whole benefit from "dark resume" would be related to the
> handling of system wakeup events.
>
> Namely, in Linux, there is this concept of freezing user space which
> allows applications to not care about system suspend, so after user
> space has been frozen and before it is thawed on the way back from
> system suspend, there is nothing user space can do.  It is all handled
> by the kernel.
>
> When the system is resuming, the kernel decides what parts of the
> system will be powered up and whether or not displays will be turned
> on etc.  Basically, device drivers have suspend and resume callbacks
> that cause things to happen and everything depends on what they do.
> Nowadays, the majority of drivers follow the rule to power up
> everything on the way back from system suspend and this needs to be
> changed in the first place for "dark resume" to be viable.
>
> What they can do instead (again, in principle) is to allow the devices
> handled by them to stay in runtime suspend after a system resume, so
> they will get powered up only after the first access attempt from user
> space.  If that's what they do, the majority of devices may stay in
> runtime suspend at the point when user space is thawed and, ideally,
> only those needed for processing any new data will be resumed.  When
> this processing is over, the system may be suspended again without
> resuming all of the devices left in runtime suspend during the
> preceding system resume (and in this case it is better to go straight
> for full system suspend because that's how energy is saved).
>
> Accordingly, if a wakeup event occurs, it may be handled without
> "reviving" the entire system even though full-fledged system suspend
> and resume transitions are carried out every time.
>
> That would be my approach to making the "dark resume" concept work and
> honestly I don't see any different way to make it work in Linux.
>
> I would start with the graphics stacks and teach them to
> runtime-suspend the HW when the displays go off.  No firmware
> notifications are needed for this to work.  Then, I would teach
> graphics drivers to leave the devices in runtime-suspend if they are
> runtime-suspended when system suspend starts and to leave them in
> runtime-suspend throughout the system suspend and resume, so they are
> still runtime-suspended whey system resume is complete.  I'm not sure
> how far away graphics stacks are from this, but at least some of them
> support runtime PM, so maybe the fruits don't hang very high.  With
> that, you'd just need a way to trigger a system suspend after a period
> of inactivity when the displays are off and you have your "dark mode".
>

Yes, this is a fair description and how it should work, where the
addition of these notifications would enhance the process.

Runtime suspend is still weird in the current kernel. Most devices,
e.g., GPU/sd card fully wake up and then are re-suspended. I am not
sure how much of this can be prevented, and even if it can, it will be
a progressive per-driver optimization that is not a prerequisite for
"dark mode" but more of a fine tuning imo.

Antheas

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

[Rafael J. Wysocki]

GMail did something silly to my reply to this message, so resending it
in case it didn't make it to the lists.  Sorry for duplicates.

On Fri, Dec 5, 2025 at 11:52=E2=80=AFPM Antheas Kapenekakis
<lkml@antheas.dev> wrote:
>
> On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > >
> > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > >

[cut]

> >
> > In Linux, making the system look like it is suspended even though in
> > fact it isn't may be quite confusing, as a user may think that it is
> > now safe to put a laptop in a bag, for example, but in fact it isn't.
>
> My thesis would be a proper userspace implementation running on a
> laptop with a properly configured platform, it should be safe for the
> user to put the laptop in their bag, even if it wakes up briefly
> multiple times per hour without their knowledge or being perceivable.

That's what Android phones/tablets do, but that's a vertical software stack.

To implement something like this you need (a) support from the GFX driver
in the kernel to go into system suspend back and forth without turning
displays on and off, and (b) a mechanism to trigger system suspend
automatically after a period of inactivity while in the "displays off, no
GUI activity" state, and (c) support for system wakeup events in (b).

I'm not sure what the LPS0 _DSM role is in that.

> It is also a very valid point that this is a _very fine_ line that
> Windows crossed with its userspace implementation and soured the
> perception of Modern Standby for a lot of users. Buggy platform
> firmware/insufficient tooling/control for OEMs, early on also
> contributed to this.
>
> > > >
> > > > To be precise, that's what MSDN has to say about it:
> > > >
> > > > "This _DSM Function will be invoked when the operating system has
> > > > entered a state where all displays=E2=80=94local and remote, if any==E2=80=94have been
> > > > turned off. This could occur based on some user action, e.g. a button
> > > > press or lid close event, or expiration of some display power down
> > > > timer."
> > > >
> > > > The "Intel Low-power S0 Idle" specification
> > > > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle=.pdf)
> > > > says almost the same thing.
> > > >
> > > > None of them says what kind of hint this is to the firmware and what
> > > > the firmware is expected to do in response to it.
> > >
> > > It is true that online documentation does not list the firmware
> > > response. There is additional documentation that lists the exact entry
> > > conditions for display on/off [1]
> > >
> > > Specifically, while it is a prerequisite of the CRTCs, local/remote,
> > > being turned off, the actual condition mirrors when userspace would
> > > present a lockscreen to the user. I.e., if it is due to inactivity,
> > > those notifications fire 5 seconds after displays turn off, and if it
> > > is due to explicit action, e.g., power button, it is instant.
> > >
> > > "However, the system continues to run and all applications continue t=
o
> > > operate normally as if the display was powered on." also implies that
> > > no hw is powered off as part of this notification.
> > >
> > > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers
> >
> > Wouldn't just turning the display off be sufficient here?  Why do you
> > want to go for platform notification in addition to it?

[cut]

> There is a tendency by Microsoft to add OEM tooling that avoids the
> need for creating platform drivers.
>
> This includes the WMI implementation which allows Windows userspace to
> talk to hardware without having a signed platform driver, and now this
> standardized set of notifications. Maintaining a signed
> vulnerability-free driver is expensive.
>
> The Display On/Off notifications provide hooks for OEMs to customize
> the inactive appearance of their device. Mostly, this is through
> turning off auxiliary lights, such as the keyboard backlight.
>
> The sleep notifications provide a way for OEMs to limit the thermal
> envelope of their machine and make it look like it is asleep, so that
> it is safe for that device to wake up multiple times per hour,
> including in a bag, without looking like it is awake.

This is based on a very optimistic assumption that generally cannot be
verified I'm afraid.

(1) User space must not do anything silly like Bitcoin mining while
this is done.
(2) The firmware must not be cheating.
(3) The GFX driver needs to be able to transition transparently
between the "displays off" graphics state and the system suspend and
resume flows.
(4) The GFX driver activity needs to be coordinated at least somewhat
with whatever user space entity would be responsible for triggering
the notifications so they do not get completely out of sync.

> Here is an example with how these DSMs would work with thinkpads.
>
> Windows does not have a Thinkpad backlight driver. There is auxiliary
> and optional software, Vantage, which provides some of this. Assume it
> is not installed. Then, in Linux, assume you disable the thinkpad
> backlight driver, so upower loses control of the thinkpad keyboard
> backlight. The thinkpad keyboard backlight is automatically controlled
> by the EC through keyboard shortcuts. So are the power modes, via Fn+L
> M H.
>
> Then, assume that Linux implements these _DSMs, and hooks them via
> systemd as following: display on/off is hooked to occur when logind
> would lock the session, i.e. after 5 seconds of inactivity or pressing
> the power button. The sleep notifications are triggered by
> systemd-sleep, before suspend-then-hibernate begins.
>
> The end result is that after the display turns off, the keyboard
> backlight of the device will also turn off automatically without a
> platform driver. This is true for all modern standby laptops at least
> post ~2021. A lot of these do not have kernel drivers in linux.
>
> Then, if the sleep state is supported (spotty in thinkpads but
> available in a lot of other hw), when the RTC Wake Alarm/battery alarm
> wakes the device and systemd briefly checks whether it should
> hibernate, it will still look like it is asleep, and it will have a
> reduced power envelope, reducing the risk of overheating if it is in a
> bag and lowering standby power consumption.
>
> I.e., without requiring vendor software, platform drivers, both
> Windows and Linux present a full feature set out of the box.

I guess it would be rather useful to start the discussion with this
proposed flow, some time might have been saved by everyone.

IIUC, the point is to make the system look "suspended" if it goes out
of suspend briefly in response to a wakeup event (the other potential
"benefits" of what the notifications can possibly do are in the domain
of marketing IMV), but is it really worth the hassle?

Assuming that the answer is "yes", which I'm not convinced about at
all, can't the kernel simply defer the "screen on" notification to
some time after thawing user space, so it can avoid doing it and the
corresponding "screen off" one if the system is suspended again
quickly enough? Perhaps so long as the GFX driver opts in?

And now we get to the most important thing: even before trying to do
the above, let alone exposing anything to user space, the existing
suspend-to-idle flow in the kernel needs to be adjusted to do the
"screen off" notification much earlier and the "screen off"
notification much later than they are done today.  I think that you
should be able to argue convincingly for making this change.

If this doesn't universally work for whatever reason, anything more
will be out of the question.

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

[Rafael J. Wysocki]

On Sun, Dec 7, 2025 at 12:06 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> GMail did something silly to my reply to this message, so resending it
> in case it didn't make it to the lists.  Sorry for duplicates.
>
> On Fri, Dec 5, 2025 at 11:52=E2=80=AFPM Antheas Kapenekakis
> <lkml@antheas.dev> wrote:
> >
> > On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > > >
> > > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > >
>
> [cut]
>
> > >
> > > In Linux, making the system look like it is suspended even though in
> > > fact it isn't may be quite confusing, as a user may think that it is
> > > now safe to put a laptop in a bag, for example, but in fact it isn't.
> >
> > My thesis would be a proper userspace implementation running on a
> > laptop with a properly configured platform, it should be safe for the
> > user to put the laptop in their bag, even if it wakes up briefly
> > multiple times per hour without their knowledge or being perceivable.
>
> That's what Android phones/tablets do, but that's a vertical software stack.
>
> To implement something like this you need (a) support from the GFX driver
> in the kernel to go into system suspend back and forth without turning
> displays on and off, and (b) a mechanism to trigger system suspend
> automatically after a period of inactivity while in the "displays off, no
> GUI activity" state, and (c) support for system wakeup events in (b).
>
> I'm not sure what the LPS0 _DSM role is in that.
>
> > It is also a very valid point that this is a _very fine_ line that
> > Windows crossed with its userspace implementation and soured the
> > perception of Modern Standby for a lot of users. Buggy platform
> > firmware/insufficient tooling/control for OEMs, early on also
> > contributed to this.
> >
> > > > >
> > > > > To be precise, that's what MSDN has to say about it:
> > > > >
> > > > > "This _DSM Function will be invoked when the operating system has
> > > > > entered a state where all displays=E2=80=94local and remote, if any==E2=80=94have been
> > > > > turned off. This could occur based on some user action, e.g. a button
> > > > > press or lid close event, or expiration of some display power down
> > > > > timer."
> > > > >
> > > > > The "Intel Low-power S0 Idle" specification
> > > > > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle=.pdf)
> > > > > says almost the same thing.
> > > > >
> > > > > None of them says what kind of hint this is to the firmware and what
> > > > > the firmware is expected to do in response to it.
> > > >
> > > > It is true that online documentation does not list the firmware
> > > > response. There is additional documentation that lists the exact entry
> > > > conditions for display on/off [1]
> > > >
> > > > Specifically, while it is a prerequisite of the CRTCs, local/remote,
> > > > being turned off, the actual condition mirrors when userspace would
> > > > present a lockscreen to the user. I.e., if it is due to inactivity,
> > > > those notifications fire 5 seconds after displays turn off, and if it
> > > > is due to explicit action, e.g., power button, it is instant.
> > > >
> > > > "However, the system continues to run and all applications continue t=
> o
> > > > operate normally as if the display was powered on." also implies that
> > > > no hw is powered off as part of this notification.
> > > >
> > > > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers
> > >
> > > Wouldn't just turning the display off be sufficient here?  Why do you
> > > want to go for platform notification in addition to it?
>
> [cut]
>
> > There is a tendency by Microsoft to add OEM tooling that avoids the
> > need for creating platform drivers.
> >
> > This includes the WMI implementation which allows Windows userspace to
> > talk to hardware without having a signed platform driver, and now this
> > standardized set of notifications. Maintaining a signed
> > vulnerability-free driver is expensive.
> >
> > The Display On/Off notifications provide hooks for OEMs to customize
> > the inactive appearance of their device. Mostly, this is through
> > turning off auxiliary lights, such as the keyboard backlight.
> >
> > The sleep notifications provide a way for OEMs to limit the thermal
> > envelope of their machine and make it look like it is asleep, so that
> > it is safe for that device to wake up multiple times per hour,
> > including in a bag, without looking like it is awake.
>
> This is based on a very optimistic assumption that generally cannot be
> verified I'm afraid.
>
> (1) User space must not do anything silly like Bitcoin mining while
> this is done.
> (2) The firmware must not be cheating.
> (3) The GFX driver needs to be able to transition transparently
> between the "displays off" graphics state and the system suspend and
> resume flows.
> (4) The GFX driver activity needs to be coordinated at least somewhat
> with whatever user space entity would be responsible for triggering
> the notifications so they do not get completely out of sync.
>
> > Here is an example with how these DSMs would work with thinkpads.
> >
> > Windows does not have a Thinkpad backlight driver. There is auxiliary
> > and optional software, Vantage, which provides some of this. Assume it
> > is not installed. Then, in Linux, assume you disable the thinkpad
> > backlight driver, so upower loses control of the thinkpad keyboard
> > backlight. The thinkpad keyboard backlight is automatically controlled
> > by the EC through keyboard shortcuts. So are the power modes, via Fn+L
> > M H.
> >
> > Then, assume that Linux implements these _DSMs, and hooks them via
> > systemd as following: display on/off is hooked to occur when logind
> > would lock the session, i.e. after 5 seconds of inactivity or pressing
> > the power button. The sleep notifications are triggered by
> > systemd-sleep, before suspend-then-hibernate begins.
> >
> > The end result is that after the display turns off, the keyboard
> > backlight of the device will also turn off automatically without a
> > platform driver. This is true for all modern standby laptops at least
> > post ~2021. A lot of these do not have kernel drivers in linux.
> >
> > Then, if the sleep state is supported (spotty in thinkpads but
> > available in a lot of other hw), when the RTC Wake Alarm/battery alarm
> > wakes the device and systemd briefly checks whether it should
> > hibernate, it will still look like it is asleep, and it will have a
> > reduced power envelope, reducing the risk of overheating if it is in a
> > bag and lowering standby power consumption.
> >
> > I.e., without requiring vendor software, platform drivers, both
> > Windows and Linux present a full feature set out of the box.
>
> I guess it would be rather useful to start the discussion with this
> proposed flow, some time might have been saved by everyone.
>
> IIUC, the point is to make the system look "suspended" if it goes out
> of suspend briefly in response to a wakeup event (the other potential
> "benefits" of what the notifications can possibly do are in the domain
> of marketing IMV), but is it really worth the hassle?
>
> Assuming that the answer is "yes", which I'm not convinced about at
> all, can't the kernel simply defer the "screen on" notification to
> some time after thawing user space, so it can avoid doing it and the
> corresponding "screen off" one if the system is suspended again
> quickly enough? Perhaps so long as the GFX driver opts in?
>
> And now we get to the most important thing: even before trying to do
> the above, let alone exposing anything to user space, the existing
> suspend-to-idle flow in the kernel needs to be adjusted to do the
> "screen off" notification much earlier and the "screen off"

The second one obviously should be "screen on", sorry for the typo.

> notification much later than they are done today.  I think that you
> should be able to argue convincingly for making this change.
>
> If this doesn't universally work for whatever reason, anything more
> will be out of the question.

So let me repeat for extra clarity.

The only change related to the LPS0 "screen off" and "screen on"
notifications that would be tentatively acceptable to me ATM, would be
to modify the suspend-to-idle flow to do the "screen off" notification
earlier (possibly even at the start of it) and the corresponding
"screen on" notification later (possibly at the end of it), provided
that one can convincingly argue that this should not introduce
regressions.

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

[Antheas Kapenekakis]

On Sun, 7 Dec 2025 at 12:20, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Sun, Dec 7, 2025 at 12:06 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > GMail did something silly to my reply to this message, so resending it
> > in case it didn't make it to the lists.  Sorry for duplicates.
> >
> > On Fri, Dec 5, 2025 at 11:52=E2=80=AFPM Antheas Kapenekakis
> > <lkml@antheas.dev> wrote:
> > >
> > > On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > >
> > > > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > > > >
> > > > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > >
> >
> > [cut]
> >
> > > >
> > > > In Linux, making the system look like it is suspended even though in
> > > > fact it isn't may be quite confusing, as a user may think that it is
> > > > now safe to put a laptop in a bag, for example, but in fact it isn't.
> > >
> > > My thesis would be a proper userspace implementation running on a
> > > laptop with a properly configured platform, it should be safe for the
> > > user to put the laptop in their bag, even if it wakes up briefly
> > > multiple times per hour without their knowledge or being perceivable.
> >
> > That's what Android phones/tablets do, but that's a vertical software stack.
> >
> > To implement something like this you need (a) support from the GFX driver
> > in the kernel to go into system suspend back and forth without turning
> > displays on and off, and (b) a mechanism to trigger system suspend
> > automatically after a period of inactivity while in the "displays off, no
> > GUI activity" state, and (c) support for system wakeup events in (b).
> >
> > I'm not sure what the LPS0 _DSM role is in that.
> >
> > > It is also a very valid point that this is a _very fine_ line that
> > > Windows crossed with its userspace implementation and soured the
> > > perception of Modern Standby for a lot of users. Buggy platform
> > > firmware/insufficient tooling/control for OEMs, early on also
> > > contributed to this.
> > >
> > > > > >
> > > > > > To be precise, that's what MSDN has to say about it:
> > > > > >
> > > > > > "This _DSM Function will be invoked when the operating system has
> > > > > > entered a state where all displays=E2=80=94local and remote, if any==E2=80=94have been
> > > > > > turned off. This could occur based on some user action, e.g. a button
> > > > > > press or lid close event, or expiration of some display power down
> > > > > > timer."
> > > > > >
> > > > > > The "Intel Low-power S0 Idle" specification
> > > > > > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle=.pdf)
> > > > > > says almost the same thing.
> > > > > >
> > > > > > None of them says what kind of hint this is to the firmware and what
> > > > > > the firmware is expected to do in response to it.
> > > > >
> > > > > It is true that online documentation does not list the firmware
> > > > > response. There is additional documentation that lists the exact entry
> > > > > conditions for display on/off [1]
> > > > >
> > > > > Specifically, while it is a prerequisite of the CRTCs, local/remote,
> > > > > being turned off, the actual condition mirrors when userspace would
> > > > > present a lockscreen to the user. I.e., if it is due to inactivity,
> > > > > those notifications fire 5 seconds after displays turn off, and if it
> > > > > is due to explicit action, e.g., power button, it is instant.
> > > > >
> > > > > "However, the system continues to run and all applications continue t=
> > o
> > > > > operate normally as if the display was powered on." also implies that
> > > > > no hw is powered off as part of this notification.
> > > > >
> > > > > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers
> > > >
> > > > Wouldn't just turning the display off be sufficient here?  Why do you
> > > > want to go for platform notification in addition to it?
> >
> > [cut]
> >
> > > There is a tendency by Microsoft to add OEM tooling that avoids the
> > > need for creating platform drivers.
> > >
> > > This includes the WMI implementation which allows Windows userspace to
> > > talk to hardware without having a signed platform driver, and now this
> > > standardized set of notifications. Maintaining a signed
> > > vulnerability-free driver is expensive.
> > >
> > > The Display On/Off notifications provide hooks for OEMs to customize
> > > the inactive appearance of their device. Mostly, this is through
> > > turning off auxiliary lights, such as the keyboard backlight.
> > >
> > > The sleep notifications provide a way for OEMs to limit the thermal
> > > envelope of their machine and make it look like it is asleep, so that
> > > it is safe for that device to wake up multiple times per hour,
> > > including in a bag, without looking like it is awake.
> >
> > This is based on a very optimistic assumption that generally cannot be
> > verified I'm afraid.
> >
> > (1) User space must not do anything silly like Bitcoin mining while
> > this is done.
> > (2) The firmware must not be cheating.
> > (3) The GFX driver needs to be able to transition transparently
> > between the "displays off" graphics state and the system suspend and
> > resume flows.
> > (4) The GFX driver activity needs to be coordinated at least somewhat
> > with whatever user space entity would be responsible for triggering
> > the notifications so they do not get completely out of sync.
> >
> > > Here is an example with how these DSMs would work with thinkpads.
> > >
> > > Windows does not have a Thinkpad backlight driver. There is auxiliary
> > > and optional software, Vantage, which provides some of this. Assume it
> > > is not installed. Then, in Linux, assume you disable the thinkpad
> > > backlight driver, so upower loses control of the thinkpad keyboard
> > > backlight. The thinkpad keyboard backlight is automatically controlled
> > > by the EC through keyboard shortcuts. So are the power modes, via Fn+L
> > > M H.
> > >
> > > Then, assume that Linux implements these _DSMs, and hooks them via
> > > systemd as following: display on/off is hooked to occur when logind
> > > would lock the session, i.e. after 5 seconds of inactivity or pressing
> > > the power button. The sleep notifications are triggered by
> > > systemd-sleep, before suspend-then-hibernate begins.
> > >
> > > The end result is that after the display turns off, the keyboard
> > > backlight of the device will also turn off automatically without a
> > > platform driver. This is true for all modern standby laptops at least
> > > post ~2021. A lot of these do not have kernel drivers in linux.
> > >
> > > Then, if the sleep state is supported (spotty in thinkpads but
> > > available in a lot of other hw), when the RTC Wake Alarm/battery alarm
> > > wakes the device and systemd briefly checks whether it should
> > > hibernate, it will still look like it is asleep, and it will have a
> > > reduced power envelope, reducing the risk of overheating if it is in a
> > > bag and lowering standby power consumption.
> > >
> > > I.e., without requiring vendor software, platform drivers, both
> > > Windows and Linux present a full feature set out of the box.
> >
> > I guess it would be rather useful to start the discussion with this
> > proposed flow, some time might have been saved by everyone.
> >
> > IIUC, the point is to make the system look "suspended" if it goes out
> > of suspend briefly in response to a wakeup event (the other potential
> > "benefits" of what the notifications can possibly do are in the domain
> > of marketing IMV), but is it really worth the hassle?
> >
> > Assuming that the answer is "yes", which I'm not convinced about at
> > all, can't the kernel simply defer the "screen on" notification to
> > some time after thawing user space, so it can avoid doing it and the
> > corresponding "screen off" one if the system is suspended again
> > quickly enough? Perhaps so long as the GFX driver opts in?
> >
> > And now we get to the most important thing: even before trying to do
> > the above, let alone exposing anything to user space, the existing
> > suspend-to-idle flow in the kernel needs to be adjusted to do the
> > "screen off" notification much earlier and the "screen off"
>
> The second one obviously should be "screen on", sorry for the typo.
>
> > notification much later than they are done today.  I think that you
> > should be able to argue convincingly for making this change.
> >
> > If this doesn't universally work for whatever reason, anything more
> > will be out of the question.
>
> So let me repeat for extra clarity.
>
> The only change related to the LPS0 "screen off" and "screen on"
> notifications that would be tentatively acceptable to me ATM, would be
> to modify the suspend-to-idle flow to do the "screen off" notification
> earlier (possibly even at the start of it) and the corresponding
> "screen on" notification later (possibly at the end of it), provided
> that one can convincingly argue that this should not introduce
> regressions.
>

From what I recall that was my original plan.

Yeah, it is a fair way forward. @Dmitry how would you like to approach
this? SInce you re-started the discussion. What is your timeline/KPIs
for this.

I could personally try to whip up a small series after the merge
window by rewriting what I have[1]. I have more experience now in
drafting this kind of thing and that series added some cruft to the pm
core with multiple additions to platform_s2idle_ops

There is a _small_ quantitative difference due to moving the calls.
Specifically, the power light responds a tad slower when waking a
device. For the legion go (non-s) devices, Lenovo added a dummy 5
second timer to resuming the controllers because of some Windows bugs,
and moving the calls causes the timer to start later. But that's the
OEM intended behavior...

Antheas

[1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/

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

[Dmitry Osipenko]

...
>> So let me repeat for extra clarity.
>>
>> The only change related to the LPS0 "screen off" and "screen on"
>> notifications that would be tentatively acceptable to me ATM, would be
>> to modify the suspend-to-idle flow to do the "screen off" notification
>> earlier (possibly even at the start of it) and the corresponding
>> "screen on" notification later (possibly at the end of it), provided
>> that one can convincingly argue that this should not introduce
>> regressions.
>>
> 
> From what I recall that was my original plan.
> 
> Yeah, it is a fair way forward. @Dmitry how would you like to approach
> this? SInce you re-started the discussion. What is your timeline/KPIs
> for this.
> 
> I could personally try to whip up a small series after the merge
> window by rewriting what I have[1]. I have more experience now in
> drafting this kind of thing and that series added some cruft to the pm
> core with multiple additions to platform_s2idle_ops
> 
> There is a _small_ quantitative difference due to moving the calls.
> Specifically, the power light responds a tad slower when waking a
> device. For the legion go (non-s) devices, Lenovo added a dummy 5
> second timer to resuming the controllers because of some Windows bugs,
> and moving the calls causes the timer to start later. But that's the
> OEM intended behavior...
> 
> Antheas
> 
> [1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/

Am I understanding correctly that the plan is to have a 2-stage freezer
for suspend-to-idle + standby mode? Rafael, could you please confirm
that you're fine with this 2-stage freezer part of the proposal from
Antheas?

What you expect to be a proper way of implementing a 2-stage freezer?
Would it be a new executable capability, a new syscall or extension of
existing one, a new cgroup type? How would you mark processes that
should not be frozen on the first stage? Or it would be only the process
that writes to /sysfs/power?

Thanks everyone for the very detailed input. It is all very productive,
helps a lot with adjusting my understanding of the modern suspend features.

Agree that the usefulness of the visual aspect of the Display
notification is questionable. Previously I thought this mode involves
power-limiting. The Sleep notification might be much more interesting then.

I'm heading to vacation till Jan. Antheas, I will be happy to review and
test your code if you'll have time to type a working prototype.
Otherwise, will continue after the Holidays and likely will use your
patches for the base.

-- 
Best regards,
Dmitry

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

[Antheas Kapenekakis]

On Tue, 9 Dec 2025 at 23:14, Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> ...
> >> So let me repeat for extra clarity.
> >>
> >> The only change related to the LPS0 "screen off" and "screen on"
> >> notifications that would be tentatively acceptable to me ATM, would be
> >> to modify the suspend-to-idle flow to do the "screen off" notification
> >> earlier (possibly even at the start of it) and the corresponding
> >> "screen on" notification later (possibly at the end of it), provided
> >> that one can convincingly argue that this should not introduce
> >> regressions.
> >>
> >
> > From what I recall that was my original plan.
> >
> > Yeah, it is a fair way forward. @Dmitry how would you like to approach
> > this? SInce you re-started the discussion. What is your timeline/KPIs
> > for this.
> >
> > I could personally try to whip up a small series after the merge
> > window by rewriting what I have[1]. I have more experience now in
> > drafting this kind of thing and that series added some cruft to the pm
> > core with multiple additions to platform_s2idle_ops
> >
> > There is a _small_ quantitative difference due to moving the calls.
> > Specifically, the power light responds a tad slower when waking a
> > device. For the legion go (non-s) devices, Lenovo added a dummy 5
> > second timer to resuming the controllers because of some Windows bugs,
> > and moving the calls causes the timer to start later. But that's the
> > OEM intended behavior...
> >
> > Antheas
> >
> > [1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/
>
> Am I understanding correctly that the plan is to have a 2-stage freezer
> for suspend-to-idle + standby mode? Rafael, could you please confirm
> that you're fine with this 2-stage freezer part of the proposal from
> Antheas?

2 stages here refers to a two patch series, where the first part moves
the firmware notifications to the beginning of the suspend sequence
and the second part introduces a sysfs entry.

This way, it can be verified that it is ok for these calls to be
moved, and thereafter they are only called before the suspend
sequence, not both depending on userspace involvement.

In your series, you introduce a call from userspace, but then do the
fallback call at the end of the suspend sequence/beginning of resume.

> What you expect to be a proper way of implementing a 2-stage freezer?
> Would it be a new executable capability, a new syscall or extension of
> existing one, a new cgroup type? How would you mark processes that
> should not be frozen on the first stage? Or it would be only the process
> that writes to /sysfs/power?

This would be handled by the init process without any kernel
extension, so it is a bit tangential.

You can reference the current freezer group in systemd-sleep for what
is done currently. It was introduced to prevent waking programs during
the transition to hibernation. In addition, freezing userspace _tends_
to improve VRAM evacuation when preparing for hibernation and cache
evacuation %, among other things.

So under systemd, the kernel essentially is only responsible for
freezing systemd.

> Thanks everyone for the very detailed input. It is all very productive,
> helps a lot with adjusting my understanding of the modern suspend features.
>
> Agree that the usefulness of the visual aspect of the Display
> notification is questionable. Previously I thought this mode involves
> power-limiting. The Sleep notification might be much more interesting then.
>
> I'm heading to vacation till Jan. Antheas, I will be happy to review and
> test your code if you'll have time to type a working prototype.
> Otherwise, will continue after the Holidays and likely will use your
> patches for the base.

Happy holidays. I am also heading off soon, but I might have some time
in the meantime.


Best,
Antheas



> --
> Best regards,
> Dmitry
>

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

[Rafael J. Wysocki]

On Tue, Dec 9, 2025 at 11:14 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> ...
> >> So let me repeat for extra clarity.
> >>
> >> The only change related to the LPS0 "screen off" and "screen on"
> >> notifications that would be tentatively acceptable to me ATM, would be
> >> to modify the suspend-to-idle flow to do the "screen off" notification
> >> earlier (possibly even at the start of it) and the corresponding
> >> "screen on" notification later (possibly at the end of it), provided
> >> that one can convincingly argue that this should not introduce
> >> regressions.
> >>
> >
> > From what I recall that was my original plan.
> >
> > Yeah, it is a fair way forward. @Dmitry how would you like to approach
> > this? SInce you re-started the discussion. What is your timeline/KPIs
> > for this.
> >
> > I could personally try to whip up a small series after the merge
> > window by rewriting what I have[1]. I have more experience now in
> > drafting this kind of thing and that series added some cruft to the pm
> > core with multiple additions to platform_s2idle_ops
> >
> > There is a _small_ quantitative difference due to moving the calls.
> > Specifically, the power light responds a tad slower when waking a
> > device. For the legion go (non-s) devices, Lenovo added a dummy 5
> > second timer to resuming the controllers because of some Windows bugs,
> > and moving the calls causes the timer to start later. But that's the
> > OEM intended behavior...
> >
> > Antheas
> >
> > [1] https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/
>
> Am I understanding correctly that the plan is to have a 2-stage freezer
> for suspend-to-idle + standby mode? Rafael, could you please confirm
> that you're fine with this 2-stage freezer part of the proposal from
> Antheas?

I still need to get to the details there, but I don't think that a
2-stage freezer is a good idea.  There is enough fragility in the
freezer that we have already.

> What you expect to be a proper way of implementing a 2-stage freezer?
> Would it be a new executable capability, a new syscall or extension of
> existing one, a new cgroup type? How would you mark processes that
> should not be frozen on the first stage? Or it would be only the process
> that writes to /sysfs/power?
>
> Thanks everyone for the very detailed input. It is all very productive,
> helps a lot with adjusting my understanding of the modern suspend features.
>
> Agree that the usefulness of the visual aspect of the Display
> notification is questionable. Previously I thought this mode involves
> power-limiting. The Sleep notification might be much more interesting then.

Well, the problem is that the Sleep notification has ordering
assumptions AFAIK and it really cannot be triggered from user space.

All really depends on what the goal is, but in any case I think that
the required preliminary step would be to move the "screen off" and
"screen on" notifications in the current suspend-to-idle flow, so they
occur earlier and later, respectively.

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

[Antheas Kapenekakis]

On Sun, 7 Dec 2025 at 12:07, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> GMail did something silly to my reply to this message, so resending it
> in case it didn't make it to the lists.  Sorry for duplicates.
>
> On Fri, Dec 5, 2025 at 11:52=E2=80=AFPM Antheas Kapenekakis
> <lkml@antheas.dev> wrote:
> >
> > On Fri, 5 Dec 2025 at 17:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Dec 4, 2025 at 7:31=E2=80=AFPM Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > > >
> > > > On Thu, 4 Dec 2025 at 17:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > >
>
> [cut]
>
> > >
> > > In Linux, making the system look like it is suspended even though in
> > > fact it isn't may be quite confusing, as a user may think that it is
> > > now safe to put a laptop in a bag, for example, but in fact it isn't.
> >
> > My thesis would be a proper userspace implementation running on a
> > laptop with a properly configured platform, it should be safe for the
> > user to put the laptop in their bag, even if it wakes up briefly
> > multiple times per hour without their knowledge or being perceivable.
>
> That's what Android phones/tablets do, but that's a vertical software stack.
>
> To implement something like this you need (a) support from the GFX driver
> in the kernel to go into system suspend back and forth without turning
> displays on and off, and (b) a mechanism to trigger system suspend
> automatically after a period of inactivity while in the "displays off, no
> GUI activity" state, and (c) support for system wakeup events in (b).

a) is already implemented for AMD devices. I have not done a lot of
intel testing. Compositors just need to fire DPMS themselves.
b) already implemented by systemd
c) systemd has a binary called systemd-sleep[1]. After inactivity,
this script is called and is responsible for implementing the current
suspend target, whether that is sleep, suspend-then-hibernate.

It is currently pretty basic, and only handles one type of wake-up
event. This is the RTC timer/Battery alarm and only if in a
suspend-then-hibernate flow. Everything else is assumed to resume the
system and unfreezes userspace/turns on the displays.

But an initial "dark resume" feature/the sleep notification would go
in that file. For a more complete implementation, more userspace
refactoring would be needed, e.g., a secondary state after systemctl
suspend with some services that can mark to run periodically and are
frozen separately.

[1] https://github.com/systemd/systemd/blob/80cfe9abf267e9e51049e9d6200f02b7922bd4d7/src/sleep/sleep.c

> I'm not sure what the LPS0 _DSM role is in that.

Nothing, these _DSMs just contain vendor code for configuring device
appearance that is out of scope for kernel drivers.

> > It is also a very valid point that this is a _very fine_ line that
> > Windows crossed with its userspace implementation and soured the
> > perception of Modern Standby for a lot of users. Buggy platform
> > firmware/insufficient tooling/control for OEMs, early on also
> > contributed to this.
> >
> > > > >
> > > > > To be precise, that's what MSDN has to say about it:
> > > > >
> > > > > "This _DSM Function will be invoked when the operating system has
> > > > > entered a state where all displays=E2=80=94local and remote, if any==E2=80=94have been
> > > > > turned off. This could occur based on some user action, e.g. a button
> > > > > press or lid close event, or expiration of some display power down
> > > > > timer."
> > > > >
> > > > > The "Intel Low-power S0 Idle" specification
> > > > > (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle=.pdf)
> > > > > says almost the same thing.
> > > > >
> > > > > None of them says what kind of hint this is to the firmware and what
> > > > > the firmware is expected to do in response to it.
> > > >
> > > > It is true that online documentation does not list the firmware
> > > > response. There is additional documentation that lists the exact entry
> > > > conditions for display on/off [1]
> > > >
> > > > Specifically, while it is a prerequisite of the CRTCs, local/remote,
> > > > being turned off, the actual condition mirrors when userspace would
> > > > present a lockscreen to the user. I.e., if it is due to inactivity,
> > > > those notifications fire 5 seconds after displays turn off, and if it
> > > > is due to explicit action, e.g., power button, it is instant.
> > > >
> > > > "However, the system continues to run and all applications continue t=
> o
> > > > operate normally as if the display was powered on." also implies that
> > > > no hw is powered off as part of this notification.
> > > >
> > > > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/display--sleep--and-hibernate-idle-timers
> > >
> > > Wouldn't just turning the display off be sufficient here?  Why do you
> > > want to go for platform notification in addition to it?
>
> [cut]
>
> > There is a tendency by Microsoft to add OEM tooling that avoids the
> > need for creating platform drivers.
> >
> > This includes the WMI implementation which allows Windows userspace to
> > talk to hardware without having a signed platform driver, and now this
> > standardized set of notifications. Maintaining a signed
> > vulnerability-free driver is expensive.
> >
> > The Display On/Off notifications provide hooks for OEMs to customize
> > the inactive appearance of their device. Mostly, this is through
> > turning off auxiliary lights, such as the keyboard backlight.
> >
> > The sleep notifications provide a way for OEMs to limit the thermal
> > envelope of their machine and make it look like it is asleep, so that
> > it is safe for that device to wake up multiple times per hour,
> > including in a bag, without looking like it is awake.
>
> This is based on a very optimistic assumption that generally cannot be
> verified I'm afraid.
>
> (1) User space must not do anything silly like Bitcoin mining while
> this is done.
> (2) The firmware must not be cheating.
> (3) The GFX driver needs to be able to transition transparently
> between the "displays off" graphics state and the system suspend and
> resume flows.
> (4) The GFX driver activity needs to be coordinated at least somewhat
> with whatever user space entity would be responsible for triggering
> the notifications so they do not get completely out of sync.

1: Currently, it is fine for userspace to wake up and mine bitcoin in
a user's bag. My Nvidia thinkpad does that currently, it wakes up,
fails to hibernate and drains the battery. Sigh. So I am not sure why
in this case the kernel would need to be stricter.

2: Even if it "cheats", or e.g., does nothing, for the sleep state
that would mean an unbound power envelope. If the userspace
implementation is a bit reserved and e.g., handles wake-ups that
should not be a problem. For more advanced use-cases years down the
line perhaps it would be more of a problem.

3: Already done in the kernel side

4: Even if they unsync, I've tested them thoroughly in that state and
I have not found a device that malfunctions yet. So the implementation
of the check could be deferred.

> > Here is an example with how these DSMs would work with thinkpads.
> >
> > Windows does not have a Thinkpad backlight driver. There is auxiliary
> > and optional software, Vantage, which provides some of this. Assume it
> > is not installed. Then, in Linux, assume you disable the thinkpad
> > backlight driver, so upower loses control of the thinkpad keyboard
> > backlight. The thinkpad keyboard backlight is automatically controlled
> > by the EC through keyboard shortcuts. So are the power modes, via Fn+L
> > M H.
> >
> > Then, assume that Linux implements these _DSMs, and hooks them via
> > systemd as following: display on/off is hooked to occur when logind
> > would lock the session, i.e. after 5 seconds of inactivity or pressing
> > the power button. The sleep notifications are triggered by
> > systemd-sleep, before suspend-then-hibernate begins.
> >
> > The end result is that after the display turns off, the keyboard
> > backlight of the device will also turn off automatically without a
> > platform driver. This is true for all modern standby laptops at least
> > post ~2021. A lot of these do not have kernel drivers in linux.
> >
> > Then, if the sleep state is supported (spotty in thinkpads but
> > available in a lot of other hw), when the RTC Wake Alarm/battery alarm
> > wakes the device and systemd briefly checks whether it should
> > hibernate, it will still look like it is asleep, and it will have a
> > reduced power envelope, reducing the risk of overheating if it is in a
> > bag and lowering standby power consumption.
> >
> > I.e., without requiring vendor software, platform drivers, both
> > Windows and Linux present a full feature set out of the box.
>
> I guess it would be rather useful to start the discussion with this
> proposed flow, some time might have been saved by everyone.
>
> IIUC, the point is to make the system look "suspended" if it goes out
> of suspend briefly in response to a wakeup event (the other potential
> "benefits" of what the notifications can possibly do are in the domain
> of marketing IMV), but is it really worth the hassle?

When it comes to the kernel side, I do not think it is much work. The
draft series I had was around 12 kernel patches and could be condensed
a bit.

> Assuming that the answer is "yes", which I'm not convinced about at
> all, can't the kernel simply defer the "screen on" notification to
> some time after thawing user space, so it can avoid doing it and the
> corresponding "screen off" one if the system is suspended again
> quickly enough? Perhaps so long as the GFX driver opts in?

Can't be delayed arbitrarily. Since it controls the suspend
light/keyboard backlight to have correct behavior it needs to fire at
exact moments to look correct. When it comes to resuming through user
input, the faster the better.

> And now we get to the most important thing: even before trying to do
> the above, let alone exposing anything to user space, the existing
> suspend-to-idle flow in the kernel needs to be adjusted to do the
> "screen off" notification much earlier and the "screen off"
> notification much later than they are done today.  I think that you
> should be able to argue convincingly for making this change.
>
> If this doesn't universally work for whatever reason, anything more
> will be out of the question.
>

Yeah, that is a fair way forward. Moving the notifications for
sleep/display on to after userspace freeze, before userspace unfreeze.
Then optionally hooking drm to turn off crtcs before the notifications
(I did not follow the patches for that; it might already be the case).

Antheas

Re: [RFC PATCH v1 0/1] ACPI: s2idle: Add /sys/power/lps0_screen_off

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Hi!

> Introduce the `/sys/power/lps0_screen_off` sysfs interface, enabling
> userspace control over ACPI LPS0 Display Off/On notifications [1].
> 
> These notifications are a part of a Modern Standby [2]. The Display Off
> notification signals the firmware when all displays (physical and remote)
> are off, allowing it to enter lower power states that makes device pretend
> it has been suspended while the system remains operational.

What is "remote" display? Remote desktop? ssh connection?

This needs better name. If it enables powersaving in exchange for
100msec latency, for example, it should say that. I'm pretty sure it
will be useful elsewhere, and all the world is not ACPI.

BR,
								Pavel

-- 
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, Netanyahu and Musk!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]