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

["José Guilherme de Castro Rodrigues" <jose.guilherme.cr.bh@gmail.com>]

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?

Best regards,
José Rodrigues