[Bug 221752] New: asus-wmi: no camera LED classdev registered on Zenbook S 14 UX5406SA (micmute LED works)

[Bug 221752] New: asus-wmi: no camera LED classdev registered on Zenbook S 14 UX5406SA (micmute LED works)

[bugzilla-daemon]

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

            Bug ID: 221752
           Summary: asus-wmi: no camera LED classdev registered on Zenbook
                    S 14 UX5406SA (micmute LED works)
           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: plattform@roninmail.cc
        Regression: No

Created attachment 310450
  --> https://bugzilla.kernel.org/attachment.cgi?id=310450&action=edit
CLI with information I guessed you might need.

Hardware
ASUS Zenbook S 14, UX5406SA_UX5406SA
BIOS UX5406SA.303, 11/08/2024
Fedora 44, kernel 7.1.3-200.fc44.x86_64, KDE Plasma (Wayland)
Secure Boot enabled (kernel lockdown active)
Description
The Fn camera key correctly toggles the internal camera at the firmware level:
when disabled, /dev/video0 cannot be opened; when enabled, it streams normally.
The keypress is delivered to userspace.
However, the camera indicator LED is never driven under Linux. It remains dark
regardless of camera state. The user therefore has a functional privacy toggle
with no working indicator.
Key observation
asus-wmi registers and correctly drives a LED classdev for micmute on this
machine, but registers nothing for the camera:
$ ls /sys/class/leds/
asus::kbd_backlight  platform::micmute  phy0-led
input2::capslock  input2::numlock  input2::scrolllock
input25::*  input28::*  input29::*
Same driver, same EC, same machine — one indicator is wired up, the other is
not.
Additional data

/sys/class/firmware-attributes/asus-armoury/attributes/ contains only
charge_mode and pending_reboot.
asus-wmi debugfs is unavailable under Secure Boot (lockdown), so
ASUS_WMI_DEVID_CAMERA (0x00060013) could not be probed via DSTS/DEVS.
v4l2-ctl -d /dev/video0 -L reports privacy with flags=read-only, value=0 — the
UVC privacy control is not the mechanism in use.

dmesg (asus)
asus_wmi: Initialization: 0x1
asus_wmi: BIOS WMI version: 9.4
asus_wmi: SFUN value: 0x21
asus-nb-wmi asus-nb-wmi: Detected ATK, not ASUSWMI, use DSTS
input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input15
asus_armoury: No matching power limits found for this system
asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -19
Note: the LED was previously stuck permanently lit; a cold boot cleared it and
it has not lit since. This is consistent with a latched EC state and no
kernel-driven LED path in either direction.
Possibly related: the S5406SA (same generation) has a reported asus-wmi issue
traced to missing LED plumbing (Launchpad #2092283).
Request: register a camera LED classdev for this model, as is done for micmute,
so the camera privacy indicator reflects actual camera state.

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

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

[Bug 221752] asus-wmi: no camera LED classdev registered on Zenbook S 14 UX5406SA (micmute LED works)

[bugzilla-daemon]

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

git@turtledev.nz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |git@turtledev.nz

--- Comment #1 from git@turtledev.nz ---
Same laptop here, UX5406SA with BIOS .309 (11/18/2025), Fedora 44 on
7.2.9-200.fc44, secure boot on. Same issue, no asus::camera LED.

I dumped the DSDT to see what's going on. I think it also explains why the
set side didn't work for José in "[PATCH v2] platform/x86: asus-wmi: fix
camera key led on Zenbook S14".

0x00060079 (CAMERA_LED) just returns 0 for both DSTS and DEVS on this
machine, so asus-wmi never registers the LED. Everything is on 0x00060078
(CAMERA_LED_NEG).

The DSTS handler for 0x00060078 reads EC register 0x50 and writes the
result straight to the LED GPIO before returning:

    Local1 = ^^PC00.LPCB.EC0.ST8E (0x50, Zero)
    If (((Local1 & One) == One))       { Local0 = One }
    ElseIf (((Local1 & 0x02) == 0x02)) { Local0 = Zero }
    If ((FSIS == Zero)) { Local0 |= 0x00080000 }
    Local0 |= 0x00050000
    Local2 = (Local0 & One)
    SGOV (0x00180885, Local2)
    Return (Local0)

So a plain read is what updates the LED. Reading it after the camera key
event, like v2 does, is enough. It's probably worth a comment in the code
since the side effect isn't obvious.

DEVS on 0x00060078 (2 = LED on, 3 = LED off) is guarded by a one-shot flag:

    If ((FSIS == One)) { Return (Zero) }
    FSIS = One

FSIS only gets cleared in EC0W when Arg0 == 4 (resume from S4). So after the
first call each boot, every set returns 0 and does nothing. Bit 0x80000 in
the DSTS result shows whether that first call is still available. I'd treat
the LED as read-only on this model.

Other things I noticed:

- The firmware handles the privacy itself. While the camera is "off",
  /dev/video0 still opens and streams, but every frame is a grey placeholder
  with a crossed-out camera icon. There's no USB disconnect. The key LED
  stays dark the whole time, since nothing does the DSTS read.
- On S0ix entry the PEPD _DSM turns the GPIO off, and on exit it only turns
  it back on if EC 0x50 bit1 is set. That might be related to the stuck LED
  in the original report.
- GPIO 0x00180885 is GPP_H_5 (INTC105D:02 pin 31). Micmute is GPP_H_4 right
  next to it. The pad is config-locked but TX isn't, so as a workaround
  "gpioset -c <chip> -t0 31=0" turns the LED on and 31=1 turns it off.

I couldn't call WMI directly because of lockdown, so this is all from reading
the DSDT. I can attach the acpidump, and I'm happy to test a v3.

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

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