From: bugzilla-daemon@kernel.org
To: platform-driver-x86@vger.kernel.org
Subject: [Bug 221752] asus-wmi: no camera LED classdev registered on Zenbook S 14 UX5406SA (micmute LED works)
Date: Sat, 10 Oct 2026 21:09:35 +0000 [thread overview]
Message-ID: <bug-221752-215701-z45DwGMijP@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-221752-215701@https.bugzilla.kernel.org/>
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.
prev parent reply other threads:[~2026-10-10 21:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:36 [Bug 221752] New: asus-wmi: no camera LED classdev registered on Zenbook S 14 UX5406SA (micmute LED works) bugzilla-daemon
2026-10-10 21:09 ` bugzilla-daemon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-221752-215701-z45DwGMijP@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.