drivers/platform/x86/asus-wmi.c | 21 +++++++++++++++++++++ include/linux/platform_data/x86/asus-wmi.h | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-)
Fix key led not turning on/off when the camera key is pressed. The
asus_wmi_dev_is_present(ASUS_WMI_DEVID_CAMERA_LED) check fails on
Zenbook S14, and no sysfs attribute for the camera key led is
created.
The check succeeds for ASUS_WMI_DEVID_CAMERA_LED_NEG, though,
and when it is read, the led state is synchronized. By doing a read after
every key press, the led is guaranteed to stay in sync with the actual
camera state.
This change is not visible to userspace, as no sysfs attribute for
ASUS_WMI_DEVID_CAMERA_LED_NEG exists.
Tested on an ASUS Zenbook S14 with BIOS version UX5406SA.309.
Signed-off-by: José Guilherme de Castro Rodrigues <jose.guilherme.cr.bh@gmail.com>
---
drivers/platform/x86/asus-wmi.c | 21 +++++++++++++++++++++
include/linux/platform_data/x86/asus-wmi.h | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 0b87214ddd1b..a50a2a6cee98 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -70,6 +70,8 @@ module_param(fnlock_default, bool, 0444);
#define NOTIFY_KBD_TTP 0xae
#define NOTIFY_LID_FLIP 0xfa
#define NOTIFY_LID_FLIP_ROG 0xbd
+#define NOTIFY_CAMERA_TOGGLE_1 0x82
+#define NOTIFY_CAMERA_TOGGLE_2 0x85
#define ASUS_WMI_FNLOCK_BIOS_DISABLED BIT(0)
@@ -307,6 +309,7 @@ struct asus_wmi {
u32 kbd_rgb_dev;
bool kbd_rgb_state_available;
bool oobe_state_available;
+ bool camera_neg_led_available;
u8 throttle_thermal_policy_mode;
u32 throttle_thermal_policy_dev;
@@ -1982,6 +1985,18 @@ static int micmute_led_set(struct led_classdev *led_cdev,
return err < 0 ? err : 0;
}
+static bool is_camera_toggle(int code)
+{
+ return code == NOTIFY_CAMERA_TOGGLE_1 || code == NOTIFY_CAMERA_TOGGLE_2;
+}
+
+static void camera_neg_led_trigger_update(struct asus_wmi *asus)
+{
+ u32 result;
+
+ asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_CAMERA_LED_NEG, &result);
+}
+
static enum led_brightness camera_led_get(struct led_classdev *led_cdev)
{
struct asus_wmi *asus;
@@ -4587,6 +4602,11 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
if (is_display_toggle(code) && asus->driver->quirks->no_display_toggle)
return;
+ if (is_camera_toggle(code) && asus->camera_neg_led_available) {
+ camera_neg_led_trigger_update(asus);
+ return;
+ }
+
if (!sparse_keymap_report_event(asus->inputdev, code,
key_value, autorelease))
pr_info("Unknown key code 0x%x\n", code);
@@ -5062,6 +5082,7 @@ static int asus_wmi_add(struct platform_device *pdev)
#endif /* IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS) */
asus->oobe_state_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_OOBE);
+ asus->camera_neg_led_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_CAMERA_LED_NEG);
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_THROTTLE_THERMAL_POLICY))
asus->throttle_thermal_policy_dev = ASUS_WMI_DEVID_THROTTLE_THERMAL_POLICY;
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 554f41b827e1..1a9349da6069 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -56,7 +56,7 @@
#define ASUS_WMI_DEVID_MICMUTE_LED 0x00040017
/* Disable Camera LED */
-#define ASUS_WMI_DEVID_CAMERA_LED_NEG 0x00060078 /* 0 = on (unused) */
+#define ASUS_WMI_DEVID_CAMERA_LED_NEG 0x00060078 /* 0 = on */
#define ASUS_WMI_DEVID_CAMERA_LED 0x00060079 /* 1 = on */
/* Backlight and Brightness */
--
2.53.0On Tue, Mar 31, 2026 at 08:01:47PM -0300, José Guilherme de Castro Rodrigues wrote:
>
> This change is not visible to userspace, as no sysfs attribute for
> ASUS_WMI_DEVID_CAMERA_LED_NEG exists.
>
> + if (is_camera_toggle(code) && asus->camera_neg_led_available) {
> + camera_neg_led_trigger_update(asus);
> + return;
> + }
> +
> if (!sparse_keymap_report_event(asus->inputdev, code,
> key_value, autorelease))
> pr_info("Unknown key code 0x%x\n", code);
This change is actually visible to userspace because I'm early returning
and that means the event for the camera key is not propagated to
userspace. Sashiko correctly identified that, as well as another detail
in formatting (using space instead of tab for indentation on the newly
added macros). The event is currently not used on my system, so I didn't
notice it before.
Removing the return fixes this. I can send a new version of the patch if
necessary.
Best Regards,
José Rodrigues
On Thu, 2 Apr 2026, José Guilherme de Castro Rodrigues wrote:
> On Tue, Mar 31, 2026 at 08:01:47PM -0300, José Guilherme de Castro Rodrigues wrote:
> >
> > This change is not visible to userspace, as no sysfs attribute for
> > ASUS_WMI_DEVID_CAMERA_LED_NEG exists.
> >
> > + if (is_camera_toggle(code) && asus->camera_neg_led_available) {
> > + camera_neg_led_trigger_update(asus);
> > + return;
> > + }
> > +
> > if (!sparse_keymap_report_event(asus->inputdev, code,
> > key_value, autorelease))
> > pr_info("Unknown key code 0x%x\n", code);
>
> This change is actually visible to userspace because I'm early returning
> and that means the event for the camera key is not propagated to
> userspace. Sashiko correctly identified that, as well as another detail
> in formatting (using space instead of tab for indentation on the newly
> added macros). The event is currently not used on my system, so I didn't
> notice it before.
>
> Removing the return fixes this. I can send a new version of the patch if
> necessary.
Please just send a new version. It will be much easier for me when I don't
need to hunt down odd spaces or do multi-line code edits.
--
i.
On Thu, Apr 09, 2026 at 03:45:29PM +0300, Ilpo Järvinen wrote: > > Please just send a new version. It will be much easier for me when I don't > need to hunt down odd spaces or do multi-line code edits. Sure, I sent the PATCH v2 a few days ago. I look forward for any feedback. Here is the link in case something went wrong and it did not arrive correctly, or if it just got lost amidst this rather busy list: https://lore.kernel.org/platform-driver-x86/adg6GzkykThAB_4u@djouze-zen/ Thank you for your time, and sorry for any inconvenience. Best regards, José Rodrigues
On Wed, 22 Apr 2026, José Guilherme de Castro Rodrigues wrote: > On Thu, Apr 09, 2026 at 03:45:29PM +0300, Ilpo Järvinen wrote: > > > > Please just send a new version. It will be much easier for me when I don't > > need to hunt down odd spaces or do multi-line code edits. > > Sure, I sent the PATCH v2 a few days ago. I look forward for any > feedback. Here is the link in case something went wrong and it did not > arrive correctly, or if it just got lost amidst this rather busy list: > > https://lore.kernel.org/platform-driver-x86/adg6GzkykThAB_4u@djouze-zen/ > > Thank you for your time, and sorry for any inconvenience. Okay. The patch seems to be sitting in the queue like it should be. Pending patches can always be viewed from there (MAINTAINERS file also has this link): https://patchwork.kernel.org/project/platform-driver-x86/list/ I (as the maintainer) won't forget any patch that appears on that list. I admit though catching myself a few times accidently closing a patch as "accepted" when I did not do the last apply step of my workflow. If a patch ever happens to suffer from such an unfortunate fate, it does not appear in either review-ilpo-* branch nor in the patchwork anymore, pinging is definitely useful (after a few days, there may be small delays in pushing review-ilpo-* branches out). -- i.
© 2016 - 2026 Red Hat, Inc.