* Re: [PATCH 3/4] HID: asus: Add WMI communication infrastructure
From: Mario Limonciello @ 2026-01-07 15:14 UTC (permalink / raw)
To: Denis Benato, Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: linux-input, linux-kernel, ionut_n2001
In-Reply-To: <088286f0-3469-4b2a-87bb-56440d40fb82@gmail.com>
On 1/7/26 7:07 AM, Denis Benato wrote:
>
> On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
>> From: Ionut Nechita <ionut_n2001@yahoo.com>
>>
>> Add the infrastructure needed for the HID driver to communicate with
>> the asus-wmi driver:
>>
>> - Add linux/acpi.h include (in alphabetical order)
> Mentioning the addition of acpi.h seems a bit too specific
> for a commit message, but wait for hid maintainers to
> tell.
>> - Define ASUS_WMI_METHODID_NOTIF method ID in asus-wmi.h
>> - Implement asus_wmi_send_event() function to send events to asus-wmi
>>
>> This infrastructure will be used to handle special keys that require
>> WMI communication.
>>
>> Change-Id: Ic4d9b35f8b1f2b48c7c26e7259b4d05951021b58
>> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
>> ---
>> drivers/hid/hid-asus.c | 24 ++++++++++++++++++++++
>> include/linux/platform_data/x86/asus-wmi.h | 1 +
>> 2 files changed, 25 insertions(+)
>>
>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>> index 06cd3d3b74af7..05fa35489258d 100644
>> --- a/drivers/hid/hid-asus.c
>> +++ b/drivers/hid/hid-asus.c
>> @@ -23,6 +23,7 @@
>> /*
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/dmi.h>
>> #include <linux/hid.h>
>> #include <linux/module.h>
>> @@ -321,6 +322,29 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
>> return 0;
>> }
>>
>> +/*
>> + * Send events to asus-wmi driver for handling special keys
>> + */
>> +static int asus_wmi_send_event(struct asus_drvdata *drvdata, u8 code)
>> +{
>> + int err;
>> + u32 retval;
>> +
>> + err = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS,
>> + ASUS_WMI_METHODID_NOTIF, code, &retval);
> This code is based on the fact asus-wmi driver is available:
> are you sure this doesn't make the kernel compilation fail
> if such driver is not enabled?
asus-wmi.h has conditional behavior already:
#if IS_REACHABLE(CONFIG_ASUS_WMI)
>> + if (err) {
>> + pr_warn("Failed to notify asus-wmi: %d\n", err);
>> + return err;
>> + }
>> +
>> + if (retval != 0) {
>> + pr_warn("Failed to notify asus-wmi (retval): 0x%x\n", retval);
>> + return -EIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int asus_event(struct hid_device *hdev, struct hid_field *field,
>> struct hid_usage *usage, __s32 value)
>> {
>> diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
>> index 419491d4abca1..516538b5a527e 100644
>> --- a/include/linux/platform_data/x86/asus-wmi.h
>> +++ b/include/linux/platform_data/x86/asus-wmi.h
>> @@ -29,6 +29,7 @@
>> #define ASUS_WMI_METHODID_KBFT 0x5446424B /* KeyBoard FilTer */
>> #define ASUS_WMI_METHODID_INIT 0x54494E49 /* INITialize */
>> #define ASUS_WMI_METHODID_HKEY 0x59454B48 /* Hot KEY ?? */
>> +#define ASUS_WMI_METHODID_NOTIF 0x00100021 /* Notify method */
>>
>> #define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFFFFFE
>>
^ permalink raw reply
* Re: [PATCH v2 0/4] HID: multitouch: set INPUT_PROP_PRESSUREPAD on compatible touchpads
From: Benjamin Tissoires @ 2026-01-07 15:13 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan, Peter Hutterer
Cc: Dmitry Torokhov, linux-input, linux-kselftest, linux-kernel,
Vadim Klishko
In-Reply-To: <20251222-wip-hid-pressurepad-v2-0-054ac9689bb7@who-t.net>
On Mon, 22 Dec 2025 09:43:33 +1000, Peter Hutterer wrote:
> Nicely enough MS defines a button type for a pressurepad touchpad [2]
> and it looks like most touchpad vendors fill this in.
>
> The selftests require a bit of prep work (and a hack for the test
> itself) - hidtools 0.12 requires python-libevdev 0.13 which in turn
> provides constructors for unknown properties.
>
> [...]
Applied to hid/hid.git (for-6.19/upstream-fixes), thanks!
[1/4] HID: multitouch: set INPUT_PROP_PRESSUREPAD based on Digitizer/Button Type
https://git.kernel.org/hid/hid/c/2b29a90131bb
[2/4] selftests/hid: require hidtools 0.12
https://git.kernel.org/hid/hid/c/1d6628f7f279
[3/4] selftests/hid: use a enum class for the different button types
https://git.kernel.org/hid/hid/c/4f36fdab084f
[4/4] selftests/hid: add a test for the Digitizer/Button Type pressurepad
https://git.kernel.org/hid/hid/c/f287ba5951a4
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] HID: asus: Replace magic number with HID_UP_ASUSVENDOR constant
From: Mario Limonciello @ 2026-01-07 15:13 UTC (permalink / raw)
To: Denis Benato, Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: linux-input, linux-kernel, ionut_n2001
In-Reply-To: <6550db38-e5a5-49f5-ac60-02d0374dd553@gmail.com>
On 1/7/26 7:00 AM, Denis Benato wrote:
>
> On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
>> From: Ionut Nechita <ionut_n2001@yahoo.com>
>>
>> Use the existing HID_UP_ASUSVENDOR constant instead of the magic number
>> 0xff310000 for better code clarity and maintainability.
>>
>> Change-Id: I65cf58cd0cd47acc39b755fa9a5fb7f2ad271046
Please strip change-id.
Otherwise LGTM and add to next version:
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Reviewed-by: Denis Benato <benato.denis96@gmail.com>
>> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
>> ---
>> drivers/hid/hid-asus.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>> index 472bca54642b9..eb14b9d13823b 100644
>> --- a/drivers/hid/hid-asus.c
>> +++ b/drivers/hid/hid-asus.c
>> @@ -317,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_UP_ASUSVENDOR &&
>> (usage->hid & HID_USAGE) != 0x00 &&
>> (usage->hid & HID_USAGE) != 0xff && !usage->type) {
>> hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
^ permalink raw reply
* Re: [PATCH 2/4] HID: asus: Filter spurious HID vendor codes on ROG laptops
From: Mario Limonciello @ 2026-01-07 15:12 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: benato.denis96, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-6-sunlightlinux@gmail.com>
On 1/7/26 5:19 AM, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> On Asus ROG G14 and G15 laptops, several HID vendor usage codes (0xea,
> 0xec, 0x02, 0x8a, 0x9e) are sent during normal operation without a clear
> purpose, generating unwanted "Unmapped Asus vendor usagepage code"
> warnings in dmesg.
>
> Add definitions for these codes and filter them out in asus_raw_event()
> to prevent kernel log spam.
>
> Tested on Asus ROG G14/G15 series laptops.
>
> Change-Id: I3f3b3a1e1698c8689e4c57582635435bfeda5990
Please strip Change-Id when sending patches to LKML.
> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Otherwise LGTM, feel free to add to next version.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> drivers/hid/hid-asus.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index eb14b9d13823b..06cd3d3b74af7 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -57,6 +57,13 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define ROG_ALLY_X_MIN_MCU 313
> #define ROG_ALLY_MIN_MCU 319
>
> +/* Spurious HID codes sent by QUIRK_ROG_NKEY_KEYBOARD devices */
> +#define ASUS_SPURIOUS_CODE_0XEA 0xea
> +#define ASUS_SPURIOUS_CODE_0XEC 0xec
> +#define ASUS_SPURIOUS_CODE_0X02 0x02
> +#define ASUS_SPURIOUS_CODE_0X8A 0x8a
> +#define ASUS_SPURIOUS_CODE_0X9E 0x9e
> +
> #define SUPPORT_KBD_BACKLIGHT BIT(0)
>
> #define MAX_TOUCH_MAJOR 8
> @@ -348,6 +355,21 @@ static int asus_raw_event(struct hid_device *hdev,
> if (report->id == FEATURE_KBD_LED_REPORT_ID1 || report->id == FEATURE_KBD_LED_REPORT_ID2)
> return -1;
> if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> + /*
> + * G14 and G15 send these codes on some keypresses with no
> + * discernable reason for doing so. Filter them out to avoid
> + * unmapped warning messages.
> + */
> + if (report->id == FEATURE_KBD_REPORT_ID) {
> + if (data[1] == ASUS_SPURIOUS_CODE_0XEA ||
> + data[1] == ASUS_SPURIOUS_CODE_0XEC ||
> + data[1] == ASUS_SPURIOUS_CODE_0X02 ||
> + data[1] == ASUS_SPURIOUS_CODE_0X8A ||
> + data[1] == ASUS_SPURIOUS_CODE_0X9E) {
> + return -1;
> + }
> + }
> +
> /*
> * G713 and G733 send these codes on some keypresses, depending on
> * the key pressed it can trigger a shutdown event if not caught.
^ permalink raw reply
* Re: [PATCH] HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
From: Benjamin Tissoires @ 2026-01-07 14:26 UTC (permalink / raw)
To: jikos, Chris Chiu; +Cc: linux-input
In-Reply-To: <20260102065643.1832426-1-chris.chiu@canonical.com>
On Fri, 02 Jan 2026 06:56:43 +0000, Chris Chiu wrote:
> Another Chicony Electronics HP 5MP Camera with USB ID 04F2:B882
> reports a HID sensor interface that is not actually implemented.
>
> Add the device to the HID ignore list so the bogus sensor is never
> exposed to userspace. Then the system won't hang when runtime PM
> tries to wake the unresponsive device.
>
> [...]
Applied to hid/hid.git (for-6.19/upstream-fixes), thanks!
[1/1] HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
https://git.kernel.org/hid/hid/c/c06bc3557542
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer
From: Benjamin Tissoires @ 2026-01-07 14:26 UTC (permalink / raw)
To: jikos, Even Xu; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Rui Zhang
In-Reply-To: <20251226033953.3651688-1-even.xu@intel.com>
On Fri, 26 Dec 2025 11:39:53 +0800, Even Xu wrote:
> Add DMA buffer readiness check before reading DMA buffer to avoid
> unexpected NULL pointer accessing.
>
>
Applied to hid/hid.git (for-6.19/upstream-fixes), thanks!
[1/1] HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer
https://git.kernel.org/hid/hid/c/a9a917998d17
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] hid: intel-thc-hid: Select SGL_ALLOC
From: Benjamin Tissoires @ 2026-01-07 14:26 UTC (permalink / raw)
To: Tim Zimmermann
Cc: Even Xu, Xinpeng Sun, Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20251128075426.628500-1-tim@linux4.de>
On Fri, 28 Nov 2025 08:54:22 +0100, Tim Zimmermann wrote:
> intel-thc-dma.c uses sgl_alloc() resulting in a build failure if CONFIG_SGL_ALLOC is not enabled
>
>
Applied to hid/hid.git (for-6.19/upstream-fixes), thanks!
[1/1] hid: intel-thc-hid: Select SGL_ALLOC
https://git.kernel.org/hid/hid/c/dd76788f9ec4
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list
From: Benjamin Tissoires @ 2026-01-07 14:25 UTC (permalink / raw)
To: Chris Chiu; +Cc: jikos, linux-input, linux-kernel
In-Reply-To: <20260106151101.3775332-1-chris.chiu@canonical.com>
On Jan 06 2026, Chris Chiu wrote:
> Another Chicony Electronics HP 5MP Camera with USB ID 04F2:B882
> reports a HID sensor interface that is not actually implemented.
>
> Add the device to the HID ignore list so the bogus sensor is never
> exposed to userspace. Then the system won't hang when runtime PM
> tries to wake the unresponsive device.
>
> Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
This looks lie a resend of https://lore.kernel.org/linux-input/20260102065643.1832426-1-chris.chiu@canonical.com/T/#u
In the future, please mark them as such ("PATCH Resend"), or change the
version number. Ansd as a general rule of thumb, don't resend a patch
after just 4 days. Worse case, send a reply with a ping in the original
submission.
Cheers,
Benjamin
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-quirks.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index d31711f1aaecc..e8a1a86313b74 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -317,6 +317,7 @@
> #define USB_DEVICE_ID_CHICONY_ACER_SWITCH12 0x1421
> #define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA 0xb824
> #define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2 0xb82c
> +#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3 0xb882
>
> #define USB_VENDOR_ID_CHUNGHWAT 0x2247
> #define USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH 0x0001
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index c89a015686c07..3cf7971d49743 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -769,6 +769,7 @@ static const struct hid_device_id hid_ignore_list[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
From: Benjamin Tissoires @ 2026-01-07 14:20 UTC (permalink / raw)
To: Kwok Kin Ming; +Cc: jikos, linux-input, linux-kernel
In-Reply-To: <20251231181830.232239-1-kenkinming2002@gmail.com>
On Jan 01 2026, Kwok Kin Ming wrote:
> `i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data
> into `ihid->rawbuf`.
>
> The former can come from the userspace in the hidraw driver and is only
> bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set
> `max_buffer_size` field of `struct hid_ll_driver` which we do not).
>
> The latter has size determined at runtime by the maximum size of
> different report types you could receive on any particular device and
> can be a much smaller value.
>
> Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.
>
> The impact is low since access to hidraw devices requires root.
>
> Signed-off-by: Kwok Kin Ming <kenkinming2002@gmail.com>
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 63f46a2e5..5a183af3d 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -286,6 +286,7 @@ static int i2c_hid_get_report(struct i2c_hid *ihid,
> * In addition to report data device will supply data length
> * in the first 2 bytes of the response, so adjust .
> */
> + recv_len = min(recv_len, ihid->bufsize - sizeof(__le16));
It makes sense to put this min call here, but it's already present at
line 304 a few lines after. Could you remove that second check (and
unnecessary one after your change).
Cheers,
Benjamin
> error = i2c_hid_xfer(ihid, ihid->cmdbuf, length,
> ihid->rawbuf, recv_len + sizeof(__le16));
> if (error) {
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH 0/2] HID: bpf: fix HID-BPF CI due to new compiler flags
From: Benjamin Tissoires @ 2026-01-07 14:05 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan, Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-kselftest
In-Reply-To: <20260106-wip-fix-bpf-compilation-v1-0-0b29c85f1157@kernel.org>
On Tue, 06 Jan 2026 16:30:53 +0100, Benjamin Tissoires wrote:
> Since the merge with v6.19-rc my CI is broken because of the newly
> enabled -fms-extensions.
>
> Add the missing flags when generating the CFLAGS for bpf.o to solve this
> and continue running the tests while applying the patches.
>
> Cheers,
> Benjamin
>
> [...]
Applied to hid/hid.git (for-6.19/upstream-fixes), thanks!
[1/2] HID: bpf: fix bpf compilation with -fms-extensions
https://git.kernel.org/hid/hid/c/b7666c891cc7
[2/2] selftests/hid: fix bpf compilations due to -fms-extensions
https://git.kernel.org/hid/hid/c/e03fb369b083
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/4] HID: asus: Implement Fn+F5 fan control key handler
From: Denis Benato @ 2026-01-07 13:10 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: superm1, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-10-sunlightlinux@gmail.com>
On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> On Asus ROG laptops, the Fn+F5 key (HID code 0xae) is used to cycle
> through fan modes. This key press needs to be forwarded to the asus-wmi
> driver to actually change the fan mode.
>
> Add ASUS_FAN_CTRL_KEY_CODE define and implement the handler in
> asus_raw_event() to send WMI events when this key is pressed.
>
> Tested on Asus ROG G14/G15 series laptops.
>
> Change-Id: Ic03df877b71e34c421e992a06e5e706d954e7dbf
> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
> ---
> drivers/hid/hid-asus.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 05fa35489258d..d93c8f030b239 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -65,6 +65,9 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define ASUS_SPURIOUS_CODE_0X8A 0x8a
> #define ASUS_SPURIOUS_CODE_0X9E 0x9e
>
> +/* Special key codes */
> +#define ASUS_FAN_CTRL_KEY_CODE 0xae
> +
> #define SUPPORT_KBD_BACKLIGHT BIT(0)
>
> #define MAX_TOUCH_MAJOR 8
> @@ -379,12 +382,21 @@ static int asus_raw_event(struct hid_device *hdev,
> if (report->id == FEATURE_KBD_LED_REPORT_ID1 || report->id == FEATURE_KBD_LED_REPORT_ID2)
> return -1;
> if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> - /*
> - * G14 and G15 send these codes on some keypresses with no
> - * discernable reason for doing so. Filter them out to avoid
> - * unmapped warning messages.
> - */
> if (report->id == FEATURE_KBD_REPORT_ID) {
> + /* Fn+F5 fan control key, send WMI event to toggle fan mode */
> + if (data[1] == ASUS_FAN_CTRL_KEY_CODE) {
> + int ret = asus_wmi_send_event(drvdata, ASUS_FAN_CTRL_KEY_CODE);
> +
What if asus-wmi is not compiled with the kernel?
Would it make sense, in that situation (or in case of a failure)
to tell userspace (via evdev) about the button press?
> + if (ret < 0)
> + hid_warn(hdev, "Failed to trigger fan control event\n");
> + return -1;
> + }
> +
> + /*
> + * G14 and G15 send these codes on some keypresses with no
> + * discernable reason for doing so. Filter them out to avoid
> + * unmapped warning messages.
> + */
> if (data[1] == ASUS_SPURIOUS_CODE_0XEA ||
> data[1] == ASUS_SPURIOUS_CODE_0XEC ||
> data[1] == ASUS_SPURIOUS_CODE_0X02 ||
^ permalink raw reply
* Re: [PATCH 3/4] HID: asus: Add WMI communication infrastructure
From: Denis Benato @ 2026-01-07 13:07 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: superm1, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-8-sunlightlinux@gmail.com>
On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> Add the infrastructure needed for the HID driver to communicate with
> the asus-wmi driver:
>
> - Add linux/acpi.h include (in alphabetical order)
Mentioning the addition of acpi.h seems a bit too specific
for a commit message, but wait for hid maintainers to
tell.
> - Define ASUS_WMI_METHODID_NOTIF method ID in asus-wmi.h
> - Implement asus_wmi_send_event() function to send events to asus-wmi
>
> This infrastructure will be used to handle special keys that require
> WMI communication.
>
> Change-Id: Ic4d9b35f8b1f2b48c7c26e7259b4d05951021b58
> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
> ---
> drivers/hid/hid-asus.c | 24 ++++++++++++++++++++++
> include/linux/platform_data/x86/asus-wmi.h | 1 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 06cd3d3b74af7..05fa35489258d 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -23,6 +23,7 @@
> /*
> */
>
> +#include <linux/acpi.h>
> #include <linux/dmi.h>
> #include <linux/hid.h>
> #include <linux/module.h>
> @@ -321,6 +322,29 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
> return 0;
> }
>
> +/*
> + * Send events to asus-wmi driver for handling special keys
> + */
> +static int asus_wmi_send_event(struct asus_drvdata *drvdata, u8 code)
> +{
> + int err;
> + u32 retval;
> +
> + err = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS,
> + ASUS_WMI_METHODID_NOTIF, code, &retval);
This code is based on the fact asus-wmi driver is available:
are you sure this doesn't make the kernel compilation fail
if such driver is not enabled?
> + if (err) {
> + pr_warn("Failed to notify asus-wmi: %d\n", err);
> + return err;
> + }
> +
> + if (retval != 0) {
> + pr_warn("Failed to notify asus-wmi (retval): 0x%x\n", retval);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> static int asus_event(struct hid_device *hdev, struct hid_field *field,
> struct hid_usage *usage, __s32 value)
> {
> diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
> index 419491d4abca1..516538b5a527e 100644
> --- a/include/linux/platform_data/x86/asus-wmi.h
> +++ b/include/linux/platform_data/x86/asus-wmi.h
> @@ -29,6 +29,7 @@
> #define ASUS_WMI_METHODID_KBFT 0x5446424B /* KeyBoard FilTer */
> #define ASUS_WMI_METHODID_INIT 0x54494E49 /* INITialize */
> #define ASUS_WMI_METHODID_HKEY 0x59454B48 /* Hot KEY ?? */
> +#define ASUS_WMI_METHODID_NOTIF 0x00100021 /* Notify method */
>
> #define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFFFFFE
>
^ permalink raw reply
* Re: [PATCH 2/4] HID: asus: Filter spurious HID vendor codes on ROG laptops
From: Denis Benato @ 2026-01-07 13:02 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: superm1, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-6-sunlightlinux@gmail.com>
On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> On Asus ROG G14 and G15 laptops, several HID vendor usage codes (0xea,
> 0xec, 0x02, 0x8a, 0x9e) are sent during normal operation without a clear
> purpose, generating unwanted "Unmapped Asus vendor usagepage code"
> warnings in dmesg.
>
> Add definitions for these codes and filter them out in asus_raw_event()
> to prevent kernel log spam.
>
> Tested on Asus ROG G14/G15 series laptops.
>
> Change-Id: I3f3b3a1e1698c8689e4c57582635435bfeda5990
> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
> ---
> drivers/hid/hid-asus.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index eb14b9d13823b..06cd3d3b74af7 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -57,6 +57,13 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define ROG_ALLY_X_MIN_MCU 313
> #define ROG_ALLY_MIN_MCU 319
>
> +/* Spurious HID codes sent by QUIRK_ROG_NKEY_KEYBOARD devices */
> +#define ASUS_SPURIOUS_CODE_0XEA 0xea
> +#define ASUS_SPURIOUS_CODE_0XEC 0xec
> +#define ASUS_SPURIOUS_CODE_0X02 0x02
> +#define ASUS_SPURIOUS_CODE_0X8A 0x8a
> +#define ASUS_SPURIOUS_CODE_0X9E 0x9e
> +
I don't know what's the preferred way to call these, I am happy
with any way.
> #define SUPPORT_KBD_BACKLIGHT BIT(0)
>
> #define MAX_TOUCH_MAJOR 8
> @@ -348,6 +355,21 @@ static int asus_raw_event(struct hid_device *hdev,
> if (report->id == FEATURE_KBD_LED_REPORT_ID1 || report->id == FEATURE_KBD_LED_REPORT_ID2)
> return -1;
> if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> + /*
> + * G14 and G15 send these codes on some keypresses with no
> + * discernable reason for doing so. Filter them out to avoid
> + * unmapped warning messages.
> + */
Pretty much all ASUS laptops do, not just G14 or G15, and it's not
only on keypresses.
> + if (report->id == FEATURE_KBD_REPORT_ID) {
> + if (data[1] == ASUS_SPURIOUS_CODE_0XEA ||
> + data[1] == ASUS_SPURIOUS_CODE_0XEC ||
> + data[1] == ASUS_SPURIOUS_CODE_0X02 ||
> + data[1] == ASUS_SPURIOUS_CODE_0X8A ||
> + data[1] == ASUS_SPURIOUS_CODE_0X9E) {
> + return -1;
> + }
> + }
> +
> /*
> * G713 and G733 send these codes on some keypresses, depending on
> * the key pressed it can trigger a shutdown event if not caught.
^ permalink raw reply
* Re: [PATCH 1/4] HID: asus: Replace magic number with HID_UP_ASUSVENDOR constant
From: Denis Benato @ 2026-01-07 13:00 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: superm1, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-4-sunlightlinux@gmail.com>
On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> Use the existing HID_UP_ASUSVENDOR constant instead of the magic number
> 0xff310000 for better code clarity and maintainability.
>
> Change-Id: I65cf58cd0cd47acc39b755fa9a5fb7f2ad271046
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
> Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
> ---
> drivers/hid/hid-asus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 472bca54642b9..eb14b9d13823b 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -317,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_UP_ASUSVENDOR &&
> (usage->hid & HID_USAGE) != 0x00 &&
> (usage->hid & HID_USAGE) != 0xff && !usage->type) {
> hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
^ permalink raw reply
* Re: [PATCH v2 0/4] HID: asus: Filter HID codes and add WMI fan control for ROG laptops
From: Denis Benato @ 2026-01-07 13:00 UTC (permalink / raw)
To: Ionut Nechita (Sunlight Linux), jikos, bentiss
Cc: superm1, linux-input, linux-kernel, ionut_n2001
In-Reply-To: <20260107111945.48018-2-sunlightlinux@gmail.com>
On 1/7/26 12:19, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> Hi Mario and maintainers,
Hi!
Maintainer of asus-wmi here, thanks a lot for your help!
Thanks Mario for including me too to the party!
A note for the future: from my email client it appears as if you sent
v2 in reply to the previous patch, I have done that on the iio subsystem
and I have been discouraged from doing so because the mail ends up
far from the latest received ones and maintainers are more likely to miss
it.
> Thank you for the review feedback on v1. I've addressed all the issues:
>
> Changes in v2:
> - Split the monolithic patch into 4 logical patches as requested
> - Fixed include order (linux/acpi.h now before linux/dmi.h)
> - Added #define ASUS_FAN_CTRL_KEY_CODE for 0xae instead of magic number
> - Added #defines for the filtered spurious codes as well for clarity
>
> The patch series now:
> 1. Replaces magic number with existing HID_UP_ASUSVENDOR constant
> 2. Filters spurious HID vendor codes (with proper #defines)
> 3. Adds WMI communication infrastructure
> 4. Implements Fn+F5 fan control key handler (using #define)
>
> This eliminates kernel log spam from unmapped HID codes and enables
> proper fan control functionality on Asus ROG G14/G15 laptops.
From my notes those unmapped codepages is the embedded controller
echoing out settings for the Windows application armoury-crate to
check if it is still in sync.
> Tested on Asus ROG G14/G15 series laptops.
>
> Ionut Nechita (4):
> HID: asus: Replace magic number with HID_UP_ASUSVENDOR constant
> HID: asus: Filter spurious HID vendor codes on ROG laptops
> HID: asus: Add WMI communication infrastructure
> HID: asus: Implement Fn+F5 fan control key handler
>
> drivers/hid/hid-asus.c | 60 +++++++++++++++++++++-
> include/linux/platform_data/x86/asus-wmi.h | 1 +
> 2 files changed, 60 insertions(+), 1 deletion(-)
>
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Denis Benato @ 2026-01-07 12:54 UTC (permalink / raw)
To: Antheas Kapenekakis, Ilpo Järvinen
Cc: Kelsios, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede
In-Reply-To: <CAGwozwEE0TXZqKy1W0zPjP=6+oog1ATfGJeLFqyLwr8kMZ56Lg@mail.gmail.com>
On 1/7/26 11:45, Antheas Kapenekakis wrote:
> On Wed, 7 Jan 2026 at 12:42, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
>> On Tue, 9 Dec 2025, Antheas Kapenekakis wrote:
>>> On Tue, 9 Dec 2025 at 10:17, Ilpo Järvinen
>>> <ilpo.jarvinen@linux.intel.com> wrote:
>>>> On Sat, 6 Dec 2025, Antheas Kapenekakis wrote:
>>>>> On Sat, 6 Dec 2025 at 00:03, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>>>>>> On Fri, 5 Dec 2025 at 23:13, Kelsios <K3lsios@proton.me> wrote:
>>>>>>> I would like to report a regression affecting keyboard backlight brightness control on my ASUS ROG Zephyrus G16 (model GU605CW).
>>>>>>>
>>>>>>> Using kernel 6.17.9-arch1-1.1-g14 with the latest HID ASUS patchset v10, keyboard *color* control works correctly, but *brightness* control no longer responds at all. The issue is reproducible on every boot. This problem is not present when using patchset v8, where both color and brightness work as expected.
>>>>>>>
>>>>>>> Important detail: the issue occurs even **without** asusctl installed, so it must be within the kernel HID/WMI handling and is unrelated to userspace tools.
>>>>>>>
>>>>>>> Output of dmesg is available here [1], please let me know if any additional information is required.
>>>>>>>
>>>>>>> Thank you for your time and work on supporting these ASUS laptops.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Kelsios
>>>>>>>
>>>>>>> [1] https://pastebin.com/ZFC13Scf
>>>>>> [ 1.035986] asus 0003:0B05:19B6.0001: Asus failed to receive handshake ack: -32
>>>>>>
>>>>>> Oh yeah, asus_kbd_init no longer works with spurious inits so it broke
>>>>>> devices marked with QUIRK_ROG_NKEY_LEGACY
>>>>>>
>>>>>> There are three ways to approach this. One is to ignore the error...
>>>>>> second is to drop the quirk... third is to check for the usages for ID1, ID2...
>>>>>>
>>>>>> I would tend towards dropping the ID2 init and ignoring the error for
>>>>>> ID1... Unless an EPIPE would cause the device to close
>>>>> Benjamin correctly caught the deviation
>>>> BTW, we want to record this knowledge also into the changelog so that the
>>>> next person who'd want to make the check stricter does not need to guess
>>>> whether it was based on a real observed problem or mere guessing there
>>>> could be a problem.
>>> If we keep the spurious inits, the stricter check will catch them and
>>> throw errors. This is problematic.
>>>
>>> Kelsios, you have a device that allegedly would not work without those
>>> inits. Perhaps you could try removing the legacy quirk from your
>>> device and see if everything is ok?
>>>
>>> If it is, then we have a tested device and a case for removing the
>>> legacy quirk altogether
>> Hi all,
>>
>> Is there any progress on this?
> Hi,
> I plan to revise the patch series and fix this issue next week.
> Currently on holidays
>
> I am unsure how I will tackle this issue, I might make the init not
> fail for 0x5d/0x5e, and try to avoid printing errors if the endpoint
> is missing.
Hello,
I have left the patchset in linux-g14 for people to try.
I estimate some thousands laptops run it at this point, however we had to
stop the driver from aborting probe for things to function otherwise lots
of model would have stopped working:
https://gitlab.com/asus-linux/linux-g14/-/blob/6.18/PATCH-v10-00-11-HID-asus-Fix-ASUS-ROG-Laptop-s-Keyboard-backlight-handling-id1-id2-pr_err.patch?ref_type=heads
There is only one laptop model remaining that display some serious problems
where loading this patchset makes keys unresponsive or repeats some keys
or takes a long time for buttons to register.
I have asked the user to response to this thread, providing instructions
but as you can see he never did.
As an additional note I would say that I plan in the future to mode the asusd implementation
of anime to hid-asus and the handshake on 5e is the perfect entrypoint to check for compatibility
so I guess just pr_info the unsupported feature for the time being.
> Best,
> Antheas
>
>> --
>> i.
^ permalink raw reply
* [PATCH 4/4] HID: asus: Implement Fn+F5 fan control key handler
From: Ionut Nechita (Sunlight Linux) @ 2026-01-07 11:19 UTC (permalink / raw)
To: jikos, bentiss
Cc: superm1, benato.denis96, linux-input, linux-kernel, ionut_n2001,
sunlightlinux
In-Reply-To: <20260107111945.48018-2-sunlightlinux@gmail.com>
From: Ionut Nechita <ionut_n2001@yahoo.com>
On Asus ROG laptops, the Fn+F5 key (HID code 0xae) is used to cycle
through fan modes. This key press needs to be forwarded to the asus-wmi
driver to actually change the fan mode.
Add ASUS_FAN_CTRL_KEY_CODE define and implement the handler in
asus_raw_event() to send WMI events when this key is pressed.
Tested on Asus ROG G14/G15 series laptops.
Change-Id: Ic03df877b71e34c421e992a06e5e706d954e7dbf
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
---
drivers/hid/hid-asus.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 05fa35489258d..d93c8f030b239 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -65,6 +65,9 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define ASUS_SPURIOUS_CODE_0X8A 0x8a
#define ASUS_SPURIOUS_CODE_0X9E 0x9e
+/* Special key codes */
+#define ASUS_FAN_CTRL_KEY_CODE 0xae
+
#define SUPPORT_KBD_BACKLIGHT BIT(0)
#define MAX_TOUCH_MAJOR 8
@@ -379,12 +382,21 @@ static int asus_raw_event(struct hid_device *hdev,
if (report->id == FEATURE_KBD_LED_REPORT_ID1 || report->id == FEATURE_KBD_LED_REPORT_ID2)
return -1;
if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
- /*
- * G14 and G15 send these codes on some keypresses with no
- * discernable reason for doing so. Filter them out to avoid
- * unmapped warning messages.
- */
if (report->id == FEATURE_KBD_REPORT_ID) {
+ /* Fn+F5 fan control key, send WMI event to toggle fan mode */
+ if (data[1] == ASUS_FAN_CTRL_KEY_CODE) {
+ int ret = asus_wmi_send_event(drvdata, ASUS_FAN_CTRL_KEY_CODE);
+
+ if (ret < 0)
+ hid_warn(hdev, "Failed to trigger fan control event\n");
+ return -1;
+ }
+
+ /*
+ * G14 and G15 send these codes on some keypresses with no
+ * discernable reason for doing so. Filter them out to avoid
+ * unmapped warning messages.
+ */
if (data[1] == ASUS_SPURIOUS_CODE_0XEA ||
data[1] == ASUS_SPURIOUS_CODE_0XEC ||
data[1] == ASUS_SPURIOUS_CODE_0X02 ||
--
2.52.0
^ permalink raw reply related
* [PATCH 3/4] HID: asus: Add WMI communication infrastructure
From: Ionut Nechita (Sunlight Linux) @ 2026-01-07 11:19 UTC (permalink / raw)
To: jikos, bentiss
Cc: superm1, benato.denis96, linux-input, linux-kernel, ionut_n2001,
sunlightlinux
In-Reply-To: <20260107111945.48018-2-sunlightlinux@gmail.com>
From: Ionut Nechita <ionut_n2001@yahoo.com>
Add the infrastructure needed for the HID driver to communicate with
the asus-wmi driver:
- Add linux/acpi.h include (in alphabetical order)
- Define ASUS_WMI_METHODID_NOTIF method ID in asus-wmi.h
- Implement asus_wmi_send_event() function to send events to asus-wmi
This infrastructure will be used to handle special keys that require
WMI communication.
Change-Id: Ic4d9b35f8b1f2b48c7c26e7259b4d05951021b58
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
---
drivers/hid/hid-asus.c | 24 ++++++++++++++++++++++
include/linux/platform_data/x86/asus-wmi.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 06cd3d3b74af7..05fa35489258d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -23,6 +23,7 @@
/*
*/
+#include <linux/acpi.h>
#include <linux/dmi.h>
#include <linux/hid.h>
#include <linux/module.h>
@@ -321,6 +322,29 @@ static int asus_e1239t_event(struct asus_drvdata *drvdat, u8 *data, int size)
return 0;
}
+/*
+ * Send events to asus-wmi driver for handling special keys
+ */
+static int asus_wmi_send_event(struct asus_drvdata *drvdata, u8 code)
+{
+ int err;
+ u32 retval;
+
+ err = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS,
+ ASUS_WMI_METHODID_NOTIF, code, &retval);
+ if (err) {
+ pr_warn("Failed to notify asus-wmi: %d\n", err);
+ return err;
+ }
+
+ if (retval != 0) {
+ pr_warn("Failed to notify asus-wmi (retval): 0x%x\n", retval);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int asus_event(struct hid_device *hdev, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 419491d4abca1..516538b5a527e 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -29,6 +29,7 @@
#define ASUS_WMI_METHODID_KBFT 0x5446424B /* KeyBoard FilTer */
#define ASUS_WMI_METHODID_INIT 0x54494E49 /* INITialize */
#define ASUS_WMI_METHODID_HKEY 0x59454B48 /* Hot KEY ?? */
+#define ASUS_WMI_METHODID_NOTIF 0x00100021 /* Notify method */
#define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFFFFFE
--
2.52.0
^ permalink raw reply related
* [PATCH 2/4] HID: asus: Filter spurious HID vendor codes on ROG laptops
From: Ionut Nechita (Sunlight Linux) @ 2026-01-07 11:19 UTC (permalink / raw)
To: jikos, bentiss
Cc: superm1, benato.denis96, linux-input, linux-kernel, ionut_n2001,
sunlightlinux
In-Reply-To: <20260107111945.48018-2-sunlightlinux@gmail.com>
From: Ionut Nechita <ionut_n2001@yahoo.com>
On Asus ROG G14 and G15 laptops, several HID vendor usage codes (0xea,
0xec, 0x02, 0x8a, 0x9e) are sent during normal operation without a clear
purpose, generating unwanted "Unmapped Asus vendor usagepage code"
warnings in dmesg.
Add definitions for these codes and filter them out in asus_raw_event()
to prevent kernel log spam.
Tested on Asus ROG G14/G15 series laptops.
Change-Id: I3f3b3a1e1698c8689e4c57582635435bfeda5990
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
---
drivers/hid/hid-asus.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index eb14b9d13823b..06cd3d3b74af7 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -57,6 +57,13 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define ROG_ALLY_X_MIN_MCU 313
#define ROG_ALLY_MIN_MCU 319
+/* Spurious HID codes sent by QUIRK_ROG_NKEY_KEYBOARD devices */
+#define ASUS_SPURIOUS_CODE_0XEA 0xea
+#define ASUS_SPURIOUS_CODE_0XEC 0xec
+#define ASUS_SPURIOUS_CODE_0X02 0x02
+#define ASUS_SPURIOUS_CODE_0X8A 0x8a
+#define ASUS_SPURIOUS_CODE_0X9E 0x9e
+
#define SUPPORT_KBD_BACKLIGHT BIT(0)
#define MAX_TOUCH_MAJOR 8
@@ -348,6 +355,21 @@ static int asus_raw_event(struct hid_device *hdev,
if (report->id == FEATURE_KBD_LED_REPORT_ID1 || report->id == FEATURE_KBD_LED_REPORT_ID2)
return -1;
if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
+ /*
+ * G14 and G15 send these codes on some keypresses with no
+ * discernable reason for doing so. Filter them out to avoid
+ * unmapped warning messages.
+ */
+ if (report->id == FEATURE_KBD_REPORT_ID) {
+ if (data[1] == ASUS_SPURIOUS_CODE_0XEA ||
+ data[1] == ASUS_SPURIOUS_CODE_0XEC ||
+ data[1] == ASUS_SPURIOUS_CODE_0X02 ||
+ data[1] == ASUS_SPURIOUS_CODE_0X8A ||
+ data[1] == ASUS_SPURIOUS_CODE_0X9E) {
+ return -1;
+ }
+ }
+
/*
* G713 and G733 send these codes on some keypresses, depending on
* the key pressed it can trigger a shutdown event if not caught.
--
2.52.0
^ permalink raw reply related
* [PATCH 1/4] HID: asus: Replace magic number with HID_UP_ASUSVENDOR constant
From: Ionut Nechita (Sunlight Linux) @ 2026-01-07 11:19 UTC (permalink / raw)
To: jikos, bentiss
Cc: superm1, benato.denis96, linux-input, linux-kernel, ionut_n2001,
sunlightlinux
In-Reply-To: <20260107111945.48018-2-sunlightlinux@gmail.com>
From: Ionut Nechita <ionut_n2001@yahoo.com>
Use the existing HID_UP_ASUSVENDOR constant instead of the magic number
0xff310000 for better code clarity and maintainability.
Change-Id: I65cf58cd0cd47acc39b755fa9a5fb7f2ad271046
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
---
drivers/hid/hid-asus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 472bca54642b9..eb14b9d13823b 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -317,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_UP_ASUSVENDOR &&
(usage->hid & HID_USAGE) != 0x00 &&
(usage->hid & HID_USAGE) != 0xff && !usage->type) {
hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/4] HID: asus: Filter HID codes and add WMI fan control for ROG laptops
From: Ionut Nechita (Sunlight Linux) @ 2026-01-07 11:19 UTC (permalink / raw)
To: jikos, bentiss
Cc: superm1, benato.denis96, linux-input, linux-kernel, ionut_n2001,
sunlightlinux
In-Reply-To: <10abfaa7-9f5b-494c-8bb5-5da53c087fc4@kernel.org>
From: Ionut Nechita <ionut_n2001@yahoo.com>
Hi Mario and maintainers,
Thank you for the review feedback on v1. I've addressed all the issues:
Changes in v2:
- Split the monolithic patch into 4 logical patches as requested
- Fixed include order (linux/acpi.h now before linux/dmi.h)
- Added #define ASUS_FAN_CTRL_KEY_CODE for 0xae instead of magic number
- Added #defines for the filtered spurious codes as well for clarity
The patch series now:
1. Replaces magic number with existing HID_UP_ASUSVENDOR constant
2. Filters spurious HID vendor codes (with proper #defines)
3. Adds WMI communication infrastructure
4. Implements Fn+F5 fan control key handler (using #define)
This eliminates kernel log spam from unmapped HID codes and enables
proper fan control functionality on Asus ROG G14/G15 laptops.
Tested on Asus ROG G14/G15 series laptops.
Ionut Nechita (4):
HID: asus: Replace magic number with HID_UP_ASUSVENDOR constant
HID: asus: Filter spurious HID vendor codes on ROG laptops
HID: asus: Add WMI communication infrastructure
HID: asus: Implement Fn+F5 fan control key handler
drivers/hid/hid-asus.c | 60 +++++++++++++++++++++-
include/linux/platform_data/x86/asus-wmi.h | 1 +
2 files changed, 60 insertions(+), 1 deletion(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Antheas Kapenekakis @ 2026-01-07 10:45 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Kelsios, platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
In-Reply-To: <d169655b-4e15-fab6-0ce8-7a6bfd6a47a5@linux.intel.com>
On Wed, 7 Jan 2026 at 12:42, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Tue, 9 Dec 2025, Antheas Kapenekakis wrote:
> > On Tue, 9 Dec 2025 at 10:17, Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > > On Sat, 6 Dec 2025, Antheas Kapenekakis wrote:
> > > > On Sat, 6 Dec 2025 at 00:03, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > > > > On Fri, 5 Dec 2025 at 23:13, Kelsios <K3lsios@proton.me> wrote:
> > > > > >
> > > > > > I would like to report a regression affecting keyboard backlight brightness control on my ASUS ROG Zephyrus G16 (model GU605CW).
> > > > > >
> > > > > > Using kernel 6.17.9-arch1-1.1-g14 with the latest HID ASUS patchset v10, keyboard *color* control works correctly, but *brightness* control no longer responds at all. The issue is reproducible on every boot. This problem is not present when using patchset v8, where both color and brightness work as expected.
> > > > > >
> > > > > > Important detail: the issue occurs even **without** asusctl installed, so it must be within the kernel HID/WMI handling and is unrelated to userspace tools.
> > > > > >
> > > > > > Output of dmesg is available here [1], please let me know if any additional information is required.
> > > > > >
> > > > > > Thank you for your time and work on supporting these ASUS laptops.
> > > > > >
> > > > > > Best regards,
> > > > > > Kelsios
> > > > > >
> > > > > > [1] https://pastebin.com/ZFC13Scf
> > > > >
> > > > > [ 1.035986] asus 0003:0B05:19B6.0001: Asus failed to receive handshake ack: -32
> > > > >
> > > > > Oh yeah, asus_kbd_init no longer works with spurious inits so it broke
> > > > > devices marked with QUIRK_ROG_NKEY_LEGACY
> > > > >
> > > > > There are three ways to approach this. One is to ignore the error...
> > > > > second is to drop the quirk... third is to check for the usages for ID1, ID2...
> > > > >
> > > > > I would tend towards dropping the ID2 init and ignoring the error for
> > > > > ID1... Unless an EPIPE would cause the device to close
> > > >
> > > > Benjamin correctly caught the deviation
> > >
> > > BTW, we want to record this knowledge also into the changelog so that the
> > > next person who'd want to make the check stricter does not need to guess
> > > whether it was based on a real observed problem or mere guessing there
> > > could be a problem.
> >
> > If we keep the spurious inits, the stricter check will catch them and
> > throw errors. This is problematic.
> >
> > Kelsios, you have a device that allegedly would not work without those
> > inits. Perhaps you could try removing the legacy quirk from your
> > device and see if everything is ok?
> >
> > If it is, then we have a tested device and a case for removing the
> > legacy quirk altogether
>
> Hi all,
>
> Is there any progress on this?
Hi,
I plan to revise the patch series and fix this issue next week.
Currently on holidays
I am unsure how I will tackle this issue, I might make the init not
fail for 0x5d/0x5e, and try to avoid printing errors if the endpoint
is missing.
Best,
Antheas
> --
> i.
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Ilpo Järvinen @ 2026-01-07 10:42 UTC (permalink / raw)
To: Antheas Kapenekakis, Kelsios
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
In-Reply-To: <CAGwozwFJfZ2ATVR+N4pwb0unsXOpJbThtefigrtax9iYcPto7A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]
On Tue, 9 Dec 2025, Antheas Kapenekakis wrote:
> On Tue, 9 Dec 2025 at 10:17, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Sat, 6 Dec 2025, Antheas Kapenekakis wrote:
> > > On Sat, 6 Dec 2025 at 00:03, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > > > On Fri, 5 Dec 2025 at 23:13, Kelsios <K3lsios@proton.me> wrote:
> > > > >
> > > > > I would like to report a regression affecting keyboard backlight brightness control on my ASUS ROG Zephyrus G16 (model GU605CW).
> > > > >
> > > > > Using kernel 6.17.9-arch1-1.1-g14 with the latest HID ASUS patchset v10, keyboard *color* control works correctly, but *brightness* control no longer responds at all. The issue is reproducible on every boot. This problem is not present when using patchset v8, where both color and brightness work as expected.
> > > > >
> > > > > Important detail: the issue occurs even **without** asusctl installed, so it must be within the kernel HID/WMI handling and is unrelated to userspace tools.
> > > > >
> > > > > Output of dmesg is available here [1], please let me know if any additional information is required.
> > > > >
> > > > > Thank you for your time and work on supporting these ASUS laptops.
> > > > >
> > > > > Best regards,
> > > > > Kelsios
> > > > >
> > > > > [1] https://pastebin.com/ZFC13Scf
> > > >
> > > > [ 1.035986] asus 0003:0B05:19B6.0001: Asus failed to receive handshake ack: -32
> > > >
> > > > Oh yeah, asus_kbd_init no longer works with spurious inits so it broke
> > > > devices marked with QUIRK_ROG_NKEY_LEGACY
> > > >
> > > > There are three ways to approach this. One is to ignore the error...
> > > > second is to drop the quirk... third is to check for the usages for ID1, ID2...
> > > >
> > > > I would tend towards dropping the ID2 init and ignoring the error for
> > > > ID1... Unless an EPIPE would cause the device to close
> > >
> > > Benjamin correctly caught the deviation
> >
> > BTW, we want to record this knowledge also into the changelog so that the
> > next person who'd want to make the check stricter does not need to guess
> > whether it was based on a real observed problem or mere guessing there
> > could be a problem.
>
> If we keep the spurious inits, the stricter check will catch them and
> throw errors. This is problematic.
>
> Kelsios, you have a device that allegedly would not work without those
> inits. Perhaps you could try removing the legacy quirk from your
> device and see if everything is ok?
>
> If it is, then we have a tested device and a case for removing the
> legacy quirk altogether
Hi all,
Is there any progress on this?
--
i.
^ permalink raw reply
* Re: [PATCH v4 1/1] Input: cros_ec_keyb - add function key support
From: Fabio Baltieri @ 2026-01-07 10:24 UTC (permalink / raw)
To: Simon Glass
Cc: Dmitry Torokhov, Benson Leung, Guenter Roeck, Tzung-Bi Shih,
linux-input, chrome-platform, linux-kernel
In-Reply-To: <CAFLszTgMeRRi_=Bs6wzdZZGDn9DbmnZEdkbqPOhi0rqDs7DnPQ@mail.gmail.com>
On Tue, Jan 06, 2026 at 09:22:06AM -0700, Simon Glass wrote:
> Hi Fabio,
>
> On Tue, 6 Jan 2026 at 04:29, Fabio Baltieri <fabiobaltieri@chromium.org> wrote:
> >
> > Add support for handling an Fn button and sending separate keycodes for
> > a subset of keys in the matrix defined in the upper half of the keymap.
> >
> > Signed-off-by: Fabio Baltieri <fabiobaltieri@chromium.org>
> > ---
> > drivers/input/keyboard/cros_ec_keyb.c | 174 +++++++++++++++++++++++---
> > 1 file changed, 158 insertions(+), 16 deletions(-)
> >
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
Thanks again!
>
> > diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> > index 1c6b0461dc35..74ac1700b104 100644
> > --- a/drivers/input/keyboard/cros_ec_keyb.c
> > +++ b/drivers/input/keyboard/cros_ec_keyb.c
> > @@ -29,6 +29,11 @@
> >
> > #include <linux/unaligned.h>
> >
> > +/* Maximum size of the normal key matrix, this is limited by the host command
> > + * key_matrix field defined in ec_response_get_next_data_v3
> > + */
> > +#define CROS_EC_KEYBOARD_COLS_MAX 18
> > +
> > /**
> > * struct cros_ec_keyb - Structure representing EC keyboard device
> > *
> > @@ -44,6 +49,11 @@
> > * @bs_idev: The input device for non-matrix buttons and switches (or NULL).
> > * @notifier: interrupt event notifier for transport devices
> > * @vdata: vivaldi function row data
> > + * @has_fn_map: whether the driver use an fn function map layer
>
> How about: driver uses an fn function-map layer
Yeah sounds good, will send a v5 with that comment tweaked.
^ permalink raw reply
* Re: [RFC PATCH 0/6] Input: New EV_BTN event for generic buttons
From: Ivan Gorinov @ 2026-01-07 5:44 UTC (permalink / raw)
To: Tomasz Pakuła
Cc: dmitry.torokhov, corbet, jikos, bentiss, linux-input,
linux-kernel, linux-doc, vi, peter.hutterer
In-Reply-To: <20260104213132.163904-1-tomasz.pakula.oficjalny@gmail.com>
On Sun, Jan 04, 2026 at 10:31:26PM +0100, Tomasz Pakuła wrote:
> I'm eagerly waiting for comments, recommendations and critique. Currently, there
> isn't a way to poll states of all buttons like with EVIOCGKEY but I'm not sure
> if it's needed? I added INPUT_MAX_KEYS just for some sane limits BUT I don't see
> a real use for it. Instead of this define, we could just use U16_MAX. 65k of
> buttons ought to be enough for ANYBODY :D
If I understand correctly, EVIOCGKEY is the only way to read initial state of buttons
and switches when the input device is opened with /dev/input/event# interface.
Legacy /dev/input/js# interface sends those initial states immediately after openeing
as JS_EVENT_BUTTON | JS_EVENT_INIT event type.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox