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

[bugzilla-daemon@kernel.org]

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

--- Comment #2 from silk98287@hotmail.co.uk ---
Hi, I'm also experiencing this same problem, where the camera disabled 
LED doesn't illuminate despite the firmware blocking the camera when f10 
is pressed. I'm using a Zenbook S 16 UM5606WA on bios ver 321 and Linux 
7.2.9+deb14-amd64. My device is missing both the LED classdev 
"asus::camera" and the device id 0x00060079 (ASUS_WMI_DEVID_CAMERA_LED). 
I created a little patch that seemed to fixed this issue by also reading 
the status from device 0x00060078 (ASUS_WMI_DEVID_CAMERA_LED_NEG) if it 
is present, every time the f10 hotkey was pressed (on my device this 
fired the WMI code 0x85). Although this worked, both the micmute key and 
camera toggle key LEDs would turn themselves off every time the computer 
was powered off, and not come back on until pressed (even though the mic 
/ camera would still actually be disabled). I was first going to look 
into that, but I can still send in the patch I have - I'm very new to 
this so I'm not sure how to proceed, and I'm sorry if I've messed up any 
formatting of this email, it is my first mail to the mailing list. :)

On 10/10/2026 22:09, bugzilla-daemon@kernel.org wrote:
> 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.