All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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.