[RFC] platform/x86: asus-wmi: no kbd backlight on Zenbook S 16 UM5606WA

[RFC] platform/x86: asus-wmi: no kbd backlight on Zenbook S 16 UM5606WA

[Catalin Cereanu]

Hi,

On the ASUS Zenbook S 16 UM5606WA (Ryzen AI 9 HX 370), asus-wmi creates
no asus::kbd_backlight LED and the factory Fn+F4 backlight key produces
no input event at all. The keyboard backlight hardware itself works
fine.

I have tracked this to a single firmware flag and have a working
out-of-tree fix, but I do not think the fix belongs in asus-wmi in its
current form. I am sending this as an RFC to ask what shape, if any,
would be acceptable.

Hardware / software
-------------------
  Model        ASUS Zenbook S 16 UM5606WA
  BIOS         UM5606WA.321, 10/14/2025
  Kernel       6.17.0-35-generic (Ubuntu/Linux Mint 22.3)
  asus_wmi     BIOS WMI version 9.4, SFUN 0x21, "Detected ATK, not ASUSWMI"

Symptoms
--------
  * /sys/class/leds/ contains no asus::kbd_backlight (only platform::micmute)
  * UPower exposes no KbdBacklight object
  * The Fn+F4 media key emits nothing: no evdev event on any device, no ACPI
    event, and no "Unknown key" message. The same key in its F4 function-layer
    role emits KEY_F4 normally, so the key and the EC layer logic are fine.

Root cause
----------
Both symptoms come from one flag: bit 7 of KBLC. From the DSDT:

    OperationRegion (AECO, SystemMemory, AECB, 0x1E)
    Field (AECO, AnyAcc, NoLock, Preserve)
    {
        ...
        Offset (0x0F), KBLC, 8,
        Offset (0x10), KBLV, 8,
        ...
    }

    Method (KBLD, 0, NotSerialized)
    {
        If (ATKP)
        {
            Local1 = (KBLC & 0x80)
            If (Local1)
            {
                ^^^^ATKD.IANE (0xC5)
            }
        }
    }                                   /* note: no Else branch */

    Method (KBLU, 0, NotSerialized)     /* same shape, IANE (0xC7) */
    Method (_Q0C, 0, NotSerialized) { KBLD () }
    Method (_Q0D, 0, NotSerialized) { KBLU () }

The EC does fire _Q0C/_Q0D on the media key. With KBLC bit 7 clear the
method falls through both conditionals and returns without notifying
anyone, which is why the key is completely silent rather than producing
an unknown scancode.

The same flag gates the DSTS presence reply that asus-wmi relies on:

    If ((IIA0 == 0x00050021))
    {
        If (^^PCI0.SBRG.EC0.GLKB (One))     /* returns One if (KBLC & 0x80) */
        {
            Local0 = ^^PCI0.SBRG.EC0.GLKB (0x03)
            Local0 <<= 0x08
            Local0 += ^^PCI0.SBRG.EC0.GLKB (0x02)
            Local0 |= 0x00050000
            Local0 |= 0x00200000
            Local0 |= 0x00100000
            Return (Local0)
        }

        Return (0x8000)                     /* no presence bit */
    }

So kbd_led_read() -> asus_wmi_get_devstate_bits() returns -ENODEV,
kbd_led_avail stays false, and no LED is registered.

Measured on this machine:

    \_SB.ATKP                     = 0x1     (INIT ran, gate 1 passes)
    GLKB(1)  i.e. KBLC & 0x80     = 0x0     (gate 2 fails)
    GLKB(2)  current level        = 0x1
    GLKB(3)  base                 = 0x80

Note the DEVS *setter* is not gated:

    If ((IIA0 == 0x00050021))
    {
        ^^PCI0.SBRG.EC0.SLKB (IIA1)
        Return (One)
    }

so the backlight can be driven even while the firmware reports it
absent.

Nothing writes KBLC
-------------------
I dumped and decompiled all 48 ACPI tables on this machine (DSDT, 30
SSDTs and 17 others). KBLC appears exactly four times: once in the field
declaration above, and three times as a read (GLKB, KBLD, KBLU). No
method in any table writes it. By contrast BLCT, the panel-backlight
equivalent, does have a WMI setter at devid 0x00050011.

So the BIOS simply never sets it on this SKU. An earlier ASUS laptop I
owned (Vivobook S14, 2024) worked out of the box, so this looks like a
firmware regression on the AMD SKU rather than an intentional
configuration.

Confirmed fix
-------------
Setting KBLC bit 7 fixes both symptoms. I wrote a small out-of-tree
module that resolves the address two independent ways and sets the bit:

    RAMW @ 0x70265000  ->  AECB @ +0x20  ->  AECO @ *AECB  ->  KBLC @ +0x0F

On this machine AECB = 0x70265300. Cross-check: KBLV read directly from
that mapping matches GLKB(2) evaluated through the ACPI interpreter.

After setting the bit:

    GLKB(1) 0x0 -> 0x1
    asus_wmi: using asus-wmi for asus::kbd_backlight
    /sys/class/leds/asus::kbd_backlight, max_brightness = 3

and the factory Fn+F4 key now cycles the backlight normally.

No "Unknown key" message appeared in testing and no keymap addition was
needed. I have not separately confirmed whether IANE(0xC7) is actually
emitted on this machine, so I cannot say whether the absence of a 0xC7
entry in the asus-nb-wmi keymap matters here.

Questions
---------
1. Would a DMI quirk that force-registers the LED (bypassing the DSTS presence
   check, since the DEVS setter works regardless) be acceptable? That would
   restore sysfs brightness control, but NOT the Fn+F4 key, since KBLD/KBLU
   remain gated in firmware.

2. Is there any appetite for setting KBLC from asus-wmi under a DMI quirk?
   It would fix both, but it means mapping an ACPI NVS address by firmware
   field plus a hardcoded structure offset, which feels out of place in this
   driver. I would understand a no.

3. Or is this purely a firmware bug to push to ASUS, with the out-of-tree
   module as the practical answer for affected owners?

I am happy to write and test whichever option you prefer. I can also
provide the full decompiled DSDT and acpidump output.

Thanks, Catalin Cereanu

Re: [RFC] platform/x86: asus-wmi: no kbd backlight on Zenbook S 16 UM5606WA

[Catalin Cereanu]

Following up on my own RFC: after sending it I came across prior art for
the first of the three questions I raised, which makes that part much
less open-ended than I posed it.

The FA401 series has the same shape of problem with a different device -
WMI device 0x00100057 is not reported by DSTS even though the EC does
support it - and that was handled with a DMI quirk ORing a quirk_entry
flag into the availability test rather than trusting the probe:

  https://lore.kernel.org/platform-driver-x86/20260902174718.16228-1-idotohors@gmail.com/

If the same approach is acceptable for the keyboard backlight here, the
equivalent would match DMI_SYS_VENDOR "ASUSTeK COMPUTER INC." and
DMI_BOARD_NAME "UM5606WA", and do roughly:

    static struct quirk_entry quirk_asus_um5606wa = {
            .kbd_backlight_available = true,
    };

with, in asus_wmi_led_init():

    asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL) ||
                          asus->driver->quirks->kbd_backlight_available;

That would restore sysfs brightness control, since the DEVS setter at
0x00050021 works regardless of what DSTS reports.

It would not restore the Fn+F4 key, which stays gated on KBLC in
firmware, so questions 2 and 3 in the original mail still stand as
written.

Happy to send this as a proper patch if the shape looks right.

Thanks,
Catalin Cereanu