Re: [PATCH v2] platform/x86: asus-wmi: fix camera key led on Zenbook S14

[Ilpo Järvinen]

On Tue, 28 Apr 2026, José Guilherme de Castro Rodrigues wrote:

> Thanks for the comment, Ilpo.
> 
> On Tue, Apr 28, 2026 at 11:22:20AM +0300, Ilpo Järvinen wrote:
> > While I believe you are "correct" that userspace won't see a thing, is 
> > this really correct way to implement support for this device?
> 
> At first, I created another sysfs attribute that basically duplicated
> the logic that is used for the "asus::camera" attribute, with the
> exception being the value that was written to it, of course. I noticed,
> however, that calling asus_wmi_set_devstate() had not effect on the LED
> state. The LED only toggled when I read the attribute, which then called
> asus_wmi_get_devstate().
> 
> I don't know if this is a quirk for this device, or if all devices that
> expose ASUS_WMI_DEVID_CAMERA_LED_NEG behave the same, but the LED is not
> toggled until I call asus_wmi_get_devstate() - be it when detecting a
> key press (hardware change) or after the sysfs attribute is written to
> (software change).
> 
> Since in this case the LED state would not change after a write to the
> sysfs attribute, I went in the "do not make it visible to userspace at
> all" direction.
> 
> > I mean the camera led init in asus_wmi_led_init() is gated by 
> > asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_CAMERA_LED) but should that 
> > be gated by either CAMERA_LED or CAMERA_LED_NEG and the related code in 
> > *_camera_led_*() that now only uses ASUS_WMI_DEVID_CAMERA_LED 
> > should use which ever of them is available?
> 
> Yes, I think what you said makes sense as it would give userspace access
> to the resource without creating a new attribute.
> 
> In this case, I feel like a good option would be to gate the camera led
> initialization by both IDs, and assume that the write and read works as
> they probably should for CAMERA_LED_NEG. Then, somehow add a quirk for
> this specific device that performs a read when the key is pressed, and 
> right after the sysfs attribute is written to. If we can confirm that
> this behavior is expected when writing to CAMERA_LED_NEG, it might not
> need to be a quirk. Unfortunately, I am not able to try this on other
> devices.
> 
> What do you think about it?

So if I understood you correctly with LED_NEG (unknown if it's just on 
your device or generally with it),

This doesn't work: set
This works: set+get

The extra get shouldn't be that harmful so doing that always if 
CAMERA_LED_NEG is being used is okay at least with me (make sure to add 
add a comment though so it can be known later why it's there even 10 
years from now).

-- 
 i.