* [PATCH v6 1/7] HID: asus: refactor init sequence per spec
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-15 10:53 ` Ilpo Järvinen
2025-10-13 20:15 ` [PATCH v6 2/7] HID: asus: prevent binding to all HID devices on ROG Antheas Kapenekakis
` (7 subsequent siblings)
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
Currently, asus_kbd_init() uses a reverse engineered init sequence
from Windows, which contains the handshakes from multiple programs.
Keep the main one, which is 0x5a (meant for brightness drivers).
In addition, perform a get_response and check if the response is the
same. To avoid regressions, print an error if the response does not
match instead of rejecting device.
Then, refactor asus_kbd_get_functions() to use the same ID it is called
with, instead of hardcoding it to 0x5a so that it may be used for 0x0d
in the future.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/hid/hid-asus.c | 91 ++++++++++++++++++++++--------------------
1 file changed, 48 insertions(+), 43 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index a444d41e53b6..d0c783df99bc 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -48,7 +48,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define FEATURE_REPORT_ID 0x0d
#define INPUT_REPORT_ID 0x5d
#define FEATURE_KBD_REPORT_ID 0x5a
-#define FEATURE_KBD_REPORT_SIZE 16
+#define FEATURE_KBD_REPORT_SIZE 64
#define FEATURE_KBD_LED_REPORT_ID1 0x5d
#define FEATURE_KBD_LED_REPORT_ID2 0x5e
@@ -393,14 +393,37 @@ static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t bu
static int asus_kbd_init(struct hid_device *hdev, u8 report_id)
{
- const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54,
- 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
+ /*
+ * The handshake is first sent as a set_report, then retrieved
+ * from a get_report. They should be equal.
+ */
+ const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20,
+ 0x54, 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
+ u8 *readbuf;
int ret;
ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
- if (ret < 0)
- hid_err(hdev, "Asus failed to send init command: %d\n", ret);
+ if (ret < 0) {
+ hid_err(hdev, "Asus failed to send handshake: %d\n", ret);
+ return ret;
+ }
+
+ readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
+ if (!readbuf)
+ return -ENOMEM;
+
+ ret = hid_hw_raw_request(hdev, report_id, readbuf,
+ FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
+ if (ret < 0) {
+ hid_err(hdev, "Asus failed to receive handshake ack: %d\n", ret);
+ } else if (memcmp(readbuf, buf, sizeof(buf)) != 0) {
+ hid_warn(hdev, "Asus handshake returned invalid response: %*ph\n",
+ FEATURE_KBD_REPORT_SIZE, readbuf);
+ // Do not return error if handshake is wrong to avoid regressions
+ }
+ kfree(readbuf);
return ret;
}
@@ -422,7 +445,7 @@ static int asus_kbd_get_functions(struct hid_device *hdev,
if (!readbuf)
return -ENOMEM;
- ret = hid_hw_raw_request(hdev, FEATURE_KBD_REPORT_ID, readbuf,
+ ret = hid_hw_raw_request(hdev, report_id, readbuf,
FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
HID_REQ_GET_REPORT);
if (ret < 0) {
@@ -638,50 +661,32 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
unsigned char kbd_func;
int ret;
- if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
- /* Initialize keyboard */
- ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
- if (ret < 0)
- return ret;
-
- /* The LED endpoint is initialised in two HID */
- ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
- if (ret < 0)
- return ret;
-
- ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
- if (ret < 0)
- return ret;
-
- if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
- ret = asus_kbd_disable_oobe(hdev);
- if (ret < 0)
- return ret;
- }
-
- if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
- intf = to_usb_interface(hdev->dev.parent);
- udev = interface_to_usbdev(intf);
- validate_mcu_fw_version(hdev,
- le16_to_cpu(udev->descriptor.idProduct));
- }
+ ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
+ if (ret < 0)
+ return ret;
- } else {
- /* Initialize keyboard */
- ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
- if (ret < 0)
- return ret;
+ /* Get keyboard functions */
+ ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
+ if (ret < 0)
+ return ret;
- /* Get keyboard functions */
- ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
+ if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
+ ret = asus_kbd_disable_oobe(hdev);
if (ret < 0)
return ret;
+ }
- /* Check for backlight support */
- if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
- return -ENODEV;
+ if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
+ intf = to_usb_interface(hdev->dev.parent);
+ udev = interface_to_usbdev(intf);
+ validate_mcu_fw_version(
+ hdev, le16_to_cpu(udev->descriptor.idProduct));
}
+ /* Check for backlight support */
+ if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
+ return -ENODEV;
+
drvdata->kbd_backlight = devm_kzalloc(&hdev->dev,
sizeof(struct asus_kbd_leds),
GFP_KERNEL);
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 1/7] HID: asus: refactor init sequence per spec
2025-10-13 20:15 ` [PATCH v6 1/7] HID: asus: refactor init sequence per spec Antheas Kapenekakis
@ 2025-10-15 10:53 ` Ilpo Järvinen
2025-10-15 11:18 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-15 10:53 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> Currently, asus_kbd_init() uses a reverse engineered init sequence
> from Windows, which contains the handshakes from multiple programs.
> Keep the main one, which is 0x5a (meant for brightness drivers).
>
> In addition, perform a get_response and check if the response is the
> same. To avoid regressions, print an error if the response does not
> match instead of rejecting device.
I'm none the wiser on "why?" question after reading all this. Please
describe the change properly. Besides, you do many thing changes which are
not mentioned here at all.
And what "spec" is the one you mention in the shortlog?
> Then, refactor asus_kbd_get_functions() to use the same ID it is called
> with, instead of hardcoding it to 0x5a so that it may be used for 0x0d
> in the future.
Can this be in own patch?
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/hid/hid-asus.c | 91 ++++++++++++++++++++++--------------------
> 1 file changed, 48 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index a444d41e53b6..d0c783df99bc 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -48,7 +48,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define FEATURE_REPORT_ID 0x0d
> #define INPUT_REPORT_ID 0x5d
> #define FEATURE_KBD_REPORT_ID 0x5a
> -#define FEATURE_KBD_REPORT_SIZE 16
> +#define FEATURE_KBD_REPORT_SIZE 64
> #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> #define FEATURE_KBD_LED_REPORT_ID2 0x5e
>
> @@ -393,14 +393,37 @@ static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t bu
>
> static int asus_kbd_init(struct hid_device *hdev, u8 report_id)
> {
> - const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54,
> - 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
> + /*
> + * The handshake is first sent as a set_report, then retrieved
> + * from a get_report. They should be equal.
> + */
> + const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20,
> + 0x54, 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
Why was layout of this changed?
> + u8 *readbuf;
> int ret;
>
> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> - if (ret < 0)
> - hid_err(hdev, "Asus failed to send init command: %d\n", ret);
> + if (ret < 0) {
> + hid_err(hdev, "Asus failed to send handshake: %d\n", ret);
> + return ret;
> + }
> +
> + readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
> + if (!readbuf)
> + return -ENOMEM;
> +
> + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> + FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> + HID_REQ_GET_REPORT);
> + if (ret < 0) {
> + hid_err(hdev, "Asus failed to receive handshake ack: %d\n", ret);
> + } else if (memcmp(readbuf, buf, sizeof(buf)) != 0) {
> + hid_warn(hdev, "Asus handshake returned invalid response: %*ph\n",
> + FEATURE_KBD_REPORT_SIZE, readbuf);
> + // Do not return error if handshake is wrong to avoid regressions
This driver so far is using only /* */ comments.
> + }
>
> + kfree(readbuf);
> return ret;
> }
>
> @@ -422,7 +445,7 @@ static int asus_kbd_get_functions(struct hid_device *hdev,
> if (!readbuf)
> return -ENOMEM;
>
> - ret = hid_hw_raw_request(hdev, FEATURE_KBD_REPORT_ID, readbuf,
> + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> HID_REQ_GET_REPORT);
> if (ret < 0) {
> @@ -638,50 +661,32 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> unsigned char kbd_func;
> int ret;
>
> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> - /* Initialize keyboard */
> - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> - if (ret < 0)
> - return ret;
> -
> - /* The LED endpoint is initialised in two HID */
> - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
> - if (ret < 0)
> - return ret;
> -
> - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
> - if (ret < 0)
> - return ret;
> -
> - if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> - ret = asus_kbd_disable_oobe(hdev);
> - if (ret < 0)
> - return ret;
> - }
> -
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> - intf = to_usb_interface(hdev->dev.parent);
> - udev = interface_to_usbdev(intf);
> - validate_mcu_fw_version(hdev,
> - le16_to_cpu(udev->descriptor.idProduct));
> - }
> + ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> + if (ret < 0)
> + return ret;
>
> - } else {
> - /* Initialize keyboard */
> - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> - if (ret < 0)
> - return ret;
> + /* Get keyboard functions */
> + ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> + if (ret < 0)
> + return ret;
>
> - /* Get keyboard functions */
> - ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> + if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> + ret = asus_kbd_disable_oobe(hdev);
> if (ret < 0)
> return ret;
> + }
>
> - /* Check for backlight support */
> - if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> - return -ENODEV;
> + if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + intf = to_usb_interface(hdev->dev.parent);
> + udev = interface_to_usbdev(intf);
> + validate_mcu_fw_version(
> + hdev, le16_to_cpu(udev->descriptor.idProduct));
> }
>
> + /* Check for backlight support */
> + if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> + return -ENODEV;
> +
> drvdata->kbd_backlight = devm_kzalloc(&hdev->dev,
> sizeof(struct asus_kbd_leds),
> GFP_KERNEL);
>
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 1/7] HID: asus: refactor init sequence per spec
2025-10-15 10:53 ` Ilpo Järvinen
@ 2025-10-15 11:18 ` Antheas Kapenekakis
2025-10-15 11:30 ` Ilpo Järvinen
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-15 11:18 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Wed, 15 Oct 2025 at 12:53, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
>
> > Currently, asus_kbd_init() uses a reverse engineered init sequence
> > from Windows, which contains the handshakes from multiple programs.
> > Keep the main one, which is 0x5a (meant for brightness drivers).
> >
> > In addition, perform a get_response and check if the response is the
> > same. To avoid regressions, print an error if the response does not
> > match instead of rejecting device.
>
> I'm none the wiser on "why?" question after reading all this. Please
> describe the change properly. **Besides, you do many thing changes which are
> not mentioned here at all.**
Changes in asus_kbd_register_leds look bigger than they are due to
un-indenting and merging the if/else for non-nkey/nkey.
I will update the text of the new patch to include the changes which
are 1) applying asus_kbd_get_functions to NKEY devices to check for
backlight, 2) removing 0x5d/0x5e initialization from NKEY devices
(0x5d is for armoury crate/0x5e for an aura matrix creator studio
thing), which then means that the if/else blocks are equivalent and
can be merged.
These two changes should not affect functionality, other than reduce
some init commands.
> And what "spec" is the one you mention in the shortlog?
>
> > Then, refactor asus_kbd_get_functions() to use the same ID it is called
> > with, instead of hardcoding it to 0x5a so that it may be used for 0x0d
> > in the future.
>
> Can this be in own patch?
I will spin this into three patches and reword. One for each paragraph
in the current commit body.
Ack on the rest.
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/hid/hid-asus.c | 91 ++++++++++++++++++++++--------------------
> > 1 file changed, 48 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > index a444d41e53b6..d0c783df99bc 100644
> > --- a/drivers/hid/hid-asus.c
> > +++ b/drivers/hid/hid-asus.c
> > @@ -48,7 +48,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > #define FEATURE_REPORT_ID 0x0d
> > #define INPUT_REPORT_ID 0x5d
> > #define FEATURE_KBD_REPORT_ID 0x5a
> > -#define FEATURE_KBD_REPORT_SIZE 16
> > +#define FEATURE_KBD_REPORT_SIZE 64
> > #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> > #define FEATURE_KBD_LED_REPORT_ID2 0x5e
> >
> > @@ -393,14 +393,37 @@ static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t bu
> >
> > static int asus_kbd_init(struct hid_device *hdev, u8 report_id)
> > {
> > - const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54,
> > - 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
> > + /*
> > + * The handshake is first sent as a set_report, then retrieved
> > + * from a get_report. They should be equal.
> > + */
> > + const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20,
> > + 0x54, 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
>
> Why was layout of this changed?
>
> > + u8 *readbuf;
> > int ret;
> >
> > ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> > - if (ret < 0)
> > - hid_err(hdev, "Asus failed to send init command: %d\n", ret);
> > + if (ret < 0) {
> > + hid_err(hdev, "Asus failed to send handshake: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
> > + if (!readbuf)
> > + return -ENOMEM;
> > +
> > + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> > + FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> > + HID_REQ_GET_REPORT);
> > + if (ret < 0) {
> > + hid_err(hdev, "Asus failed to receive handshake ack: %d\n", ret);
> > + } else if (memcmp(readbuf, buf, sizeof(buf)) != 0) {
> > + hid_warn(hdev, "Asus handshake returned invalid response: %*ph\n",
> > + FEATURE_KBD_REPORT_SIZE, readbuf);
> > + // Do not return error if handshake is wrong to avoid regressions
>
> This driver so far is using only /* */ comments.
>
> > + }
> >
> > + kfree(readbuf);
> > return ret;
> > }
> >
> > @@ -422,7 +445,7 @@ static int asus_kbd_get_functions(struct hid_device *hdev,
> > if (!readbuf)
> > return -ENOMEM;
> >
> > - ret = hid_hw_raw_request(hdev, FEATURE_KBD_REPORT_ID, readbuf,
> > + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> > FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> > HID_REQ_GET_REPORT);
> > if (ret < 0) {
> > @@ -638,50 +661,32 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> > unsigned char kbd_func;
> > int ret;
> >
> > - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> > - /* Initialize keyboard */
> > - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > - if (ret < 0)
> > - return ret;
> > -
> > - /* The LED endpoint is initialised in two HID */
> > - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
> > - if (ret < 0)
> > - return ret;
> > -
> > - if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> > - ret = asus_kbd_disable_oobe(hdev);
> > - if (ret < 0)
> > - return ret;
> > - }
> > -
> > - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> > - intf = to_usb_interface(hdev->dev.parent);
> > - udev = interface_to_usbdev(intf);
> > - validate_mcu_fw_version(hdev,
> > - le16_to_cpu(udev->descriptor.idProduct));
> > - }
> > + ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > + if (ret < 0)
> > + return ret;
> >
> > - } else {
> > - /* Initialize keyboard */
> > - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > - if (ret < 0)
> > - return ret;
> > + /* Get keyboard functions */
> > + ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> > + if (ret < 0)
> > + return ret;
> >
> > - /* Get keyboard functions */
> > - ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> > + if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> > + ret = asus_kbd_disable_oobe(hdev);
> > if (ret < 0)
> > return ret;
> > + }
> >
> > - /* Check for backlight support */
> > - if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> > - return -ENODEV;
> > + if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> > + intf = to_usb_interface(hdev->dev.parent);
> > + udev = interface_to_usbdev(intf);
> > + validate_mcu_fw_version(
> > + hdev, le16_to_cpu(udev->descriptor.idProduct));
> > }
> >
> > + /* Check for backlight support */
> > + if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> > + return -ENODEV;
> > +
> > drvdata->kbd_backlight = devm_kzalloc(&hdev->dev,
> > sizeof(struct asus_kbd_leds),
> > GFP_KERNEL);
> >
>
> --
> i.
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 1/7] HID: asus: refactor init sequence per spec
2025-10-15 11:18 ` Antheas Kapenekakis
@ 2025-10-15 11:30 ` Ilpo Järvinen
0 siblings, 0 replies; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-15 11:30 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
[-- Attachment #1: Type: text/plain, Size: 8734 bytes --]
On Wed, 15 Oct 2025, Antheas Kapenekakis wrote:
> On Wed, 15 Oct 2025 at 12:53, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> >
> > > Currently, asus_kbd_init() uses a reverse engineered init sequence
> > > from Windows, which contains the handshakes from multiple programs.
> > > Keep the main one, which is 0x5a (meant for brightness drivers).
> > >
> > > In addition, perform a get_response and check if the response is the
> > > same. To avoid regressions, print an error if the response does not
> > > match instead of rejecting device.
> >
> > I'm none the wiser on "why?" question after reading all this. Please
> > describe the change properly. **Besides, you do many thing changes which are
> > not mentioned here at all.**
>
> Changes in asus_kbd_register_leds look bigger than they are due to
> un-indenting and merging the if/else for non-nkey/nkey.
>
> I will update the text of the new patch to include the changes which
> are 1) applying asus_kbd_get_functions to NKEY devices to check for
> backlight, 2) removing 0x5d/0x5e initialization from NKEY devices
> (0x5d is for armoury crate/0x5e for an aura matrix creator studio
> thing), which then means that the if/else blocks are equivalent and
> can be merged.
Oh, I see it now. It was not at all obvious you wanted to consolidate the
init path because of all the other moving parts, to me it looked like you
just removed the if (<quirk>) check.
> These two changes should not affect functionality, other than reduce
> some init commands.
>
> > And what "spec" is the one you mention in the shortlog?
> >
> > > Then, refactor asus_kbd_get_functions() to use the same ID it is called
> > > with, instead of hardcoding it to 0x5a so that it may be used for 0x0d
> > > in the future.
> >
> > Can this be in own patch?
>
> I will spin this into three patches and reword. One for each paragraph
> in the current commit body.
3 patches already sounds much better! They'll surely be easier to review
and understand if somebody has to look at the commits years later from the
commit history.
Thanks.
--
i.
> Ack on the rest.
>
> > > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > > ---
> > > drivers/hid/hid-asus.c | 91 ++++++++++++++++++++++--------------------
> > > 1 file changed, 48 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > > index a444d41e53b6..d0c783df99bc 100644
> > > --- a/drivers/hid/hid-asus.c
> > > +++ b/drivers/hid/hid-asus.c
> > > @@ -48,7 +48,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > #define FEATURE_REPORT_ID 0x0d
> > > #define INPUT_REPORT_ID 0x5d
> > > #define FEATURE_KBD_REPORT_ID 0x5a
> > > -#define FEATURE_KBD_REPORT_SIZE 16
> > > +#define FEATURE_KBD_REPORT_SIZE 64
> > > #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> > > #define FEATURE_KBD_LED_REPORT_ID2 0x5e
> > >
> > > @@ -393,14 +393,37 @@ static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t bu
> > >
> > > static int asus_kbd_init(struct hid_device *hdev, u8 report_id)
> > > {
> > > - const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54,
> > > - 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
> > > + /*
> > > + * The handshake is first sent as a set_report, then retrieved
> > > + * from a get_report. They should be equal.
> > > + */
> > > + const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20,
> > > + 0x54, 0x65, 0x63, 0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
> >
> > Why was layout of this changed?
> >
> > > + u8 *readbuf;
> > > int ret;
> > >
> > > ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> > > - if (ret < 0)
> > > - hid_err(hdev, "Asus failed to send init command: %d\n", ret);
> > > + if (ret < 0) {
> > > + hid_err(hdev, "Asus failed to send handshake: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
> > > + if (!readbuf)
> > > + return -ENOMEM;
> > > +
> > > + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> > > + FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> > > + HID_REQ_GET_REPORT);
> > > + if (ret < 0) {
> > > + hid_err(hdev, "Asus failed to receive handshake ack: %d\n", ret);
> > > + } else if (memcmp(readbuf, buf, sizeof(buf)) != 0) {
> > > + hid_warn(hdev, "Asus handshake returned invalid response: %*ph\n",
> > > + FEATURE_KBD_REPORT_SIZE, readbuf);
> > > + // Do not return error if handshake is wrong to avoid regressions
> >
> > This driver so far is using only /* */ comments.
> >
> > > + }
> > >
> > > + kfree(readbuf);
> > > return ret;
> > > }
> > >
> > > @@ -422,7 +445,7 @@ static int asus_kbd_get_functions(struct hid_device *hdev,
> > > if (!readbuf)
> > > return -ENOMEM;
> > >
> > > - ret = hid_hw_raw_request(hdev, FEATURE_KBD_REPORT_ID, readbuf,
> > > + ret = hid_hw_raw_request(hdev, report_id, readbuf,
> > > FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> > > HID_REQ_GET_REPORT);
> > > if (ret < 0) {
> > > @@ -638,50 +661,32 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> > > unsigned char kbd_func;
> > > int ret;
> > >
> > > - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> > > - /* Initialize keyboard */
> > > - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > > - if (ret < 0)
> > > - return ret;
> > > -
> > > - /* The LED endpoint is initialised in two HID */
> > > - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
> > > - if (ret < 0)
> > > - return ret;
> > > -
> > > - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
> > > - if (ret < 0)
> > > - return ret;
> > > -
> > > - if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> > > - ret = asus_kbd_disable_oobe(hdev);
> > > - if (ret < 0)
> > > - return ret;
> > > - }
> > > -
> > > - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> > > - intf = to_usb_interface(hdev->dev.parent);
> > > - udev = interface_to_usbdev(intf);
> > > - validate_mcu_fw_version(hdev,
> > > - le16_to_cpu(udev->descriptor.idProduct));
> > > - }
> > > + ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > > + if (ret < 0)
> > > + return ret;
> > >
> > > - } else {
> > > - /* Initialize keyboard */
> > > - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> > > - if (ret < 0)
> > > - return ret;
> > > + /* Get keyboard functions */
> > > + ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> > > + if (ret < 0)
> > > + return ret;
> > >
> > > - /* Get keyboard functions */
> > > - ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> > > + if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
> > > + ret = asus_kbd_disable_oobe(hdev);
> > > if (ret < 0)
> > > return ret;
> > > + }
> > >
> > > - /* Check for backlight support */
> > > - if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> > > - return -ENODEV;
> > > + if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> > > + intf = to_usb_interface(hdev->dev.parent);
> > > + udev = interface_to_usbdev(intf);
> > > + validate_mcu_fw_version(
> > > + hdev, le16_to_cpu(udev->descriptor.idProduct));
> > > }
> > >
> > > + /* Check for backlight support */
> > > + if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
> > > + return -ENODEV;
> > > +
> > > drvdata->kbd_backlight = devm_kzalloc(&hdev->dev,
> > > sizeof(struct asus_kbd_leds),
> > > GFP_KERNEL);
> > >
> >
> > --
> > i.
> >
> >
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v6 2/7] HID: asus: prevent binding to all HID devices on ROG
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-10-13 20:15 ` [PATCH v6 1/7] HID: asus: refactor init sequence per spec Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-15 10:59 ` Ilpo Järvinen
2025-10-13 20:15 ` [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers Antheas Kapenekakis
` (6 subsequent siblings)
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
ROG keyboards are HID compliant and only care about the endpoint that
produces vendor events (e.g., fan mode) and has the keyboard backlight.
Therefore, handle all of the endpoints of ROG keyboards as compliant,
by adding HID_QUIRK_INPUT_PER_APP and, for devices other than the vendor
one, by adding QUIRK_HANDLE_GENERIC to stop mutating them.
Due to HID_QUIRK_INPUT_PER_APP, rgb register is moved into probe, as
the input_* functions are called multiple times (4 for the Z13).
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/hid/hid-asus.c | 71 +++++++++++++++++++++++++++++-------------
1 file changed, 50 insertions(+), 21 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d0c783df99bc..a62559e3e064 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -47,6 +47,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define T100CHI_MOUSE_REPORT_ID 0x06
#define FEATURE_REPORT_ID 0x0d
#define INPUT_REPORT_ID 0x5d
+#define HID_USAGE_PAGE_VENDOR 0xff310000
#define FEATURE_KBD_REPORT_ID 0x5a
#define FEATURE_KBD_REPORT_SIZE 64
#define FEATURE_KBD_LED_REPORT_ID1 0x5d
@@ -89,6 +90,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define QUIRK_ROG_NKEY_KEYBOARD BIT(11)
#define QUIRK_ROG_CLAYMORE_II_KEYBOARD BIT(12)
#define QUIRK_ROG_ALLY_XPAD BIT(13)
+#define QUIRK_HANDLE_GENERIC BIT(14)
#define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
QUIRK_NO_INIT_REPORTS | \
@@ -125,7 +127,6 @@ struct asus_drvdata {
struct input_dev *tp_kbd_input;
struct asus_kbd_leds *kbd_backlight;
const struct asus_touchpad_info *tp;
- bool enable_backlight;
struct power_supply *battery;
struct power_supply_desc battery_desc;
int battery_capacity;
@@ -316,7 +317,7 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
static int asus_event(struct hid_device *hdev, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
- if ((usage->hid & HID_USAGE_PAGE) == 0xff310000 &&
+ if ((usage->hid & HID_USAGE_PAGE) == HID_USAGE_PAGE_VENDOR &&
(usage->hid & HID_USAGE) != 0x00 &&
(usage->hid & HID_USAGE) != 0xff && !usage->type) {
hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
@@ -331,6 +332,10 @@ static int asus_raw_event(struct hid_device *hdev,
{
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+ /* NOOP on generic HID devices to avoid side effects. */
+ if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
+ return 0;
+
if (drvdata->battery && data[0] == BATTERY_REPORT_ID)
return asus_report_battery(drvdata, data, size);
@@ -875,6 +880,10 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
struct input_dev *input = hi->input;
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+ /* NOOP on generic HID devices to avoid side effects. */
+ if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
+ return 0;
+
/* T100CHI uses MULTI_INPUT, bind the touchpad to the mouse hid_input */
if (drvdata->quirks & QUIRK_T100CHI &&
hi->report->id != T100CHI_MOUSE_REPORT_ID)
@@ -928,11 +937,6 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
drvdata->input = input;
- if (drvdata->enable_backlight &&
- !asus_kbd_wmi_led_control_present(hdev) &&
- asus_kbd_register_leds(hdev))
- hid_warn(hdev, "Failed to initialize backlight.\n");
-
return 0;
}
@@ -952,6 +956,10 @@ static int asus_input_mapping(struct hid_device *hdev,
return -1;
}
+ /* NOOP on generic HID devices to avoid side effects. */
+ if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
+ return 0;
+
/*
* Ignore a bunch of bogus collections in the T100CHI descriptor.
* This avoids a bunch of non-functional hid_input devices getting
@@ -1005,15 +1013,6 @@ static int asus_input_mapping(struct hid_device *hdev,
return -1;
}
- /*
- * Check and enable backlight only on devices with UsagePage ==
- * 0xff31 to avoid initializing the keyboard firmware multiple
- * times on devices with multiple HID descriptors but same
- * PID/VID.
- */
- if (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT)
- drvdata->enable_backlight = true;
-
set_bit(EV_REP, hi->input->evbit);
return 1;
}
@@ -1130,8 +1129,10 @@ static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
- int ret;
+ struct hid_report_enum *rep_enum;
struct asus_drvdata *drvdata;
+ struct hid_report *rep;
+ int ret, is_vendor = 0;
drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
if (drvdata == NULL) {
@@ -1215,18 +1216,42 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
+ /* Check for vendor for RGB init and handle generic devices properly. */
+ rep_enum = &hdev->report_enum[HID_INPUT_REPORT];
+ list_for_each_entry(rep, &rep_enum->report_list, list) {
+ if ((rep->application & HID_USAGE_PAGE) == HID_USAGE_PAGE_VENDOR)
+ is_vendor = true;
+ }
+
+ /*
+ * For ROG keyboards, make them hid compliant by
+ * creating one input per application. For interfaces other than
+ * the vendor one, disable hid-asus handlers.
+ */
+ if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
+ if (!is_vendor)
+ drvdata->quirks |= QUIRK_HANDLE_GENERIC;
+ hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ }
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "Asus hw start failed: %d\n", ret);
return ret;
}
+ if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
+ !asus_kbd_wmi_led_control_present(hdev) &&
+ asus_kbd_register_leds(hdev))
+ hid_warn(hdev, "Failed to initialize backlight.\n");
+
/*
- * Check that input registration succeeded. Checking that
- * HID_CLAIMED_INPUT is set prevents a UAF when all input devices
- * were freed during registration due to no usages being mapped,
- * leaving drvdata->input pointing to freed memory.
+ * For ROG keyboards, skip rename for consistency and ->input check as
+ * some devices do not have inputs.
*/
+ if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD)
+ return 0;
+
if (!drvdata->input || !(hdev->claimed & HID_CLAIMED_INPUT)) {
hid_err(hdev, "Asus input not registered\n");
ret = -ENOMEM;
@@ -1277,6 +1302,10 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
{
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+ /* NOOP on generic HID devices to avoid side effects. */
+ if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
+ return rdesc;
+
if (drvdata->quirks & QUIRK_FIX_NOTEBOOK_REPORT &&
*rsize >= 56 && rdesc[54] == 0x25 && rdesc[55] == 0x65) {
hid_info(hdev, "Fixing up Asus notebook report descriptor\n");
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 2/7] HID: asus: prevent binding to all HID devices on ROG
2025-10-13 20:15 ` [PATCH v6 2/7] HID: asus: prevent binding to all HID devices on ROG Antheas Kapenekakis
@ 2025-10-15 10:59 ` Ilpo Järvinen
0 siblings, 0 replies; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-15 10:59 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> ROG keyboards are HID compliant and only care about the endpoint that
> produces vendor events (e.g., fan mode) and has the keyboard backlight.
>
> Therefore, handle all of the endpoints of ROG keyboards as compliant,
> by adding HID_QUIRK_INPUT_PER_APP and, for devices other than the vendor
> one, by adding QUIRK_HANDLE_GENERIC to stop mutating them.
>
> Due to HID_QUIRK_INPUT_PER_APP, rgb register is moved into probe, as
> the input_* functions are called multiple times (4 for the Z13).
>
> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/hid/hid-asus.c | 71 +++++++++++++++++++++++++++++-------------
> 1 file changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index d0c783df99bc..a62559e3e064 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -47,6 +47,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define T100CHI_MOUSE_REPORT_ID 0x06
> #define FEATURE_REPORT_ID 0x0d
> #define INPUT_REPORT_ID 0x5d
> +#define HID_USAGE_PAGE_VENDOR 0xff310000
> #define FEATURE_KBD_REPORT_ID 0x5a
> #define FEATURE_KBD_REPORT_SIZE 64
> #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> @@ -89,6 +90,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define QUIRK_ROG_NKEY_KEYBOARD BIT(11)
> #define QUIRK_ROG_CLAYMORE_II_KEYBOARD BIT(12)
> #define QUIRK_ROG_ALLY_XPAD BIT(13)
> +#define QUIRK_HANDLE_GENERIC BIT(14)
>
> #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> QUIRK_NO_INIT_REPORTS | \
> @@ -125,7 +127,6 @@ struct asus_drvdata {
> struct input_dev *tp_kbd_input;
> struct asus_kbd_leds *kbd_backlight;
> const struct asus_touchpad_info *tp;
> - bool enable_backlight;
> struct power_supply *battery;
> struct power_supply_desc battery_desc;
> int battery_capacity;
> @@ -316,7 +317,7 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
> static int asus_event(struct hid_device *hdev, struct hid_field *field,
> struct hid_usage *usage, __s32 value)
> {
> - if ((usage->hid & HID_USAGE_PAGE) == 0xff310000 &&
> + if ((usage->hid & HID_USAGE_PAGE) == HID_USAGE_PAGE_VENDOR &&
> (usage->hid & HID_USAGE) != 0x00 &&
> (usage->hid & HID_USAGE) != 0xff && !usage->type) {
> hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
> @@ -331,6 +332,10 @@ static int asus_raw_event(struct hid_device *hdev,
> {
> struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>
> + /* NOOP on generic HID devices to avoid side effects. */
> + if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
> + return 0;
> +
> if (drvdata->battery && data[0] == BATTERY_REPORT_ID)
> return asus_report_battery(drvdata, data, size);
>
> @@ -875,6 +880,10 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
> struct input_dev *input = hi->input;
> struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>
> + /* NOOP on generic HID devices to avoid side effects. */
> + if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
> + return 0;
> +
> /* T100CHI uses MULTI_INPUT, bind the touchpad to the mouse hid_input */
> if (drvdata->quirks & QUIRK_T100CHI &&
> hi->report->id != T100CHI_MOUSE_REPORT_ID)
> @@ -928,11 +937,6 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
>
> drvdata->input = input;
>
> - if (drvdata->enable_backlight &&
> - !asus_kbd_wmi_led_control_present(hdev) &&
> - asus_kbd_register_leds(hdev))
> - hid_warn(hdev, "Failed to initialize backlight.\n");
> -
> return 0;
> }
>
> @@ -952,6 +956,10 @@ static int asus_input_mapping(struct hid_device *hdev,
> return -1;
> }
>
> + /* NOOP on generic HID devices to avoid side effects. */
> + if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
> + return 0;
> +
> /*
> * Ignore a bunch of bogus collections in the T100CHI descriptor.
> * This avoids a bunch of non-functional hid_input devices getting
> @@ -1005,15 +1013,6 @@ static int asus_input_mapping(struct hid_device *hdev,
> return -1;
> }
>
> - /*
> - * Check and enable backlight only on devices with UsagePage ==
> - * 0xff31 to avoid initializing the keyboard firmware multiple
> - * times on devices with multiple HID descriptors but same
> - * PID/VID.
> - */
> - if (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT)
> - drvdata->enable_backlight = true;
> -
> set_bit(EV_REP, hi->input->evbit);
> return 1;
> }
> @@ -1130,8 +1129,10 @@ static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
>
> static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> {
> - int ret;
> + struct hid_report_enum *rep_enum;
> struct asus_drvdata *drvdata;
> + struct hid_report *rep;
> + int ret, is_vendor = 0;
>
> drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> if (drvdata == NULL) {
> @@ -1215,18 +1216,42 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> + /* Check for vendor for RGB init and handle generic devices properly. */
> + rep_enum = &hdev->report_enum[HID_INPUT_REPORT];
> + list_for_each_entry(rep, &rep_enum->report_list, list) {
> + if ((rep->application & HID_USAGE_PAGE) == HID_USAGE_PAGE_VENDOR)
> + is_vendor = true;
> + }
> +
> + /*
> + * For ROG keyboards, make them hid compliant by
hid -> HID
> + * creating one input per application. For interfaces other than
> + * the vendor one, disable hid-asus handlers.
Please reflow to 80 chars.
> + */
> + if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> + if (!is_vendor)
> + drvdata->quirks |= QUIRK_HANDLE_GENERIC;
> + hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
> + }
> +
> ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> if (ret) {
> hid_err(hdev, "Asus hw start failed: %d\n", ret);
> return ret;
> }
>
> + if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> + !asus_kbd_wmi_led_control_present(hdev) &&
> + asus_kbd_register_leds(hdev))
> + hid_warn(hdev, "Failed to initialize backlight.\n");
> +
> /*
> - * Check that input registration succeeded. Checking that
> - * HID_CLAIMED_INPUT is set prevents a UAF when all input devices
> - * were freed during registration due to no usages being mapped,
> - * leaving drvdata->input pointing to freed memory.
> + * For ROG keyboards, skip rename for consistency and ->input check as
> + * some devices do not have inputs.
> */
> + if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD)
> + return 0;
> +
> if (!drvdata->input || !(hdev->claimed & HID_CLAIMED_INPUT)) {
> hid_err(hdev, "Asus input not registered\n");
> ret = -ENOMEM;
> @@ -1277,6 +1302,10 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> {
> struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>
> + /* NOOP on generic HID devices to avoid side effects. */
> + if (drvdata->quirks & QUIRK_HANDLE_GENERIC)
> + return rdesc;
> +
> if (drvdata->quirks & QUIRK_FIX_NOTEBOOK_REPORT &&
> *rsize >= 56 && rdesc[54] == 0x25 && rdesc[55] == 0x65) {
> hid_info(hdev, "Fixing up Asus notebook report descriptor\n");
>
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-10-13 20:15 ` [PATCH v6 1/7] HID: asus: refactor init sequence per spec Antheas Kapenekakis
2025-10-13 20:15 ` [PATCH v6 2/7] HID: asus: prevent binding to all HID devices on ROG Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-15 11:59 ` Ilpo Järvinen
2025-10-13 20:15 ` [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
` (5 subsequent siblings)
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
Some devices, such as the Z13 have multiple AURA devices connected
to them by USB. In addition, they might have a WMI interface for
RGB. In Windows, Armoury Crate exposes a unified brightness slider
for all of them, with 3 brightness levels.
Therefore, to be synergistic in Linux, and support existing tooling
such as UPower, allow adding listeners to the RGB device of the WMI
interface. If WMI does not exist, lazy initialize the interface.
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Tested-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
include/linux/platform_data/x86/asus-wmi.h | 16 +++
2 files changed, 121 insertions(+), 13 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index e72a2b5d158e..a2a7cd61fd59 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -258,6 +258,8 @@ struct asus_wmi {
int tpd_led_wk;
struct led_classdev kbd_led;
int kbd_led_wk;
+ bool kbd_led_avail;
+ bool kbd_led_registered;
struct led_classdev lightbar_led;
int lightbar_led_wk;
struct led_classdev micmute_led;
@@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
/* LEDs ***********************************************************************/
+struct asus_hid_ref {
+ struct list_head listeners;
+ struct asus_wmi *asus;
+ spinlock_t lock;
+};
+
+struct asus_hid_ref asus_ref = {
+ .listeners = LIST_HEAD_INIT(asus_ref.listeners),
+ .asus = NULL,
+ .lock = __SPIN_LOCK_UNLOCKED(asus_ref.lock),
+};
+
+int asus_hid_register_listener(struct asus_hid_listener *bdev)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ list_add_tail(&bdev->list, &asus_ref.listeners);
+ if (asus_ref.asus) {
+ if (asus_ref.asus->kbd_led_registered && asus_ref.asus->kbd_led_wk >= 0)
+ bdev->brightness_set(bdev, asus_ref.asus->kbd_led_wk);
+
+ if (!asus_ref.asus->kbd_led_registered) {
+ ret = led_classdev_register(
+ &asus_ref.asus->platform_device->dev,
+ &asus_ref.asus->kbd_led);
+ if (!ret)
+ asus_ref.asus->kbd_led_registered = true;
+ }
+ }
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(asus_hid_register_listener);
+
+void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ list_del(&bdev->list);
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
+}
+EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
+
/*
* These functions actually update the LED's, and are called from a
* workqueue. By doing this as separate work rather than when the LED
@@ -1609,6 +1658,7 @@ static int kbd_led_read(struct asus_wmi *asus, int *level, int *env)
static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
{
+ struct asus_hid_listener *listener;
struct asus_wmi *asus;
int max_level;
@@ -1616,25 +1666,39 @@ static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
max_level = asus->kbd_led.max_brightness;
asus->kbd_led_wk = clamp_val(value, 0, max_level);
- kbd_led_update(asus);
+
+ if (asus->kbd_led_avail)
+ kbd_led_update(asus);
+
+ list_for_each_entry(listener, &asus_ref.listeners, list)
+ listener->brightness_set(listener, asus->kbd_led_wk);
}
static void kbd_led_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
+ unsigned long flags;
+
/* Prevent disabling keyboard backlight on module unregister */
if (led_cdev->flags & LED_UNREGISTERING)
return;
+ spin_lock_irqsave(&asus_ref.lock, flags);
do_kbd_led_set(led_cdev, value);
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
}
static void kbd_led_set_by_kbd(struct asus_wmi *asus, enum led_brightness value)
{
- struct led_classdev *led_cdev = &asus->kbd_led;
+ struct led_classdev *led_cdev;
+ unsigned long flags;
+
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ led_cdev = &asus->kbd_led;
do_kbd_led_set(led_cdev, value);
led_classdev_notify_brightness_hw_changed(led_cdev, asus->kbd_led_wk);
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
}
static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
@@ -1644,6 +1708,9 @@ static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
asus = container_of(led_cdev, struct asus_wmi, kbd_led);
+ if (!asus->kbd_led_avail)
+ return asus->kbd_led_wk;
+
retval = kbd_led_read(asus, &value, NULL);
if (retval < 0)
return retval;
@@ -1759,7 +1826,15 @@ static int camera_led_set(struct led_classdev *led_cdev,
static void asus_wmi_led_exit(struct asus_wmi *asus)
{
- led_classdev_unregister(&asus->kbd_led);
+ unsigned long flags;
+
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ asus_ref.asus = NULL;
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
+
+ if (asus->kbd_led_registered)
+ led_classdev_unregister(&asus->kbd_led);
+
led_classdev_unregister(&asus->tpd_led);
led_classdev_unregister(&asus->wlan_led);
led_classdev_unregister(&asus->lightbar_led);
@@ -1773,6 +1848,8 @@ static void asus_wmi_led_exit(struct asus_wmi *asus)
static int asus_wmi_led_init(struct asus_wmi *asus)
{
int rv = 0, num_rgb_groups = 0, led_val;
+ struct asus_hid_listener *listener;
+ unsigned long flags;
if (asus->kbd_rgb_dev)
kbd_rgb_mode_groups[num_rgb_groups++] = &kbd_rgb_mode_group;
@@ -1797,23 +1874,38 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
goto error;
}
- if (!kbd_led_read(asus, &led_val, NULL) && !dmi_check_system(asus_use_hid_led_dmi_ids)) {
- pr_info("using asus-wmi for asus::kbd_backlight\n");
+ asus->kbd_led.name = "asus::kbd_backlight";
+ asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
+ asus->kbd_led.brightness_set = kbd_led_set;
+ asus->kbd_led.brightness_get = kbd_led_get;
+ asus->kbd_led.max_brightness = 3;
+ asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
+
+ if (asus->kbd_led_avail)
asus->kbd_led_wk = led_val;
- asus->kbd_led.name = "asus::kbd_backlight";
- asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
- asus->kbd_led.brightness_set = kbd_led_set;
- asus->kbd_led.brightness_get = kbd_led_get;
- asus->kbd_led.max_brightness = 3;
+ else
+ asus->kbd_led_wk = -1;
- if (num_rgb_groups != 0)
- asus->kbd_led.groups = kbd_rgb_mode_groups;
+ if (asus->kbd_led_avail && num_rgb_groups != 0)
+ asus->kbd_led.groups = kbd_rgb_mode_groups;
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ if (asus->kbd_led_avail || !list_empty(&asus_ref.listeners)) {
rv = led_classdev_register(&asus->platform_device->dev,
&asus->kbd_led);
- if (rv)
+ if (rv) {
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
goto error;
+ }
+ asus->kbd_led_registered = true;
+
+ if (asus->kbd_led_wk >= 0) {
+ list_for_each_entry(listener, &asus_ref.listeners, list)
+ listener->brightness_set(listener, asus->kbd_led_wk);
+ }
}
+ asus_ref.asus = asus;
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_WIRELESS_LED)
&& (asus->driver->quirks->wapf > 0)) {
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 8a515179113d..f13a701f47a8 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -163,11 +163,19 @@ enum asus_ally_mcu_hack {
ASUS_WMI_ALLY_MCU_HACK_DISABLED,
};
+struct asus_hid_listener {
+ struct list_head list;
+ void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
+};
+
#if IS_REACHABLE(CONFIG_ASUS_WMI)
void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
void set_ally_mcu_powersave(bool enabled);
int asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param, u32 *retval);
int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
+
+int asus_hid_register_listener(struct asus_hid_listener *cdev);
+void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
#else
static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
{
@@ -184,6 +192,14 @@ static inline int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
{
return -ENODEV;
}
+
+static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
+{
+ return -ENODEV;
+}
+static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
+{
+}
#endif
/* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-13 20:15 ` [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers Antheas Kapenekakis
@ 2025-10-15 11:59 ` Ilpo Järvinen
2025-10-15 15:45 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-15 11:59 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> Some devices, such as the Z13 have multiple AURA devices connected
> to them by USB. In addition, they might have a WMI interface for
> RGB. In Windows, Armoury Crate exposes a unified brightness slider
> for all of them, with 3 brightness levels.
>
> Therefore, to be synergistic in Linux, and support existing tooling
> such as UPower, allow adding listeners to the RGB device of the WMI
> interface. If WMI does not exist, lazy initialize the interface.
>
> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> Tested-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
> include/linux/platform_data/x86/asus-wmi.h | 16 +++
> 2 files changed, 121 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index e72a2b5d158e..a2a7cd61fd59 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -258,6 +258,8 @@ struct asus_wmi {
> int tpd_led_wk;
> struct led_classdev kbd_led;
> int kbd_led_wk;
> + bool kbd_led_avail;
> + bool kbd_led_registered;
> struct led_classdev lightbar_led;
> int lightbar_led_wk;
> struct led_classdev micmute_led;
> @@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
>
> /* LEDs ***********************************************************************/
>
> +struct asus_hid_ref {
> + struct list_head listeners;
> + struct asus_wmi *asus;
> + spinlock_t lock;
Please always document what a lock protects.
I started wonder why it needs to be spinlock?
It would seem rwsem is more natural for it as write is only needed at
probe/remove time (if there's no good reason for using a spinlock).
You're also missing include.
> +};
> +
> +struct asus_hid_ref asus_ref = {
Should be static ?
> + .listeners = LIST_HEAD_INIT(asus_ref.listeners),
> + .asus = NULL,
> + .lock = __SPIN_LOCK_UNLOCKED(asus_ref.lock),
> +};
> +
> +int asus_hid_register_listener(struct asus_hid_listener *bdev)
> +{
> + unsigned long flags;
> + int ret = 0;
> +
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + list_add_tail(&bdev->list, &asus_ref.listeners);
> + if (asus_ref.asus) {
> + if (asus_ref.asus->kbd_led_registered && asus_ref.asus->kbd_led_wk >= 0)
> + bdev->brightness_set(bdev, asus_ref.asus->kbd_led_wk);
> +
> + if (!asus_ref.asus->kbd_led_registered) {
> + ret = led_classdev_register(
> + &asus_ref.asus->platform_device->dev,
> + &asus_ref.asus->kbd_led);
> + if (!ret)
> + asus_ref.asus->kbd_led_registered = true;
I suggest you use guard() for the spinlock and return early where possible.
With guard() in use, you can do normal error handling here with return ret
immediately.
Please also add a local var for asus_ref.asus.
> + }
> + }
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(asus_hid_register_listener);
> +
> +void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + list_del(&bdev->list);
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
> +
> /*
> * These functions actually update the LED's, and are called from a
> * workqueue. By doing this as separate work rather than when the LED
> @@ -1609,6 +1658,7 @@ static int kbd_led_read(struct asus_wmi *asus, int *level, int *env)
>
> static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
> {
> + struct asus_hid_listener *listener;
> struct asus_wmi *asus;
> int max_level;
>
> @@ -1616,25 +1666,39 @@ static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
> max_level = asus->kbd_led.max_brightness;
>
> asus->kbd_led_wk = clamp_val(value, 0, max_level);
> - kbd_led_update(asus);
> +
> + if (asus->kbd_led_avail)
> + kbd_led_update(asus);
> +
> + list_for_each_entry(listener, &asus_ref.listeners, list)
> + listener->brightness_set(listener, asus->kbd_led_wk);
> }
>
> static void kbd_led_set(struct led_classdev *led_cdev,
> enum led_brightness value)
> {
> + unsigned long flags;
> +
> /* Prevent disabling keyboard backlight on module unregister */
> if (led_cdev->flags & LED_UNREGISTERING)
> return;
>
> + spin_lock_irqsave(&asus_ref.lock, flags);
> do_kbd_led_set(led_cdev, value);
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> }
>
> static void kbd_led_set_by_kbd(struct asus_wmi *asus, enum led_brightness value)
> {
> - struct led_classdev *led_cdev = &asus->kbd_led;
> + struct led_classdev *led_cdev;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + led_cdev = &asus->kbd_led;
>
I'd remove the empty line from the critical section.
I think you should mention the locking in the changelog too as it clearly
impacts not only the new code.
> do_kbd_led_set(led_cdev, value);
> led_classdev_notify_brightness_hw_changed(led_cdev, asus->kbd_led_wk);
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> }
>
> static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
> @@ -1644,6 +1708,9 @@ static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
>
> asus = container_of(led_cdev, struct asus_wmi, kbd_led);
>
> + if (!asus->kbd_led_avail)
> + return asus->kbd_led_wk;
> +
> retval = kbd_led_read(asus, &value, NULL);
> if (retval < 0)
> return retval;
> @@ -1759,7 +1826,15 @@ static int camera_led_set(struct led_classdev *led_cdev,
>
> static void asus_wmi_led_exit(struct asus_wmi *asus)
> {
> - led_classdev_unregister(&asus->kbd_led);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + asus_ref.asus = NULL;
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> +
> + if (asus->kbd_led_registered)
> + led_classdev_unregister(&asus->kbd_led);
> +
> led_classdev_unregister(&asus->tpd_led);
> led_classdev_unregister(&asus->wlan_led);
> led_classdev_unregister(&asus->lightbar_led);
> @@ -1773,6 +1848,8 @@ static void asus_wmi_led_exit(struct asus_wmi *asus)
> static int asus_wmi_led_init(struct asus_wmi *asus)
> {
> int rv = 0, num_rgb_groups = 0, led_val;
> + struct asus_hid_listener *listener;
> + unsigned long flags;
>
> if (asus->kbd_rgb_dev)
> kbd_rgb_mode_groups[num_rgb_groups++] = &kbd_rgb_mode_group;
> @@ -1797,23 +1874,38 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
> goto error;
> }
>
> - if (!kbd_led_read(asus, &led_val, NULL) && !dmi_check_system(asus_use_hid_led_dmi_ids)) {
> - pr_info("using asus-wmi for asus::kbd_backlight\n");
> + asus->kbd_led.name = "asus::kbd_backlight";
> + asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> + asus->kbd_led.brightness_set = kbd_led_set;
> + asus->kbd_led.brightness_get = kbd_led_get;
> + asus->kbd_led.max_brightness = 3;
> + asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
> +
> + if (asus->kbd_led_avail)
> asus->kbd_led_wk = led_val;
> - asus->kbd_led.name = "asus::kbd_backlight";
> - asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> - asus->kbd_led.brightness_set = kbd_led_set;
> - asus->kbd_led.brightness_get = kbd_led_get;
> - asus->kbd_led.max_brightness = 3;
> + else
> + asus->kbd_led_wk = -1;
>
> - if (num_rgb_groups != 0)
> - asus->kbd_led.groups = kbd_rgb_mode_groups;
> + if (asus->kbd_led_avail && num_rgb_groups != 0)
> + asus->kbd_led.groups = kbd_rgb_mode_groups;
Can't this be placed into the block above?
>
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + if (asus->kbd_led_avail || !list_empty(&asus_ref.listeners)) {
> rv = led_classdev_register(&asus->platform_device->dev,
> &asus->kbd_led);
> - if (rv)
> + if (rv) {
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
Please use scoped_guard() so you don't need to call unlock yourself.
Unrelated to this patch, I'd also simplify error label by adding return 0
before it so the code after the label doesn't need if (rv) check.
> goto error;
> + }
> + asus->kbd_led_registered = true;
> +
> + if (asus->kbd_led_wk >= 0) {
> + list_for_each_entry(listener, &asus_ref.listeners, list)
> + listener->brightness_set(listener, asus->kbd_led_wk);
> + }
> }
> + asus_ref.asus = asus;
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
>
> if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_WIRELESS_LED)
> && (asus->driver->quirks->wapf > 0)) {
> diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> index 8a515179113d..f13a701f47a8 100644
> --- a/include/linux/platform_data/x86/asus-wmi.h
> +++ b/include/linux/platform_data/x86/asus-wmi.h
> @@ -163,11 +163,19 @@ enum asus_ally_mcu_hack {
> ASUS_WMI_ALLY_MCU_HACK_DISABLED,
> };
>
> +struct asus_hid_listener {
> + struct list_head list;
> + void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
> +};
Please add kerneldoc to this struct and the exported functions.
> +
> #if IS_REACHABLE(CONFIG_ASUS_WMI)
> void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
> void set_ally_mcu_powersave(bool enabled);
> int asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param, u32 *retval);
> int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
> +
> +int asus_hid_register_listener(struct asus_hid_listener *cdev);
> +void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
> #else
> static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
> {
> @@ -184,6 +192,14 @@ static inline int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
> {
> return -ENODEV;
> }
> +
> +static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
> +{
> + return -ENODEV;
> +}
> +static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> +{
> +}
> #endif
>
> /* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
>
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-15 11:59 ` Ilpo Järvinen
@ 2025-10-15 15:45 ` Antheas Kapenekakis
2025-10-16 10:18 ` Ilpo Järvinen
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-15 15:45 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Wed, 15 Oct 2025 at 13:59, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
>
> > Some devices, such as the Z13 have multiple AURA devices connected
> > to them by USB. In addition, they might have a WMI interface for
> > RGB. In Windows, Armoury Crate exposes a unified brightness slider
> > for all of them, with 3 brightness levels.
> >
> > Therefore, to be synergistic in Linux, and support existing tooling
> > such as UPower, allow adding listeners to the RGB device of the WMI
> > interface. If WMI does not exist, lazy initialize the interface.
> >
> > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > Tested-by: Luke D. Jones <luke@ljones.dev>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
> > include/linux/platform_data/x86/asus-wmi.h | 16 +++
> > 2 files changed, 121 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> > index e72a2b5d158e..a2a7cd61fd59 100644
> > --- a/drivers/platform/x86/asus-wmi.c
> > +++ b/drivers/platform/x86/asus-wmi.c
> > @@ -258,6 +258,8 @@ struct asus_wmi {
> > int tpd_led_wk;
> > struct led_classdev kbd_led;
> > int kbd_led_wk;
> > + bool kbd_led_avail;
> > + bool kbd_led_registered;
> > struct led_classdev lightbar_led;
> > int lightbar_led_wk;
> > struct led_classdev micmute_led;
> > @@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
> >
> > /* LEDs ***********************************************************************/
> >
> > +struct asus_hid_ref {
> > + struct list_head listeners;
> > + struct asus_wmi *asus;
> > + spinlock_t lock;
>
> Please always document what a lock protects.
>
> I started wonder why it needs to be spinlock?
>
> It would seem rwsem is more natural for it as write is only needed at
> probe/remove time (if there's no good reason for using a spinlock).
>
> You're also missing include.
I went through the comments. Thanks. The reason that it is a spinlock
is that both hid-asus and asus-wmi interact with the primitives to
register and unregister listeners, either of which can prompt the
creation of the led device which has to be atomic. And they do so from
IRQs too.
Perhaps the driver could be refactored to use rwsem, I am not sure.
The fixed version can be found here[1]. I will give it 1-2 more days
in case someone else wants to chime in and resend.
Antheas
[1] https://github.com/bazzite-org/patchwork/commits/asusrgb/
> > +};
> > +
> > +struct asus_hid_ref asus_ref = {
>
> Should be static ?
>
> > + .listeners = LIST_HEAD_INIT(asus_ref.listeners),
> > + .asus = NULL,
> > + .lock = __SPIN_LOCK_UNLOCKED(asus_ref.lock),
> > +};
> > +
> > +int asus_hid_register_listener(struct asus_hid_listener *bdev)
> > +{
> > + unsigned long flags;
> > + int ret = 0;
> > +
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + list_add_tail(&bdev->list, &asus_ref.listeners);
> > + if (asus_ref.asus) {
> > + if (asus_ref.asus->kbd_led_registered && asus_ref.asus->kbd_led_wk >= 0)
> > + bdev->brightness_set(bdev, asus_ref.asus->kbd_led_wk);
> > +
> > + if (!asus_ref.asus->kbd_led_registered) {
> > + ret = led_classdev_register(
> > + &asus_ref.asus->platform_device->dev,
> > + &asus_ref.asus->kbd_led);
> > + if (!ret)
> > + asus_ref.asus->kbd_led_registered = true;
>
> I suggest you use guard() for the spinlock and return early where possible.
>
> With guard() in use, you can do normal error handling here with return ret
> immediately.
>
> Please also add a local var for asus_ref.asus.
>
> > + }
> > + }
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(asus_hid_register_listener);
> > +
> > +void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + list_del(&bdev->list);
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > +}
> > +EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
> > +
> > /*
> > * These functions actually update the LED's, and are called from a
> > * workqueue. By doing this as separate work rather than when the LED
> > @@ -1609,6 +1658,7 @@ static int kbd_led_read(struct asus_wmi *asus, int *level, int *env)
> >
> > static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
> > {
> > + struct asus_hid_listener *listener;
> > struct asus_wmi *asus;
> > int max_level;
> >
> > @@ -1616,25 +1666,39 @@ static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
> > max_level = asus->kbd_led.max_brightness;
> >
> > asus->kbd_led_wk = clamp_val(value, 0, max_level);
> > - kbd_led_update(asus);
> > +
> > + if (asus->kbd_led_avail)
> > + kbd_led_update(asus);
> > +
> > + list_for_each_entry(listener, &asus_ref.listeners, list)
> > + listener->brightness_set(listener, asus->kbd_led_wk);
> > }
> >
> > static void kbd_led_set(struct led_classdev *led_cdev,
> > enum led_brightness value)
> > {
> > + unsigned long flags;
> > +
> > /* Prevent disabling keyboard backlight on module unregister */
> > if (led_cdev->flags & LED_UNREGISTERING)
> > return;
> >
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > do_kbd_led_set(led_cdev, value);
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > }
> >
> > static void kbd_led_set_by_kbd(struct asus_wmi *asus, enum led_brightness value)
> > {
> > - struct led_classdev *led_cdev = &asus->kbd_led;
> > + struct led_classdev *led_cdev;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + led_cdev = &asus->kbd_led;
> >
>
> I'd remove the empty line from the critical section.
>
> I think you should mention the locking in the changelog too as it clearly
> impacts not only the new code.
>
> > do_kbd_led_set(led_cdev, value);
> > led_classdev_notify_brightness_hw_changed(led_cdev, asus->kbd_led_wk);
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > }
> >
> > static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
> > @@ -1644,6 +1708,9 @@ static enum led_brightness kbd_led_get(struct led_classdev *led_cdev)
> >
> > asus = container_of(led_cdev, struct asus_wmi, kbd_led);
> >
> > + if (!asus->kbd_led_avail)
> > + return asus->kbd_led_wk;
> > +
> > retval = kbd_led_read(asus, &value, NULL);
> > if (retval < 0)
> > return retval;
> > @@ -1759,7 +1826,15 @@ static int camera_led_set(struct led_classdev *led_cdev,
> >
> > static void asus_wmi_led_exit(struct asus_wmi *asus)
> > {
> > - led_classdev_unregister(&asus->kbd_led);
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + asus_ref.asus = NULL;
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > +
> > + if (asus->kbd_led_registered)
> > + led_classdev_unregister(&asus->kbd_led);
> > +
> > led_classdev_unregister(&asus->tpd_led);
> > led_classdev_unregister(&asus->wlan_led);
> > led_classdev_unregister(&asus->lightbar_led);
> > @@ -1773,6 +1848,8 @@ static void asus_wmi_led_exit(struct asus_wmi *asus)
> > static int asus_wmi_led_init(struct asus_wmi *asus)
> > {
> > int rv = 0, num_rgb_groups = 0, led_val;
> > + struct asus_hid_listener *listener;
> > + unsigned long flags;
> >
> > if (asus->kbd_rgb_dev)
> > kbd_rgb_mode_groups[num_rgb_groups++] = &kbd_rgb_mode_group;
> > @@ -1797,23 +1874,38 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
> > goto error;
> > }
> >
> > - if (!kbd_led_read(asus, &led_val, NULL) && !dmi_check_system(asus_use_hid_led_dmi_ids)) {
> > - pr_info("using asus-wmi for asus::kbd_backlight\n");
> > + asus->kbd_led.name = "asus::kbd_backlight";
> > + asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> > + asus->kbd_led.brightness_set = kbd_led_set;
> > + asus->kbd_led.brightness_get = kbd_led_get;
> > + asus->kbd_led.max_brightness = 3;
> > + asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
> > +
> > + if (asus->kbd_led_avail)
> > asus->kbd_led_wk = led_val;
> > - asus->kbd_led.name = "asus::kbd_backlight";
> > - asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> > - asus->kbd_led.brightness_set = kbd_led_set;
> > - asus->kbd_led.brightness_get = kbd_led_get;
> > - asus->kbd_led.max_brightness = 3;
> > + else
> > + asus->kbd_led_wk = -1;
> >
> > - if (num_rgb_groups != 0)
> > - asus->kbd_led.groups = kbd_rgb_mode_groups;
> > + if (asus->kbd_led_avail && num_rgb_groups != 0)
> > + asus->kbd_led.groups = kbd_rgb_mode_groups;
>
> Can't this be placed into the block above?
>
> >
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + if (asus->kbd_led_avail || !list_empty(&asus_ref.listeners)) {
> > rv = led_classdev_register(&asus->platform_device->dev,
> > &asus->kbd_led);
> > - if (rv)
> > + if (rv) {
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
>
> Please use scoped_guard() so you don't need to call unlock yourself.
>
> Unrelated to this patch, I'd also simplify error label by adding return 0
> before it so the code after the label doesn't need if (rv) check.
>
> > goto error;
> > + }
> > + asus->kbd_led_registered = true;
> > +
> > + if (asus->kbd_led_wk >= 0) {
> > + list_for_each_entry(listener, &asus_ref.listeners, list)
> > + listener->brightness_set(listener, asus->kbd_led_wk);
> > + }
> > }
> > + asus_ref.asus = asus;
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> >
> > if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_WIRELESS_LED)
> > && (asus->driver->quirks->wapf > 0)) {
> > diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> > index 8a515179113d..f13a701f47a8 100644
> > --- a/include/linux/platform_data/x86/asus-wmi.h
> > +++ b/include/linux/platform_data/x86/asus-wmi.h
> > @@ -163,11 +163,19 @@ enum asus_ally_mcu_hack {
> > ASUS_WMI_ALLY_MCU_HACK_DISABLED,
> > };
> >
> > +struct asus_hid_listener {
> > + struct list_head list;
> > + void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
> > +};
>
> Please add kerneldoc to this struct and the exported functions.
>
> > +
> > #if IS_REACHABLE(CONFIG_ASUS_WMI)
> > void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
> > void set_ally_mcu_powersave(bool enabled);
> > int asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param, u32 *retval);
> > int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
> > +
> > +int asus_hid_register_listener(struct asus_hid_listener *cdev);
> > +void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
> > #else
> > static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
> > {
> > @@ -184,6 +192,14 @@ static inline int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
> > {
> > return -ENODEV;
> > }
> > +
> > +static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
> > +{
> > + return -ENODEV;
> > +}
> > +static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> > +{
> > +}
> > #endif
> >
> > /* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
> >
>
> --
> i.
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-15 15:45 ` Antheas Kapenekakis
@ 2025-10-16 10:18 ` Ilpo Järvinen
2025-10-16 10:23 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-16 10:18 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]
On Wed, 15 Oct 2025, Antheas Kapenekakis wrote:
> On Wed, 15 Oct 2025 at 13:59, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> >
> > > Some devices, such as the Z13 have multiple AURA devices connected
> > > to them by USB. In addition, they might have a WMI interface for
> > > RGB. In Windows, Armoury Crate exposes a unified brightness slider
> > > for all of them, with 3 brightness levels.
> > >
> > > Therefore, to be synergistic in Linux, and support existing tooling
> > > such as UPower, allow adding listeners to the RGB device of the WMI
> > > interface. If WMI does not exist, lazy initialize the interface.
> > >
> > > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > > Tested-by: Luke D. Jones <luke@ljones.dev>
> > > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > > ---
> > > drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
> > > include/linux/platform_data/x86/asus-wmi.h | 16 +++
> > > 2 files changed, 121 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> > > index e72a2b5d158e..a2a7cd61fd59 100644
> > > --- a/drivers/platform/x86/asus-wmi.c
> > > +++ b/drivers/platform/x86/asus-wmi.c
> > > @@ -258,6 +258,8 @@ struct asus_wmi {
> > > int tpd_led_wk;
> > > struct led_classdev kbd_led;
> > > int kbd_led_wk;
> > > + bool kbd_led_avail;
> > > + bool kbd_led_registered;
> > > struct led_classdev lightbar_led;
> > > int lightbar_led_wk;
> > > struct led_classdev micmute_led;
> > > @@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
> > >
> > > /* LEDs ***********************************************************************/
> > >
> > > +struct asus_hid_ref {
> > > + struct list_head listeners;
> > > + struct asus_wmi *asus;
> > > + spinlock_t lock;
> >
> > Please always document what a lock protects.
> >
> > I started wonder why it needs to be spinlock?
> >
> > It would seem rwsem is more natural for it as write is only needed at
> > probe/remove time (if there's no good reason for using a spinlock).
> >
> > You're also missing include.
>
> I went through the comments. Thanks. The reason that it is a spinlock
> is that both hid-asus and asus-wmi interact with the primitives to
> register and unregister listeners, either of which can prompt the
> creation of the led device which has to be atomic. And they do so from
> IRQs too.
Please note in the changelog how it can happen from IRQs as I tried but
couldn't find anything. Admittedly, I didn't try to follow the callchains
that deeply. The justification should be clear enough to anyone who
looks this commit later so better have it in the changelog.
> Perhaps the driver could be refactored to use rwsem, I am not sure.
Just leave it spinlock.
> The fixed version can be found here[1]. I will give it 1-2 more days
> in case someone else wants to chime in and resend.
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-16 10:18 ` Ilpo Järvinen
@ 2025-10-16 10:23 ` Antheas Kapenekakis
2025-10-16 10:38 ` Ilpo Järvinen
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 10:23 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Thu, 16 Oct 2025 at 12:19, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Wed, 15 Oct 2025, Antheas Kapenekakis wrote:
>
> > On Wed, 15 Oct 2025 at 13:59, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > >
> > > On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> > >
> > > > Some devices, such as the Z13 have multiple AURA devices connected
> > > > to them by USB. In addition, they might have a WMI interface for
> > > > RGB. In Windows, Armoury Crate exposes a unified brightness slider
> > > > for all of them, with 3 brightness levels.
> > > >
> > > > Therefore, to be synergistic in Linux, and support existing tooling
> > > > such as UPower, allow adding listeners to the RGB device of the WMI
> > > > interface. If WMI does not exist, lazy initialize the interface.
> > > >
> > > > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > > > Tested-by: Luke D. Jones <luke@ljones.dev>
> > > > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > > > ---
> > > > drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
> > > > include/linux/platform_data/x86/asus-wmi.h | 16 +++
> > > > 2 files changed, 121 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> > > > index e72a2b5d158e..a2a7cd61fd59 100644
> > > > --- a/drivers/platform/x86/asus-wmi.c
> > > > +++ b/drivers/platform/x86/asus-wmi.c
> > > > @@ -258,6 +258,8 @@ struct asus_wmi {
> > > > int tpd_led_wk;
> > > > struct led_classdev kbd_led;
> > > > int kbd_led_wk;
> > > > + bool kbd_led_avail;
> > > > + bool kbd_led_registered;
> > > > struct led_classdev lightbar_led;
> > > > int lightbar_led_wk;
> > > > struct led_classdev micmute_led;
> > > > @@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
> > > >
> > > > /* LEDs ***********************************************************************/
> > > >
> > > > +struct asus_hid_ref {
> > > > + struct list_head listeners;
> > > > + struct asus_wmi *asus;
> > > > + spinlock_t lock;
> > >
> > > Please always document what a lock protects.
> > >
> > > I started wonder why it needs to be spinlock?
> > >
> > > It would seem rwsem is more natural for it as write is only needed at
> > > probe/remove time (if there's no good reason for using a spinlock).
> > >
> > > You're also missing include.
> >
> > I went through the comments. Thanks. The reason that it is a spinlock
> > is that both hid-asus and asus-wmi interact with the primitives to
> > register and unregister listeners, either of which can prompt the
> > creation of the led device which has to be atomic. And they do so from
> > IRQs too.
>
> Please note in the changelog how it can happen from IRQs as I tried but
> couldn't find anything. Admittedly, I didn't try to follow the callchains
> that deeply. The justification should be clear enough to anyone who
> looks this commit later so better have it in the changelog.
The initial versions used a mutex, and we found kernel hangs under
IRQs, so it was converted to a spinlock. I will try to reword.
Specifically, I think the errors came when holding the lock when
changing brightness.
I recall one of them was brightness hotkey (second to last patch)
triggers an IRQ -> event goes to asus-wmi -> calls brightness handler
-> tries to hold lock -> crashes. Lock needs to be held because
hid-asus can choose to unregister a listener.
> > Perhaps the driver could be refactored to use rwsem, I am not sure.
>
> Just leave it spinlock.
>
> > The fixed version can be found here[1]. I will give it 1-2 more days
> > in case someone else wants to chime in and resend.
>
>
>
> --
> i.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
2025-10-16 10:23 ` Antheas Kapenekakis
@ 2025-10-16 10:38 ` Ilpo Järvinen
0 siblings, 0 replies; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-16 10:38 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]
On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 12:19, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Wed, 15 Oct 2025, Antheas Kapenekakis wrote:
> >
> > > On Wed, 15 Oct 2025 at 13:59, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > >
> > > > On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> > > >
> > > > > Some devices, such as the Z13 have multiple AURA devices connected
> > > > > to them by USB. In addition, they might have a WMI interface for
> > > > > RGB. In Windows, Armoury Crate exposes a unified brightness slider
> > > > > for all of them, with 3 brightness levels.
> > > > >
> > > > > Therefore, to be synergistic in Linux, and support existing tooling
> > > > > such as UPower, allow adding listeners to the RGB device of the WMI
> > > > > interface. If WMI does not exist, lazy initialize the interface.
> > > > >
> > > > > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > > > > Tested-by: Luke D. Jones <luke@ljones.dev>
> > > > > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > > > > ---
> > > > > drivers/platform/x86/asus-wmi.c | 118 ++++++++++++++++++---
> > > > > include/linux/platform_data/x86/asus-wmi.h | 16 +++
> > > > > 2 files changed, 121 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> > > > > index e72a2b5d158e..a2a7cd61fd59 100644
> > > > > --- a/drivers/platform/x86/asus-wmi.c
> > > > > +++ b/drivers/platform/x86/asus-wmi.c
> > > > > @@ -258,6 +258,8 @@ struct asus_wmi {
> > > > > int tpd_led_wk;
> > > > > struct led_classdev kbd_led;
> > > > > int kbd_led_wk;
> > > > > + bool kbd_led_avail;
> > > > > + bool kbd_led_registered;
> > > > > struct led_classdev lightbar_led;
> > > > > int lightbar_led_wk;
> > > > > struct led_classdev micmute_led;
> > > > > @@ -1530,6 +1532,53 @@ static void asus_wmi_battery_exit(struct asus_wmi *asus)
> > > > >
> > > > > /* LEDs ***********************************************************************/
> > > > >
> > > > > +struct asus_hid_ref {
> > > > > + struct list_head listeners;
> > > > > + struct asus_wmi *asus;
> > > > > + spinlock_t lock;
> > > >
> > > > Please always document what a lock protects.
> > > >
> > > > I started wonder why it needs to be spinlock?
> > > >
> > > > It would seem rwsem is more natural for it as write is only needed at
> > > > probe/remove time (if there's no good reason for using a spinlock).
> > > >
> > > > You're also missing include.
> > >
> > > I went through the comments. Thanks. The reason that it is a spinlock
> > > is that both hid-asus and asus-wmi interact with the primitives to
> > > register and unregister listeners, either of which can prompt the
> > > creation of the led device which has to be atomic. And they do so from
> > > IRQs too.
> >
> > Please note in the changelog how it can happen from IRQs as I tried but
> > couldn't find anything. Admittedly, I didn't try to follow the callchains
> > that deeply. The justification should be clear enough to anyone who
> > looks this commit later so better have it in the changelog.
>
> The initial versions used a mutex, and we found kernel hangs under
> IRQs, so it was converted to a spinlock. I will try to reword.
> Specifically, I think the errors came when holding the lock when
> changing brightness.
>
> I recall one of them was brightness hotkey (second to last patch)
> triggers an IRQ -> event goes to asus-wmi -> calls brightness handler
> -> tries to hold lock -> crashes. Lock needs to be held because
> hid-asus can choose to unregister a listener.
If you're not certain and want an easy way to obtain a stacktrace to
confirm, you can likely do something like:
WARN_ON_ONCE(in_atomic());
...at where you are taking the lock.
--
i.
> > > Perhaps the driver could be refactored to use rwsem, I am not sure.
> >
> > Just leave it spinlock.
> >
> > > The fixed version can be found here[1]. I will give it 1-2 more days
> > > in case someone else wants to chime in and resend.
> >
> >
> >
> > --
> > i.
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (2 preceding siblings ...)
2025-10-13 20:15 ` [PATCH v6 3/7] platform/x86: asus-wmi: Add support for multiple kbd RGB handlers Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-13 21:44 ` Denis Benato
2025-10-13 20:15 ` [PATCH v6 5/7] platform/x86: asus-wmi: remove unused keyboard backlight quirk Antheas Kapenekakis
` (4 subsequent siblings)
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
Some ROG laptops expose multiple interfaces for controlling the
keyboard/RGB brightness. This creates a name conflict under
asus::kbd_brightness, where the second device ends up being
named asus::kbd_brightness_1 and they are both broken.
Therefore, register a listener to the asus-wmi brightness device
instead of creating a new one.
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
1 file changed, 10 insertions(+), 54 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index a62559e3e064..0af19c8ef035 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define TRKID_SGN ((TRKID_MAX + 1) >> 1)
struct asus_kbd_leds {
- struct led_classdev cdev;
+ struct asus_hid_listener listener;
struct hid_device *hdev;
struct work_struct work;
unsigned int brightness;
@@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
spin_unlock_irqrestore(&led->lock, flags);
}
-static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
+static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
+ int brightness)
{
- struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
- cdev);
+ struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
+ listener);
unsigned long flags;
spin_lock_irqsave(&led->lock, flags);
@@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
asus_schedule_work(led);
}
-static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
-{
- struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
- cdev);
- enum led_brightness brightness;
- unsigned long flags;
-
- spin_lock_irqsave(&led->lock, flags);
- brightness = led->brightness;
- spin_unlock_irqrestore(&led->lock, flags);
-
- return brightness;
-}
-
static void asus_kbd_backlight_work(struct work_struct *work)
{
struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
@@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
}
-/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
- * precedence. We only activate HID-based backlight control when the
- * WMI control is not available.
- */
-static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
-{
- struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
- u32 value;
- int ret;
-
- if (!IS_ENABLED(CONFIG_ASUS_WMI))
- return false;
-
- if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
- dmi_check_system(asus_use_hid_led_dmi_ids)) {
- hid_info(hdev, "using HID for asus::kbd_backlight\n");
- return false;
- }
-
- ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
- ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
- hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
- if (ret)
- return false;
-
- return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
-}
-
/*
* We don't care about any other part of the string except the version section.
* Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
@@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
drvdata->kbd_backlight->removed = false;
drvdata->kbd_backlight->brightness = 0;
drvdata->kbd_backlight->hdev = hdev;
- drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
- drvdata->kbd_backlight->cdev.max_brightness = 3;
- drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
- drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
+ drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
spin_lock_init(&drvdata->kbd_backlight->lock);
- ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
+ ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
@@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
if (drvdata->kbd_backlight) {
const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
- drvdata->kbd_backlight->cdev.brightness };
+ drvdata->kbd_backlight->brightness };
ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
if (ret < 0) {
hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
@@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
}
if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
- !asus_kbd_wmi_led_control_present(hdev) &&
asus_kbd_register_leds(hdev))
hid_warn(hdev, "Failed to initialize backlight.\n");
@@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
unsigned long flags;
if (drvdata->kbd_backlight) {
+ asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
+
spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
drvdata->kbd_backlight->removed = true;
spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 20:15 ` [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
@ 2025-10-13 21:44 ` Denis Benato
2025-10-13 21:57 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-13 21:44 UTC (permalink / raw)
To: Antheas Kapenekakis, platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen
On 10/13/25 22:15, Antheas Kapenekakis wrote:
> Some ROG laptops expose multiple interfaces for controlling the
> keyboard/RGB brightness. This creates a name conflict under
> asus::kbd_brightness, where the second device ends up being
> named asus::kbd_brightness_1 and they are both broken.
Can you please reference a bug report and/or an analysis of why they ends
up being broken?
>
> Therefore, register a listener to the asus-wmi brightness device
> instead of creating a new one.
>
> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
> 1 file changed, 10 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index a62559e3e064..0af19c8ef035 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
>
> struct asus_kbd_leds {
> - struct led_classdev cdev;
> + struct asus_hid_listener listener;
It is my understanding from "register a listener .... instead of creating a new one"
that you are attempting to use the same listener among many devices... so why isn't
this a pointer? And more importantly: why do we have bool available, bool registered
instead of either one or the other being replaced by this field being possibly NULL?
> struct hid_device *hdev;
> struct work_struct work;
> unsigned int brightness;
> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
> spin_unlock_irqrestore(&led->lock, flags);
> }
>
> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> - enum led_brightness brightness)
> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
> + int brightness)
> {
> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> - cdev);
> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
> + listener);
> unsigned long flags;
>
> spin_lock_irqsave(&led->lock, flags);
> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> asus_schedule_work(led);
> }
>
> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
> -{
> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> - cdev);
> - enum led_brightness brightness;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&led->lock, flags);
> - brightness = led->brightness;
> - spin_unlock_irqrestore(&led->lock, flags);
> -
> - return brightness;
> -}
> -
> static void asus_kbd_backlight_work(struct work_struct *work)
> {
> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> }
>
> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> - * precedence. We only activate HID-based backlight control when the
> - * WMI control is not available.
> - */
> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> -{
> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> - u32 value;
> - int ret;
> -
> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
> - return false;
> -
> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
> - return false;
> - }
> -
> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
> - if (ret)
> - return false;
> -
> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
> -}
> -
> /*
> * We don't care about any other part of the string except the version section.
> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> drvdata->kbd_backlight->removed = false;
> drvdata->kbd_backlight->brightness = 0;
> drvdata->kbd_backlight->hdev = hdev;
> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> - drvdata->kbd_backlight->cdev.max_brightness = 3;
> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
> spin_lock_init(&drvdata->kbd_backlight->lock);
>
> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
> if (ret < 0) {
> /* No need to have this still around */
> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
>
> if (drvdata->kbd_backlight) {
> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
> - drvdata->kbd_backlight->cdev.brightness };
> + drvdata->kbd_backlight->brightness };
> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> if (ret < 0) {
> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> }
>
> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> - !asus_kbd_wmi_led_control_present(hdev) &&
> asus_kbd_register_leds(hdev))
> hid_warn(hdev, "Failed to initialize backlight.\n");
>
> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
> unsigned long flags;
>
> if (drvdata->kbd_backlight) {
> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
> +
> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
> drvdata->kbd_backlight->removed = true;
> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 21:44 ` Denis Benato
@ 2025-10-13 21:57 ` Antheas Kapenekakis
2025-10-13 22:06 ` Denis Benato
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 21:57 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > Some ROG laptops expose multiple interfaces for controlling the
> > keyboard/RGB brightness. This creates a name conflict under
> > asus::kbd_brightness, where the second device ends up being
> > named asus::kbd_brightness_1 and they are both broken.
> Can you please reference a bug report and/or an analysis of why they ends
> up being broken?
You can reference the V1 description [1]
[1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >
> > Therefore, register a listener to the asus-wmi brightness device
> > instead of creating a new one.
> >
> > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
> > 1 file changed, 10 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > index a62559e3e064..0af19c8ef035 100644
> > --- a/drivers/hid/hid-asus.c
> > +++ b/drivers/hid/hid-asus.c
> > @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
> >
> > struct asus_kbd_leds {
> > - struct led_classdev cdev;
> > + struct asus_hid_listener listener;
> It is my understanding from "register a listener .... instead of creating a new one"
> that you are attempting to use the same listener among many devices... so why isn't
> this a pointer? And more importantly: why do we have bool available, bool registered
> instead of either one or the other being replaced by this field being possibly NULL?
A listener is the handle that is passed to asus-wmi so that it can
communicate with hid-asus. Since the flow of communication flows from
asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
The boolean kbd_led_avail is used to signify whether the BIOS supports
RGB commands. If not, we still want the common handler to be there to
link multiple hid-asus devices together. At the same time, we need to
skip calling the bios commands for brightness, and hold a value for
the previous brightness outside the bios.
The kbd_led_registered fixes the race condition that happens between
hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
is only setup once, either once asus-wmi loads (if it supports RGB) or
when the first hid device loads.
Best,
Antheas
> > struct hid_device *hdev;
> > struct work_struct work;
> > unsigned int brightness;
> > @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
> > spin_unlock_irqrestore(&led->lock, flags);
> > }
> >
> > -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> > - enum led_brightness brightness)
> > +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
> > + int brightness)
> > {
> > - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> > - cdev);
> > + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
> > + listener);
> > unsigned long flags;
> >
> > spin_lock_irqsave(&led->lock, flags);
> > @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> > asus_schedule_work(led);
> > }
> >
> > -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
> > -{
> > - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> > - cdev);
> > - enum led_brightness brightness;
> > - unsigned long flags;
> > -
> > - spin_lock_irqsave(&led->lock, flags);
> > - brightness = led->brightness;
> > - spin_unlock_irqrestore(&led->lock, flags);
> > -
> > - return brightness;
> > -}
> > -
> > static void asus_kbd_backlight_work(struct work_struct *work)
> > {
> > struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
> > @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
> > hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> > }
> >
> > -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> > - * precedence. We only activate HID-based backlight control when the
> > - * WMI control is not available.
> > - */
> > -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> > -{
> > - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> > - u32 value;
> > - int ret;
> > -
> > - if (!IS_ENABLED(CONFIG_ASUS_WMI))
> > - return false;
> > -
> > - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
> > - dmi_check_system(asus_use_hid_led_dmi_ids)) {
> > - hid_info(hdev, "using HID for asus::kbd_backlight\n");
> > - return false;
> > - }
> > -
> > - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
> > - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
> > - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
> > - if (ret)
> > - return false;
> > -
> > - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
> > -}
> > -
> > /*
> > * We don't care about any other part of the string except the version section.
> > * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
> > @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> > drvdata->kbd_backlight->removed = false;
> > drvdata->kbd_backlight->brightness = 0;
> > drvdata->kbd_backlight->hdev = hdev;
> > - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> > - drvdata->kbd_backlight->cdev.max_brightness = 3;
> > - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
> > - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
> > + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
> > INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
> > spin_lock_init(&drvdata->kbd_backlight->lock);
> >
> > - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
> > + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
> > if (ret < 0) {
> > /* No need to have this still around */
> > devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> > @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
> >
> > if (drvdata->kbd_backlight) {
> > const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
> > - drvdata->kbd_backlight->cdev.brightness };
> > + drvdata->kbd_backlight->brightness };
> > ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> > if (ret < 0) {
> > hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> > @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > }
> >
> > if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> > - !asus_kbd_wmi_led_control_present(hdev) &&
> > asus_kbd_register_leds(hdev))
> > hid_warn(hdev, "Failed to initialize backlight.\n");
> >
> > @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
> > unsigned long flags;
> >
> > if (drvdata->kbd_backlight) {
> > + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
> > +
> > spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
> > drvdata->kbd_backlight->removed = true;
> > spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 21:57 ` Antheas Kapenekakis
@ 2025-10-13 22:06 ` Denis Benato
2025-10-13 22:18 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-13 22:06 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On 10/13/25 23:57, Antheas Kapenekakis wrote:
> On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>> Some ROG laptops expose multiple interfaces for controlling the
>>> keyboard/RGB brightness. This creates a name conflict under
>>> asus::kbd_brightness, where the second device ends up being
>>> named asus::kbd_brightness_1 and they are both broken.
>> Can you please reference a bug report and/or an analysis of why they ends
>> up being broken?
> You can reference the V1 description [1]
>
> [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
oh okay thanks. I would suggest to keep relevant parts in successive revisions,
and most importantly repeat (a shorter description of) relevant parts on the proper
commit since commit messages will (hopefully) become part of the kernel,
because just reading messages of the current revision doesn't give the full picture
of the what and why,
Regards,
Denis
>>> Therefore, register a listener to the asus-wmi brightness device
>>> instead of creating a new one.
>>>
>>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>> ---
>>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
>>> 1 file changed, 10 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>> index a62559e3e064..0af19c8ef035 100644
>>> --- a/drivers/hid/hid-asus.c
>>> +++ b/drivers/hid/hid-asus.c
>>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
>>>
>>> struct asus_kbd_leds {
>>> - struct led_classdev cdev;
>>> + struct asus_hid_listener listener;
>> It is my understanding from "register a listener .... instead of creating a new one"
>> that you are attempting to use the same listener among many devices... so why isn't
>> this a pointer? And more importantly: why do we have bool available, bool registered
>> instead of either one or the other being replaced by this field being possibly NULL?
> A listener is the handle that is passed to asus-wmi so that it can
> communicate with hid-asus. Since the flow of communication flows from
> asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
>
> The boolean kbd_led_avail is used to signify whether the BIOS supports
> RGB commands. If not, we still want the common handler to be there to
> link multiple hid-asus devices together. At the same time, we need to
> skip calling the bios commands for brightness, and hold a value for
> the previous brightness outside the bios.
>
> The kbd_led_registered fixes the race condition that happens between
> hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
> is only setup once, either once asus-wmi loads (if it supports RGB) or
> when the first hid device loads.
>
> Best,
> Antheas
>
>>> struct hid_device *hdev;
>>> struct work_struct work;
>>> unsigned int brightness;
>>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
>>> spin_unlock_irqrestore(&led->lock, flags);
>>> }
>>>
>>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>> - enum led_brightness brightness)
>>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
>>> + int brightness)
>>> {
>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>> - cdev);
>>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
>>> + listener);
>>> unsigned long flags;
>>>
>>> spin_lock_irqsave(&led->lock, flags);
>>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>> asus_schedule_work(led);
>>> }
>>>
>>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
>>> -{
>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>> - cdev);
>>> - enum led_brightness brightness;
>>> - unsigned long flags;
>>> -
>>> - spin_lock_irqsave(&led->lock, flags);
>>> - brightness = led->brightness;
>>> - spin_unlock_irqrestore(&led->lock, flags);
>>> -
>>> - return brightness;
>>> -}
>>> -
>>> static void asus_kbd_backlight_work(struct work_struct *work)
>>> {
>>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
>>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
>>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>> }
>>>
>>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
>>> - * precedence. We only activate HID-based backlight control when the
>>> - * WMI control is not available.
>>> - */
>>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
>>> -{
>>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>>> - u32 value;
>>> - int ret;
>>> -
>>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
>>> - return false;
>>> -
>>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
>>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
>>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
>>> - return false;
>>> - }
>>> -
>>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
>>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
>>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
>>> - if (ret)
>>> - return false;
>>> -
>>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
>>> -}
>>> -
>>> /*
>>> * We don't care about any other part of the string except the version section.
>>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
>>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>>> drvdata->kbd_backlight->removed = false;
>>> drvdata->kbd_backlight->brightness = 0;
>>> drvdata->kbd_backlight->hdev = hdev;
>>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
>>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
>>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
>>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
>>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
>>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
>>> spin_lock_init(&drvdata->kbd_backlight->lock);
>>>
>>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
>>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
>>> if (ret < 0) {
>>> /* No need to have this still around */
>>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
>>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
>>>
>>> if (drvdata->kbd_backlight) {
>>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
>>> - drvdata->kbd_backlight->cdev.brightness };
>>> + drvdata->kbd_backlight->brightness };
>>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
>>> if (ret < 0) {
>>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>> }
>>>
>>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>>> - !asus_kbd_wmi_led_control_present(hdev) &&
>>> asus_kbd_register_leds(hdev))
>>> hid_warn(hdev, "Failed to initialize backlight.\n");
>>>
>>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
>>> unsigned long flags;
>>>
>>> if (drvdata->kbd_backlight) {
>>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
>>> +
>>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
>>> drvdata->kbd_backlight->removed = true;
>>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 22:06 ` Denis Benato
@ 2025-10-13 22:18 ` Antheas Kapenekakis
2025-10-13 22:50 ` Denis Benato
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 22:18 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Tue, 14 Oct 2025 at 00:06, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 23:57, Antheas Kapenekakis wrote:
> > On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
> >>
> >> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>> Some ROG laptops expose multiple interfaces for controlling the
> >>> keyboard/RGB brightness. This creates a name conflict under
> >>> asus::kbd_brightness, where the second device ends up being
> >>> named asus::kbd_brightness_1 and they are both broken.
> >> Can you please reference a bug report and/or an analysis of why they ends
> >> up being broken?
> > You can reference the V1 description [1]
> >
> > [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> oh okay thanks. I would suggest to keep relevant parts in successive revisions,
> and most importantly repeat (a shorter description of) relevant parts on the proper
> commit since commit messages will (hopefully) become part of the kernel,
> because just reading messages of the current revision doesn't give the full picture
> of the what and why,
It's true I cut out the introduction, perhaps I shouldn't have, but it
will get thrown away anyway. I think the commit body is detailed
enough though.
I am looping you in late, but since you are taking over
Luke's series and you ended up moving the quirks this series removes
and earlier series did not, you will have some merge conflicts.
By the way, remember to sign off that series yourself as well, since
you are changing the commits.
Antheas
> Regards,
> Denis
> >>> Therefore, register a listener to the asus-wmi brightness device
> >>> instead of creating a new one.
> >>>
> >>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> >>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> >>> ---
> >>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
> >>> 1 file changed, 10 insertions(+), 54 deletions(-)
> >>>
> >>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> >>> index a62559e3e064..0af19c8ef035 100644
> >>> --- a/drivers/hid/hid-asus.c
> >>> +++ b/drivers/hid/hid-asus.c
> >>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> >>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
> >>>
> >>> struct asus_kbd_leds {
> >>> - struct led_classdev cdev;
> >>> + struct asus_hid_listener listener;
> >> It is my understanding from "register a listener .... instead of creating a new one"
> >> that you are attempting to use the same listener among many devices... so why isn't
> >> this a pointer? And more importantly: why do we have bool available, bool registered
> >> instead of either one or the other being replaced by this field being possibly NULL?
> > A listener is the handle that is passed to asus-wmi so that it can
> > communicate with hid-asus. Since the flow of communication flows from
> > asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
> >
> > The boolean kbd_led_avail is used to signify whether the BIOS supports
> > RGB commands. If not, we still want the common handler to be there to
> > link multiple hid-asus devices together. At the same time, we need to
> > skip calling the bios commands for brightness, and hold a value for
> > the previous brightness outside the bios.
> >
> > The kbd_led_registered fixes the race condition that happens between
> > hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
> > is only setup once, either once asus-wmi loads (if it supports RGB) or
> > when the first hid device loads.
> >
> > Best,
> > Antheas
> >
> >>> struct hid_device *hdev;
> >>> struct work_struct work;
> >>> unsigned int brightness;
> >>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
> >>> spin_unlock_irqrestore(&led->lock, flags);
> >>> }
> >>>
> >>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> >>> - enum led_brightness brightness)
> >>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
> >>> + int brightness)
> >>> {
> >>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> >>> - cdev);
> >>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
> >>> + listener);
> >>> unsigned long flags;
> >>>
> >>> spin_lock_irqsave(&led->lock, flags);
> >>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
> >>> asus_schedule_work(led);
> >>> }
> >>>
> >>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
> >>> -{
> >>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
> >>> - cdev);
> >>> - enum led_brightness brightness;
> >>> - unsigned long flags;
> >>> -
> >>> - spin_lock_irqsave(&led->lock, flags);
> >>> - brightness = led->brightness;
> >>> - spin_unlock_irqrestore(&led->lock, flags);
> >>> -
> >>> - return brightness;
> >>> -}
> >>> -
> >>> static void asus_kbd_backlight_work(struct work_struct *work)
> >>> {
> >>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
> >>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
> >>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> >>> }
> >>>
> >>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> >>> - * precedence. We only activate HID-based backlight control when the
> >>> - * WMI control is not available.
> >>> - */
> >>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> >>> -{
> >>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
> >>> - u32 value;
> >>> - int ret;
> >>> -
> >>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
> >>> - return false;
> >>> -
> >>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
> >>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
> >>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
> >>> - return false;
> >>> - }
> >>> -
> >>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
> >>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
> >>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
> >>> - if (ret)
> >>> - return false;
> >>> -
> >>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
> >>> -}
> >>> -
> >>> /*
> >>> * We don't care about any other part of the string except the version section.
> >>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
> >>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> >>> drvdata->kbd_backlight->removed = false;
> >>> drvdata->kbd_backlight->brightness = 0;
> >>> drvdata->kbd_backlight->hdev = hdev;
> >>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> >>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
> >>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
> >>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
> >>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
> >>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
> >>> spin_lock_init(&drvdata->kbd_backlight->lock);
> >>>
> >>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
> >>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
> >>> if (ret < 0) {
> >>> /* No need to have this still around */
> >>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> >>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
> >>>
> >>> if (drvdata->kbd_backlight) {
> >>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
> >>> - drvdata->kbd_backlight->cdev.brightness };
> >>> + drvdata->kbd_backlight->brightness };
> >>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
> >>> if (ret < 0) {
> >>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
> >>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> >>> }
> >>>
> >>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> >>> - !asus_kbd_wmi_led_control_present(hdev) &&
> >>> asus_kbd_register_leds(hdev))
> >>> hid_warn(hdev, "Failed to initialize backlight.\n");
> >>>
> >>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
> >>> unsigned long flags;
> >>>
> >>> if (drvdata->kbd_backlight) {
> >>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
> >>> +
> >>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
> >>> drvdata->kbd_backlight->removed = true;
> >>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one
2025-10-13 22:18 ` Antheas Kapenekakis
@ 2025-10-13 22:50 ` Denis Benato
0 siblings, 0 replies; 45+ messages in thread
From: Denis Benato @ 2025-10-13 22:50 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On 10/14/25 00:18, Antheas Kapenekakis wrote:
> On Tue, 14 Oct 2025 at 00:06, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/13/25 23:57, Antheas Kapenekakis wrote:
>>> On Mon, 13 Oct 2025 at 23:44, Denis Benato <benato.denis96@gmail.com> wrote:
>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>> Some ROG laptops expose multiple interfaces for controlling the
>>>>> keyboard/RGB brightness. This creates a name conflict under
>>>>> asus::kbd_brightness, where the second device ends up being
>>>>> named asus::kbd_brightness_1 and they are both broken.
>>>> Can you please reference a bug report and/or an analysis of why they ends
>>>> up being broken?
>>> You can reference the V1 description [1]
>>>
>>> [1] https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>> oh okay thanks. I would suggest to keep relevant parts in successive revisions,
>> and most importantly repeat (a shorter description of) relevant parts on the proper
>> commit since commit messages will (hopefully) become part of the kernel,
>> because just reading messages of the current revision doesn't give the full picture
>> of the what and why,
> It's true I cut out the introduction, perhaps I shouldn't have, but it
> will get thrown away anyway. I think the commit body is detailed
> enough though.
I am aware the cover letter won't be part of the kernel, it's why I asked for the
relevant context to be repeated in the appropriate commit message.
I don't think commit messages are detailed enough: a few more explanation
lines would surely help a reader as messages are more centered on the "what" and
not the "why".
Note: this comment of mine is not limited to this particular commit:
look at how long the v1 cover letter is and how long commit messages are
once combined. A lot that has been left out should really be included
(personal opinion of mine, looking at this for the first time: it would have helped).
Thanks,
Denis
> I am looping you in late, but since you are taking over
> Luke's series and you ended up moving the quirks this series removes
> and earlier series did not, you will have some merge conflicts.
>
> By the way, remember to sign off that series yourself as well, since
> you are changing the commits.
>
> Antheas
>
>
>> Regards,
>> Denis
>>>>> Therefore, register a listener to the asus-wmi brightness device
>>>>> instead of creating a new one.
>>>>>
>>>>> Reviewed-by: Luke D. Jones <luke@ljones.dev>
>>>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>>>> ---
>>>>> drivers/hid/hid-asus.c | 64 +++++++-----------------------------------
>>>>> 1 file changed, 10 insertions(+), 54 deletions(-)
>>>>>
>>>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>>>> index a62559e3e064..0af19c8ef035 100644
>>>>> --- a/drivers/hid/hid-asus.c
>>>>> +++ b/drivers/hid/hid-asus.c
>>>>> @@ -102,7 +102,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>>>>> #define TRKID_SGN ((TRKID_MAX + 1) >> 1)
>>>>>
>>>>> struct asus_kbd_leds {
>>>>> - struct led_classdev cdev;
>>>>> + struct asus_hid_listener listener;
>>>> It is my understanding from "register a listener .... instead of creating a new one"
>>>> that you are attempting to use the same listener among many devices... so why isn't
>>>> this a pointer? And more importantly: why do we have bool available, bool registered
>>>> instead of either one or the other being replaced by this field being possibly NULL?
>>> A listener is the handle that is passed to asus-wmi so that it can
>>> communicate with hid-asus. Since the flow of communication flows from
>>> asus-wmi -> hid-asus, the pointer is placed on asus-wmi.
>>>
>>> The boolean kbd_led_avail is used to signify whether the BIOS supports
>>> RGB commands. If not, we still want the common handler to be there to
>>> link multiple hid-asus devices together. At the same time, we need to
>>> skip calling the bios commands for brightness, and hold a value for
>>> the previous brightness outside the bios.
>>>
>>> The kbd_led_registered fixes the race condition that happens between
>>> hid-asus and asus-wmi. Specifically, it ensures that the rgb listener
>>> is only setup once, either once asus-wmi loads (if it supports RGB) or
>>> when the first hid device loads.
>>>
>>> Best,
>>> Antheas
>>>
>>>>> struct hid_device *hdev;
>>>>> struct work_struct work;
>>>>> unsigned int brightness;
>>>>> @@ -495,11 +495,11 @@ static void asus_schedule_work(struct asus_kbd_leds *led)
>>>>> spin_unlock_irqrestore(&led->lock, flags);
>>>>> }
>>>>>
>>>>> -static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>>>> - enum led_brightness brightness)
>>>>> +static void asus_kbd_backlight_set(struct asus_hid_listener *listener,
>>>>> + int brightness)
>>>>> {
>>>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>>>> - cdev);
>>>>> + struct asus_kbd_leds *led = container_of(listener, struct asus_kbd_leds,
>>>>> + listener);
>>>>> unsigned long flags;
>>>>>
>>>>> spin_lock_irqsave(&led->lock, flags);
>>>>> @@ -509,20 +509,6 @@ static void asus_kbd_backlight_set(struct led_classdev *led_cdev,
>>>>> asus_schedule_work(led);
>>>>> }
>>>>>
>>>>> -static enum led_brightness asus_kbd_backlight_get(struct led_classdev *led_cdev)
>>>>> -{
>>>>> - struct asus_kbd_leds *led = container_of(led_cdev, struct asus_kbd_leds,
>>>>> - cdev);
>>>>> - enum led_brightness brightness;
>>>>> - unsigned long flags;
>>>>> -
>>>>> - spin_lock_irqsave(&led->lock, flags);
>>>>> - brightness = led->brightness;
>>>>> - spin_unlock_irqrestore(&led->lock, flags);
>>>>> -
>>>>> - return brightness;
>>>>> -}
>>>>> -
>>>>> static void asus_kbd_backlight_work(struct work_struct *work)
>>>>> {
>>>>> struct asus_kbd_leds *led = container_of(work, struct asus_kbd_leds, work);
>>>>> @@ -539,34 +525,6 @@ static void asus_kbd_backlight_work(struct work_struct *work)
>>>>> hid_err(led->hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>>>> }
>>>>>
>>>>> -/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
>>>>> - * precedence. We only activate HID-based backlight control when the
>>>>> - * WMI control is not available.
>>>>> - */
>>>>> -static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
>>>>> -{
>>>>> - struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
>>>>> - u32 value;
>>>>> - int ret;
>>>>> -
>>>>> - if (!IS_ENABLED(CONFIG_ASUS_WMI))
>>>>> - return false;
>>>>> -
>>>>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
>>>>> - dmi_check_system(asus_use_hid_led_dmi_ids)) {
>>>>> - hid_info(hdev, "using HID for asus::kbd_backlight\n");
>>>>> - return false;
>>>>> - }
>>>>> -
>>>>> - ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
>>>>> - ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
>>>>> - hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
>>>>> - if (ret)
>>>>> - return false;
>>>>> -
>>>>> - return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
>>>>> -}
>>>>> -
>>>>> /*
>>>>> * We don't care about any other part of the string except the version section.
>>>>> * Example strings: FGA80100.RC72LA.312_T01, FGA80100.RC71LS.318_T01
>>>>> @@ -701,14 +659,11 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>>>>> drvdata->kbd_backlight->removed = false;
>>>>> drvdata->kbd_backlight->brightness = 0;
>>>>> drvdata->kbd_backlight->hdev = hdev;
>>>>> - drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
>>>>> - drvdata->kbd_backlight->cdev.max_brightness = 3;
>>>>> - drvdata->kbd_backlight->cdev.brightness_set = asus_kbd_backlight_set;
>>>>> - drvdata->kbd_backlight->cdev.brightness_get = asus_kbd_backlight_get;
>>>>> + drvdata->kbd_backlight->listener.brightness_set = asus_kbd_backlight_set;
>>>>> INIT_WORK(&drvdata->kbd_backlight->work, asus_kbd_backlight_work);
>>>>> spin_lock_init(&drvdata->kbd_backlight->lock);
>>>>>
>>>>> - ret = devm_led_classdev_register(&hdev->dev, &drvdata->kbd_backlight->cdev);
>>>>> + ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
>>>>> if (ret < 0) {
>>>>> /* No need to have this still around */
>>>>> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
>>>>> @@ -1105,7 +1060,7 @@ static int __maybe_unused asus_resume(struct hid_device *hdev) {
>>>>>
>>>>> if (drvdata->kbd_backlight) {
>>>>> const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
>>>>> - drvdata->kbd_backlight->cdev.brightness };
>>>>> + drvdata->kbd_backlight->brightness };
>>>>> ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
>>>>> if (ret < 0) {
>>>>> hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
>>>>> @@ -1241,7 +1196,6 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>>>> }
>>>>>
>>>>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>>>>> - !asus_kbd_wmi_led_control_present(hdev) &&
>>>>> asus_kbd_register_leds(hdev))
>>>>> hid_warn(hdev, "Failed to initialize backlight.\n");
>>>>>
>>>>> @@ -1282,6 +1236,8 @@ static void asus_remove(struct hid_device *hdev)
>>>>> unsigned long flags;
>>>>>
>>>>> if (drvdata->kbd_backlight) {
>>>>> + asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
>>>>> +
>>>>> spin_lock_irqsave(&drvdata->kbd_backlight->lock, flags);
>>>>> drvdata->kbd_backlight->removed = true;
>>>>> spin_unlock_irqrestore(&drvdata->kbd_backlight->lock, flags);
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v6 5/7] platform/x86: asus-wmi: remove unused keyboard backlight quirk
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (3 preceding siblings ...)
2025-10-13 20:15 ` [PATCH v6 4/7] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-13 20:15 ` [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
` (3 subsequent siblings)
8 siblings, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
The quirk for selecting whether keyboard backlight should be controlled
by HID or WMI is not needed anymore, so remove it.
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
include/linux/platform_data/x86/asus-wmi.h | 40 ----------------------
1 file changed, 40 deletions(-)
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index f13a701f47a8..1f85d76387a8 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -202,44 +202,4 @@ static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
}
#endif
-/* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
-static const struct dmi_system_id asus_use_hid_led_dmi_ids[] = {
- {
- .matches = {
- DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Zephyrus"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Strix"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Flow"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_PRODUCT_FAMILY, "ProArt P16"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "GA403U"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "GU605M"),
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "RC71L"),
- },
- },
- { },
-};
-
#endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (4 preceding siblings ...)
2025-10-13 20:15 ` [PATCH v6 5/7] platform/x86: asus-wmi: remove unused keyboard backlight quirk Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-15 12:18 ` Ilpo Järvinen
2025-10-13 20:15 ` [PATCH v6 7/7] HID: asus: add support for the asus-wmi brightness handler Antheas Kapenekakis
` (2 subsequent siblings)
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
Currenlty, the keyboard brightness control of Asus WMI keyboards is
handled in the kernel, which leads to the shortcut going from
brightness 0, to 1, to 2, and 3.
However, for HID keyboards it is exposed as a key and handled by the
user's desktop environment. For the toggle button, this means that
brightness control becomes on/off. In addition, in the absence of a
DE, the keyboard brightness does not work.
Therefore, expose an event handler for the keyboard brightness control
which can then be used by hid-asus.
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Tested-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/platform/x86/asus-wmi.c | 41 +++++++++++++++++++++-
include/linux/platform_data/x86/asus-wmi.h | 13 +++++++
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index a2a7cd61fd59..58407a3b6d41 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1579,6 +1579,45 @@ void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
}
EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
+static void do_kbd_led_set(struct led_classdev *led_cdev, int value);
+
+int asus_hid_event(enum asus_hid_event event)
+{
+ unsigned long flags;
+ int brightness;
+
+ spin_lock_irqsave(&asus_ref.lock, flags);
+ if (!asus_ref.asus || !asus_ref.asus->kbd_led_registered) {
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
+ return -EBUSY;
+ }
+ brightness = asus_ref.asus->kbd_led_wk;
+
+ switch (event) {
+ case ASUS_EV_BRTUP:
+ brightness += 1;
+ break;
+ case ASUS_EV_BRTDOWN:
+ brightness -= 1;
+ break;
+ case ASUS_EV_BRTTOGGLE:
+ if (brightness >= ASUS_EV_MAX_BRIGHTNESS)
+ brightness = 0;
+ else
+ brightness += 1;
+ break;
+ }
+
+ do_kbd_led_set(&asus_ref.asus->kbd_led, brightness);
+ led_classdev_notify_brightness_hw_changed(&asus_ref.asus->kbd_led,
+ asus_ref.asus->kbd_led_wk);
+
+ spin_unlock_irqrestore(&asus_ref.lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(asus_hid_event);
+
/*
* These functions actually update the LED's, and are called from a
* workqueue. By doing this as separate work rather than when the LED
@@ -1878,7 +1917,7 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
asus->kbd_led.brightness_set = kbd_led_set;
asus->kbd_led.brightness_get = kbd_led_get;
- asus->kbd_led.max_brightness = 3;
+ asus->kbd_led.max_brightness = ASUS_EV_MAX_BRIGHTNESS;
asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
if (asus->kbd_led_avail)
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 1f85d76387a8..e78e0fbccede 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -168,6 +168,14 @@ struct asus_hid_listener {
void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
};
+enum asus_hid_event {
+ ASUS_EV_BRTUP,
+ ASUS_EV_BRTDOWN,
+ ASUS_EV_BRTTOGGLE,
+};
+
+#define ASUS_EV_MAX_BRIGHTNESS 3
+
#if IS_REACHABLE(CONFIG_ASUS_WMI)
void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
void set_ally_mcu_powersave(bool enabled);
@@ -176,6 +184,7 @@ int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
int asus_hid_register_listener(struct asus_hid_listener *cdev);
void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
+int asus_hid_event(enum asus_hid_event event);
#else
static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
{
@@ -200,6 +209,10 @@ static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
{
}
+static inline int asus_hid_event(enum asus_hid_event event)
+{
+ return -ENODEV;
+}
#endif
#endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler
2025-10-13 20:15 ` [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
@ 2025-10-15 12:18 ` Ilpo Järvinen
2025-10-15 15:38 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-15 12:18 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, Denis Benato
On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
> Currenlty, the keyboard brightness control of Asus WMI keyboards is
There's a typo here but preferrably avoid "currently" altogether where
possible.
> handled in the kernel, which leads to the shortcut going from
> brightness 0, to 1, to 2, and 3.
>
> However, for HID keyboards it is exposed as a key and handled by the
> user's desktop environment. For the toggle button, this means that
> brightness control becomes on/off. In addition, in the absence of a
> DE, the keyboard brightness does not work.
>
> Therefore, expose an event handler for the keyboard brightness control
> which can then be used by hid-asus.
>
> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> Tested-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/platform/x86/asus-wmi.c | 41 +++++++++++++++++++++-
> include/linux/platform_data/x86/asus-wmi.h | 13 +++++++
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index a2a7cd61fd59..58407a3b6d41 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -1579,6 +1579,45 @@ void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> }
> EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
>
> +static void do_kbd_led_set(struct led_classdev *led_cdev, int value);
> +
> +int asus_hid_event(enum asus_hid_event event)
> +{
> + unsigned long flags;
> + int brightness;
> +
> + spin_lock_irqsave(&asus_ref.lock, flags);
> + if (!asus_ref.asus || !asus_ref.asus->kbd_led_registered) {
Please add a local variable for asus_ref.asus. Check other
patches/functions too if its use is repeated in some function many times,
the local var seems to be in order.
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
Use guard() instead.
> + return -EBUSY;
> + }
> + brightness = asus_ref.asus->kbd_led_wk;
> +
> + switch (event) {
> + case ASUS_EV_BRTUP:
> + brightness += 1;
> + break;
> + case ASUS_EV_BRTDOWN:
> + brightness -= 1;
> + break;
> + case ASUS_EV_BRTTOGGLE:
> + if (brightness >= ASUS_EV_MAX_BRIGHTNESS)
> + brightness = 0;
> + else
> + brightness += 1;
> + break;
> + }
> +
> + do_kbd_led_set(&asus_ref.asus->kbd_led, brightness);
> + led_classdev_notify_brightness_hw_changed(&asus_ref.asus->kbd_led,
> + asus_ref.asus->kbd_led_wk);
> +
> + spin_unlock_irqrestore(&asus_ref.lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(asus_hid_event);
> +
> /*
> * These functions actually update the LED's, and are called from a
> * workqueue. By doing this as separate work rather than when the LED
> @@ -1878,7 +1917,7 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
> asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> asus->kbd_led.brightness_set = kbd_led_set;
> asus->kbd_led.brightness_get = kbd_led_get;
> - asus->kbd_led.max_brightness = 3;
> + asus->kbd_led.max_brightness = ASUS_EV_MAX_BRIGHTNESS;
> asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
>
> if (asus->kbd_led_avail)
> diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> index 1f85d76387a8..e78e0fbccede 100644
> --- a/include/linux/platform_data/x86/asus-wmi.h
> +++ b/include/linux/platform_data/x86/asus-wmi.h
> @@ -168,6 +168,14 @@ struct asus_hid_listener {
> void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
> };
>
> +enum asus_hid_event {
> + ASUS_EV_BRTUP,
> + ASUS_EV_BRTDOWN,
> + ASUS_EV_BRTTOGGLE,
Where does "BRT" come from. To me it doesn't associate with brightness
(might be due to me being non-native). If there's a good reason why it's
that way, fine but otherwise I suggest changing it so that it becomes
easier to understand.
It's not a big problem as is because the context in the code above allows
decrypting the meaning but without the other names, I'd have been totally
lost what it means.
> +};
> +
> +#define ASUS_EV_MAX_BRIGHTNESS 3
> +
> #if IS_REACHABLE(CONFIG_ASUS_WMI)
> void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
> void set_ally_mcu_powersave(bool enabled);
> @@ -176,6 +184,7 @@ int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
>
> int asus_hid_register_listener(struct asus_hid_listener *cdev);
> void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
> +int asus_hid_event(enum asus_hid_event event);
> #else
> static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
> {
> @@ -200,6 +209,10 @@ static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
> static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> {
> }
> +static inline int asus_hid_event(enum asus_hid_event event)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
>
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler
2025-10-15 12:18 ` Ilpo Järvinen
@ 2025-10-15 15:38 ` Antheas Kapenekakis
0 siblings, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-15 15:38 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
On Wed, 15 Oct 2025 at 14:19, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Mon, 13 Oct 2025, Antheas Kapenekakis wrote:
>
> > Currenlty, the keyboard brightness control of Asus WMI keyboards is
>
> There's a typo here but preferrably avoid "currently" altogether where
> possible.
>
> > handled in the kernel, which leads to the shortcut going from
> > brightness 0, to 1, to 2, and 3.
> >
> > However, for HID keyboards it is exposed as a key and handled by the
> > user's desktop environment. For the toggle button, this means that
> > brightness control becomes on/off. In addition, in the absence of a
> > DE, the keyboard brightness does not work.
> >
> > Therefore, expose an event handler for the keyboard brightness control
> > which can then be used by hid-asus.
> >
> > Reviewed-by: Luke D. Jones <luke@ljones.dev>
> > Tested-by: Luke D. Jones <luke@ljones.dev>
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> > ---
> > drivers/platform/x86/asus-wmi.c | 41 +++++++++++++++++++++-
> > include/linux/platform_data/x86/asus-wmi.h | 13 +++++++
> > 2 files changed, 53 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> > index a2a7cd61fd59..58407a3b6d41 100644
> > --- a/drivers/platform/x86/asus-wmi.c
> > +++ b/drivers/platform/x86/asus-wmi.c
> > @@ -1579,6 +1579,45 @@ void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> > }
> > EXPORT_SYMBOL_GPL(asus_hid_unregister_listener);
> >
> > +static void do_kbd_led_set(struct led_classdev *led_cdev, int value);
> > +
> > +int asus_hid_event(enum asus_hid_event event)
> > +{
> > + unsigned long flags;
> > + int brightness;
> > +
> > + spin_lock_irqsave(&asus_ref.lock, flags);
> > + if (!asus_ref.asus || !asus_ref.asus->kbd_led_registered) {
>
> Please add a local variable for asus_ref.asus. Check other
> patches/functions too if its use is repeated in some function many times,
> the local var seems to be in order.
>
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
>
> Use guard() instead.
>
> > + return -EBUSY;
> > + }
> > + brightness = asus_ref.asus->kbd_led_wk;
> > +
> > + switch (event) {
> > + case ASUS_EV_BRTUP:
> > + brightness += 1;
> > + break;
> > + case ASUS_EV_BRTDOWN:
> > + brightness -= 1;
> > + break;
> > + case ASUS_EV_BRTTOGGLE:
> > + if (brightness >= ASUS_EV_MAX_BRIGHTNESS)
> > + brightness = 0;
> > + else
> > + brightness += 1;
> > + break;
> > + }
> > +
> > + do_kbd_led_set(&asus_ref.asus->kbd_led, brightness);
> > + led_classdev_notify_brightness_hw_changed(&asus_ref.asus->kbd_led,
> > + asus_ref.asus->kbd_led_wk);
> > +
> > + spin_unlock_irqrestore(&asus_ref.lock, flags);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(asus_hid_event);
> > +
> > /*
> > * These functions actually update the LED's, and are called from a
> > * workqueue. By doing this as separate work rather than when the LED
> > @@ -1878,7 +1917,7 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
> > asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
> > asus->kbd_led.brightness_set = kbd_led_set;
> > asus->kbd_led.brightness_get = kbd_led_get;
> > - asus->kbd_led.max_brightness = 3;
> > + asus->kbd_led.max_brightness = ASUS_EV_MAX_BRIGHTNESS;
> > asus->kbd_led_avail = !kbd_led_read(asus, &led_val, NULL);
> >
> > if (asus->kbd_led_avail)
> > diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> > index 1f85d76387a8..e78e0fbccede 100644
> > --- a/include/linux/platform_data/x86/asus-wmi.h
> > +++ b/include/linux/platform_data/x86/asus-wmi.h
> > @@ -168,6 +168,14 @@ struct asus_hid_listener {
> > void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
> > };
> >
> > +enum asus_hid_event {
> > + ASUS_EV_BRTUP,
> > + ASUS_EV_BRTDOWN,
> > + ASUS_EV_BRTTOGGLE,
>
> Where does "BRT" come from. To me it doesn't associate with brightness
> (might be due to me being non-native). If there's a good reason why it's
> that way, fine but otherwise I suggest changing it so that it becomes
> easier to understand.
>
> It's not a big problem as is because the context in the code above allows
> decrypting the meaning but without the other names, I'd have been totally
> lost what it means.
Comes from e9809c0b9670 ("asus-wmi: add keyboard backlight support")
I matched it to the driver, other alternative is KBDILLUM. I will keep
it as BRT for now to match the current driver.
> > +};
> > +
> > +#define ASUS_EV_MAX_BRIGHTNESS 3
> > +
> > #if IS_REACHABLE(CONFIG_ASUS_WMI)
> > void set_ally_mcu_hack(enum asus_ally_mcu_hack status);
> > void set_ally_mcu_powersave(bool enabled);
> > @@ -176,6 +184,7 @@ int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
> >
> > int asus_hid_register_listener(struct asus_hid_listener *cdev);
> > void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
> > +int asus_hid_event(enum asus_hid_event event);
> > #else
> > static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
> > {
> > @@ -200,6 +209,10 @@ static inline int asus_hid_register_listener(struct asus_hid_listener *bdev)
> > static inline void asus_hid_unregister_listener(struct asus_hid_listener *bdev)
> > {
> > }
> > +static inline int asus_hid_event(enum asus_hid_event event)
> > +{
> > + return -ENODEV;
> > +}
> > #endif
> >
> > #endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
> >
>
> --
> i.
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH v6 7/7] HID: asus: add support for the asus-wmi brightness handler
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (5 preceding siblings ...)
2025-10-13 20:15 ` [PATCH v6 6/7] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
@ 2025-10-13 20:15 ` Antheas Kapenekakis
2025-10-13 21:37 ` Denis Benato
2025-10-13 21:36 ` [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Denis Benato
2025-10-16 11:57 ` Denis Benato
8 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 20:15 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato,
Antheas Kapenekakis
If the asus-wmi brightness handler is available, send the
keyboard brightness events to it instead of passing them
to userspace. If it is not, fall back to sending them to it.
Reviewed-by: Luke D. Jones <luke@ljones.dev>
Tested-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/hid/hid-asus.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 0af19c8ef035..1f904bb66396 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -324,6 +324,17 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
usage->hid & HID_USAGE);
}
+ if (usage->type == EV_KEY && value) {
+ switch (usage->code) {
+ case KEY_KBDILLUMUP:
+ return !asus_hid_event(ASUS_EV_BRTUP);
+ case KEY_KBDILLUMDOWN:
+ return !asus_hid_event(ASUS_EV_BRTDOWN);
+ case KEY_KBDILLUMTOGGLE:
+ return !asus_hid_event(ASUS_EV_BRTTOGGLE);
+ }
+ }
+
return 0;
}
--
2.51.0
^ permalink raw reply related [flat|nested] 45+ messages in thread* Re: [PATCH v6 7/7] HID: asus: add support for the asus-wmi brightness handler
2025-10-13 20:15 ` [PATCH v6 7/7] HID: asus: add support for the asus-wmi brightness handler Antheas Kapenekakis
@ 2025-10-13 21:37 ` Denis Benato
0 siblings, 0 replies; 45+ messages in thread
From: Denis Benato @ 2025-10-13 21:37 UTC (permalink / raw)
To: Antheas Kapenekakis, platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen
On 10/13/25 22:15, Antheas Kapenekakis wrote:
> If the asus-wmi brightness handler is available, send the
> keyboard brightness events to it instead of passing them
> to userspace. If it is not, fall back to sending them to it.
>
> Reviewed-by: Luke D. Jones <luke@ljones.dev>
> Tested-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
> drivers/hid/hid-asus.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 0af19c8ef035..1f904bb66396 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -324,6 +324,17 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
> usage->hid & HID_USAGE);
> }
>
> + if (usage->type == EV_KEY && value) {
> + switch (usage->code) {
> + case KEY_KBDILLUMUP:
> + return !asus_hid_event(ASUS_EV_BRTUP);
> + case KEY_KBDILLUMDOWN:
> + return !asus_hid_event(ASUS_EV_BRTDOWN);
> + case KEY_KBDILLUMTOGGLE:
> + return !asus_hid_event(ASUS_EV_BRTTOGGLE);
> + }
> + }
> +
> return 0;
> }
>
Neat. I like this.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (6 preceding siblings ...)
2025-10-13 20:15 ` [PATCH v6 7/7] HID: asus: add support for the asus-wmi brightness handler Antheas Kapenekakis
@ 2025-10-13 21:36 ` Denis Benato
2025-10-13 21:45 ` Antheas Kapenekakis
2025-10-16 11:57 ` Denis Benato
8 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-13 21:36 UTC (permalink / raw)
To: Antheas Kapenekakis, platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen
On 10/13/25 22:15, Antheas Kapenekakis wrote:
> This is a two part series which does the following:
> - Clean-up init sequence
> - Unify backlight handling to happen under asus-wmi so that all Aura
> devices have synced brightness controls and the backlight button works
> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>
> For more context, see cover letter of V1. Since V5, I removed some patches
> to make this easier to merge.
>
> All comments with these patches had been addressed since V4.
>
> ---
> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>
> Changes since V5:
> - It's been a long time
> - Remove addition of RGB as that had some comments I need to work on
Hello and thanks for this,
I would like to see a set of objectives that this series is trying to reach clearly spelled out:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
section 2, basically.
I can deduct you are trying to fix certain keyboards having keys not properly changing
the backlight, but is that all there is to it?
These commits sure touches a lot of code to fix an (unspecified? Unclear to me at least) number of bugs.
Given the fact I expect regressions (nothing personal: ASUS has a very large pool of models,
many requiring specialized quirks as can be seen in the diff)
wouldn't it be wise to take the chance and expose the "static" lighting mode,
including colors handling, for every asus rog, tuf, tx and proart laptop
in existence in a way that most already-existing programs (including the KDE widget) can handle?
At least there would be a big incentive behind all these changes.
[^ the above paragraph is valid if the number of fixed bugs is small and there is at least another way to fix it/them].
Surely data needed to check what model support
what lighting mode is known at this point, would probably be wise
to put such data in the kernel and make good use of it.
Thanks,
Denis
> - Remove folio patch (already merged)
> - Remove legacy fix patch 11 from V4. There is a small chance that
> without this patch, some old NKEY keyboards might not respond to
> RGB commands according to Luke, but the kernel driver does not do
> RGB currently. The 0x5d init is done by Armoury crate software in
> Windows. If an issue is found, we can re-add it or just remove patches
> 1/2 before merging. However, init could use the cleanup.
>
> Changes since V4:
> - Fix KConfig (reported by kernel robot)
> - Fix Ilpo's nits, if I missed anything lmk
>
> Changes since V3:
> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> that it is not needed for their media keys to function.
> - Cover init in asus-wmi with spinlock as per Hans
> - If asus-wmi registers WMI handler with brightness, init the brightness
> in USB Asus keyboards, per Hans.
> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> - Fix oops when unregistering asus-wmi by moving unregister outside of
> the spin lock (but after the asus reference is set to null)
>
> Changes since V2:
> - Check lazy init succeds in asus-wmi before setting register variable
> - make explicit check in asus_hid_register_listener for listener existing
> to avoid re-init
> - rename asus_brt to asus_hid in most places and harmonize everything
> - switch to a spinlock instead of a mutex to avoid kernel ooops
> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> all input vendor devices. This includes moving rgb init to probe
> instead of the input_configured callbacks.
> - Remove fan key (during retest it appears to be 0xae that is already
> supported by hid-asus)
> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> - removes fds from userspace and breaks backlight functionality. All
> - current mainline drivers do not support backlight hotplugging, so most
> userspace software (e.g., KDE, UPower) is built with that assumption.
> For the Ally, since it disconnects its controller during sleep, this
> caused the backlight slider to not work in KDE.
>
> Changes since V1:
> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> - Fix ifdef else having an invalid signature (reported by kernel robot)
> - Restore input arguments to init and keyboard function so they can
> be re-used for RGB controls.
> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> keyboard rename into it.
> - Unregister brightness listener before removing work queue to avoid
> a race condition causing corruption
> - Remove spurious mutex unlock in asus_brt_event
> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> relocking the mutex and causing a deadlock when unregistering leds
> - Add extra check during unregistering to avoid calling unregister when
> no led device is registered.
> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> the driver to create 4 RGB handlers per device. I also suspect some
> extra events sneak through (KDE had the @@@@@@).
>
> Antheas Kapenekakis (7):
> HID: asus: refactor init sequence per spec
> HID: asus: prevent binding to all HID devices on ROG
> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> HID: asus: listen to the asus-wmi brightness device instead of
> creating one
> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> platform/x86: asus-wmi: add keyboard brightness event handler
> HID: asus: add support for the asus-wmi brightness handler
>
> drivers/hid/hid-asus.c | 235 +++++++++++----------
> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> 3 files changed, 291 insertions(+), 170 deletions(-)
>
>
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-13 21:36 ` [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Denis Benato
@ 2025-10-13 21:45 ` Antheas Kapenekakis
0 siblings, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-13 21:45 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Mon, 13 Oct 2025 at 23:36, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > This is a two part series which does the following:
> > - Clean-up init sequence
> > - Unify backlight handling to happen under asus-wmi so that all Aura
> > devices have synced brightness controls and the backlight button works
> > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >
> > For more context, see cover letter of V1. Since V5, I removed some patches
> > to make this easier to merge.
> >
> > All comments with these patches had been addressed since V4.
> >
> > ---
> > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >
> > Changes since V5:
> > - It's been a long time
> > - Remove addition of RGB as that had some comments I need to work on
> Hello and thanks for this,
>
> I would like to see a set of objectives that this series is trying to reach clearly spelled out:
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
> section 2, basically.
>
> I can deduct you are trying to fix certain keyboards having keys not properly changing
> the backlight, but is that all there is to it?
First two patches cleanup the init sequence.
Next three patches centralize the keyboard brightness handler into
asus-wmi, by having hid-asus register a listener for brightness events
to it.
This allows Asus laptops that have both WMI and Aura devices to still
work without a rerouting quirk, the Z13 to work while having both a
lightbar and a keyboard (2 Aura devices), and specifically for devices
with removable keyboards such as the Z13, the ability to maintain the
same brightness file descriptor, so that handlers like upower do not
stop working after detaching the keyboard.
Finally, the last two patches send the brightness events to asus-wmi
to process them internally. This allows for 0-33%-66%-100% brightness,
instead of 100%/0% toggle. This mirrors how the thinkpad devices work
internally. Brightness events are broadcast, so KDE reports the
brightness changing correctly.
> These commits sure touches a lot of code to fix an (unspecified? Unclear to me at least) number of bugs.
>
> Given the fact I expect regressions (nothing personal: ASUS has a very large pool of models,
> many requiring specialized quirks as can be seen in the diff)
> wouldn't it be wise to take the chance and expose the "static" lighting mode,
> including colors handling, for every asus rog, tuf, tx and proart laptop
> in existence in a way that most already-existing programs (including the KDE widget) can handle?
> At least there would be a big incentive behind all these changes.
The patches for RGB have been removed from this series.
Thanks,
Antheas
> [^ the above paragraph is valid if the number of fixed bugs is small and there is at least another way to fix it/them].
>
> Surely data needed to check what model support
> what lighting mode is known at this point, would probably be wise
> to put such data in the kernel and make good use of it.
>
> Thanks,
> Denis
>
> > - Remove folio patch (already merged)
> > - Remove legacy fix patch 11 from V4. There is a small chance that
> > without this patch, some old NKEY keyboards might not respond to
> > RGB commands according to Luke, but the kernel driver does not do
> > RGB currently. The 0x5d init is done by Armoury crate software in
> > Windows. If an issue is found, we can re-add it or just remove patches
> > 1/2 before merging. However, init could use the cleanup.
> >
> > Changes since V4:
> > - Fix KConfig (reported by kernel robot)
> > - Fix Ilpo's nits, if I missed anything lmk
> >
> > Changes since V3:
> > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > that it is not needed for their media keys to function.
> > - Cover init in asus-wmi with spinlock as per Hans
> > - If asus-wmi registers WMI handler with brightness, init the brightness
> > in USB Asus keyboards, per Hans.
> > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > the spin lock (but after the asus reference is set to null)
> >
> > Changes since V2:
> > - Check lazy init succeds in asus-wmi before setting register variable
> > - make explicit check in asus_hid_register_listener for listener existing
> > to avoid re-init
> > - rename asus_brt to asus_hid in most places and harmonize everything
> > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > all input vendor devices. This includes moving rgb init to probe
> > instead of the input_configured callbacks.
> > - Remove fan key (during retest it appears to be 0xae that is already
> > supported by hid-asus)
> > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > - removes fds from userspace and breaks backlight functionality. All
> > - current mainline drivers do not support backlight hotplugging, so most
> > userspace software (e.g., KDE, UPower) is built with that assumption.
> > For the Ally, since it disconnects its controller during sleep, this
> > caused the backlight slider to not work in KDE.
> >
> > Changes since V1:
> > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > - Restore input arguments to init and keyboard function so they can
> > be re-used for RGB controls.
> > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > keyboard rename into it.
> > - Unregister brightness listener before removing work queue to avoid
> > a race condition causing corruption
> > - Remove spurious mutex unlock in asus_brt_event
> > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > relocking the mutex and causing a deadlock when unregistering leds
> > - Add extra check during unregistering to avoid calling unregister when
> > no led device is registered.
> > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > the driver to create 4 RGB handlers per device. I also suspect some
> > extra events sneak through (KDE had the @@@@@@).
> >
> > Antheas Kapenekakis (7):
> > HID: asus: refactor init sequence per spec
> > HID: asus: prevent binding to all HID devices on ROG
> > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > HID: asus: listen to the asus-wmi brightness device instead of
> > creating one
> > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > platform/x86: asus-wmi: add keyboard brightness event handler
> > HID: asus: add support for the asus-wmi brightness handler
> >
> > drivers/hid/hid-asus.c | 235 +++++++++++----------
> > drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > 3 files changed, 291 insertions(+), 170 deletions(-)
> >
> >
> > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-13 20:15 [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
` (7 preceding siblings ...)
2025-10-13 21:36 ` [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Denis Benato
@ 2025-10-16 11:57 ` Denis Benato
2025-10-16 12:14 ` Antheas Kapenekakis
8 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-16 11:57 UTC (permalink / raw)
To: Antheas Kapenekakis, platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen
On 10/13/25 22:15, Antheas Kapenekakis wrote:
> This is a two part series which does the following:
> - Clean-up init sequence
> - Unify backlight handling to happen under asus-wmi so that all Aura
> devices have synced brightness controls and the backlight button works
> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>
> For more context, see cover letter of V1. Since V5, I removed some patches
> to make this easier to merge.
>
> All comments with these patches had been addressed since V4.
I have loaded this patchset for users of asus-linux project to try out.
One of them opened a bug report about a kernel bug that happens
consistently when closing the lid of his laptop [1].
He also sent another piece of kernel log, but didn't specify anything more
about this [2].
[1] https://pastebin.com/akZx1w10
[2] https://pastebin.com/sKdczPgf
> ---
> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>
> Changes since V5:
> - It's been a long time
> - Remove addition of RGB as that had some comments I need to work on
> - Remove folio patch (already merged)
> - Remove legacy fix patch 11 from V4. There is a small chance that
> without this patch, some old NKEY keyboards might not respond to
> RGB commands according to Luke, but the kernel driver does not do
> RGB currently. The 0x5d init is done by Armoury crate software in
> Windows. If an issue is found, we can re-add it or just remove patches
> 1/2 before merging. However, init could use the cleanup.
>
> Changes since V4:
> - Fix KConfig (reported by kernel robot)
> - Fix Ilpo's nits, if I missed anything lmk
>
> Changes since V3:
> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> that it is not needed for their media keys to function.
> - Cover init in asus-wmi with spinlock as per Hans
> - If asus-wmi registers WMI handler with brightness, init the brightness
> in USB Asus keyboards, per Hans.
> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> - Fix oops when unregistering asus-wmi by moving unregister outside of
> the spin lock (but after the asus reference is set to null)
>
> Changes since V2:
> - Check lazy init succeds in asus-wmi before setting register variable
> - make explicit check in asus_hid_register_listener for listener existing
> to avoid re-init
> - rename asus_brt to asus_hid in most places and harmonize everything
> - switch to a spinlock instead of a mutex to avoid kernel ooops
> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> all input vendor devices. This includes moving rgb init to probe
> instead of the input_configured callbacks.
> - Remove fan key (during retest it appears to be 0xae that is already
> supported by hid-asus)
> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> - removes fds from userspace and breaks backlight functionality. All
> - current mainline drivers do not support backlight hotplugging, so most
> userspace software (e.g., KDE, UPower) is built with that assumption.
> For the Ally, since it disconnects its controller during sleep, this
> caused the backlight slider to not work in KDE.
>
> Changes since V1:
> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> - Fix ifdef else having an invalid signature (reported by kernel robot)
> - Restore input arguments to init and keyboard function so they can
> be re-used for RGB controls.
> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> keyboard rename into it.
> - Unregister brightness listener before removing work queue to avoid
> a race condition causing corruption
> - Remove spurious mutex unlock in asus_brt_event
> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> relocking the mutex and causing a deadlock when unregistering leds
> - Add extra check during unregistering to avoid calling unregister when
> no led device is registered.
> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> the driver to create 4 RGB handlers per device. I also suspect some
> extra events sneak through (KDE had the @@@@@@).
>
> Antheas Kapenekakis (7):
> HID: asus: refactor init sequence per spec
> HID: asus: prevent binding to all HID devices on ROG
> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> HID: asus: listen to the asus-wmi brightness device instead of
> creating one
> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> platform/x86: asus-wmi: add keyboard brightness event handler
> HID: asus: add support for the asus-wmi brightness handler
>
> drivers/hid/hid-asus.c | 235 +++++++++++----------
> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> 3 files changed, 291 insertions(+), 170 deletions(-)
>
>
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 11:57 ` Denis Benato
@ 2025-10-16 12:14 ` Antheas Kapenekakis
2025-10-16 12:19 ` Denis Benato
2025-10-16 15:08 ` Ilpo Järvinen
0 siblings, 2 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 12:14 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > This is a two part series which does the following:
> > - Clean-up init sequence
> > - Unify backlight handling to happen under asus-wmi so that all Aura
> > devices have synced brightness controls and the backlight button works
> > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >
> > For more context, see cover letter of V1. Since V5, I removed some patches
> > to make this easier to merge.
> >
> > All comments with these patches had been addressed since V4.
> I have loaded this patchset for users of asus-linux project to try out.
>
> One of them opened a bug report about a kernel bug that happens
> consistently when closing the lid of his laptop [1].
>
> He also sent another piece of kernel log, but didn't specify anything more
> about this [2].
>
> [1] https://pastebin.com/akZx1w10
> [2] https://pastebin.com/sKdczPgf
Can you provide a link to the bug report? [2] seems unrelated.
As for [1], it looks like a trace that stems from a sysfs write to
brightness stemming from userspace that follows the same chain it
would on a stock kernel and times out. Is it present on a stock
kernel?
Ilpo should know more about this, could the spinlock be interfering?
My testing on devices that have WMI led controls is a bit limited
unfortunately. However, most of our asus users have been happy with
this series for around half a year now.
Antheas
> > ---
> > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >
> > Changes since V5:
> > - It's been a long time
> > - Remove addition of RGB as that had some comments I need to work on
> > - Remove folio patch (already merged)
> > - Remove legacy fix patch 11 from V4. There is a small chance that
> > without this patch, some old NKEY keyboards might not respond to
> > RGB commands according to Luke, but the kernel driver does not do
> > RGB currently. The 0x5d init is done by Armoury crate software in
> > Windows. If an issue is found, we can re-add it or just remove patches
> > 1/2 before merging. However, init could use the cleanup.
> >
> > Changes since V4:
> > - Fix KConfig (reported by kernel robot)
> > - Fix Ilpo's nits, if I missed anything lmk
> >
> > Changes since V3:
> > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > that it is not needed for their media keys to function.
> > - Cover init in asus-wmi with spinlock as per Hans
> > - If asus-wmi registers WMI handler with brightness, init the brightness
> > in USB Asus keyboards, per Hans.
> > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > the spin lock (but after the asus reference is set to null)
> >
> > Changes since V2:
> > - Check lazy init succeds in asus-wmi before setting register variable
> > - make explicit check in asus_hid_register_listener for listener existing
> > to avoid re-init
> > - rename asus_brt to asus_hid in most places and harmonize everything
> > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > all input vendor devices. This includes moving rgb init to probe
> > instead of the input_configured callbacks.
> > - Remove fan key (during retest it appears to be 0xae that is already
> > supported by hid-asus)
> > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > - removes fds from userspace and breaks backlight functionality. All
> > - current mainline drivers do not support backlight hotplugging, so most
> > userspace software (e.g., KDE, UPower) is built with that assumption.
> > For the Ally, since it disconnects its controller during sleep, this
> > caused the backlight slider to not work in KDE.
> >
> > Changes since V1:
> > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > - Restore input arguments to init and keyboard function so they can
> > be re-used for RGB controls.
> > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > keyboard rename into it.
> > - Unregister brightness listener before removing work queue to avoid
> > a race condition causing corruption
> > - Remove spurious mutex unlock in asus_brt_event
> > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > relocking the mutex and causing a deadlock when unregistering leds
> > - Add extra check during unregistering to avoid calling unregister when
> > no led device is registered.
> > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > the driver to create 4 RGB handlers per device. I also suspect some
> > extra events sneak through (KDE had the @@@@@@).
> >
> > Antheas Kapenekakis (7):
> > HID: asus: refactor init sequence per spec
> > HID: asus: prevent binding to all HID devices on ROG
> > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > HID: asus: listen to the asus-wmi brightness device instead of
> > creating one
> > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > platform/x86: asus-wmi: add keyboard brightness event handler
> > HID: asus: add support for the asus-wmi brightness handler
> >
> > drivers/hid/hid-asus.c | 235 +++++++++++----------
> > drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > 3 files changed, 291 insertions(+), 170 deletions(-)
> >
> >
> > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:14 ` Antheas Kapenekakis
@ 2025-10-16 12:19 ` Denis Benato
2025-10-16 12:28 ` Antheas Kapenekakis
2025-10-16 15:08 ` Ilpo Järvinen
1 sibling, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-16 12:19 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On 10/16/25 14:14, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>> This is a two part series which does the following:
>>> - Clean-up init sequence
>>> - Unify backlight handling to happen under asus-wmi so that all Aura
>>> devices have synced brightness controls and the backlight button works
>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>>>
>>> For more context, see cover letter of V1. Since V5, I removed some patches
>>> to make this easier to merge.
>>>
>>> All comments with these patches had been addressed since V4.
>> I have loaded this patchset for users of asus-linux project to try out.
>>
>> One of them opened a bug report about a kernel bug that happens
>> consistently when closing the lid of his laptop [1].
>>
>> He also sent another piece of kernel log, but didn't specify anything more
>> about this [2].
>>
>> [1] https://pastebin.com/akZx1w10
>> [2] https://pastebin.com/sKdczPgf
> Can you provide a link to the bug report? [2] seems unrelated.
The log in [2] was posted without additional context in the same
discord message as [1].
I think I will tell the user to open a proper bug report because
I do agree on the fact that it's looking unrelated.
> As for [1], it looks like a trace that stems from a sysfs write to
> brightness stemming from userspace that follows the same chain it
> would on a stock kernel and times out. Is it present on a stock
> kernel?
I have asked more details to the user. The user is not online ATM
so I will get to you with more details when I can.
> Ilpo should know more about this, could the spinlock be interfering?
> My testing on devices that have WMI led controls is a bit limited
> unfortunately. However, most of our asus users have been happy with
> this series for around half a year now.
Unless they have looked to kernel logs they won't be able to tell
since apparently there are no visible consequences.
> Antheas
>
>>> ---
>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>>>
>>> Changes since V5:
>>> - It's been a long time
>>> - Remove addition of RGB as that had some comments I need to work on
>>> - Remove folio patch (already merged)
>>> - Remove legacy fix patch 11 from V4. There is a small chance that
>>> without this patch, some old NKEY keyboards might not respond to
>>> RGB commands according to Luke, but the kernel driver does not do
>>> RGB currently. The 0x5d init is done by Armoury crate software in
>>> Windows. If an issue is found, we can re-add it or just remove patches
>>> 1/2 before merging. However, init could use the cleanup.
>>>
>>> Changes since V4:
>>> - Fix KConfig (reported by kernel robot)
>>> - Fix Ilpo's nits, if I missed anything lmk
>>>
>>> Changes since V3:
>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
>>> that it is not needed for their media keys to function.
>>> - Cover init in asus-wmi with spinlock as per Hans
>>> - If asus-wmi registers WMI handler with brightness, init the brightness
>>> in USB Asus keyboards, per Hans.
>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
>>> the spin lock (but after the asus reference is set to null)
>>>
>>> Changes since V2:
>>> - Check lazy init succeds in asus-wmi before setting register variable
>>> - make explicit check in asus_hid_register_listener for listener existing
>>> to avoid re-init
>>> - rename asus_brt to asus_hid in most places and harmonize everything
>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
>>> all input vendor devices. This includes moving rgb init to probe
>>> instead of the input_configured callbacks.
>>> - Remove fan key (during retest it appears to be 0xae that is already
>>> supported by hid-asus)
>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
>>> - removes fds from userspace and breaks backlight functionality. All
>>> - current mainline drivers do not support backlight hotplugging, so most
>>> userspace software (e.g., KDE, UPower) is built with that assumption.
>>> For the Ally, since it disconnects its controller during sleep, this
>>> caused the backlight slider to not work in KDE.
>>>
>>> Changes since V1:
>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
>>> - Restore input arguments to init and keyboard function so they can
>>> be re-used for RGB controls.
>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
>>> keyboard rename into it.
>>> - Unregister brightness listener before removing work queue to avoid
>>> a race condition causing corruption
>>> - Remove spurious mutex unlock in asus_brt_event
>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
>>> relocking the mutex and causing a deadlock when unregistering leds
>>> - Add extra check during unregistering to avoid calling unregister when
>>> no led device is registered.
>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
>>> the driver to create 4 RGB handlers per device. I also suspect some
>>> extra events sneak through (KDE had the @@@@@@).
>>>
>>> Antheas Kapenekakis (7):
>>> HID: asus: refactor init sequence per spec
>>> HID: asus: prevent binding to all HID devices on ROG
>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
>>> HID: asus: listen to the asus-wmi brightness device instead of
>>> creating one
>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
>>> platform/x86: asus-wmi: add keyboard brightness event handler
>>> HID: asus: add support for the asus-wmi brightness handler
>>>
>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
>>> 3 files changed, 291 insertions(+), 170 deletions(-)
>>>
>>>
>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:19 ` Denis Benato
@ 2025-10-16 12:28 ` Antheas Kapenekakis
2025-10-16 12:46 ` Denis Benato
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 12:28 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/16/25 14:14, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> >>
> >> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>> This is a two part series which does the following:
> >>> - Clean-up init sequence
> >>> - Unify backlight handling to happen under asus-wmi so that all Aura
> >>> devices have synced brightness controls and the backlight button works
> >>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >>>
> >>> For more context, see cover letter of V1. Since V5, I removed some patches
> >>> to make this easier to merge.
> >>>
> >>> All comments with these patches had been addressed since V4.
> >> I have loaded this patchset for users of asus-linux project to try out.
> >>
> >> One of them opened a bug report about a kernel bug that happens
> >> consistently when closing the lid of his laptop [1].
> >>
> >> He also sent another piece of kernel log, but didn't specify anything more
> >> about this [2].
> >>
> >> [1] https://pastebin.com/akZx1w10
> >> [2] https://pastebin.com/sKdczPgf
> > Can you provide a link to the bug report? [2] seems unrelated.
> The log in [2] was posted without additional context in the same
> discord message as [1].
Link me the kernel sources. Is it linux-g14 in the AUR?
> I think I will tell the user to open a proper bug report because
> I do agree on the fact that it's looking unrelated.
> > As for [1], it looks like a trace that stems from a sysfs write to
> > brightness stemming from userspace that follows the same chain it
> > would on a stock kernel and times out. Is it present on a stock
> > kernel?
> I have asked more details to the user. The user is not online ATM
> so I will get to you with more details when I can.
> > Ilpo should know more about this, could the spinlock be interfering?
> > My testing on devices that have WMI led controls is a bit limited
> > unfortunately. However, most of our asus users have been happy with
> > this series for around half a year now.
> Unless they have looked to kernel logs they won't be able to tell
> since apparently there are no visible consequences.
> > Antheas
> >
> >>> ---
> >>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> >>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> >>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> >>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> >>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >>>
> >>> Changes since V5:
> >>> - It's been a long time
> >>> - Remove addition of RGB as that had some comments I need to work on
> >>> - Remove folio patch (already merged)
> >>> - Remove legacy fix patch 11 from V4. There is a small chance that
> >>> without this patch, some old NKEY keyboards might not respond to
> >>> RGB commands according to Luke, but the kernel driver does not do
> >>> RGB currently. The 0x5d init is done by Armoury crate software in
> >>> Windows. If an issue is found, we can re-add it or just remove patches
> >>> 1/2 before merging. However, init could use the cleanup.
> >>>
> >>> Changes since V4:
> >>> - Fix KConfig (reported by kernel robot)
> >>> - Fix Ilpo's nits, if I missed anything lmk
> >>>
> >>> Changes since V3:
> >>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> >>> that it is not needed for their media keys to function.
> >>> - Cover init in asus-wmi with spinlock as per Hans
> >>> - If asus-wmi registers WMI handler with brightness, init the brightness
> >>> in USB Asus keyboards, per Hans.
> >>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> >>> - Fix oops when unregistering asus-wmi by moving unregister outside of
> >>> the spin lock (but after the asus reference is set to null)
> >>>
> >>> Changes since V2:
> >>> - Check lazy init succeds in asus-wmi before setting register variable
> >>> - make explicit check in asus_hid_register_listener for listener existing
> >>> to avoid re-init
> >>> - rename asus_brt to asus_hid in most places and harmonize everything
> >>> - switch to a spinlock instead of a mutex to avoid kernel ooops
> >>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> >>> all input vendor devices. This includes moving rgb init to probe
> >>> instead of the input_configured callbacks.
> >>> - Remove fan key (during retest it appears to be 0xae that is already
> >>> supported by hid-asus)
> >>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> >>> - removes fds from userspace and breaks backlight functionality. All
> >>> - current mainline drivers do not support backlight hotplugging, so most
> >>> userspace software (e.g., KDE, UPower) is built with that assumption.
> >>> For the Ally, since it disconnects its controller during sleep, this
> >>> caused the backlight slider to not work in KDE.
> >>>
> >>> Changes since V1:
> >>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> >>> - Fix ifdef else having an invalid signature (reported by kernel robot)
> >>> - Restore input arguments to init and keyboard function so they can
> >>> be re-used for RGB controls.
> >>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> >>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> >>> keyboard rename into it.
> >>> - Unregister brightness listener before removing work queue to avoid
> >>> a race condition causing corruption
> >>> - Remove spurious mutex unlock in asus_brt_event
> >>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> >>> relocking the mutex and causing a deadlock when unregistering leds
> >>> - Add extra check during unregistering to avoid calling unregister when
> >>> no led device is registered.
> >>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> >>> the driver to create 4 RGB handlers per device. I also suspect some
> >>> extra events sneak through (KDE had the @@@@@@).
> >>>
> >>> Antheas Kapenekakis (7):
> >>> HID: asus: refactor init sequence per spec
> >>> HID: asus: prevent binding to all HID devices on ROG
> >>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> >>> HID: asus: listen to the asus-wmi brightness device instead of
> >>> creating one
> >>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> >>> platform/x86: asus-wmi: add keyboard brightness event handler
> >>> HID: asus: add support for the asus-wmi brightness handler
> >>>
> >>> drivers/hid/hid-asus.c | 235 +++++++++++----------
> >>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> >>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> >>> 3 files changed, 291 insertions(+), 170 deletions(-)
> >>>
> >>>
> >>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:28 ` Antheas Kapenekakis
@ 2025-10-16 12:46 ` Denis Benato
2025-10-16 12:51 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-16 12:46 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On 10/16/25 14:28, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/16/25 14:14, Antheas Kapenekakis wrote:
>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>> This is a two part series which does the following:
>>>>> - Clean-up init sequence
>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
>>>>> devices have synced brightness controls and the backlight button works
>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>>>>>
>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
>>>>> to make this easier to merge.
>>>>>
>>>>> All comments with these patches had been addressed since V4.
>>>> I have loaded this patchset for users of asus-linux project to try out.
>>>>
>>>> One of them opened a bug report about a kernel bug that happens
>>>> consistently when closing the lid of his laptop [1].
>>>>
>>>> He also sent another piece of kernel log, but didn't specify anything more
>>>> about this [2].
>>>>
>>>> [1] https://pastebin.com/akZx1w10
>>>> [2] https://pastebin.com/sKdczPgf
>>> Can you provide a link to the bug report? [2] seems unrelated.
>> The log in [2] was posted without additional context in the same
>> discord message as [1].
> Link me the kernel sources. Is it linux-g14 in the AUR?
Someone has replicated it on the AUR but it's just an out-of-sync replica.
The true source code is here:
https://gitlab.com/asus-linux/linux-g14 branch 6.17
>> I think I will tell the user to open a proper bug report because
>> I do agree on the fact that it's looking unrelated.
>>> As for [1], it looks like a trace that stems from a sysfs write to
>>> brightness stemming from userspace that follows the same chain it
>>> would on a stock kernel and times out. Is it present on a stock
>>> kernel?
>> I have asked more details to the user. The user is not online ATM
>> so I will get to you with more details when I can.
>>> Ilpo should know more about this, could the spinlock be interfering?
>>> My testing on devices that have WMI led controls is a bit limited
>>> unfortunately. However, most of our asus users have been happy with
>>> this series for around half a year now.
>> Unless they have looked to kernel logs they won't be able to tell
>> since apparently there are no visible consequences.
>>> Antheas
>>>
>>>>> ---
>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>>>>>
>>>>> Changes since V5:
>>>>> - It's been a long time
>>>>> - Remove addition of RGB as that had some comments I need to work on
>>>>> - Remove folio patch (already merged)
>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
>>>>> without this patch, some old NKEY keyboards might not respond to
>>>>> RGB commands according to Luke, but the kernel driver does not do
>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
>>>>> Windows. If an issue is found, we can re-add it or just remove patches
>>>>> 1/2 before merging. However, init could use the cleanup.
>>>>>
>>>>> Changes since V4:
>>>>> - Fix KConfig (reported by kernel robot)
>>>>> - Fix Ilpo's nits, if I missed anything lmk
>>>>>
>>>>> Changes since V3:
>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
>>>>> that it is not needed for their media keys to function.
>>>>> - Cover init in asus-wmi with spinlock as per Hans
>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
>>>>> in USB Asus keyboards, per Hans.
>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
>>>>> the spin lock (but after the asus reference is set to null)
>>>>>
>>>>> Changes since V2:
>>>>> - Check lazy init succeds in asus-wmi before setting register variable
>>>>> - make explicit check in asus_hid_register_listener for listener existing
>>>>> to avoid re-init
>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
>>>>> all input vendor devices. This includes moving rgb init to probe
>>>>> instead of the input_configured callbacks.
>>>>> - Remove fan key (during retest it appears to be 0xae that is already
>>>>> supported by hid-asus)
>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
>>>>> - removes fds from userspace and breaks backlight functionality. All
>>>>> - current mainline drivers do not support backlight hotplugging, so most
>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
>>>>> For the Ally, since it disconnects its controller during sleep, this
>>>>> caused the backlight slider to not work in KDE.
>>>>>
>>>>> Changes since V1:
>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
>>>>> - Restore input arguments to init and keyboard function so they can
>>>>> be re-used for RGB controls.
>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
>>>>> keyboard rename into it.
>>>>> - Unregister brightness listener before removing work queue to avoid
>>>>> a race condition causing corruption
>>>>> - Remove spurious mutex unlock in asus_brt_event
>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
>>>>> relocking the mutex and causing a deadlock when unregistering leds
>>>>> - Add extra check during unregistering to avoid calling unregister when
>>>>> no led device is registered.
>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
>>>>> the driver to create 4 RGB handlers per device. I also suspect some
>>>>> extra events sneak through (KDE had the @@@@@@).
>>>>>
>>>>> Antheas Kapenekakis (7):
>>>>> HID: asus: refactor init sequence per spec
>>>>> HID: asus: prevent binding to all HID devices on ROG
>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
>>>>> HID: asus: listen to the asus-wmi brightness device instead of
>>>>> creating one
>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
>>>>> HID: asus: add support for the asus-wmi brightness handler
>>>>>
>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
>>>>>
>>>>>
>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:46 ` Denis Benato
@ 2025-10-16 12:51 ` Antheas Kapenekakis
2025-10-16 14:32 ` Denis Benato
0 siblings, 1 reply; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 12:51 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen
On Thu, 16 Oct 2025 at 14:46, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/16/25 14:28, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
> >>
> >> On 10/16/25 14:14, Antheas Kapenekakis wrote:
> >>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> >>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>>>> This is a two part series which does the following:
> >>>>> - Clean-up init sequence
> >>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
> >>>>> devices have synced brightness controls and the backlight button works
> >>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >>>>>
> >>>>> For more context, see cover letter of V1. Since V5, I removed some patches
> >>>>> to make this easier to merge.
> >>>>>
> >>>>> All comments with these patches had been addressed since V4.
> >>>> I have loaded this patchset for users of asus-linux project to try out.
> >>>>
> >>>> One of them opened a bug report about a kernel bug that happens
> >>>> consistently when closing the lid of his laptop [1].
> >>>>
> >>>> He also sent another piece of kernel log, but didn't specify anything more
> >>>> about this [2].
> >>>>
> >>>> [1] https://pastebin.com/akZx1w10
> >>>> [2] https://pastebin.com/sKdczPgf
> >>> Can you provide a link to the bug report? [2] seems unrelated.
> >> The log in [2] was posted without additional context in the same
> >> discord message as [1].
> > Link me the kernel sources. Is it linux-g14 in the AUR?
> Someone has replicated it on the AUR but it's just an out-of-sync replica.
>
> The true source code is here:
> https://gitlab.com/asus-linux/linux-g14 branch 6.17
Ok, lets wait for the user to replicate on a stock kernel
> >> I think I will tell the user to open a proper bug report because
> >> I do agree on the fact that it's looking unrelated.
> >>> As for [1], it looks like a trace that stems from a sysfs write to
> >>> brightness stemming from userspace that follows the same chain it
> >>> would on a stock kernel and times out. Is it present on a stock
> >>> kernel?
> >> I have asked more details to the user. The user is not online ATM
> >> so I will get to you with more details when I can.
> >>> Ilpo should know more about this, could the spinlock be interfering?
> >>> My testing on devices that have WMI led controls is a bit limited
> >>> unfortunately. However, most of our asus users have been happy with
> >>> this series for around half a year now.
> >> Unless they have looked to kernel logs they won't be able to tell
> >> since apparently there are no visible consequences.
> >>> Antheas
> >>>
> >>>>> ---
> >>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> >>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> >>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> >>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> >>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >>>>>
> >>>>> Changes since V5:
> >>>>> - It's been a long time
> >>>>> - Remove addition of RGB as that had some comments I need to work on
> >>>>> - Remove folio patch (already merged)
> >>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
> >>>>> without this patch, some old NKEY keyboards might not respond to
> >>>>> RGB commands according to Luke, but the kernel driver does not do
> >>>>> RGB currently. The 0x5d init is done by Armoury crate software in
> >>>>> Windows. If an issue is found, we can re-add it or just remove patches
> >>>>> 1/2 before merging. However, init could use the cleanup.
> >>>>>
> >>>>> Changes since V4:
> >>>>> - Fix KConfig (reported by kernel robot)
> >>>>> - Fix Ilpo's nits, if I missed anything lmk
> >>>>>
> >>>>> Changes since V3:
> >>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> >>>>> that it is not needed for their media keys to function.
> >>>>> - Cover init in asus-wmi with spinlock as per Hans
> >>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
> >>>>> in USB Asus keyboards, per Hans.
> >>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> >>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
> >>>>> the spin lock (but after the asus reference is set to null)
> >>>>>
> >>>>> Changes since V2:
> >>>>> - Check lazy init succeds in asus-wmi before setting register variable
> >>>>> - make explicit check in asus_hid_register_listener for listener existing
> >>>>> to avoid re-init
> >>>>> - rename asus_brt to asus_hid in most places and harmonize everything
> >>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
> >>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> >>>>> all input vendor devices. This includes moving rgb init to probe
> >>>>> instead of the input_configured callbacks.
> >>>>> - Remove fan key (during retest it appears to be 0xae that is already
> >>>>> supported by hid-asus)
> >>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> >>>>> - removes fds from userspace and breaks backlight functionality. All
> >>>>> - current mainline drivers do not support backlight hotplugging, so most
> >>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
> >>>>> For the Ally, since it disconnects its controller during sleep, this
> >>>>> caused the backlight slider to not work in KDE.
> >>>>>
> >>>>> Changes since V1:
> >>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> >>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
> >>>>> - Restore input arguments to init and keyboard function so they can
> >>>>> be re-used for RGB controls.
> >>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> >>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> >>>>> keyboard rename into it.
> >>>>> - Unregister brightness listener before removing work queue to avoid
> >>>>> a race condition causing corruption
> >>>>> - Remove spurious mutex unlock in asus_brt_event
> >>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> >>>>> relocking the mutex and causing a deadlock when unregistering leds
> >>>>> - Add extra check during unregistering to avoid calling unregister when
> >>>>> no led device is registered.
> >>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> >>>>> the driver to create 4 RGB handlers per device. I also suspect some
> >>>>> extra events sneak through (KDE had the @@@@@@).
> >>>>>
> >>>>> Antheas Kapenekakis (7):
> >>>>> HID: asus: refactor init sequence per spec
> >>>>> HID: asus: prevent binding to all HID devices on ROG
> >>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> >>>>> HID: asus: listen to the asus-wmi brightness device instead of
> >>>>> creating one
> >>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> >>>>> platform/x86: asus-wmi: add keyboard brightness event handler
> >>>>> HID: asus: add support for the asus-wmi brightness handler
> >>>>>
> >>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
> >>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> >>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> >>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
> >>>>>
> >>>>>
> >>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:51 ` Antheas Kapenekakis
@ 2025-10-16 14:32 ` Denis Benato
2025-10-16 14:44 ` Antheas Kapenekakis
0 siblings, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-16 14:32 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, fooqux
On 10/16/25 14:51, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 14:46, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/16/25 14:28, Antheas Kapenekakis wrote:
>>> On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
>>>> On 10/16/25 14:14, Antheas Kapenekakis wrote:
>>>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>>>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>>>> This is a two part series which does the following:
>>>>>>> - Clean-up init sequence
>>>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
>>>>>>> devices have synced brightness controls and the backlight button works
>>>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>>>>>>>
>>>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
>>>>>>> to make this easier to merge.
>>>>>>>
>>>>>>> All comments with these patches had been addressed since V4.
>>>>>> I have loaded this patchset for users of asus-linux project to try out.
>>>>>>
>>>>>> One of them opened a bug report about a kernel bug that happens
>>>>>> consistently when closing the lid of his laptop [1].
>>>>>>
>>>>>> He also sent another piece of kernel log, but didn't specify anything more
>>>>>> about this [2].
>>>>>>
>>>>>> [1] https://pastebin.com/akZx1w10
>>>>>> [2] https://pastebin.com/sKdczPgf
>>>>> Can you provide a link to the bug report? [2] seems unrelated.
>>>> The log in [2] was posted without additional context in the same
>>>> discord message as [1].
>>> Link me the kernel sources. Is it linux-g14 in the AUR?
>> Someone has replicated it on the AUR but it's just an out-of-sync replica.
>>
>> The true source code is here:
>> https://gitlab.com/asus-linux/linux-g14 branch 6.17
> Ok, lets wait for the user to replicate on a stock kernel
>
User said "yes I just confirmed it: it is only on the asus kernel, mainline doesn't have this issue".
With "asus kernel" he is referring to -g14.
I added him in CC.
>>>> I think I will tell the user to open a proper bug report because
>>>> I do agree on the fact that it's looking unrelated.
>>>>> As for [1], it looks like a trace that stems from a sysfs write to
>>>>> brightness stemming from userspace that follows the same chain it
>>>>> would on a stock kernel and times out. Is it present on a stock
>>>>> kernel?
>>>> I have asked more details to the user. The user is not online ATM
>>>> so I will get to you with more details when I can.
>>>>> Ilpo should know more about this, could the spinlock be interfering?
>>>>> My testing on devices that have WMI led controls is a bit limited
>>>>> unfortunately. However, most of our asus users have been happy with
>>>>> this series for around half a year now.
>>>> Unless they have looked to kernel logs they won't be able to tell
>>>> since apparently there are no visible consequences.
>>>>> Antheas
>>>>>
>>>>>>> ---
>>>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
>>>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
>>>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
>>>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
>>>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>>>>>>>
>>>>>>> Changes since V5:
>>>>>>> - It's been a long time
>>>>>>> - Remove addition of RGB as that had some comments I need to work on
>>>>>>> - Remove folio patch (already merged)
>>>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
>>>>>>> without this patch, some old NKEY keyboards might not respond to
>>>>>>> RGB commands according to Luke, but the kernel driver does not do
>>>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
>>>>>>> Windows. If an issue is found, we can re-add it or just remove patches
>>>>>>> 1/2 before merging. However, init could use the cleanup.
>>>>>>>
>>>>>>> Changes since V4:
>>>>>>> - Fix KConfig (reported by kernel robot)
>>>>>>> - Fix Ilpo's nits, if I missed anything lmk
>>>>>>>
>>>>>>> Changes since V3:
>>>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
>>>>>>> that it is not needed for their media keys to function.
>>>>>>> - Cover init in asus-wmi with spinlock as per Hans
>>>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
>>>>>>> in USB Asus keyboards, per Hans.
>>>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
>>>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
>>>>>>> the spin lock (but after the asus reference is set to null)
>>>>>>>
>>>>>>> Changes since V2:
>>>>>>> - Check lazy init succeds in asus-wmi before setting register variable
>>>>>>> - make explicit check in asus_hid_register_listener for listener existing
>>>>>>> to avoid re-init
>>>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
>>>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
>>>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
>>>>>>> all input vendor devices. This includes moving rgb init to probe
>>>>>>> instead of the input_configured callbacks.
>>>>>>> - Remove fan key (during retest it appears to be 0xae that is already
>>>>>>> supported by hid-asus)
>>>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
>>>>>>> - removes fds from userspace and breaks backlight functionality. All
>>>>>>> - current mainline drivers do not support backlight hotplugging, so most
>>>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
>>>>>>> For the Ally, since it disconnects its controller during sleep, this
>>>>>>> caused the backlight slider to not work in KDE.
>>>>>>>
>>>>>>> Changes since V1:
>>>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
>>>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
>>>>>>> - Restore input arguments to init and keyboard function so they can
>>>>>>> be re-used for RGB controls.
>>>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
>>>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
>>>>>>> keyboard rename into it.
>>>>>>> - Unregister brightness listener before removing work queue to avoid
>>>>>>> a race condition causing corruption
>>>>>>> - Remove spurious mutex unlock in asus_brt_event
>>>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
>>>>>>> relocking the mutex and causing a deadlock when unregistering leds
>>>>>>> - Add extra check during unregistering to avoid calling unregister when
>>>>>>> no led device is registered.
>>>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
>>>>>>> the driver to create 4 RGB handlers per device. I also suspect some
>>>>>>> extra events sneak through (KDE had the @@@@@@).
>>>>>>>
>>>>>>> Antheas Kapenekakis (7):
>>>>>>> HID: asus: refactor init sequence per spec
>>>>>>> HID: asus: prevent binding to all HID devices on ROG
>>>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
>>>>>>> HID: asus: listen to the asus-wmi brightness device instead of
>>>>>>> creating one
>>>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
>>>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
>>>>>>> HID: asus: add support for the asus-wmi brightness handler
>>>>>>>
>>>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
>>>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
>>>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
>>>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
>>>>>>>
>>>>>>>
>>>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 14:32 ` Denis Benato
@ 2025-10-16 14:44 ` Antheas Kapenekakis
2025-10-16 14:44 ` Antheas Kapenekakis
2025-10-16 15:16 ` Denis Benato
0 siblings, 2 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 14:44 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, fooqux
On Thu, 16 Oct 2025 at 16:32, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/16/25 14:51, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 14:46, Denis Benato <benato.denis96@gmail.com> wrote:
> >>
> >> On 10/16/25 14:28, Antheas Kapenekakis wrote:
> >>> On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
> >>>> On 10/16/25 14:14, Antheas Kapenekakis wrote:
> >>>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> >>>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>>>>>> This is a two part series which does the following:
> >>>>>>> - Clean-up init sequence
> >>>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
> >>>>>>> devices have synced brightness controls and the backlight button works
> >>>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >>>>>>>
> >>>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
> >>>>>>> to make this easier to merge.
> >>>>>>>
> >>>>>>> All comments with these patches had been addressed since V4.
> >>>>>> I have loaded this patchset for users of asus-linux project to try out.
> >>>>>>
> >>>>>> One of them opened a bug report about a kernel bug that happens
> >>>>>> consistently when closing the lid of his laptop [1].
> >>>>>>
> >>>>>> He also sent another piece of kernel log, but didn't specify anything more
> >>>>>> about this [2].
> >>>>>>
> >>>>>> [1] https://pastebin.com/akZx1w10
> >>>>>> [2] https://pastebin.com/sKdczPgf
> >>>>> Can you provide a link to the bug report? [2] seems unrelated.
> >>>> The log in [2] was posted without additional context in the same
> >>>> discord message as [1].
> >>> Link me the kernel sources. Is it linux-g14 in the AUR?
> >> Someone has replicated it on the AUR but it's just an out-of-sync replica.
> >>
> >> The true source code is here:
> >> https://gitlab.com/asus-linux/linux-g14 branch 6.17
> > Ok, lets wait for the user to replicate on a stock kernel
> >
> User said "yes I just confirmed it: it is only on the asus kernel, mainline doesn't have this issue".
>
> With "asus kernel" he is referring to -g14.
>
> I added him in CC.
If possible, try the bazzite kernel, its linux-bazzite-bin. It has
this series + another older armoury series. If it still happens with
that, we can cut a release with just this series to begin isolating
this issue
Antheas
> >>>> I think I will tell the user to open a proper bug report because
> >>>> I do agree on the fact that it's looking unrelated.
> >>>>> As for [1], it looks like a trace that stems from a sysfs write to
> >>>>> brightness stemming from userspace that follows the same chain it
> >>>>> would on a stock kernel and times out. Is it present on a stock
> >>>>> kernel?
> >>>> I have asked more details to the user. The user is not online ATM
> >>>> so I will get to you with more details when I can.
> >>>>> Ilpo should know more about this, could the spinlock be interfering?
> >>>>> My testing on devices that have WMI led controls is a bit limited
> >>>>> unfortunately. However, most of our asus users have been happy with
> >>>>> this series for around half a year now.
> >>>> Unless they have looked to kernel logs they won't be able to tell
> >>>> since apparently there are no visible consequences.
> >>>>> Antheas
> >>>>>
> >>>>>>> ---
> >>>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> >>>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> >>>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> >>>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> >>>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >>>>>>>
> >>>>>>> Changes since V5:
> >>>>>>> - It's been a long time
> >>>>>>> - Remove addition of RGB as that had some comments I need to work on
> >>>>>>> - Remove folio patch (already merged)
> >>>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
> >>>>>>> without this patch, some old NKEY keyboards might not respond to
> >>>>>>> RGB commands according to Luke, but the kernel driver does not do
> >>>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
> >>>>>>> Windows. If an issue is found, we can re-add it or just remove patches
> >>>>>>> 1/2 before merging. However, init could use the cleanup.
> >>>>>>>
> >>>>>>> Changes since V4:
> >>>>>>> - Fix KConfig (reported by kernel robot)
> >>>>>>> - Fix Ilpo's nits, if I missed anything lmk
> >>>>>>>
> >>>>>>> Changes since V3:
> >>>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> >>>>>>> that it is not needed for their media keys to function.
> >>>>>>> - Cover init in asus-wmi with spinlock as per Hans
> >>>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
> >>>>>>> in USB Asus keyboards, per Hans.
> >>>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> >>>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
> >>>>>>> the spin lock (but after the asus reference is set to null)
> >>>>>>>
> >>>>>>> Changes since V2:
> >>>>>>> - Check lazy init succeds in asus-wmi before setting register variable
> >>>>>>> - make explicit check in asus_hid_register_listener for listener existing
> >>>>>>> to avoid re-init
> >>>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
> >>>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
> >>>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> >>>>>>> all input vendor devices. This includes moving rgb init to probe
> >>>>>>> instead of the input_configured callbacks.
> >>>>>>> - Remove fan key (during retest it appears to be 0xae that is already
> >>>>>>> supported by hid-asus)
> >>>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> >>>>>>> - removes fds from userspace and breaks backlight functionality. All
> >>>>>>> - current mainline drivers do not support backlight hotplugging, so most
> >>>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
> >>>>>>> For the Ally, since it disconnects its controller during sleep, this
> >>>>>>> caused the backlight slider to not work in KDE.
> >>>>>>>
> >>>>>>> Changes since V1:
> >>>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> >>>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
> >>>>>>> - Restore input arguments to init and keyboard function so they can
> >>>>>>> be re-used for RGB controls.
> >>>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> >>>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> >>>>>>> keyboard rename into it.
> >>>>>>> - Unregister brightness listener before removing work queue to avoid
> >>>>>>> a race condition causing corruption
> >>>>>>> - Remove spurious mutex unlock in asus_brt_event
> >>>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> >>>>>>> relocking the mutex and causing a deadlock when unregistering leds
> >>>>>>> - Add extra check during unregistering to avoid calling unregister when
> >>>>>>> no led device is registered.
> >>>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> >>>>>>> the driver to create 4 RGB handlers per device. I also suspect some
> >>>>>>> extra events sneak through (KDE had the @@@@@@).
> >>>>>>>
> >>>>>>> Antheas Kapenekakis (7):
> >>>>>>> HID: asus: refactor init sequence per spec
> >>>>>>> HID: asus: prevent binding to all HID devices on ROG
> >>>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> >>>>>>> HID: asus: listen to the asus-wmi brightness device instead of
> >>>>>>> creating one
> >>>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> >>>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
> >>>>>>> HID: asus: add support for the asus-wmi brightness handler
> >>>>>>>
> >>>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
> >>>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> >>>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> >>>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
> >>>>>>>
> >>>>>>>
> >>>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 14:44 ` Antheas Kapenekakis
@ 2025-10-16 14:44 ` Antheas Kapenekakis
2025-10-16 15:16 ` Denis Benato
1 sibling, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 14:44 UTC (permalink / raw)
To: Denis Benato
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, fooqux
On Thu, 16 Oct 2025 at 16:44, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Thu, 16 Oct 2025 at 16:32, Denis Benato <benato.denis96@gmail.com> wrote:
> >
> >
> > On 10/16/25 14:51, Antheas Kapenekakis wrote:
> > > On Thu, 16 Oct 2025 at 14:46, Denis Benato <benato.denis96@gmail.com> wrote:
> > >>
> > >> On 10/16/25 14:28, Antheas Kapenekakis wrote:
> > >>> On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
> > >>>> On 10/16/25 14:14, Antheas Kapenekakis wrote:
> > >>>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > >>>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > >>>>>>> This is a two part series which does the following:
> > >>>>>>> - Clean-up init sequence
> > >>>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
> > >>>>>>> devices have synced brightness controls and the backlight button works
> > >>>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > >>>>>>>
> > >>>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
> > >>>>>>> to make this easier to merge.
> > >>>>>>>
> > >>>>>>> All comments with these patches had been addressed since V4.
> > >>>>>> I have loaded this patchset for users of asus-linux project to try out.
> > >>>>>>
> > >>>>>> One of them opened a bug report about a kernel bug that happens
> > >>>>>> consistently when closing the lid of his laptop [1].
> > >>>>>>
> > >>>>>> He also sent another piece of kernel log, but didn't specify anything more
> > >>>>>> about this [2].
> > >>>>>>
> > >>>>>> [1] https://pastebin.com/akZx1w10
> > >>>>>> [2] https://pastebin.com/sKdczPgf
> > >>>>> Can you provide a link to the bug report? [2] seems unrelated.
> > >>>> The log in [2] was posted without additional context in the same
> > >>>> discord message as [1].
> > >>> Link me the kernel sources. Is it linux-g14 in the AUR?
> > >> Someone has replicated it on the AUR but it's just an out-of-sync replica.
> > >>
> > >> The true source code is here:
> > >> https://gitlab.com/asus-linux/linux-g14 branch 6.17
> > > Ok, lets wait for the user to replicate on a stock kernel
> > >
> > User said "yes I just confirmed it: it is only on the asus kernel, mainline doesn't have this issue".
> >
> > With "asus kernel" he is referring to -g14.
> >
> > I added him in CC.
>
> If possible, try the bazzite kernel, its linux-bazzite-bin. It has
> this series + another older armoury series. If it still happens with
> that, we can cut a release with just this series to begin isolating
> this issue
>
> Antheas
To that end, using the previous version of that kernel without this
series is also a possibility.
> > >>>> I think I will tell the user to open a proper bug report because
> > >>>> I do agree on the fact that it's looking unrelated.
> > >>>>> As for [1], it looks like a trace that stems from a sysfs write to
> > >>>>> brightness stemming from userspace that follows the same chain it
> > >>>>> would on a stock kernel and times out. Is it present on a stock
> > >>>>> kernel?
> > >>>> I have asked more details to the user. The user is not online ATM
> > >>>> so I will get to you with more details when I can.
> > >>>>> Ilpo should know more about this, could the spinlock be interfering?
> > >>>>> My testing on devices that have WMI led controls is a bit limited
> > >>>>> unfortunately. However, most of our asus users have been happy with
> > >>>>> this series for around half a year now.
> > >>>> Unless they have looked to kernel logs they won't be able to tell
> > >>>> since apparently there are no visible consequences.
> > >>>>> Antheas
> > >>>>>
> > >>>>>>> ---
> > >>>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > >>>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > >>>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > >>>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > >>>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> > >>>>>>>
> > >>>>>>> Changes since V5:
> > >>>>>>> - It's been a long time
> > >>>>>>> - Remove addition of RGB as that had some comments I need to work on
> > >>>>>>> - Remove folio patch (already merged)
> > >>>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
> > >>>>>>> without this patch, some old NKEY keyboards might not respond to
> > >>>>>>> RGB commands according to Luke, but the kernel driver does not do
> > >>>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
> > >>>>>>> Windows. If an issue is found, we can re-add it or just remove patches
> > >>>>>>> 1/2 before merging. However, init could use the cleanup.
> > >>>>>>>
> > >>>>>>> Changes since V4:
> > >>>>>>> - Fix KConfig (reported by kernel robot)
> > >>>>>>> - Fix Ilpo's nits, if I missed anything lmk
> > >>>>>>>
> > >>>>>>> Changes since V3:
> > >>>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > >>>>>>> that it is not needed for their media keys to function.
> > >>>>>>> - Cover init in asus-wmi with spinlock as per Hans
> > >>>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
> > >>>>>>> in USB Asus keyboards, per Hans.
> > >>>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > >>>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
> > >>>>>>> the spin lock (but after the asus reference is set to null)
> > >>>>>>>
> > >>>>>>> Changes since V2:
> > >>>>>>> - Check lazy init succeds in asus-wmi before setting register variable
> > >>>>>>> - make explicit check in asus_hid_register_listener for listener existing
> > >>>>>>> to avoid re-init
> > >>>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
> > >>>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
> > >>>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > >>>>>>> all input vendor devices. This includes moving rgb init to probe
> > >>>>>>> instead of the input_configured callbacks.
> > >>>>>>> - Remove fan key (during retest it appears to be 0xae that is already
> > >>>>>>> supported by hid-asus)
> > >>>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > >>>>>>> - removes fds from userspace and breaks backlight functionality. All
> > >>>>>>> - current mainline drivers do not support backlight hotplugging, so most
> > >>>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
> > >>>>>>> For the Ally, since it disconnects its controller during sleep, this
> > >>>>>>> caused the backlight slider to not work in KDE.
> > >>>>>>>
> > >>>>>>> Changes since V1:
> > >>>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > >>>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
> > >>>>>>> - Restore input arguments to init and keyboard function so they can
> > >>>>>>> be re-used for RGB controls.
> > >>>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > >>>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > >>>>>>> keyboard rename into it.
> > >>>>>>> - Unregister brightness listener before removing work queue to avoid
> > >>>>>>> a race condition causing corruption
> > >>>>>>> - Remove spurious mutex unlock in asus_brt_event
> > >>>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > >>>>>>> relocking the mutex and causing a deadlock when unregistering leds
> > >>>>>>> - Add extra check during unregistering to avoid calling unregister when
> > >>>>>>> no led device is registered.
> > >>>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > >>>>>>> the driver to create 4 RGB handlers per device. I also suspect some
> > >>>>>>> extra events sneak through (KDE had the @@@@@@).
> > >>>>>>>
> > >>>>>>> Antheas Kapenekakis (7):
> > >>>>>>> HID: asus: refactor init sequence per spec
> > >>>>>>> HID: asus: prevent binding to all HID devices on ROG
> > >>>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > >>>>>>> HID: asus: listen to the asus-wmi brightness device instead of
> > >>>>>>> creating one
> > >>>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > >>>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
> > >>>>>>> HID: asus: add support for the asus-wmi brightness handler
> > >>>>>>>
> > >>>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
> > >>>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > >>>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > >>>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> >
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 14:44 ` Antheas Kapenekakis
2025-10-16 14:44 ` Antheas Kapenekakis
@ 2025-10-16 15:16 ` Denis Benato
1 sibling, 0 replies; 45+ messages in thread
From: Denis Benato @ 2025-10-16 15:16 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, linux-kernel, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Ilpo Järvinen, fooqux
On 10/16/25 16:44, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 16:32, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 10/16/25 14:51, Antheas Kapenekakis wrote:
>>> On Thu, 16 Oct 2025 at 14:46, Denis Benato <benato.denis96@gmail.com> wrote:
>>>> On 10/16/25 14:28, Antheas Kapenekakis wrote:
>>>>> On Thu, 16 Oct 2025 at 14:19, Denis Benato <benato.denis96@gmail.com> wrote:
>>>>>> On 10/16/25 14:14, Antheas Kapenekakis wrote:
>>>>>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>>>>>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>>>>>> This is a two part series which does the following:
>>>>>>>>> - Clean-up init sequence
>>>>>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
>>>>>>>>> devices have synced brightness controls and the backlight button works
>>>>>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>>>>>>>>>
>>>>>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
>>>>>>>>> to make this easier to merge.
>>>>>>>>>
>>>>>>>>> All comments with these patches had been addressed since V4.
>>>>>>>> I have loaded this patchset for users of asus-linux project to try out.
>>>>>>>>
>>>>>>>> One of them opened a bug report about a kernel bug that happens
>>>>>>>> consistently when closing the lid of his laptop [1].
>>>>>>>>
>>>>>>>> He also sent another piece of kernel log, but didn't specify anything more
>>>>>>>> about this [2].
>>>>>>>>
>>>>>>>> [1] https://pastebin.com/akZx1w10
>>>>>>>> [2] https://pastebin.com/sKdczPgf
>>>>>>> Can you provide a link to the bug report? [2] seems unrelated.
>>>>>> The log in [2] was posted without additional context in the same
>>>>>> discord message as [1].
>>>>> Link me the kernel sources. Is it linux-g14 in the AUR?
>>>> Someone has replicated it on the AUR but it's just an out-of-sync replica.
>>>>
>>>> The true source code is here:
>>>> https://gitlab.com/asus-linux/linux-g14 branch 6.17
>>> Ok, lets wait for the user to replicate on a stock kernel
>>>
>> User said "yes I just confirmed it: it is only on the asus kernel, mainline doesn't have this issue".
>>
>> With "asus kernel" he is referring to -g14.
>>
>> I added him in CC.
> If possible, try the bazzite kernel, its linux-bazzite-bin. It has
> this series + another older armoury series. If it still happens with
> that, we can cut a release with just this series to begin isolating
> this issue
If deemed necessary I will provide the user a kernel matching exactly
what doesn't give him the error and add to it this patch series.
However the problem does appear to be tied to the use of spinlock,
so perhaps it's better to try a version with some other type of locking.
> Antheas
>
>>>>>> I think I will tell the user to open a proper bug report because
>>>>>> I do agree on the fact that it's looking unrelated.
>>>>>>> As for [1], it looks like a trace that stems from a sysfs write to
>>>>>>> brightness stemming from userspace that follows the same chain it
>>>>>>> would on a stock kernel and times out. Is it present on a stock
>>>>>>> kernel?
>>>>>> I have asked more details to the user. The user is not online ATM
>>>>>> so I will get to you with more details when I can.
>>>>>>> Ilpo should know more about this, could the spinlock be interfering?
>>>>>>> My testing on devices that have WMI led controls is a bit limited
>>>>>>> unfortunately. However, most of our asus users have been happy with
>>>>>>> this series for around half a year now.
>>>>>> Unless they have looked to kernel logs they won't be able to tell
>>>>>> since apparently there are no visible consequences.
>>>>>>> Antheas
>>>>>>>
>>>>>>>>> ---
>>>>>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
>>>>>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
>>>>>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
>>>>>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
>>>>>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>>>>>>>>>
>>>>>>>>> Changes since V5:
>>>>>>>>> - It's been a long time
>>>>>>>>> - Remove addition of RGB as that had some comments I need to work on
>>>>>>>>> - Remove folio patch (already merged)
>>>>>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
>>>>>>>>> without this patch, some old NKEY keyboards might not respond to
>>>>>>>>> RGB commands according to Luke, but the kernel driver does not do
>>>>>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
>>>>>>>>> Windows. If an issue is found, we can re-add it or just remove patches
>>>>>>>>> 1/2 before merging. However, init could use the cleanup.
>>>>>>>>>
>>>>>>>>> Changes since V4:
>>>>>>>>> - Fix KConfig (reported by kernel robot)
>>>>>>>>> - Fix Ilpo's nits, if I missed anything lmk
>>>>>>>>>
>>>>>>>>> Changes since V3:
>>>>>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
>>>>>>>>> that it is not needed for their media keys to function.
>>>>>>>>> - Cover init in asus-wmi with spinlock as per Hans
>>>>>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
>>>>>>>>> in USB Asus keyboards, per Hans.
>>>>>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
>>>>>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
>>>>>>>>> the spin lock (but after the asus reference is set to null)
>>>>>>>>>
>>>>>>>>> Changes since V2:
>>>>>>>>> - Check lazy init succeds in asus-wmi before setting register variable
>>>>>>>>> - make explicit check in asus_hid_register_listener for listener existing
>>>>>>>>> to avoid re-init
>>>>>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
>>>>>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
>>>>>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
>>>>>>>>> all input vendor devices. This includes moving rgb init to probe
>>>>>>>>> instead of the input_configured callbacks.
>>>>>>>>> - Remove fan key (during retest it appears to be 0xae that is already
>>>>>>>>> supported by hid-asus)
>>>>>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
>>>>>>>>> - removes fds from userspace and breaks backlight functionality. All
>>>>>>>>> - current mainline drivers do not support backlight hotplugging, so most
>>>>>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
>>>>>>>>> For the Ally, since it disconnects its controller during sleep, this
>>>>>>>>> caused the backlight slider to not work in KDE.
>>>>>>>>>
>>>>>>>>> Changes since V1:
>>>>>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
>>>>>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
>>>>>>>>> - Restore input arguments to init and keyboard function so they can
>>>>>>>>> be re-used for RGB controls.
>>>>>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
>>>>>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
>>>>>>>>> keyboard rename into it.
>>>>>>>>> - Unregister brightness listener before removing work queue to avoid
>>>>>>>>> a race condition causing corruption
>>>>>>>>> - Remove spurious mutex unlock in asus_brt_event
>>>>>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
>>>>>>>>> relocking the mutex and causing a deadlock when unregistering leds
>>>>>>>>> - Add extra check during unregistering to avoid calling unregister when
>>>>>>>>> no led device is registered.
>>>>>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
>>>>>>>>> the driver to create 4 RGB handlers per device. I also suspect some
>>>>>>>>> extra events sneak through (KDE had the @@@@@@).
>>>>>>>>>
>>>>>>>>> Antheas Kapenekakis (7):
>>>>>>>>> HID: asus: refactor init sequence per spec
>>>>>>>>> HID: asus: prevent binding to all HID devices on ROG
>>>>>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
>>>>>>>>> HID: asus: listen to the asus-wmi brightness device instead of
>>>>>>>>> creating one
>>>>>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
>>>>>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
>>>>>>>>> HID: asus: add support for the asus-wmi brightness handler
>>>>>>>>>
>>>>>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
>>>>>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
>>>>>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
>>>>>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 12:14 ` Antheas Kapenekakis
2025-10-16 12:19 ` Denis Benato
@ 2025-10-16 15:08 ` Ilpo Järvinen
2025-10-16 16:16 ` Antheas Kapenekakis
1 sibling, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-16 15:08 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > This is a two part series which does the following:
> > > - Clean-up init sequence
> > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > devices have synced brightness controls and the backlight button works
> > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > >
> > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > to make this easier to merge.
> > >
> > > All comments with these patches had been addressed since V4.
> > I have loaded this patchset for users of asus-linux project to try out.
> >
> > One of them opened a bug report about a kernel bug that happens
> > consistently when closing the lid of his laptop [1].
> >
> > He also sent another piece of kernel log, but didn't specify anything more
> > about this [2].
> >
> > [1] https://pastebin.com/akZx1w10
> > [2] https://pastebin.com/sKdczPgf
>
> Can you provide a link to the bug report? [2] seems unrelated.
>
> As for [1], it looks like a trace that stems from a sysfs write to
> brightness stemming from userspace that follows the same chain it
> would on a stock kernel and times out. Is it present on a stock
> kernel?
>
> Ilpo should know more about this, could the spinlock be interfering?
[1] certainly seems to do schedule() from do_kbd_led_set() so it's not
possible to use spinlock there.
So we're back to what requires the spinlock? And what the spinlock
protects?
Not related to this particular email in this thread, if the users are
testing something with different kernels, it's also important to make sure
that the lockdep configs are enabled in both. As it could be that in one
kernel lockdep is not enabled and thus it won't do the splat.
--
i.
> My testing on devices that have WMI led controls is a bit limited
> unfortunately. However, most of our asus users have been happy with
> this series for around half a year now.
>
> > > ---
> > > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> > >
> > > Changes since V5:
> > > - It's been a long time
> > > - Remove addition of RGB as that had some comments I need to work on
> > > - Remove folio patch (already merged)
> > > - Remove legacy fix patch 11 from V4. There is a small chance that
> > > without this patch, some old NKEY keyboards might not respond to
> > > RGB commands according to Luke, but the kernel driver does not do
> > > RGB currently. The 0x5d init is done by Armoury crate software in
> > > Windows. If an issue is found, we can re-add it or just remove patches
> > > 1/2 before merging. However, init could use the cleanup.
> > >
> > > Changes since V4:
> > > - Fix KConfig (reported by kernel robot)
> > > - Fix Ilpo's nits, if I missed anything lmk
> > >
> > > Changes since V3:
> > > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > > that it is not needed for their media keys to function.
> > > - Cover init in asus-wmi with spinlock as per Hans
> > > - If asus-wmi registers WMI handler with brightness, init the brightness
> > > in USB Asus keyboards, per Hans.
> > > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > > the spin lock (but after the asus reference is set to null)
> > >
> > > Changes since V2:
> > > - Check lazy init succeds in asus-wmi before setting register variable
> > > - make explicit check in asus_hid_register_listener for listener existing
> > > to avoid re-init
> > > - rename asus_brt to asus_hid in most places and harmonize everything
> > > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > > all input vendor devices. This includes moving rgb init to probe
> > > instead of the input_configured callbacks.
> > > - Remove fan key (during retest it appears to be 0xae that is already
> > > supported by hid-asus)
> > > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > > - removes fds from userspace and breaks backlight functionality. All
> > > - current mainline drivers do not support backlight hotplugging, so most
> > > userspace software (e.g., KDE, UPower) is built with that assumption.
> > > For the Ally, since it disconnects its controller during sleep, this
> > > caused the backlight slider to not work in KDE.
> > >
> > > Changes since V1:
> > > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > > - Restore input arguments to init and keyboard function so they can
> > > be re-used for RGB controls.
> > > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > > keyboard rename into it.
> > > - Unregister brightness listener before removing work queue to avoid
> > > a race condition causing corruption
> > > - Remove spurious mutex unlock in asus_brt_event
> > > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > > relocking the mutex and causing a deadlock when unregistering leds
> > > - Add extra check during unregistering to avoid calling unregister when
> > > no led device is registered.
> > > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > > the driver to create 4 RGB handlers per device. I also suspect some
> > > extra events sneak through (KDE had the @@@@@@).
> > >
> > > Antheas Kapenekakis (7):
> > > HID: asus: refactor init sequence per spec
> > > HID: asus: prevent binding to all HID devices on ROG
> > > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > > HID: asus: listen to the asus-wmi brightness device instead of
> > > creating one
> > > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > > platform/x86: asus-wmi: add keyboard brightness event handler
> > > HID: asus: add support for the asus-wmi brightness handler
> > >
> > > drivers/hid/hid-asus.c | 235 +++++++++++----------
> > > drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > > include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > > 3 files changed, 291 insertions(+), 170 deletions(-)
> > >
> > >
> > > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> >
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 15:08 ` Ilpo Järvinen
@ 2025-10-16 16:16 ` Antheas Kapenekakis
2025-10-17 7:54 ` Antheas Kapenekakis
2025-10-17 10:36 ` Ilpo Järvinen
0 siblings, 2 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-16 16:16 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > > This is a two part series which does the following:
> > > > - Clean-up init sequence
> > > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > > devices have synced brightness controls and the backlight button works
> > > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > > >
> > > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > > to make this easier to merge.
> > > >
> > > > All comments with these patches had been addressed since V4.
> > > I have loaded this patchset for users of asus-linux project to try out.
> > >
> > > One of them opened a bug report about a kernel bug that happens
> > > consistently when closing the lid of his laptop [1].
> > >
> > > He also sent another piece of kernel log, but didn't specify anything more
> > > about this [2].
> > >
> > > [1] https://pastebin.com/akZx1w10
> > > [2] https://pastebin.com/sKdczPgf
> >
> > Can you provide a link to the bug report? [2] seems unrelated.
> >
> > As for [1], it looks like a trace that stems from a sysfs write to
> > brightness stemming from userspace that follows the same chain it
> > would on a stock kernel and times out. Is it present on a stock
> > kernel?
> >
> > Ilpo should know more about this, could the spinlock be interfering?
>
> [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> possible to use spinlock there.
>
> So we're back to what requires the spinlock? And what the spinlock
> protects?
For that invocation, since it is coming from the cdev device owned by
asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
asus_wmi is protected by the fact it is owned by that device. Spinlock
is not required in this invocation due to not being an IRQ.
Under asus_hid_event (second to last patch), which is called from an
IRQ, a spinlock is required for protecting both listeners and the
asus_ref.asus, and I suspect that scheduling from an IRQ is not
allowed either. Is that correct?
Antheas
>
> Not related to this particular email in this thread, if the users are
> testing something with different kernels, it's also important to make sure
> that the lockdep configs are enabled in both. As it could be that in one
> kernel lockdep is not enabled and thus it won't do the splat.
>
> --
> i.
>
>
> > My testing on devices that have WMI led controls is a bit limited
> > unfortunately. However, most of our asus users have been happy with
> > this series for around half a year now.
> >
> > > > ---
> > > > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > > > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > > > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > > > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > > > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> > > >
> > > > Changes since V5:
> > > > - It's been a long time
> > > > - Remove addition of RGB as that had some comments I need to work on
> > > > - Remove folio patch (already merged)
> > > > - Remove legacy fix patch 11 from V4. There is a small chance that
> > > > without this patch, some old NKEY keyboards might not respond to
> > > > RGB commands according to Luke, but the kernel driver does not do
> > > > RGB currently. The 0x5d init is done by Armoury crate software in
> > > > Windows. If an issue is found, we can re-add it or just remove patches
> > > > 1/2 before merging. However, init could use the cleanup.
> > > >
> > > > Changes since V4:
> > > > - Fix KConfig (reported by kernel robot)
> > > > - Fix Ilpo's nits, if I missed anything lmk
> > > >
> > > > Changes since V3:
> > > > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > > > that it is not needed for their media keys to function.
> > > > - Cover init in asus-wmi with spinlock as per Hans
> > > > - If asus-wmi registers WMI handler with brightness, init the brightness
> > > > in USB Asus keyboards, per Hans.
> > > > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > > > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > > > the spin lock (but after the asus reference is set to null)
> > > >
> > > > Changes since V2:
> > > > - Check lazy init succeds in asus-wmi before setting register variable
> > > > - make explicit check in asus_hid_register_listener for listener existing
> > > > to avoid re-init
> > > > - rename asus_brt to asus_hid in most places and harmonize everything
> > > > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > > > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > > > all input vendor devices. This includes moving rgb init to probe
> > > > instead of the input_configured callbacks.
> > > > - Remove fan key (during retest it appears to be 0xae that is already
> > > > supported by hid-asus)
> > > > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > > > - removes fds from userspace and breaks backlight functionality. All
> > > > - current mainline drivers do not support backlight hotplugging, so most
> > > > userspace software (e.g., KDE, UPower) is built with that assumption.
> > > > For the Ally, since it disconnects its controller during sleep, this
> > > > caused the backlight slider to not work in KDE.
> > > >
> > > > Changes since V1:
> > > > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > > > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > > > - Restore input arguments to init and keyboard function so they can
> > > > be re-used for RGB controls.
> > > > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > > > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > > > keyboard rename into it.
> > > > - Unregister brightness listener before removing work queue to avoid
> > > > a race condition causing corruption
> > > > - Remove spurious mutex unlock in asus_brt_event
> > > > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > > > relocking the mutex and causing a deadlock when unregistering leds
> > > > - Add extra check during unregistering to avoid calling unregister when
> > > > no led device is registered.
> > > > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > > > the driver to create 4 RGB handlers per device. I also suspect some
> > > > extra events sneak through (KDE had the @@@@@@).
> > > >
> > > > Antheas Kapenekakis (7):
> > > > HID: asus: refactor init sequence per spec
> > > > HID: asus: prevent binding to all HID devices on ROG
> > > > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > > > HID: asus: listen to the asus-wmi brightness device instead of
> > > > creating one
> > > > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > > > platform/x86: asus-wmi: add keyboard brightness event handler
> > > > HID: asus: add support for the asus-wmi brightness handler
> > > >
> > > > drivers/hid/hid-asus.c | 235 +++++++++++----------
> > > > drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > > > include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > > > 3 files changed, 291 insertions(+), 170 deletions(-)
> > > >
> > > >
> > > > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> > >
> >
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 16:16 ` Antheas Kapenekakis
@ 2025-10-17 7:54 ` Antheas Kapenekakis
2025-10-17 11:00 ` Denis Benato
2025-10-20 17:13 ` Ilpo Järvinen
2025-10-17 10:36 ` Ilpo Järvinen
1 sibling, 2 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-17 7:54 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
On Thu, 16 Oct 2025 at 18:16, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> > > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > > > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > > > This is a two part series which does the following:
> > > > > - Clean-up init sequence
> > > > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > > > devices have synced brightness controls and the backlight button works
> > > > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > > > >
> > > > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > > > to make this easier to merge.
> > > > >
> > > > > All comments with these patches had been addressed since V4.
> > > > I have loaded this patchset for users of asus-linux project to try out.
> > > >
> > > > One of them opened a bug report about a kernel bug that happens
> > > > consistently when closing the lid of his laptop [1].
> > > >
> > > > He also sent another piece of kernel log, but didn't specify anything more
> > > > about this [2].
> > > >
> > > > [1] https://pastebin.com/akZx1w10
> > > > [2] https://pastebin.com/sKdczPgf
> > >
> > > Can you provide a link to the bug report? [2] seems unrelated.
> > >
> > > As for [1], it looks like a trace that stems from a sysfs write to
> > > brightness stemming from userspace that follows the same chain it
> > > would on a stock kernel and times out. Is it present on a stock
> > > kernel?
> > >
> > > Ilpo should know more about this, could the spinlock be interfering?
> >
> > [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> > possible to use spinlock there.
> >
> > So we're back to what requires the spinlock? And what the spinlock
> > protects?
>
> For that invocation, since it is coming from the cdev device owned by
> asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
> asus_wmi is protected by the fact it is owned by that device. Spinlock
> is not required in this invocation due to not being an IRQ.
>
> Under asus_hid_event (second to last patch), which is called from an
> IRQ, a spinlock is required for protecting both listeners and the
> asus_ref.asus, and I suspect that scheduling from an IRQ is not
> allowed either. Is that correct?
So it is a bit tricky here. When the IRQ fires, it needs to know
whether asus-wmi will handle the keyboard brightness event so that it
falls back to emitting it.
If we want it to know for sure, it needs to access asus_wmi, so it
needs a spinlock or an IRQ friendly lock. This way, currently,
asus_hid_event will return -EBUSY if there is no led device so the
event propagates through hid.
If we say that it is good enough to know that it was compiled with
IS_REACHABLE(CONFIG_ASUS_WMI), ie the actual implementation of
asus_hid_event in asus-wmi will never return an error, then,
asus_hid_event can schedule a task to fire the event without a lock,
and that task can use a normal locking primitive.
If the task needs to be assigned to a device or have a handle,
asus_hid_listener can be provided to asus_hid_event, so that it is
owned by the calling device.
What would the appropriate locking primitive be in this case?
> Antheas
> >
> > Not related to this particular email in this thread, if the users are
> > testing something with different kernels, it's also important to make sure
> > that the lockdep configs are enabled in both. As it could be that in one
> > kernel lockdep is not enabled and thus it won't do the splat.
> >
> > --
> > i.
> >
> >
> > > My testing on devices that have WMI led controls is a bit limited
> > > unfortunately. However, most of our asus users have been happy with
> > > this series for around half a year now.
> > >
> > > > > ---
> > > > > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > > > > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > > > > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > > > > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > > > > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> > > > >
> > > > > Changes since V5:
> > > > > - It's been a long time
> > > > > - Remove addition of RGB as that had some comments I need to work on
> > > > > - Remove folio patch (already merged)
> > > > > - Remove legacy fix patch 11 from V4. There is a small chance that
> > > > > without this patch, some old NKEY keyboards might not respond to
> > > > > RGB commands according to Luke, but the kernel driver does not do
> > > > > RGB currently. The 0x5d init is done by Armoury crate software in
> > > > > Windows. If an issue is found, we can re-add it or just remove patches
> > > > > 1/2 before merging. However, init could use the cleanup.
> > > > >
> > > > > Changes since V4:
> > > > > - Fix KConfig (reported by kernel robot)
> > > > > - Fix Ilpo's nits, if I missed anything lmk
> > > > >
> > > > > Changes since V3:
> > > > > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > > > > that it is not needed for their media keys to function.
> > > > > - Cover init in asus-wmi with spinlock as per Hans
> > > > > - If asus-wmi registers WMI handler with brightness, init the brightness
> > > > > in USB Asus keyboards, per Hans.
> > > > > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > > > > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > > > > the spin lock (but after the asus reference is set to null)
> > > > >
> > > > > Changes since V2:
> > > > > - Check lazy init succeds in asus-wmi before setting register variable
> > > > > - make explicit check in asus_hid_register_listener for listener existing
> > > > > to avoid re-init
> > > > > - rename asus_brt to asus_hid in most places and harmonize everything
> > > > > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > > > > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > > > > all input vendor devices. This includes moving rgb init to probe
> > > > > instead of the input_configured callbacks.
> > > > > - Remove fan key (during retest it appears to be 0xae that is already
> > > > > supported by hid-asus)
> > > > > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > > > > - removes fds from userspace and breaks backlight functionality. All
> > > > > - current mainline drivers do not support backlight hotplugging, so most
> > > > > userspace software (e.g., KDE, UPower) is built with that assumption.
> > > > > For the Ally, since it disconnects its controller during sleep, this
> > > > > caused the backlight slider to not work in KDE.
> > > > >
> > > > > Changes since V1:
> > > > > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > > > > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > > > > - Restore input arguments to init and keyboard function so they can
> > > > > be re-used for RGB controls.
> > > > > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > > > > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > > > > keyboard rename into it.
> > > > > - Unregister brightness listener before removing work queue to avoid
> > > > > a race condition causing corruption
> > > > > - Remove spurious mutex unlock in asus_brt_event
> > > > > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > > > > relocking the mutex and causing a deadlock when unregistering leds
> > > > > - Add extra check during unregistering to avoid calling unregister when
> > > > > no led device is registered.
> > > > > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > > > > the driver to create 4 RGB handlers per device. I also suspect some
> > > > > extra events sneak through (KDE had the @@@@@@).
> > > > >
> > > > > Antheas Kapenekakis (7):
> > > > > HID: asus: refactor init sequence per spec
> > > > > HID: asus: prevent binding to all HID devices on ROG
> > > > > platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> > > > > HID: asus: listen to the asus-wmi brightness device instead of
> > > > > creating one
> > > > > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > > > > platform/x86: asus-wmi: add keyboard brightness event handler
> > > > > HID: asus: add support for the asus-wmi brightness handler
> > > > >
> > > > > drivers/hid/hid-asus.c | 235 +++++++++++----------
> > > > > drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> > > > > include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> > > > > 3 files changed, 291 insertions(+), 170 deletions(-)
> > > > >
> > > > >
> > > > > base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> > > >
> > >
> >
> >
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-17 7:54 ` Antheas Kapenekakis
@ 2025-10-17 11:00 ` Denis Benato
2025-10-17 11:21 ` Antheas Kapenekakis
2025-10-20 17:13 ` Ilpo Järvinen
1 sibling, 1 reply; 45+ messages in thread
From: Denis Benato @ 2025-10-17 11:00 UTC (permalink / raw)
To: Antheas Kapenekakis, Ilpo Järvinen
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
On 10/17/25 09:54, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 18:16, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>> On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
>> <ilpo.jarvinen@linux.intel.com> wrote:
>>> On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
>>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
>>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
>>>>>> This is a two part series which does the following:
>>>>>> - Clean-up init sequence
>>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
>>>>>> devices have synced brightness controls and the backlight button works
>>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>>>>>>
>>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
>>>>>> to make this easier to merge.
>>>>>>
>>>>>> All comments with these patches had been addressed since V4.
>>>>> I have loaded this patchset for users of asus-linux project to try out.
>>>>>
>>>>> One of them opened a bug report about a kernel bug that happens
>>>>> consistently when closing the lid of his laptop [1].
>>>>>
>>>>> He also sent another piece of kernel log, but didn't specify anything more
>>>>> about this [2].
>>>>>
>>>>> [1] https://pastebin.com/akZx1w10
>>>>> [2] https://pastebin.com/sKdczPgf
>>>> Can you provide a link to the bug report? [2] seems unrelated.
>>>>
>>>> As for [1], it looks like a trace that stems from a sysfs write to
>>>> brightness stemming from userspace that follows the same chain it
>>>> would on a stock kernel and times out. Is it present on a stock
>>>> kernel?
>>>>
>>>> Ilpo should know more about this, could the spinlock be interfering?
>>> [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
>>> possible to use spinlock there.
>>>
>>> So we're back to what requires the spinlock? And what the spinlock
>>> protects?
>> For that invocation, since it is coming from the cdev device owned by
>> asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
>> asus_wmi is protected by the fact it is owned by that device. Spinlock
>> is not required in this invocation due to not being an IRQ.
>>
>> Under asus_hid_event (second to last patch), which is called from an
>> IRQ, a spinlock is required for protecting both listeners and the
>> asus_ref.asus, and I suspect that scheduling from an IRQ is not
>> allowed either. Is that correct?
> So it is a bit tricky here. When the IRQ fires, it needs to know
> whether asus-wmi will handle the keyboard brightness event so that it
> falls back to emitting it.
>
> If we want it to know for sure, it needs to access asus_wmi, so it
> needs a spinlock or an IRQ friendly lock. This way, currently,
> asus_hid_event will return -EBUSY if there is no led device so the
> event propagates through hid.
>
> If we say that it is good enough to know that it was compiled with
> IS_REACHABLE(CONFIG_ASUS_WMI), ie the actual implementation of
> asus_hid_event in asus-wmi will never return an error, then,
> asus_hid_event can schedule a task to fire the event without a lock,
> and that task can use a normal locking primitive.
>
> If the task needs to be assigned to a device or have a handle,
> asus_hid_listener can be provided to asus_hid_event, so that it is
> owned by the calling device.
>
> What would the appropriate locking primitive be in this case?
The right place to look into appears to be Documentation/kernel-hacking/locking.rst
I see mutex being used in various irq handlers, even bmi323-imu but that page has
many alternatives for irq.
There is rwlock_t but it appears to be using spinlock on certain configurations.
Absolute worst-case scenario you might resort implementing an rwlock with mutexes only.
I would avoid taking decisions based solely on the configuration because ASUS
makes keyboards and reuses designs across various products, so it is very likely
at least one model of those keyboards can be confused with a laptop one.
Beside I am sure there must be at the very least one appropriate synchronization primitive,
so I would discard the configure option.
>> Antheas
>>> Not related to this particular email in this thread, if the users are
>>> testing something with different kernels, it's also important to make sure
>>> that the lockdep configs are enabled in both. As it could be that in one
>>> kernel lockdep is not enabled and thus it won't do the splat.
>>>
>>> --
>>> i.
>>>
>>>
>>>> My testing on devices that have WMI led controls is a bit limited
>>>> unfortunately. However, most of our asus users have been happy with
>>>> this series for around half a year now.
>>>>
>>>>>> ---
>>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
>>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
>>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
>>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
>>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>>>>>>
>>>>>> Changes since V5:
>>>>>> - It's been a long time
>>>>>> - Remove addition of RGB as that had some comments I need to work on
>>>>>> - Remove folio patch (already merged)
>>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
>>>>>> without this patch, some old NKEY keyboards might not respond to
>>>>>> RGB commands according to Luke, but the kernel driver does not do
>>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
>>>>>> Windows. If an issue is found, we can re-add it or just remove patches
>>>>>> 1/2 before merging. However, init could use the cleanup.
>>>>>>
>>>>>> Changes since V4:
>>>>>> - Fix KConfig (reported by kernel robot)
>>>>>> - Fix Ilpo's nits, if I missed anything lmk
>>>>>>
>>>>>> Changes since V3:
>>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
>>>>>> that it is not needed for their media keys to function.
>>>>>> - Cover init in asus-wmi with spinlock as per Hans
>>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
>>>>>> in USB Asus keyboards, per Hans.
>>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
>>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
>>>>>> the spin lock (but after the asus reference is set to null)
>>>>>>
>>>>>> Changes since V2:
>>>>>> - Check lazy init succeds in asus-wmi before setting register variable
>>>>>> - make explicit check in asus_hid_register_listener for listener existing
>>>>>> to avoid re-init
>>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
>>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
>>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
>>>>>> all input vendor devices. This includes moving rgb init to probe
>>>>>> instead of the input_configured callbacks.
>>>>>> - Remove fan key (during retest it appears to be 0xae that is already
>>>>>> supported by hid-asus)
>>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
>>>>>> - removes fds from userspace and breaks backlight functionality. All
>>>>>> - current mainline drivers do not support backlight hotplugging, so most
>>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
>>>>>> For the Ally, since it disconnects its controller during sleep, this
>>>>>> caused the backlight slider to not work in KDE.
>>>>>>
>>>>>> Changes since V1:
>>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
>>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
>>>>>> - Restore input arguments to init and keyboard function so they can
>>>>>> be re-used for RGB controls.
>>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
>>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
>>>>>> keyboard rename into it.
>>>>>> - Unregister brightness listener before removing work queue to avoid
>>>>>> a race condition causing corruption
>>>>>> - Remove spurious mutex unlock in asus_brt_event
>>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
>>>>>> relocking the mutex and causing a deadlock when unregistering leds
>>>>>> - Add extra check during unregistering to avoid calling unregister when
>>>>>> no led device is registered.
>>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
>>>>>> the driver to create 4 RGB handlers per device. I also suspect some
>>>>>> extra events sneak through (KDE had the @@@@@@).
>>>>>>
>>>>>> Antheas Kapenekakis (7):
>>>>>> HID: asus: refactor init sequence per spec
>>>>>> HID: asus: prevent binding to all HID devices on ROG
>>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
>>>>>> HID: asus: listen to the asus-wmi brightness device instead of
>>>>>> creating one
>>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
>>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
>>>>>> HID: asus: add support for the asus-wmi brightness handler
>>>>>>
>>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
>>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
>>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
>>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
>>>>>>
>>>>>>
>>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
>>>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-17 11:00 ` Denis Benato
@ 2025-10-17 11:21 ` Antheas Kapenekakis
0 siblings, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-17 11:21 UTC (permalink / raw)
To: Denis Benato
Cc: Ilpo Järvinen, platform-driver-x86, linux-input, LKML,
Jiri Kosina, Benjamin Tissoires, Corentin Chary, Luke D . Jones,
Hans de Goede
On Fri, 17 Oct 2025 at 13:00, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 10/17/25 09:54, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 18:16, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >> On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
> >> <ilpo.jarvinen@linux.intel.com> wrote:
> >>> On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> >>>> On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> >>>>> On 10/13/25 22:15, Antheas Kapenekakis wrote:
> >>>>>> This is a two part series which does the following:
> >>>>>> - Clean-up init sequence
> >>>>>> - Unify backlight handling to happen under asus-wmi so that all Aura
> >>>>>> devices have synced brightness controls and the backlight button works
> >>>>>> properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >>>>>>
> >>>>>> For more context, see cover letter of V1. Since V5, I removed some patches
> >>>>>> to make this easier to merge.
> >>>>>>
> >>>>>> All comments with these patches had been addressed since V4.
> >>>>> I have loaded this patchset for users of asus-linux project to try out.
> >>>>>
> >>>>> One of them opened a bug report about a kernel bug that happens
> >>>>> consistently when closing the lid of his laptop [1].
> >>>>>
> >>>>> He also sent another piece of kernel log, but didn't specify anything more
> >>>>> about this [2].
> >>>>>
> >>>>> [1] https://pastebin.com/akZx1w10
> >>>>> [2] https://pastebin.com/sKdczPgf
> >>>> Can you provide a link to the bug report? [2] seems unrelated.
> >>>>
> >>>> As for [1], it looks like a trace that stems from a sysfs write to
> >>>> brightness stemming from userspace that follows the same chain it
> >>>> would on a stock kernel and times out. Is it present on a stock
> >>>> kernel?
> >>>>
> >>>> Ilpo should know more about this, could the spinlock be interfering?
> >>> [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> >>> possible to use spinlock there.
> >>>
> >>> So we're back to what requires the spinlock? And what the spinlock
> >>> protects?
> >> For that invocation, since it is coming from the cdev device owned by
> >> asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
> >> asus_wmi is protected by the fact it is owned by that device. Spinlock
> >> is not required in this invocation due to not being an IRQ.
> >>
> >> Under asus_hid_event (second to last patch), which is called from an
> >> IRQ, a spinlock is required for protecting both listeners and the
> >> asus_ref.asus, and I suspect that scheduling from an IRQ is not
> >> allowed either. Is that correct?
> > So it is a bit tricky here. When the IRQ fires, it needs to know
> > whether asus-wmi will handle the keyboard brightness event so that it
> > falls back to emitting it.
> >
> > If we want it to know for sure, it needs to access asus_wmi, so it
> > needs a spinlock or an IRQ friendly lock. This way, currently,
> > asus_hid_event will return -EBUSY if there is no led device so the
> > event propagates through hid.
> >
> > If we say that it is good enough to know that it was compiled with
> > IS_REACHABLE(CONFIG_ASUS_WMI), ie the actual implementation of
> > asus_hid_event in asus-wmi will never return an error, then,
> > asus_hid_event can schedule a task to fire the event without a lock,
> > and that task can use a normal locking primitive.
> >
> > If the task needs to be assigned to a device or have a handle,
> > asus_hid_listener can be provided to asus_hid_event, so that it is
> > owned by the calling device.
> >
> > What would the appropriate locking primitive be in this case?
> The right place to look into appears to be Documentation/kernel-hacking/locking.rst
>
> I see mutex being used in various irq handlers, even bmi323-imu but that page has
> many alternatives for irq.
>
> There is rwlock_t but it appears to be using spinlock on certain configurations.
>
> Absolute worst-case scenario you might resort implementing an rwlock with mutexes only.
>
> I would avoid taking decisions based solely on the configuration because ASUS
> makes keyboards and reuses designs across various products, so it is very likely
> at least one model of those keyboards can be confused with a laptop one.
>
> Beside I am sure there must be at the very least one appropriate synchronization primitive,
> so I would discard the configure option.
The bug is not due to the spinlock. Its due to accessing WMI through
an IRQ. A work queue should be used. Using a spinlock is a result of
that omission.
asus-wmi already has workqueues for the other leds but not for the
keyboard one so we can add one.
If we want the IRQ that handles brightness events through
asus_hid_event to know whether a brightness handler is registered
before choosing whether to forward the event, then we will need to use
a spinlock. Since the spinlock protects objects that are setup during
asus-wmi init and removal, this spinlock needs to be in asus-wmi since
hid-asus has a child relationship.
Now, if we assume that hid-asus should be able to handle cases where
asus-wmi is not loaded with proper brightness control and in parallel
support cases where asus-wmi is loaded in a unified manner, then
that's a different class of problem because a device needs to own the
led handler and currently that would be the platform device.
> >> Antheas
> >>> Not related to this particular email in this thread, if the users are
> >>> testing something with different kernels, it's also important to make sure
> >>> that the lockdep configs are enabled in both. As it could be that in one
> >>> kernel lockdep is not enabled and thus it won't do the splat.
> >>>
> >>> --
> >>> i.
> >>>
> >>>
> >>>> My testing on devices that have WMI led controls is a bit limited
> >>>> unfortunately. However, most of our asus users have been happy with
> >>>> this series for around half a year now.
> >>>>
> >>>>>> ---
> >>>>>> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> >>>>>> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> >>>>>> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> >>>>>> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> >>>>>> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >>>>>>
> >>>>>> Changes since V5:
> >>>>>> - It's been a long time
> >>>>>> - Remove addition of RGB as that had some comments I need to work on
> >>>>>> - Remove folio patch (already merged)
> >>>>>> - Remove legacy fix patch 11 from V4. There is a small chance that
> >>>>>> without this patch, some old NKEY keyboards might not respond to
> >>>>>> RGB commands according to Luke, but the kernel driver does not do
> >>>>>> RGB currently. The 0x5d init is done by Armoury crate software in
> >>>>>> Windows. If an issue is found, we can re-add it or just remove patches
> >>>>>> 1/2 before merging. However, init could use the cleanup.
> >>>>>>
> >>>>>> Changes since V4:
> >>>>>> - Fix KConfig (reported by kernel robot)
> >>>>>> - Fix Ilpo's nits, if I missed anything lmk
> >>>>>>
> >>>>>> Changes since V3:
> >>>>>> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> >>>>>> that it is not needed for their media keys to function.
> >>>>>> - Cover init in asus-wmi with spinlock as per Hans
> >>>>>> - If asus-wmi registers WMI handler with brightness, init the brightness
> >>>>>> in USB Asus keyboards, per Hans.
> >>>>>> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> >>>>>> - Fix oops when unregistering asus-wmi by moving unregister outside of
> >>>>>> the spin lock (but after the asus reference is set to null)
> >>>>>>
> >>>>>> Changes since V2:
> >>>>>> - Check lazy init succeds in asus-wmi before setting register variable
> >>>>>> - make explicit check in asus_hid_register_listener for listener existing
> >>>>>> to avoid re-init
> >>>>>> - rename asus_brt to asus_hid in most places and harmonize everything
> >>>>>> - switch to a spinlock instead of a mutex to avoid kernel ooops
> >>>>>> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> >>>>>> all input vendor devices. This includes moving rgb init to probe
> >>>>>> instead of the input_configured callbacks.
> >>>>>> - Remove fan key (during retest it appears to be 0xae that is already
> >>>>>> supported by hid-asus)
> >>>>>> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> >>>>>> - removes fds from userspace and breaks backlight functionality. All
> >>>>>> - current mainline drivers do not support backlight hotplugging, so most
> >>>>>> userspace software (e.g., KDE, UPower) is built with that assumption.
> >>>>>> For the Ally, since it disconnects its controller during sleep, this
> >>>>>> caused the backlight slider to not work in KDE.
> >>>>>>
> >>>>>> Changes since V1:
> >>>>>> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> >>>>>> - Fix ifdef else having an invalid signature (reported by kernel robot)
> >>>>>> - Restore input arguments to init and keyboard function so they can
> >>>>>> be re-used for RGB controls.
> >>>>>> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> >>>>>> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> >>>>>> keyboard rename into it.
> >>>>>> - Unregister brightness listener before removing work queue to avoid
> >>>>>> a race condition causing corruption
> >>>>>> - Remove spurious mutex unlock in asus_brt_event
> >>>>>> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> >>>>>> relocking the mutex and causing a deadlock when unregistering leds
> >>>>>> - Add extra check during unregistering to avoid calling unregister when
> >>>>>> no led device is registered.
> >>>>>> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> >>>>>> the driver to create 4 RGB handlers per device. I also suspect some
> >>>>>> extra events sneak through (KDE had the @@@@@@).
> >>>>>>
> >>>>>> Antheas Kapenekakis (7):
> >>>>>> HID: asus: refactor init sequence per spec
> >>>>>> HID: asus: prevent binding to all HID devices on ROG
> >>>>>> platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
> >>>>>> HID: asus: listen to the asus-wmi brightness device instead of
> >>>>>> creating one
> >>>>>> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> >>>>>> platform/x86: asus-wmi: add keyboard brightness event handler
> >>>>>> HID: asus: add support for the asus-wmi brightness handler
> >>>>>>
> >>>>>> drivers/hid/hid-asus.c | 235 +++++++++++----------
> >>>>>> drivers/platform/x86/asus-wmi.c | 157 ++++++++++++--
> >>>>>> include/linux/platform_data/x86/asus-wmi.h | 69 +++---
> >>>>>> 3 files changed, 291 insertions(+), 170 deletions(-)
> >>>>>>
> >>>>>>
> >>>>>> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> >>>
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-17 7:54 ` Antheas Kapenekakis
2025-10-17 11:00 ` Denis Benato
@ 2025-10-20 17:13 ` Ilpo Järvinen
2025-10-20 18:54 ` Antheas Kapenekakis
1 sibling, 1 reply; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-20 17:13 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]
On Fri, 17 Oct 2025, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 18:16, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > >
> > > On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> > > > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > > > > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > > > > This is a two part series which does the following:
> > > > > > - Clean-up init sequence
> > > > > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > > > > devices have synced brightness controls and the backlight button works
> > > > > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > > > > >
> > > > > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > > > > to make this easier to merge.
> > > > > >
> > > > > > All comments with these patches had been addressed since V4.
> > > > > I have loaded this patchset for users of asus-linux project to try out.
> > > > >
> > > > > One of them opened a bug report about a kernel bug that happens
> > > > > consistently when closing the lid of his laptop [1].
> > > > >
> > > > > He also sent another piece of kernel log, but didn't specify anything more
> > > > > about this [2].
> > > > >
> > > > > [1] https://pastebin.com/akZx1w10
> > > > > [2] https://pastebin.com/sKdczPgf
> > > >
> > > > Can you provide a link to the bug report? [2] seems unrelated.
> > > >
> > > > As for [1], it looks like a trace that stems from a sysfs write to
> > > > brightness stemming from userspace that follows the same chain it
> > > > would on a stock kernel and times out. Is it present on a stock
> > > > kernel?
> > > >
> > > > Ilpo should know more about this, could the spinlock be interfering?
> > >
> > > [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> > > possible to use spinlock there.
> > >
> > > So we're back to what requires the spinlock? And what the spinlock
> > > protects?
> >
> > For that invocation, since it is coming from the cdev device owned by
> > asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
> > asus_wmi is protected by the fact it is owned by that device. Spinlock
> > is not required in this invocation due to not being an IRQ.
> >
> > Under asus_hid_event (second to last patch), which is called from an
> > IRQ, a spinlock is required for protecting both listeners and the
> > asus_ref.asus, and I suspect that scheduling from an IRQ is not
> > allowed either. Is that correct?
>
> So it is a bit tricky here. When the IRQ fires, it needs to know
> whether asus-wmi will handle the keyboard brightness event so that it
> falls back to emitting it.
>
> If we want it to know for sure, it needs to access asus_wmi, so it
> needs a spinlock or an IRQ friendly lock. This way, currently,
> asus_hid_event will return -EBUSY if there is no led device so the
> event propagates through hid.
>
> If we say that it is good enough to know that it was compiled with
> IS_REACHABLE(CONFIG_ASUS_WMI), ie the actual implementation of
> asus_hid_event in asus-wmi will never return an error, then,
> asus_hid_event can schedule a task to fire the event without a lock,
> and that task can use a normal locking primitive.
>
> If the task needs to be assigned to a device or have a handle,
> asus_hid_listener can be provided to asus_hid_event, so that it is
> owned by the calling device.
>
> What would the appropriate locking primitive be in this case?
If you can move the non-check content out of asus_hid_event(), then you
can nest mutex & spinlock for updating asus_ref. On reader side,
asus_hid_event() only takes the spinlock and the rest of the readers
(non-irq ones) can take just the mutex.
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-20 17:13 ` Ilpo Järvinen
@ 2025-10-20 18:54 ` Antheas Kapenekakis
0 siblings, 0 replies; 45+ messages in thread
From: Antheas Kapenekakis @ 2025-10-20 18:54 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
On Mon, 20 Oct 2025 at 19:13, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Fri, 17 Oct 2025, Antheas Kapenekakis wrote:
> > On Thu, 16 Oct 2025 at 18:16, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > >
> > > On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > >
> > > > On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> > > > > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > > > > > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > > > > > This is a two part series which does the following:
> > > > > > > - Clean-up init sequence
> > > > > > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > > > > > devices have synced brightness controls and the backlight button works
> > > > > > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > > > > > >
> > > > > > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > > > > > to make this easier to merge.
> > > > > > >
> > > > > > > All comments with these patches had been addressed since V4.
> > > > > > I have loaded this patchset for users of asus-linux project to try out.
> > > > > >
> > > > > > One of them opened a bug report about a kernel bug that happens
> > > > > > consistently when closing the lid of his laptop [1].
> > > > > >
> > > > > > He also sent another piece of kernel log, but didn't specify anything more
> > > > > > about this [2].
> > > > > >
> > > > > > [1] https://pastebin.com/akZx1w10
> > > > > > [2] https://pastebin.com/sKdczPgf
> > > > >
> > > > > Can you provide a link to the bug report? [2] seems unrelated.
> > > > >
> > > > > As for [1], it looks like a trace that stems from a sysfs write to
> > > > > brightness stemming from userspace that follows the same chain it
> > > > > would on a stock kernel and times out. Is it present on a stock
> > > > > kernel?
> > > > >
> > > > > Ilpo should know more about this, could the spinlock be interfering?
> > > >
> > > > [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> > > > possible to use spinlock there.
> > > >
> > > > So we're back to what requires the spinlock? And what the spinlock
> > > > protects?
> > >
> > > For that invocation, since it is coming from the cdev device owned by
> > > asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
> > > asus_wmi is protected by the fact it is owned by that device. Spinlock
> > > is not required in this invocation due to not being an IRQ.
> > >
> > > Under asus_hid_event (second to last patch), which is called from an
> > > IRQ, a spinlock is required for protecting both listeners and the
> > > asus_ref.asus, and I suspect that scheduling from an IRQ is not
> > > allowed either. Is that correct?
> >
> > So it is a bit tricky here. When the IRQ fires, it needs to know
> > whether asus-wmi will handle the keyboard brightness event so that it
> > falls back to emitting it.
> >
> > If we want it to know for sure, it needs to access asus_wmi, so it
> > needs a spinlock or an IRQ friendly lock. This way, currently,
> > asus_hid_event will return -EBUSY if there is no led device so the
> > event propagates through hid.
> >
> > If we say that it is good enough to know that it was compiled with
> > IS_REACHABLE(CONFIG_ASUS_WMI), ie the actual implementation of
> > asus_hid_event in asus-wmi will never return an error, then,
> > asus_hid_event can schedule a task to fire the event without a lock,
> > and that task can use a normal locking primitive.
> >
> > If the task needs to be assigned to a device or have a handle,
> > asus_hid_listener can be provided to asus_hid_event, so that it is
> > owned by the calling device.
> >
> > What would the appropriate locking primitive be in this case?
>
> If you can move the non-check content out of asus_hid_event(), then you
> can nest mutex & spinlock for updating asus_ref. On reader side,
> asus_hid_event() only takes the spinlock and the rest of the readers
> (non-irq ones) can take just the mutex.
I think I found a good compromise on the V7. I also found that in
kbd_get I was missing a lock for the brightness value which
complicated things further, as get was called when creating the led
device.
On V7 I use a workqueue to do the bulk of initialization and setting
brightness so I manage to limit the lock to asus, the led wk value and
a new notify value that does hw_changed
>
> --
> i.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH v6 0/7] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
2025-10-16 16:16 ` Antheas Kapenekakis
2025-10-17 7:54 ` Antheas Kapenekakis
@ 2025-10-17 10:36 ` Ilpo Järvinen
1 sibling, 0 replies; 45+ messages in thread
From: Ilpo Järvinen @ 2025-10-17 10:36 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: Denis Benato, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]
On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen
> > On Thu, 16 Oct 2025, Antheas Kapenekakis wrote:
> > > On Thu, 16 Oct 2025 at 13:57, Denis Benato <benato.denis96@gmail.com> wrote:
> > > > On 10/13/25 22:15, Antheas Kapenekakis wrote:
> > > > > This is a two part series which does the following:
> > > > > - Clean-up init sequence
> > > > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > > > devices have synced brightness controls and the backlight button works
> > > > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > > > >
> > > > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > > > to make this easier to merge.
> > > > >
> > > > > All comments with these patches had been addressed since V4.
> > > > I have loaded this patchset for users of asus-linux project to try out.
> > > >
> > > > One of them opened a bug report about a kernel bug that happens
> > > > consistently when closing the lid of his laptop [1].
> > > >
> > > > He also sent another piece of kernel log, but didn't specify anything more
> > > > about this [2].
> > > >
> > > > [1] https://pastebin.com/akZx1w10
> > > > [2] https://pastebin.com/sKdczPgf
> > >
> > > Can you provide a link to the bug report? [2] seems unrelated.
> > >
> > > As for [1], it looks like a trace that stems from a sysfs write to
> > > brightness stemming from userspace that follows the same chain it
> > > would on a stock kernel and times out. Is it present on a stock
> > > kernel?
> > >
> > > Ilpo should know more about this, could the spinlock be interfering?
> >
> > [1] certainly seems to do schedule() from do_kbd_led_set() so it's not
> > possible to use spinlock there.
> >
> > So we're back to what requires the spinlock? And what the spinlock
> > protects?
>
> For that invocation, since it is coming from the cdev device owned by
> asus_wmi, it protects asus_ref.listeners under do_kbd_led_set.
> asus_wmi is protected by the fact it is owned by that device. Spinlock
> is not required in this invocation due to not being an IRQ.
>
> Under asus_hid_event (second to last patch), which is called from an
> IRQ, a spinlock is required for protecting both listeners and the
> asus_ref.asus, and I suspect that scheduling from an IRQ is not
> allowed either. Is that correct?
Yes, it's not allowed either.
hid-asus seems to already use workqueue (though include for it is
missing) likely to workaround a similar challenge.
--
i.
^ permalink raw reply [flat|nested] 45+ messages in thread