[Bug 221133] New: asus-wmi: keyboard backlight not detected on ASUS Zenbook S 14 UX5406SA due to KBLC flag not set in BIOS

[Bug 221133] New: asus-wmi: keyboard backlight not detected on ASUS Zenbook S 14 UX5406SA due to KBLC flag not set in BIOS

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221133

            Bug ID: 221133
           Summary: asus-wmi: keyboard backlight not detected on ASUS
                    Zenbook S 14 UX5406SA due to KBLC flag not set in BIOS
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: keithpsu03@gmail.com
        Regression: No

System:
•  Device: ASUS Zenbook S 14 UX5406SA
•  Board: UX5406SA
•  BIOS: UX5406SA.308 (06/05/2025)
•  Kernel: 6.17.0-14-generic (Ubuntu)
•  Platform: Intel Lunar Lake

Bug:
The asus-wmi driver does not create asus::kbd_backlight on this laptop, even
though the keyboard backlight hardware works. GNOME cannot display a brightness
OSD or manage auto-timeout on inactivity.

Root cause:
The WMI DSTS handler for ASUS_WMI_DEVID_KBD_BACKLIGHT (0x00050021) calls the EC
method GLKB(1), which checks KBLC & 0x80. On this laptop, the BIOS does not set
bit 7 of the KBLC ACPI variable, so GLKB(1) returns 0, and the driver's
kbd_led_init() sees -ENODEV from asus_wmi_get_devstate_simple().

However, the DEVS handler for 0x00050021 calls SLKB() unconditionally (no KBLC
check), and the hardware responds correctly:

# Confirm GLKB(1) returns 0 (backlight reported as not present):
echo "\_SB.PC00.LPCB.EC0.GLKB 1" > /proc/acpi/call
cat /proc/acpi/call
# Result: 0x0

# But calling SLKB directly turns on the backlight:
echo "\_SB.PC00.LPCB.EC0.SLKB 0x83" > /proc/acpi/call
cat /proc/acpi/call
# Result: 0x1 (success, backlight turns on)

Relevant DSDT excerpts (BIOS UX5406SA.308):

KBLC is an 8-bit field in the AECO SystemMemory region:

OperationRegion (AECO, SystemMemory, AECB, 0x1F)
Field (AECO, AnyAcc, NoLock, Preserve)
{
    AECS, 32, ACPF, 8, DCPF, 8, TPSV, 8, TCRT, 8,
    PPSV, 8, DSYN, 8, WOLO, 8, EGBF, 32,
    KBLC, 8,   // <-- bit 7 gates kbd backlight presence
    KBLV, 8,
    ...
}

GLKB (get keyboard backlight state):

Method (GLKB, 1, NotSerialized)
{
    If ((Arg0 == One))
    {
        Local0 = (KBLC & 0x80)
        If (Local0) { Return (One) }
        Else        { Return (Zero) }  // <-- always hits this path
    }
    ElseIf ((Arg0 == 0x02)) { Return (KBLV) }
    ElseIf ((Arg0 == 0x03)) { Return (0x80) }
    Return (Ones)
}

SLKB (set keyboard backlight) — works unconditionally:

Method (SLKB, 1, NotSerialized)
{
    KBLV = (Arg0 & 0x7F)
    If ((Arg0 & 0x80)) { Local0 = DerefOf (PWKB [KBLV]) }
    Else               { Local0 = Zero }
    ST9E (0x1F, 0xFF, Local0)
    Return (One)
}

Additional context:
An earlier unit of this same model (before RMA replacement) had the keyboard
backlight working correctly under Linux, suggesting a BIOS update removed or
broke the KBLC bit 7 initialization.

Proposed fix:
Add a DMI quirk for the UX5406SA that skips the KBLC presence check and forces
keyboard backlight support, since the hardware and SLKB setter work correctly
regardless. Something like:

static const struct dmi_system_id asus_wmi_force_kbd_backlight[] = {
    {
        .matches = {
            DMI_MATCH(DMI_BOARD_NAME, "UX5406SA"),
        },
    },
    { }
};

And in kbd_led_init(), if the DMI matches, proceed with backlight setup even if
asus_wmi_get_devstate_simple() returns -ENODEV.

Workaround:
Using acpi_call to directly invoke SLKB:

modprobe acpi_call
echo "\_SB.PC00.LPCB.EC0.SLKB 0x83" > /proc/acpi/call

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.