Re: [PATCH v3 1/2] platform/x86: asus-wmi: adjust screenpad power/brightness handling — regression on non-DUO ScreenPad (ASUS ZenBook UX435EG)

Re: [PATCH v3 1/2] platform/x86: asus-wmi: adjust screenpad power/brightness handling — regression on non-DUO ScreenPad (ASUS ZenBook UX435EG)

[Denis Benato]

On 8/1/26 19:24, Manuel A. R. de Orúe Ríos wrote:
> Hi Denis, Luke,
>
> I'm following up on this patch series (commit 034f5efd362fb87a3970d61eaf982664f84e6c5a,
> merged for kernel 7.0.10) — I believe I've found and confirmed a regression it
> introduces on non-DUO ScreenPad hardware.
>
> Hardware: ASUS ZenBook UX435EG (BIOS UX435EG.315), single ScreenPad model
> (not ScreenPad Plus / DUO).
>
Hello Manuel,

Thanks for the report and additional information. Quite recently there has been
another user with yet another model reporting a regression in this field:
https://lore.kernel.org/all/178362762638.911488.8564892548331679884@eldamar.lan/
and hopefully this is the same bug.

> Symptom: after upgrading past kernel-7.0.9-205 to kernel-7.0.10-200 (and
> confirmed still present in 7.1.5), the ScreenPad stops functioning as a
> secondary display entirely — it still works as a touchpad (separate i2c-hid
> digitizer), but the panel itself never lights up as a screen.
>
> I bisected this cleanly across official Fedora kernel builds:
>   kernel-7.0.9-205.fc44   -> works
>   kernel-7.0.10-200.fc44  -> broken
>   kernel-7.1.5-201.fc44   -> still broken
>
> Root cause, as far as I can tell: in update_screenpad_bl_status(), the new
> logic branches on bd->props.power being truthy/falsy, but in the backlight
> framework convention, props.power == 0 means ON (FB_BLANK_UNBLANK) and any
> non-zero value means OFF. The new code appears to have this inverted:
>
I don't think any non-zero value is meant to mean OFF but perhaps the kernel simply
checks in various places !props.power for the status (?) I have found this:

#define BACKLIGHT_POWER_ON              (0)
#define BACKLIGHT_POWER_OFF             (4)

and that clears my question on "why 4 and not 1 if it's a simple bool?".
>     if (ctrl_param >= 0 && bd->props.power) {
>         err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_POWER, 1, NULL); // turns ON
>         ...
>     }
>     if (!bd->props.power) {
>         err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_POWER, 0, NULL); // turns OFF
>     }
>
> On my hardware, sysfs reports bl_power = 0 (which the kernel considers "ON"),
> but that's exactly the condition that triggers the branch sending
> SCREENPAD_POWER = 0 (off) via WMI — so the panel ends up physically powered
> off as a display, while sysfs still reports it as on at full brightness.
>
> I confirmed this empirically: manually writing bl_power = 4 (which the
> framework considers "off") reliably turns the panel back on as a display on
> my hardware:
>
>     echo 4 > /sys/class/backlight/asus_screenpad/bl_power
>
> I understand from the review thread that this series was tested specifically
> on a ZenBook DUO — it's very possible the DUO's ScreenPad firmware/EC
> behaves differently enough that the polarity works out correctly there, while
> it's inverted on this single-ScreenPad model.
>
Honestly I am not that sure about the inversion: it looks like a mistake
from me simplifying the Luke's original code and I highly hope this is
the case or I will need to branch what gets set depending on the DMI.
> Happy to test any proposed fix on this hardware, or provide more DMI/ACPI/
> debug info if useful. I'm currently working around this with a udev-triggered
> script forcing bl_power=4 on boot, but would obviously prefer a proper fix.
>
Do you want a patch or are you fine with small edits?

My understanding is that switching in the two if:

bd->props.power with (bd->props.power == BACKLIGHT_POWER_ON)

and

!bd->props.power with (bd->props.power == BACKLIGHT_POWER_OFF)

the hardware should return working fine again.

Very likely I assumed "not power" as... "not power" when it was a shorthand
for writing "power on".

> Kernel/hardware details:
> DMI: ASUSTeK COMPUTER INC. ZenBook UX435EG_UX435EG/UX435EG, BIOS UX435EG.315 04/22/2022
> Distro: Fedora Linux 44 (KDE Plasma)
>
> Thanks for the work on this — I know these ScreenPad quirks are a pain to
> get right across the different hardware variants.
>
Worry not, I will make it working again: I just need a few hints on these
mystical objects.

Best regards,
Denis
> Best,
> ___________________________

Re: [PATCH v3 1/2] platform/x86: asus-wmi: adjust screenpad power/brightness handling — regression on non-DUO ScreenPad (ASUS ZenBook UX435EG)

[Denis Benato]

On 8/1/26 20:03, Manuel A. R. de Orúe Ríos wrote:
> Hi Denis, Luke,
>
> I'm following up on this patch series (commit 034f5efd362fb87a3970d61eaf982664f84e6c5a,
> merged for kernel 7.0.10) — I believe I've found and confirmed a regression it
> introduces on non-DUO ScreenPad hardware.
>
> Hardware: ASUS ZenBook UX435EG (BIOS UX435EG.315), single ScreenPad model
> (not ScreenPad Plus / DUO).
>
> Symptom: after upgrading past kernel-7.0.9-205 to kernel-7.0.10-200 (and
> confirmed still present in 7.1.5), the ScreenPad stops functioning as a
> secondary display entirely — it still works as a touchpad (separate i2c-hid
> digitizer), but the panel itself never lights up as a screen.
>
> I bisected this cleanly across official Fedora kernel builds:
>   kernel-7.0.9-205.fc44   -> works
>   kernel-7.0.10-200.fc44  -> broken
>   kernel-7.1.5-201.fc44   -> still broken
>
>
> image.png
> I understand from the review thread that this series was tested specifically
> on a ZenBook DUO — it's very possible the DUO's ScreenPad firmware/EC
> behaves differently enough that the polarity works out correctly there, while
> it's inverted on this single-ScreenPad model.
>
> Happy to test any proposed fix on this hardware, or provide more DMI/ACPI/
> debug info if useful. I'm currently working around this with a udev-triggered
> script forcing bl_power=4 on boot, but would obviously prefer a proper fix.
>
> Kernel/hardware details:
> DMI: ASUSTeK COMPUTER INC. ZenBook UX435EG_UX435EG/UX435EG, BIOS UX435EG.315 04/22/2022
> Distro: Fedora Linux 44 (KDE Plasma)
>
> Thanks for the work on this — I know these ScreenPad quirks are a pain to
> get right across the different hardware variants.
>
> Best,
> ___________________________


Please try the below patch and see if it fixes things for you:

From e9f4d0ef00c4f3e1ba26db68a688e523a743e733 Mon Sep 17 00:00:00 2001
From: Denis Benato <denis.benato@linux.dev>
Date: Wed, 5 Aug 2026 16:05:36 +0000
Subject: [PATCH] platform/x86: asus-wmi: fix unclear usage of bd->props.power
The bd->props.power is checked in parts of the driver correctly comparing with
BACKLIGHT_POWER_ON, while in others with a raw usage of bd->props.power
and !bd->props.power, moreover in certain checks the logic has been
inverted due to BACKLIGHT_POWER_ON being defined as 0: fix both the wrong
usage and the inconsistencies by using proper comparisons.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/platform/x86/asus-wmi.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 8610663b8269..3600dddd8f36 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -4500,7 +4500,8 @@static int update_screenpad_bl_status(struct backlight_device *bd)
u32 ctrl_param = bd->props.brightness;
int err = 0;
- if (bd->props.power) {
+ switch (bd->props.power) {
+ case BACKLIGHT_POWER_ON:
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_POWER, 1, NULL);
if (err < 0)
return err;
@@ -4508,12 +4509,17 @@static int update_screenpad_bl_status(struct backlight_device *bd)
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_LIGHT, ctrl_param, NULL);
if (err < 0)
return err;
- }
+ break;
- if (!bd->props.power) {
+ case BACKLIGHT_POWER_OFF:
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_POWER, 0, NULL);
if (err < 0)
return err;
+ break;
+
+ default:
+ pr_warn("Invalid screenpad backlight power state: %d\n", bd->props.power);
+ return -EINVAL;
}
return err;
-- 
2.47.3