[PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[Paolo Pisati]

Add support for the detachable USB/Bluetooth keyboard of the ASUS
Zenbook Duo line (UX8406MA, UX8406CA, UX8407AA): hotkeys, keyboard
backlight and the platform profile key, over both transports.

This patchset is a collective effort, gathered here:

  https://github.com/NeroReflex/asusctl/issues/25

Tested on a UX8407AA against 7.3, docked and over Bluetooth: hotkeys,
keyboard backlight, Fn+F profile cycling, and the touchpad staying with
hid-multitouch. Rebecca tested v2 the same way on her UX8407AA.

Rebecca Mara Müller posted an independent patch for the UX8407AA
keyboard in August [1]. This series follows it in using
HID_CONNECT_HIDINPUT_FORCE and in binding the IDs by group, and
carries her re-sent handshake as the last patch.

Changes in v3:
- Queue at most one platform profile cycle at a time, so that a device
  repeating the key cannot grow the worker's action list (Sashiko).
- Bind the Bluetooth IDs to HID_GROUP_GENERIC as well: over Bluetooth
  the touchpad is a second HID device with the same IDs, which hid-asus
  must leave to hid-multitouch (Sashiko).
- Say "15 data bytes, 16 with the report ID" where the feature report
  size is discussed: hid_report_len() counts the ID, so the 16 byte
  handshake is sent whole (Sashiko).
- Add Rebecca's Tested-by, and Assisted-by on her patch at her request.

Changes in v2:
- Rebase onto hid.git#for-7.4/asus; QUIRK_ZENBOOK_DUO_KEYBOARD moves to
  BIT(16) as BIT(15) is taken now.
- Fold the USB descriptor offsets and the padding removal into the
  descriptor fixup patch; fix the padding removal, which read past the
  end of the descriptor and could write past the end of the new one,
  and move the whole remainder of the descriptor instead of 12 bytes,
  as the Zenbook Duo collection does not end there (Sashiko).
- End the fixup's branch chain with a plain else so clang does not warn
  that rsize_orig may be uninitialized (kernel test robot, Nathan).
- Drop the MyASUS key mapping, which is upstream as KEY_PROG1 now and
  matches asus-nb-wmi (Sashiko).
- Use HID_CONNECT_HIDINPUT_FORCE on the vendor interface instead of
  injecting a fake keyboard collection into its descriptor (Sashiko
  flagged the malformed padding item).
- Cycle the platform profile from the driver's worker instead of the
  HID event callback, consume the event, and only build the call when
  ACPI_PLATFORM_PROFILE is reachable; v1 did not link on architectures
  without ACPI (Sashiko).
- New: cap feature report writes at the declared report length; the
  Zenbook Duo does not answer the 64 byte writes the driver sends for
  the backlight since 7.3.
- Bind the USB IDs to HID_GROUP_GENERIC so hid-multitouch keeps the
  touchpad interfaces, and leave Fn-lock out, see that patch.
- New: re-send the handshake after probe (from Rebecca's patch).
- Use the "HID: asus:" subject prefix, write commit messages for every
  patch, and fix the Signed-off-by chains.

Not covered: Fn-lock (see patch 6). On the UX8407AA the screen swap key
sends a Super+P chord by itself; the 0x9c mapping is for the UX8406MA.
Sashiko also pointed out, on v2 4/7, that the worker's WMI fan fallback
takes driver_input_lock while hid_device_remove() holds it around
asus_remove(), which waits for the worker; that predates this series
and is better fixed separately.

v2: https://lore.kernel.org/r/20261009153459.124752-1-p.pisati@gmail.com
v1: https://lore.kernel.org/r/20260513163248.16483-1-p.pisati@gmail.com
[1] https://lore.kernel.org/r/20260811125548.1975748-1-rebecca.mara@posteo.de

Joshua Leivenzon (4):
  HID: asus: Fix up Zenbook Duo report descriptors
  HID: asus: Add missing Zenbook Duo hotkeys
  HID: asus: Force hid-input to bind to the Zenbook Duo hotkey interface
  HID: asus: Cycle the platform profile from the Zenbook Duo profile key

Luke Jones (1):
  HID: asus: add prod-id, quirk for Zenbook Duo keyboard

Paolo Pisati (1):
  HID: asus: Do not send feature reports larger than declared

Rebecca Mara Müller (1):
  HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

 drivers/hid/hid-asus.c | 194 +++++++++++++++++++++++++++++++++++++----
 drivers/hid/hid-ids.h  |   6 ++
 2 files changed, 185 insertions(+), 15 deletions(-)


base-commit: 8099f9da59f1c338bf88e25b7aa2a7fdf840879c
-- 
2.43.0

[PATCH v3 1/7] HID: asus: Fix up Zenbook Duo report descriptors

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

The Zenbook Duo keyboards (UX8406MA, UX8406CA, UX8407AA) ship the same
broken vendor hotkey collection as the T100CHI/T90CHI keyboard docks:
the Input item of report 0x5a is preceded by a single Usage (76h)
instead of a Usage Minimum/Maximum range, so none of the hotkey codes
get mapped and every key press logs

  Unmapped Asus vendor usagepage code 0x76

Extend the T100CHI/T90CHI fixup to the Zenbook Duo: the descriptor is
90 bytes long with the bogus usage at offset 66 on the USB hotkey
interface, and 257 bytes long with the usage at offset 176 over
Bluetooth.

The dock fixup only moves the 12 bytes between the usage and the End
Collection item, as nothing but a bogus trailing 0 byte follows them.
That is not true of the Zenbook Duo: the collection goes on with a 15
byte feature report (also ID 0x5a) after the Input item, and over
Bluetooth a further collection follows it, which a 12 byte move
corrupts, leaving stray 0 bytes at the end. Move everything after the
usage instead, after dropping any trailing 0 bytes, and allocate the
two bytes the usage range adds. The result for the T100CHI/T90CHI is
unchanged.

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
[pisati: fold the USB offsets and the padding removal into this patch,
 bound the padding removal, move the whole tail of the descriptor, and
 end the branch chain with a plain else so clang does not warn that
 rsize_orig may be uninitialized]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 38 ++++++++++++++++++++++++++------------
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index bd46aba6622a..34739198d90e 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -100,6 +100,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
 #define QUIRK_ROG_ALLY_XPAD		BIT(13)
 #define QUIRK_HID_FN_LOCK		BIT(14)
 #define QUIRK_FILTER_CAMERA_COMPANION	BIT(15)
+#define QUIRK_ZENBOOK_DUO_KEYBOARD	BIT(16)
 
 #define I2C_KEYBOARD_QUIRKS			(QUIRK_FIX_NOTEBOOK_REPORT | \
 						 QUIRK_NO_INIT_REPORTS | \
@@ -1579,43 +1580,56 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
 		rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
 	}
-	/* For the T100CHI/T90CHI keyboard dock */
-	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
+	/* For the T100CHI/T90CHI keyboard dock and Zenbook Duo keyboards */
+	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
 		int rsize_orig;
 		int offs;
 
 		if (drvdata->quirks & QUIRK_T100CHI) {
 			rsize_orig = 403;
 			offs = 388;
-		} else {
+		} else if (drvdata->quirks & QUIRK_T90CHI) {
 			rsize_orig = 306;
 			offs = 291;
+		} else if (hid_is_usb(hdev)) { /* QUIRK_ZENBOOK_DUO_KEYBOARD */
+			rsize_orig = 90;
+			offs = 66;
+		} else { /* QUIRK_ZENBOOK_DUO_KEYBOARD over Bluetooth */
+			rsize_orig = 257;
+			offs = 176;
 		}
 
 		/*
 		 * Change Usage (76h) to Usage Minimum (00h), Usage Maximum
-		 * (FFh) and clear the flags in the Input() byte.
-		 * Note the descriptor has a bogus 0 byte at the end so we
-		 * only need 1 extra byte.
+		 * (FFh) and clear the flags in the Input() byte, shifting
+		 * the rest of the descriptor by the 2 bytes that adds. Drop
+		 * the bogus 0 bytes some descriptors end with first, but
+		 * never the Input() item that follows the usage.
 		 */
 		if (*rsize == rsize_orig &&
 			rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
+			unsigned int new_rsize = rsize_orig;
 			__u8 *new_rdesc;
 
-			new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
+			while (new_rsize > offs + 14 && rdesc[new_rsize - 1] == 0)
+				--new_rsize;
+
+			new_rdesc = devm_kzalloc(&hdev->dev, new_rsize + 2,
 						 GFP_KERNEL);
 			if (!new_rdesc)
 				return rdesc;
 
 			hid_info(hdev, "Fixing up %s keyb report descriptor\n",
-				drvdata->quirks & QUIRK_T100CHI ?
-				"T100CHI" : "T90CHI");
+				drvdata->quirks & QUIRK_T100CHI ? "T100CHI" :
+				drvdata->quirks & QUIRK_T90CHI ? "T90CHI" :
+				"Zenbook Duo");
 
-			memcpy(new_rdesc, rdesc, rsize_orig);
-			*rsize = rsize_orig + 1;
+			memcpy(new_rdesc, rdesc, new_rsize);
+			*rsize = new_rsize + 2;
 			rdesc = new_rdesc;
 
-			memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
+			memmove(rdesc + offs + 4, rdesc + offs + 2,
+				new_rsize - (offs + 2));
 			rdesc[offs] = 0x19;
 			rdesc[offs + 1] = 0x00;
 			rdesc[offs + 2] = 0x29;
-- 
2.43.0

[PATCH v3 2/7] HID: asus: Add missing Zenbook Duo hotkeys

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

Map the Zenbook Duo "screen swap" hotkey (vendor usage 0x9c) to
KEY_F19, like the other ASUS vendor keys that have no dedicated
keycode, so that userspace can bind it.

The mappings from the ROG Ally onwards belong to devices with built-in
keyboards and can share keycodes freely. The Zenbook Duo keyboard
cannot: it is a standard USB/Bluetooth device and can be connected to
another ASUS machine handled by this driver. Document that above the
ROG Ally mappings.

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
[pisati: drop the MyASUS key (0x86) mapping, 2061075360182 ("HID:
 asus: support the Zenbook A16 (UX3607OA) keyboard") maps it to
 KEY_PROG1 like asus-nb-wmi does]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 34739198d90e..242e273e4cb3 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1264,6 +1264,19 @@ static int asus_input_mapping(struct hid_device *hdev,
 		case 0xb3: asus_map_key_clear(KEY_PROG3);	break; /* Fn+Left next aura */
 		case 0x6a: asus_map_key_clear(KEY_F13);		break; /* Screenpad toggle */
 		case 0x4b: asus_map_key_clear(KEY_F14);		break; /* Arrows/Pg-Up/Dn toggle */
+		case 0x9c: asus_map_key_clear(KEY_F19);		break; /* Screen swap */
+
+		/*
+		 * Mutually exclusive section: Special keys from different devices
+		 * can bind to the same keycodes without concern, as they will never
+		 * conflict.
+		 *
+		 * Note that devices with removable keyboards that connect over a
+		 * standard interface (e.g. Zenbook Duo UX8406 with USB/Bluetooth) do
+		 * not belong in this section, as such keyboards can be connected to
+		 * another ASUS device that also uses this driver for its own keyboard.
+		 */
+		/* ROG Ally */
 		case 0xa5: asus_map_key_clear(KEY_F15);		break; /* ROG Ally left back */
 		case 0xa6: asus_map_key_clear(KEY_F16);		break; /* ROG Ally QAM button */
 		case 0xa7: asus_map_key_clear(KEY_F17);		break; /* ROG Ally ROG long-press */
-- 
2.43.0

[PATCH v3 3/7] HID: asus: Force hid-input to bind to the Zenbook Duo hotkey interface

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

The Zenbook Duo USB keyboard reports its hotkeys on a dedicated
interface, separate from the keyboard and consumer control ones, that
only contains ASUS vendor usage collections. hid-input does not
consider those an input application and never binds to the interface,
so the hotkeys are never mapped.

Pass HID_CONNECT_HIDINPUT_FORCE for the interface of Zenbook Duo
keyboards that carries the ASUS vendor collection, which skips that
check, so the vendor usages go through asus_input_mapping() like on
any other ASUS keyboard. The other interfaces either have a proper
input application or nothing worth an input device.

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
[pisati: use HID_CONNECT_HIDINPUT_FORCE on the vendor interface instead
 of injecting a fake keyboard collection into its report descriptor]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 242e273e4cb3..d69431615c27 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1405,6 +1405,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 	struct asus_drvdata *drvdata;
 	struct hid_report *rep;
 	bool is_vendor = false;
+	unsigned int connect_mask;
 	int ret;
 
 	drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
@@ -1500,7 +1501,18 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		return ret;
 	}
 
-	ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+	/*
+	 * The Zenbook Duo keyboard reports its hotkeys on a dedicated USB
+	 * interface that only has vendor usage collections, which hid-input
+	 * does not consider an input application. Make it bind to the
+	 * interface carrying the ASUS vendor collection anyway so the
+	 * hotkeys get mapped.
+	 */
+	connect_mask = HID_CONNECT_DEFAULT;
+	if ((drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) && is_vendor)
+		connect_mask |= HID_CONNECT_HIDINPUT_FORCE;
+
+	ret = hid_hw_start(hdev, connect_mask);
 	if (ret) {
 		asus_worker_stop(drvdata->worker);
 		hid_err(hdev, "Asus hw start failed: %d\n", ret);
-- 
2.43.0

[PATCH v3 4/7] HID: asus: Cycle the platform profile from the Zenbook Duo profile key

[Paolo Pisati]

From: Joshua Leivenzon <hacker1024@users.sourceforge.net>

The Zenbook Duo keyboard reports Fn+F, the performance mode key, as
vendor usage 0x9d. On the built-in keyboards of other ASUS laptops the
same key arrives through asus-wmi, which cycles the platform profile
in response. Do the same here so the key works on the detachable
keyboard too.

asus_event() runs from the HID input path, which for USB is the URB
completion handler, while platform_profile_cycle() takes a mutex, so run
it from the driver's worker like the Fn-lock toggle, and consume the
event. Queue at most one cycle at a time, so that a device repeating the
key cannot grow the worker's list. Only call it when the platform
profile class is reachable: it is not built on architectures without
ACPI, where HID_ASUS still is, and it may be a module while HID_ASUS is
built in.

Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
[pisati: defer platform_profile_cycle() to the worker and queue at
 most one cycle, return 1 from asus_event() instead of propagating
 its return value, and guard the call with
 IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE)]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 67 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d69431615c27..b127f5c38f60 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -29,6 +29,7 @@
 #include <linux/input/mt.h>
 #include <linux/usb.h> /* For to_usb_interface for T100 touchpad intf check */
 #include <linux/power_supply.h>
+#include <linux/platform_profile.h>
 #include <linux/leds.h>
 
 #include "hid-ids.h"
@@ -115,6 +116,7 @@ enum asus_work_action_type {
 	FN_LOCK_SYNC,
 	BRIGHTNESS_SET,
 	WMI_FAN,
+	PLATFORM_PROFILE_CYCLE,
 };
 
 struct hid_raw_event_data {
@@ -423,6 +425,42 @@ static int asus_kbd_fn_lock_set(struct asus_drvdata *drvdata, bool enabled)
 	return 0;
 }
 
+static int asus_platform_profile_cycle(struct asus_drvdata *drvdata)
+{
+	struct asus_worker *worker = drvdata->worker;
+	struct asus_work_action *action, *pending;
+	unsigned long flags;
+	int ret = 0;
+
+	if (!IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE))
+		return 0;
+
+	spin_lock_irqsave(&worker->lock, flags);
+
+	/*
+	 * One pending cycle is enough: a key press cannot outrun the
+	 * worker, and a device repeating the key must not grow the list.
+	 */
+	list_for_each_entry(pending, &worker->actions, node) {
+		if (pending->type == PLATFORM_PROFILE_CYCLE)
+			goto unlock;
+	}
+
+	action = kzalloc_obj(struct asus_work_action, GFP_ATOMIC);
+	if (!action) {
+		ret = -ENOMEM;
+		goto unlock;
+	}
+
+	action->type = PLATFORM_PROFILE_CYCLE;
+	INIT_LIST_HEAD(&action->node);
+	asus_worker_schedule(worker, action);
+
+unlock:
+	spin_unlock_irqrestore(&worker->lock, flags);
+	return ret;
+}
+
 static int asus_kbd_wmi_fan_send(struct asus_drvdata *drvdata, u8 *report_data,
 				 size_t report_size)
 {
@@ -459,8 +497,25 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
 	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",
-			 usage->hid & HID_USAGE);
+		/*
+		 * Some vendor usages do not map to a key and need special
+		 * handling.
+		 */
+		switch (usage->hid & HID_USAGE) {
+		case 0x9d: /* Zenbook Duo Fn+F: cycle the platform profile */
+			if (value) {
+				ret = asus_platform_profile_cycle(drvdata);
+				if (ret) {
+					hid_err(hdev, "Failed to cycle the platform profile: %d\n",
+						ret);
+					return ret;
+				}
+			}
+			return 1;
+		default:
+			hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
+				 usage->hid & HID_USAGE);
+		}
 	}
 
 	if (usage->type == EV_KEY && value) {
@@ -765,6 +820,7 @@ static void asus_work(struct work_struct *work)
 	struct asus_worker *worker = container_of(work, struct asus_worker, work);
 	struct asus_work_action *action = NULL;
 	unsigned long flags;
+	int ret;
 
 	/* Save the action to be performed and clear the flag */
 	spin_lock_irqsave(&worker->lock, flags);
@@ -788,6 +844,13 @@ static void asus_work(struct work_struct *work)
 	case WMI_FAN:
 		asus_kbd_wmi_fan(worker->hdev, &action->data.fan_hid_data);
 		break;
+	case PLATFORM_PROFILE_CYCLE:
+		if (!IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE))
+			break;
+		ret = platform_profile_cycle();
+		if (ret)
+			hid_dbg(worker->hdev, "Failed to cycle the platform profile: %d\n", ret);
+		break;
 	default:
 		hid_err(worker->hdev, "Invalid action type: %d\n", action->type);
 		break;
-- 
2.43.0

[PATCH v3 5/7] HID: asus: Do not send feature reports larger than declared

[Paolo Pisati]

The keyboard backlight and Fn-lock commands are sent as 64 byte
feature reports, the size of report 0x5a on the ROG keyboards. The
Zenbook Duo keyboards declare feature report 0x5a with 15 data bytes,
16 with the report ID, and do not answer writes larger than that: the
control transfer times out over USB and fails with -EIO over
Bluetooth, so the backlight cannot be set, while the 16 byte handshake
goes through.

Cap feature report writes at the length the device declares for the
report, when it declares it. hid_report_len() counts the report ID, so
the handshake and the other commands up to that size are sent as they
are.

Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index b127f5c38f60..7b17553e94b6 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -632,6 +632,18 @@ static int asus_raw_event(struct hid_device *hdev,
 
 static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t buf_size)
 {
+	struct hid_report *report;
+
+	/*
+	 * Do not send more than the declared size of the report, report ID
+	 * included: the Zenbook Duo keyboards declare 15 data bytes for
+	 * report 0x5a, 16 on the wire like the handshake, and do not answer
+	 * the 64 byte writes sized for the ROG keyboards.
+	 */
+	report = hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[buf[0]];
+	if (report)
+		buf_size = min_t(size_t, buf_size, hid_report_len(report));
+
 	u8 *dmabuf __free(kfree) = kmemdup(buf, buf_size, GFP_KERNEL);
 	if (!dmabuf)
 		return -ENOMEM;
-- 
2.43.0

[PATCH v3 6/7] HID: asus: add prod-id, quirk for Zenbook Duo keyboard

[Paolo Pisati]

From: Luke Jones <luke@ljones.dev>

The 2024/2025/2026 ASUS Zenbook Duo has a similar keyboard setup as
many of the ROG range of laptops, with the same init sequence and
control for backlight. Enable the keyboard control and backlight by:
- adding the product ID for 2024/2025/2026 Zenbook Duo keyboard MCU
- adding the Bluetooth Zenbook Duo keyboard IDs

Intended for the UX8406-style product line with the fully removable
keyboard.

The keyboard also exposes its touchpad as a separate HID device with
the same IDs, an interface of the USB device and a second device over
Bluetooth, so bind the IDs to the HID_GROUP_GENERIC group only, like
the ROG Z13 Folio, and leave the touchpad to hid-multitouch.

Fn-lock is left out for now: with QUIRK_HID_FN_LOCK the Fn-lock report
is sent to every interface of the device, before the handshake, and on
the UX8407AA that stalled the hotkey interface for good. It can be
added back once the driver only sends it where and when it belongs.

Signed-off-by: Luke Jones <luke@ljones.dev>
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
Signed-off-by: Ivan Levchenko <me@livan.pro>
[pisati: bind the IDs to HID_GROUP_GENERIC only, drop
 QUIRK_HID_FN_LOCK]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
---
 drivers/hid/hid-asus.c | 24 ++++++++++++++++++++++++
 drivers/hid/hid-ids.h  |  6 ++++++
 2 files changed, 30 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 7b17553e94b6..503396963eeb 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1849,6 +1849,30 @@ static const struct hid_device_id asus_devices[] = {
 	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
 	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
 		USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD) },
+	/*
+	 * Zenbook Duo detachable keyboards. The touchpad shows up as a
+	 * separate HID device with the same IDs, over USB and Bluetooth:
+	 * bind to the HID_GROUP_GENERIC group only, like the ROG Z13 Folio,
+	 * so that hid-multitouch keeps handling it.
+	 */
+	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
+	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
+	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
+	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, asus_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b3aca5aa9176..59f44204d738 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -228,6 +228,12 @@
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD	0x1866
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2	0x19b6
 #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_FOLIO		0x1a30
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2c
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2d
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf2
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf3
+#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd7
+#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd8
 #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR		0x18c6
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY		0x1abe
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X		0x1b4c
-- 
2.43.0

[PATCH v3 7/7] HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

[Paolo Pisati]

From: Rebecca Mara Müller <rebecca.mara@posteo.de>

When docked, the Zenbook Duo keyboard powers up in F-key mode and
needs the "ASUS Tech.Inc." handshake to emit hotkeys at all. The
handshake sent from probe is lost again when hid-multitouch configures
the touchpad on the sibling USB interface, which resets the keyboard
to F-key mode, so the hotkeys stop working as soon as the touchpad is
set up.

Re-send the handshake from delayed work two seconds after probe.

Assisted-by: LLM
Signed-off-by: Rebecca Mara Müller <rebecca.mara@posteo.de>
Link: https://lore.kernel.org/r/20260811125548.1975748-1-rebecca.mara@posteo.de
[pisati: taken from Rebecca's standalone UX8407AA patch and adapted to
 the current driver; initialize and cancel the work unconditionally]
Assisted-by: LLM
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
---
 drivers/hid/hid-asus.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 503396963eeb..ce413eb011c4 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -173,6 +173,7 @@ struct asus_drvdata {
 	unsigned long battery_next_query;
 	struct asus_hid_listener listener;
 	bool fn_lock;
+	struct delayed_work reinit_work;
 };
 
 static int asus_report_battery(struct asus_drvdata *, u8 *, int);
@@ -1474,6 +1475,17 @@ static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
 	return 0;
 }
 
+static void asus_reinit_work(struct work_struct *work)
+{
+	struct asus_drvdata *drvdata = container_of(work, struct asus_drvdata,
+						    reinit_work.work);
+	int ret;
+
+	ret = asus_kbd_init(drvdata->hdev, FEATURE_KBD_REPORT_ID);
+	if (ret < 0)
+		hid_warn(drvdata->hdev, "Failed to re-initialize the keyboard: %d\n", ret);
+}
+
 static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 {
 	struct hid_report_enum *rep_enum;
@@ -1570,6 +1582,8 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 			is_vendor = true;
 	}
 
+	INIT_DELAYED_WORK(&drvdata->reinit_work, asus_reinit_work);
+
 	ret = asus_worker_create(hdev, drvdata);
 	if (ret) {
 		hid_warn(hdev, "Failed to initialize worker: %d\n", ret);
@@ -1605,6 +1619,16 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		}
 	}
 
+	/*
+	 * When docked, the Zenbook Duo keyboard drops back to F-key mode when
+	 * hid-multitouch configures the touchpad on the sibling USB interface,
+	 * which can happen after the handshake above. Send it again once the
+	 * dust has settled.
+	 */
+	if (is_vendor && (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) &&
+	    hid_is_usb(hdev))
+		schedule_delayed_work(&drvdata->reinit_work, msecs_to_jiffies(2000));
+
 	/* Laptops keyboard backlight is always at 0x5a */
 	if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
 	    (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
@@ -1639,6 +1663,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
 
 	return 0;
 err_stop_hw:
+	cancel_delayed_work_sync(&drvdata->reinit_work);
 	if (drvdata->listener.brightness_set)
 		asus_hid_unregister_listener(&drvdata->listener);
 
@@ -1654,6 +1679,7 @@ static void asus_remove(struct hid_device *hdev)
 	if (drvdata->listener.brightness_set)
 		asus_hid_unregister_listener(&drvdata->listener);
 
+	cancel_delayed_work_sync(&drvdata->reinit_work);
 	asus_worker_stop(drvdata->worker);
 	hid_hw_stop(hdev);
 }
-- 
2.43.0

Re: [PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[Rebecca Mara Müller]

On Tue, Oct 13, 2026 at 12:39:57PM +0200, Paolo Pisati wrote:
> - Bind the Bluetooth IDs to HID_GROUP_GENERIC as well: over Bluetooth
>   the touchpad is a second HID device with the same IDs, which hid-asus
>   must leave to hid-multitouch (Sashiko).

I re-tested v3 the same way as v2 on a UX8407AA: applied on top of
base-commit 8099f9da59f1 (the resulting hid-asus.c matches the index
line of 7/7), built unmodified as an out-of-tree module against a
7.0.11-based distribution kernel, with my userspace workaround stopped.

- Docked (USB, 0b05:1cd7), module loaded with the keyboard attached and
  then three dock cycles: the five keyboard interfaces bind to hid-asus,
  the touchpad stays with hid-multitouch. Hotkeys, keyboard backlight,
  volume/mute, mic mute, the screenshot key and Fn+F profile cycling
  (balanced <-> performance) work. The delayed handshake re-send never
  failed.
- Bluetooth (0b05:1cd8): the keyboard device (generic group) binds to
  hid-asus and the touchpad device (multitouch group) to hid-multitouch,
  as intended by the v3 change. The same keys and the touchpad work.

The screen brightness keys emit KEY_BRIGHTNESSDOWN/KEY_BRIGHTNESSUP when
docked (checked with an evdev reader).

My Tested-by from v2 holds for v3:

Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA

Thanks,
Rebecca

Re: [PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[Denis Benato]

13 ott 2026 14:45:22 Rebecca Mara Müller <rebecca.mara@posteo.de>:

> On Tue, Oct 13, 2026 at 12:39:57PM +0200, Paolo Pisati wrote:
>> - Bind the Bluetooth IDs to HID_GROUP_GENERIC as well: over Bluetooth
>>   the touchpad is a second HID device with the same IDs, which hid-asus
>>   must leave to hid-multitouch (Sashiko).
>
> I re-tested v3 the same way as v2 on a UX8407AA: applied on top of
> base-commit 8099f9da59f1 (the resulting hid-asus.c matches the index
> line of 7/7), built unmodified as an out-of-tree module against a
> 7.0.11-based distribution kernel, with my userspace workaround stopped.
>
> - Docked (USB, 0b05:1cd7), module loaded with the keyboard attached and
>   then three dock cycles: the five keyboard interfaces bind to hid-asus,
>   the touchpad stays with hid-multitouch. Hotkeys, keyboard backlight,
>   volume/mute, mic mute, the screenshot key and Fn+F profile cycling
>   (balanced <-> performance) work. The delayed handshake re-send never
>   failed.
> - Bluetooth (0b05:1cd8): the keyboard device (generic group) binds to
>   hid-asus and the touchpad device (multitouch group) to hid-multitouch,
>   as intended by the v3 change. The same keys and the touchpad work.
>
> The screen brightness keys emit KEY_BRIGHTNESSDOWN/KEY_BRIGHTNESSUP when
> docked (checked with an evdev reader).
>
> My Tested-by from v2 holds for v3:
>

Hi all,

I'll re-send this mail as the other client formatted in html and the mailing list rejected the message. Apologies.

I'm currently on vacation so I will need to postpone reviewing this.

My greatest concern is with report size: every device needs its own and hardcoding it is not an option anymore because no device can be fully made happy (and working): xg mobile is 300, ally and new ROGs is 64, some have 32, some 16 and I think TP is 15.


I have yet to look at the patch that changes the report size but please make the report size variable reading it from the descriptor.

I will be beack the 18th October.

Best regards,
Denis



> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
>
> Thanks,
> Rebecca

Re: [PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[Paolo Pisati]

On Tue, Oct 13, 2026 at 04:56:39PM +0300, Denis Benato wrote:
> My greatest concern is with report size: every device needs its own and
> hardcoding it is not an option anymore because no device can be fully
> made happy (and working): xg mobile is 300, ally and new ROGs is 64,
> some have 32, some 16 and I think TP is 15.
>
> I have yet to look at the patch that changes the report size but please
> make the report size variable reading it from the descriptor.

Isn't 5/7 what you are looking for?

asus_kbd_set_report() looks up the feature report with the ID in
buf[0] and never sends more than hid_report_len() of it, that is what
the descriptor declares, report ID included. The Zenbook Duo declares
15 data bytes for report 0x5a, so the 64 byte backlight buffer goes
out as 16 bytes, like the handshake, and the keyboard answers it.
A device declaring 64 or more sees no change.

No hurry, enjoy the vacation.
-- 
bye,
p.

Re: [PATCH v3 1/7] HID: asus: Fix up Zenbook Duo report descriptors

[Denis Benato]

On 10/13/26 12:39, Paolo Pisati wrote:
> From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
>
> The Zenbook Duo keyboards (UX8406MA, UX8406CA, UX8407AA) ship the same
> broken vendor hotkey collection as the T100CHI/T90CHI keyboard docks:
> the Input item of report 0x5a is preceded by a single Usage (76h)
> instead of a Usage Minimum/Maximum range, so none of the hotkey codes
> get mapped and every key press logs
>
>   Unmapped Asus vendor usagepage code 0x76
>
> Extend the T100CHI/T90CHI fixup to the Zenbook Duo: the descriptor is
> 90 bytes long with the bogus usage at offset 66 on the USB hotkey
> interface, and 257 bytes long with the usage at offset 176 over
> Bluetooth.
>
> The dock fixup only moves the 12 bytes between the usage and the End
> Collection item, as nothing but a bogus trailing 0 byte follows them.
> That is not true of the Zenbook Duo: the collection goes on with a 15
> byte feature report (also ID 0x5a) after the Input item, and over
> Bluetooth a further collection follows it, which a 12 byte move
> corrupts, leaving stray 0 bytes at the end. Move everything after the
> usage instead, after dropping any trailing 0 bytes, and allocate the
> two bytes the usage range adds. The result for the T100CHI/T90CHI is
> unchanged.
>
> Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
> [pisati: fold the USB offsets and the padding removal into this patch,
>  bound the padding removal, move the whole tail of the descriptor, and
>  end the branch chain with a plain else so clang does not warn that
>  rsize_orig may be uninitialized]
> Assisted-by: LLM
> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA

Hello Paolo,

I am back from vacation and I can therefore getting on with my review.

I don't know if I have enough time for all patches but I will try!

Thanks for looking into these devices!

> ---
>  drivers/hid/hid-asus.c | 38 ++++++++++++++++++++++++++------------
>  1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index bd46aba6622a..34739198d90e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -100,6 +100,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>  #define QUIRK_ROG_ALLY_XPAD		BIT(13)
>  #define QUIRK_HID_FN_LOCK		BIT(14)
>  #define QUIRK_FILTER_CAMERA_COMPANION	BIT(15)
> +#define QUIRK_ZENBOOK_DUO_KEYBOARD	BIT(16)
>  
>  #define I2C_KEYBOARD_QUIRKS			(QUIRK_FIX_NOTEBOOK_REPORT | \
>  						 QUIRK_NO_INIT_REPORTS | \
> @@ -1579,43 +1580,56 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
>  		hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
>  		rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
>  	}
> -	/* For the T100CHI/T90CHI keyboard dock */
> -	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
> +	/* For the T100CHI/T90CHI keyboard dock and Zenbook Duo keyboards */
> +	if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
>  		int rsize_orig;
>  		int offs;
>  
>  		if (drvdata->quirks & QUIRK_T100CHI) {
>  			rsize_orig = 403;
>  			offs = 388;
> -		} else {
> +		} else if (drvdata->quirks & QUIRK_T90CHI) {
>  			rsize_orig = 306;
>  			offs = 291;
> +		} else if (hid_is_usb(hdev)) { /* QUIRK_ZENBOOK_DUO_KEYBOARD */
> +			rsize_orig = 90;
> +			offs = 66;
> +		} else { /* QUIRK_ZENBOOK_DUO_KEYBOARD over Bluetooth */
> +			rsize_orig = 257;
> +			offs = 176;
>  		}

Please either use a switch or otherwise make each if check one quirk, eventually use other nested if(s)
to check for bluetooth in order to not cause future problems if this code needs adding other models.

Also unless it's for counting try to use explicit types matching what you are trying to do like u8 or u16 etc...

>  
>  		/*
>  		 * Change Usage (76h) to Usage Minimum (00h), Usage Maximum
> -		 * (FFh) and clear the flags in the Input() byte.
> -		 * Note the descriptor has a bogus 0 byte at the end so we
> -		 * only need 1 extra byte.
> +		 * (FFh) and clear the flags in the Input() byte, shifting
> +		 * the rest of the descriptor by the 2 bytes that adds. Drop
> +		 * the bogus 0 bytes some descriptors end with first, but
> +		 * never the Input() item that follows the usage.
>  		 */
>  		if (*rsize == rsize_orig &&
>  			rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
> +			unsigned int new_rsize = rsize_orig;

In kernel declaration of variables goes on top of the function, in reverse xmas-tree.

The only exception is with _kfree() pattern for pointers.

>  			__u8 *new_rdesc;
>  
> -			new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
> +			while (new_rsize > offs + 14 && rdesc[new_rsize - 1] == 0)
> +				--new_rsize;
> +
> +			new_rdesc = devm_kzalloc(&hdev->dev, new_rsize + 2,
>  						 GFP_KERNEL);
>  			if (!new_rdesc)
>  				return rdesc;
>  
>  			hid_info(hdev, "Fixing up %s keyb report descriptor\n",
> -				drvdata->quirks & QUIRK_T100CHI ?
> -				"T100CHI" : "T90CHI");
> +				drvdata->quirks & QUIRK_T100CHI ? "T100CHI" :
> +				drvdata->quirks & QUIRK_T90CHI ? "T90CHI" :
> +				"Zenbook Duo");
>  

Does the zenbook duo really needs fixing the report descriptor? I think you can avoid this
altogether on this hardware.

Best regards,
Denis Benato

> -			memcpy(new_rdesc, rdesc, rsize_orig);
> -			*rsize = rsize_orig + 1;
> +			memcpy(new_rdesc, rdesc, new_rsize);
> +			*rsize = new_rsize + 2;
>  			rdesc = new_rdesc;
>  
> -			memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
> +			memmove(rdesc + offs + 4, rdesc + offs + 2,
> +				new_rsize - (offs + 2));
>  			rdesc[offs] = 0x19;
>  			rdesc[offs + 1] = 0x00;
>  			rdesc[offs + 2] = 0x29;

Re: [PATCH v3 2/7] HID: asus: Add missing Zenbook Duo hotkeys

[Denis Benato]

On 10/13/26 12:39, Paolo Pisati wrote:
> From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
>
> Map the Zenbook Duo "screen swap" hotkey (vendor usage 0x9c) to
> KEY_F19, like the other ASUS vendor keys that have no dedicated
> keycode, so that userspace can bind it.
>
> The mappings from the ROG Ally onwards belong to devices with built-in
> keyboards and can share keycodes freely. The Zenbook Duo keyboard
> cannot: it is a standard USB/Bluetooth device and can be connected to
> another ASUS machine handled by this driver. Document that above the
> ROG Ally mappings.
>
> Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
> [pisati: drop the MyASUS key (0x86) mapping, 2061075360182 ("HID:
>  asus: support the Zenbook A16 (UX3607OA) keyboard") maps it to
>  KEY_PROG1 like asus-nb-wmi does]
> Assisted-by: LLM

Assisted-by tags have harness:model like this:

Assisted-by: opencode:deepseek-v4.1-flash

> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
> ---
>  drivers/hid/hid-asus.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 34739198d90e..242e273e4cb3 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1264,6 +1264,19 @@ static int asus_input_mapping(struct hid_device *hdev,
>  		case 0xb3: asus_map_key_clear(KEY_PROG3);	break; /* Fn+Left next aura */
>  		case 0x6a: asus_map_key_clear(KEY_F13);		break; /* Screenpad toggle */
>  		case 0x4b: asus_map_key_clear(KEY_F14);		break; /* Arrows/Pg-Up/Dn toggle */
> +		case 0x9c: asus_map_key_clear(KEY_F19);		break; /* Screen swap */
> +
> +		/*
> +		 * Mutually exclusive section: Special keys from different devices
> +		 * can bind to the same keycodes without concern, as they will never
> +		 * conflict.
> +		 *
> +		 * Note that devices with removable keyboards that connect over a
> +		 * standard interface (e.g. Zenbook Duo UX8406 with USB/Bluetooth) do
> +		 * not belong in this section, as such keyboards can be connected to
> +		 * another ASUS device that also uses this driver for its own keyboard.
> +		 */

Maybe shorten this and put it on top of the line it refers too.

Perhaps something like "Keep this unique as it may conflict since the keyboard is bluettoth"
above the F19.

> +		/* ROG Ally */
>  		case 0xa5: asus_map_key_clear(KEY_F15);		break; /* ROG Ally left back */
>  		case 0xa6: asus_map_key_clear(KEY_F16);		break; /* ROG Ally QAM button */
>  		case 0xa7: asus_map_key_clear(KEY_F17);		break; /* ROG Ally ROG long-press */

Re: [PATCH v3 3/7] HID: asus: Force hid-input to bind to the Zenbook Duo hotkey interface

[Denis Benato]

On 10/13/26 12:40, Paolo Pisati wrote:
> From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
>
> The Zenbook Duo USB keyboard reports its hotkeys on a dedicated
> interface, separate from the keyboard and consumer control ones, that
> only contains ASUS vendor usage collections. hid-input does not
> consider those an input application and never binds to the interface,
> so the hotkeys are never mapped.
>
> Pass HID_CONNECT_HIDINPUT_FORCE for the interface of Zenbook Duo
> keyboards that carries the ASUS vendor collection, which skips that
> check, so the vendor usages go through asus_input_mapping() like on
> any other ASUS keyboard. The other interfaces either have a proper
> input application or nothing worth an input device.
>
> Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
> [pisati: use HID_CONNECT_HIDINPUT_FORCE on the vendor interface instead
>  of injecting a fake keyboard collection into its report descriptor]
> Assisted-by: LLM

Same as the other one, Assisted-by isn't right like this... About the rest:

Reviewed-by: Denis Benato <denis.benato@linux.dev>

> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
> ---
>  drivers/hid/hid-asus.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 242e273e4cb3..d69431615c27 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1405,6 +1405,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  	struct asus_drvdata *drvdata;
>  	struct hid_report *rep;
>  	bool is_vendor = false;
> +	unsigned int connect_mask;
>  	int ret;
>  
>  	drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> @@ -1500,7 +1501,18 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  		return ret;
>  	}
>  
> -	ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> +	/*
> +	 * The Zenbook Duo keyboard reports its hotkeys on a dedicated USB
> +	 * interface that only has vendor usage collections, which hid-input
> +	 * does not consider an input application. Make it bind to the
> +	 * interface carrying the ASUS vendor collection anyway so the
> +	 * hotkeys get mapped.
> +	 */

I would shorten this comment, but I'm not good in this and the code is okay so
I gave reviewed-by regardless: do what you wish with my suggestion.

> +	connect_mask = HID_CONNECT_DEFAULT;
> +	if ((drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) && is_vendor)
> +		connect_mask |= HID_CONNECT_HIDINPUT_FORCE;
> +
> +	ret = hid_hw_start(hdev, connect_mask);
>  	if (ret) {
>  		asus_worker_stop(drvdata->worker);
>  		hid_err(hdev, "Asus hw start failed: %d\n", ret);

Re: [PATCH v3 1/7] HID: asus: Fix up Zenbook Duo report descriptors

[Rebecca Mara Müller]

On Sun, Oct 18, 2026 at 05:50:08PM +0200, Denis Benato wrote:
> Does the zenbook duo really needs fixing the report descriptor? I think you can avoid this
> altogether on this hardware.

Welcome back, Denis. I tested exactly that on my UX8407AA today, docked
over USB: v3 built as an out-of-tree module against a 7.0.11-based
distribution kernel, once as posted and once with only the Zenbook Duo
fixup disabled (QUIRK_ZENBOOK_DUO_KEYBOARD removed from the fixup
condition, nothing else changed), my userspace workaround stopped.

Without the fixup, the hotkey interface gets no input device at all:

  asus 0003:0B05:1CD7.000A: hiddev2,hidraw8: USB HID v1.11 Device [...] on usb-0000:00:14.0-6/input4

With the fixup:

  asus 0003:0B05:1CD7.000A: Fixing up Zenbook Duo keyb report descriptor
  asus 0003:0B05:1CD7.000A: input,hiddev2,hidraw8: USB HID v1.11 Device [...] on usb-0000:00:14.0-6/input4

Without the fixup, volume up/down and mute still work, as they come from
another interface, but screen brightness, keyboard backlight, mic mute
and Fn+F profile cycling are dead (checked with an evdev reader and
/sys/firmware/acpi/platform_profile). With the fixup all of them work.
So yes, as far as I can tell this keyboard needs it.

On the Assisted-by format: my original patch (7/7) was written with
Claude Code using claude-fable-5, so following
Documentation/process/coding-assistants.rst that would be

Assisted-by: Claude:claude-fable-5

Paolo, feel free to use that above my Signed-off-by in a respin.

Thanks,
Rebecca

Re: [PATCH v3 4/7] HID: asus: Cycle the platform profile from the Zenbook Duo profile key

[Denis Benato]

On 10/13/26 12:40, Paolo Pisati wrote:
> From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
>
> The Zenbook Duo keyboard reports Fn+F, the performance mode key, as
> vendor usage 0x9d. On the built-in keyboards of other ASUS laptops the
> same key arrives through asus-wmi, which cycles the platform profile
> in response. Do the same here so the key works on the detachable
> keyboard too.
>
> asus_event() runs from the HID input path, which for USB is the URB
> completion handler, while platform_profile_cycle() takes a mutex, so run
> it from the driver's worker like the Fn-lock toggle, and consume the
> event. Queue at most one cycle at a time, so that a device repeating the
> key cannot grow the worker's list. Only call it when the platform
> profile class is reachable: it is not built on architectures without
> ACPI, where HID_ASUS still is, and it may be a module while HID_ASUS is
> built in.
>
> Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
> [pisati: defer platform_profile_cycle() to the worker and queue at
>  most one cycle, return 1 from asus_event() instead of propagating
>  its return value, and guard the call with
>  IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE)]
> Assisted-by: LLM
> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
> ---
>  drivers/hid/hid-asus.c | 67 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index d69431615c27..b127f5c38f60 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -29,6 +29,7 @@
>  #include <linux/input/mt.h>
>  #include <linux/usb.h> /* For to_usb_interface for T100 touchpad intf check */
>  #include <linux/power_supply.h>
> +#include <linux/platform_profile.h>
>  #include <linux/leds.h>
>  
>  #include "hid-ids.h"
> @@ -115,6 +116,7 @@ enum asus_work_action_type {
>  	FN_LOCK_SYNC,
>  	BRIGHTNESS_SET,
>  	WMI_FAN,
> +	PLATFORM_PROFILE_CYCLE,
>  };
>  
>  struct hid_raw_event_data {
> @@ -423,6 +425,42 @@ static int asus_kbd_fn_lock_set(struct asus_drvdata *drvdata, bool enabled)
>  	return 0;
>  }
>  
> +static int asus_platform_profile_cycle(struct asus_drvdata *drvdata)
> +{
> +	struct asus_worker *worker = drvdata->worker;
> +	struct asus_work_action *action, *pending;
> +	unsigned long flags;
> +	int ret = 0;
> +
> +	if (!IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE))
> +		return 0;
> +
Isn't IS_REACHABLE a macro? Why not using #if and/or #else ?
> +	spin_lock_irqsave(&worker->lock, flags);
> +
> +	/*
> +	 * One pending cycle is enough: a key press cannot outrun the
> +	 * worker, and a device repeating the key must not grow the list.
> +	 */
> +	list_for_each_entry(pending, &worker->actions, node) {
> +		if (pending->type == PLATFORM_PROFILE_CYCLE)
> +			goto unlock;
> +	}
> +
> +	action = kzalloc_obj(struct asus_work_action, GFP_ATOMIC);
> +	if (!action) {
> +		ret = -ENOMEM;
> +		goto unlock;
> +	}
> +
> +	action->type = PLATFORM_PROFILE_CYCLE;
> +	INIT_LIST_HEAD(&action->node);
> +	asus_worker_schedule(worker, action);
> +
> +unlock:

asus_platform_profile_cycle_unlock please because label names
are unique, not per-function

> +	spin_unlock_irqrestore(&worker->lock, flags);
> +	return ret;
> +}
> +
>  static int asus_kbd_wmi_fan_send(struct asus_drvdata *drvdata, u8 *report_data,
>  				 size_t report_size)
>  {
> @@ -459,8 +497,25 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
>  	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",
> -			 usage->hid & HID_USAGE);
> +		/*
> +		 * Some vendor usages do not map to a key and need special
> +		 * handling.
> +		 */
> +		switch (usage->hid & HID_USAGE) {
> +		case 0x9d: /* Zenbook Duo Fn+F: cycle the platform profile */
> +			if (value) {
> +				ret = asus_platform_profile_cycle(drvdata);
> +				if (ret) {
> +					hid_err(hdev, "Failed to cycle the platform profile: %d\n",
> +						ret);
> +					return ret;
> +				}
> +			}
> +			return 1;
> +		default:
> +			hid_warn(hdev, "Unmapped Asus vendor usagepage code 0x%02x\n",
> +				 usage->hid & HID_USAGE);
> +		}

If asus recycles 0x9d to make something else is nome other hardware it will end up
doing something else... It's acceptable I think but perhaps a guard may be better?
After all there is a warn about that already...

>  	}
>  
>  	if (usage->type == EV_KEY && value) {
> @@ -765,6 +820,7 @@ static void asus_work(struct work_struct *work)
>  	struct asus_worker *worker = container_of(work, struct asus_worker, work);
>  	struct asus_work_action *action = NULL;
>  	unsigned long flags;
> +	int ret;
>  
>  	/* Save the action to be performed and clear the flag */
>  	spin_lock_irqsave(&worker->lock, flags);
> @@ -788,6 +844,13 @@ static void asus_work(struct work_struct *work)
>  	case WMI_FAN:
>  		asus_kbd_wmi_fan(worker->hdev, &action->data.fan_hid_data);
>  		break;
> +	case PLATFORM_PROFILE_CYCLE:
> +		if (!IS_REACHABLE(CONFIG_ACPI_PLATFORM_PROFILE))
> +			break;

As before: #if !IS_REACHABLE(...)

> +		ret = platform_profile_cycle();
> +		if (ret)
> +			hid_dbg(worker->hdev, "Failed to cycle the platform profile: %d\n", ret);
> +		break;
>  	default:
>  		hid_err(worker->hdev, "Invalid action type: %d\n", action->type);
>  		break;

Re: [PATCH v3 5/7] HID: asus: Do not send feature reports larger than declared

[Denis Benato]

On 10/13/26 12:40, Paolo Pisati wrote:
> The keyboard backlight and Fn-lock commands are sent as 64 byte
> feature reports, the size of report 0x5a on the ROG keyboards. The
> Zenbook Duo keyboards declare feature report 0x5a with 15 data bytes,
> 16 with the report ID, and do not answer writes larger than that: the
> control transfer times out over USB and fails with -EIO over
> Bluetooth, so the backlight cannot be set, while the 16 byte handshake
> goes through.
>
> Cap feature report writes at the length the device declares for the
> report, when it declares it. hid_report_len() counts the report ID, so
> the handshake and the other commands up to that size are sent as they
> are.

This has been a huge pain in the past months for me so than you for
taking care of this.

> Assisted-by: LLM

As the others.

With comments extended (see below):

Reviewed-by: Denis Benato <denis.benato@linux.dev>

If you decide to help me and unify packets alloc between devices
you can do it on a separate patch after this one and preserve my reviewed-by.

> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
> ---
>  drivers/hid/hid-asus.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index b127f5c38f60..7b17553e94b6 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -632,6 +632,18 @@ static int asus_raw_event(struct hid_device *hdev,
>  
>  static int asus_kbd_set_report(struct hid_device *hdev, const u8 *buf, size_t buf_size)
>  {
> +	struct hid_report *report;
> +
> +	/*
> +	 * Do not send more than the declared size of the report, report ID
> +	 * included: the Zenbook Duo keyboards declare 15 data bytes for
> +	 * report 0x5a, 16 on the wire like the handshake, and do not answer
> +	 * the 64 byte writes sized for the ROG keyboards.
> +	 */

Maybe also mentions the majority of ROG laptops uses 64 bytes, xgm 300 bytes
and touchpads also 16 bytes as the duo.

> +	report = hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[buf[0]];
> +	if (report)
> +		buf_size = min_t(size_t, buf_size, hid_report_len(report));
> +

I think that it's worth doing this for every supported devices: rog ally,
laptops, touchpads and so on, my only question is if this code is robust
enough to handle all cases, but it's worth a try.

It's also worth adding another patch to unify all devices to use this code.

I can test on a rog xg mobile: obscure hardware that uses 300 bytes and
see if it still works.

>  	u8 *dmabuf __free(kfree) = kmemdup(buf, buf_size, GFP_KERNEL);
>  	if (!dmabuf)
>  		return -ENOMEM;

Re: [PATCH v3 6/7] HID: asus: add prod-id, quirk for Zenbook Duo keyboard

[Denis Benato]

On 10/13/26 12:40, Paolo Pisati wrote:
> From: Luke Jones <luke@ljones.dev>

A piece of mail header opening a commit? Never seen this.

I'd say remove this: that this comes from Luke can be deducted
in the Signed-off-by.

My question is why has this not been accepted before? Did I miss
this while we transitioned maintainer? If so apologies.

> The 2024/2025/2026 ASUS Zenbook Duo has a similar keyboard setup as
> many of the ROG range of laptops, with the same init sequence and
> control for backlight. Enable the keyboard control and backlight by:
> - adding the product ID for 2024/2025/2026 Zenbook Duo keyboard MCU
> - adding the Bluetooth Zenbook Duo keyboard IDs
>
> Intended for the UX8406-style product line with the fully removable
> keyboard.
>
> The keyboard also exposes its touchpad as a separate HID device with
> the same IDs, an interface of the USB device and a second device over
> Bluetooth, so bind the IDs to the HID_GROUP_GENERIC group only, like
> the ROG Z13 Folio, and leave the touchpad to hid-multitouch.
>
> Fn-lock is left out for now: with QUIRK_HID_FN_LOCK the Fn-lock report
> is sent to every interface of the device, before the handshake, and on
> the UX8407AA that stalled the hotkey interface for good. It can be
> added back once the driver only sends it where and when it belongs.
>
> Signed-off-by: Luke Jones <luke@ljones.dev>
> Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
> Signed-off-by: Ivan Levchenko <me@livan.pro>
> [pisati: bind the IDs to HID_GROUP_GENERIC only, drop
>  QUIRK_HID_FN_LOCK]
> Assisted-by: LLM

Same as all others regarding Assisted-by.

When you have removed the weird start:

Reviewed-by: Denis Benato <denis.benato@linux.dev>

> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> Tested-by: Rebecca Mara Müller <rebecca.mara@posteo.de> # UX8407AA
> ---
>  drivers/hid/hid-asus.c | 24 ++++++++++++++++++++++++
>  drivers/hid/hid-ids.h  |  6 ++++++
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 7b17553e94b6..503396963eeb 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1849,6 +1849,30 @@ static const struct hid_device_id asus_devices[] = {
>  	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
>  	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
>  		USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD) },
> +	/*
> +	 * Zenbook Duo detachable keyboards. The touchpad shows up as a
> +	 * separate HID device with the same IDs, over USB and Bluetooth:
> +	 * bind to the HID_GROUP_GENERIC group only, like the ROG Z13 Folio,
> +	 * so that hid-multitouch keeps handling it.
> +	 */
> +	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
> +	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
> +	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
> +	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
> +	{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
> +	{ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, USB_VENDOR_ID_ASUSTEK,
> +	    BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD),
> +	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ZENBOOK_DUO_KEYBOARD },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(hid, asus_devices);
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index b3aca5aa9176..59f44204d738 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -228,6 +228,12 @@
>  #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD	0x1866
>  #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2	0x19b6
>  #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_FOLIO		0x1a30
> +#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2c
> +#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406MA_KEYBOARD	0x1b2d
> +#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf2
> +#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8406CA_KEYBOARD	0x1bf3
> +#define USB_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd7
> +#define BT_DEVICE_ID_ASUSTEK_ZENBOOK_DUO_UX8407AA_KEYBOARD	0x1cd8
>  #define USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR		0x18c6
>  #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY		0x1abe
>  #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X		0x1b4c

Re: [PATCH v3 7/7] HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

[Denis Benato]

On 10/13/26 12:40, Paolo Pisati wrote:
> From: Rebecca Mara Müller <rebecca.mara@posteo.de>
>
> When docked, the Zenbook Duo keyboard powers up in F-key mode and
> needs the "ASUS Tech.Inc." handshake to emit hotkeys at all. The
> handshake sent from probe is lost again when hid-multitouch configures
> the touchpad on the sibling USB interface, which resets the keyboard
> to F-key mode, so the hotkeys stop working as soon as the touchpad is
> set up.
>
> Re-send the handshake from delayed work two seconds after probe.


So this patch is based on an arbitrary wait that is based on the
assumption that some other device gets initialized...

Can you try making this deterministic? Maybe returning from
_probe a specific value will postpone binding of this driver after
all other drivers and you can comment in code why it was done...

Or perhaps you can setup some way of hid-multitouch to signal
completion?

Regardless I will also review what we have here in case this ends
up to be the best way to go.

> Assisted-by: LLM
> Signed-off-by: Rebecca Mara Müller <rebecca.mara@posteo.de>
> Link: https://lore.kernel.org/r/20260811125548.1975748-1-rebecca.mara@posteo.de
> [pisati: taken from Rebecca's standalone UX8407AA patch and adapted to
>  the current driver; initialize and cancel the work unconditionally]
> Assisted-by: LLM
> Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
> ---
>  drivers/hid/hid-asus.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 503396963eeb..ce413eb011c4 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -173,6 +173,7 @@ struct asus_drvdata {
>  	unsigned long battery_next_query;
>  	struct asus_hid_listener listener;
>  	bool fn_lock;
> +	struct delayed_work reinit_work;

Why not reusing the workqueue we have already?

>  };
>  
>  static int asus_report_battery(struct asus_drvdata *, u8 *, int);
> @@ -1474,6 +1475,17 @@ static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
>  	return 0;
>  }
>  
> +static void asus_reinit_work(struct work_struct *work)
> +{
> +	struct asus_drvdata *drvdata = container_of(work, struct asus_drvdata,
> +						    reinit_work.work);
> +	int ret;
> +
> +	ret = asus_kbd_init(drvdata->hdev, FEATURE_KBD_REPORT_ID);
> +	if (ret < 0)
> +		hid_warn(drvdata->hdev, "Failed to re-initialize the keyboard: %d\n", ret);
> +}
> +
>  static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  {
>  	struct hid_report_enum *rep_enum;
> @@ -1570,6 +1582,8 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  			is_vendor = true;
>  	}
>  
> +	INIT_DELAYED_WORK(&drvdata->reinit_work, asus_reinit_work);
> +
>  	ret = asus_worker_create(hdev, drvdata);
>  	if (ret) {
>  		hid_warn(hdev, "Failed to initialize worker: %d\n", ret);
> @@ -1605,6 +1619,16 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  		}
>  	}
>  
> +	/*
> +	 * When docked, the Zenbook Duo keyboard drops back to F-key mode when
> +	 * hid-multitouch configures the touchpad on the sibling USB interface,
> +	 * which can happen after the handshake above. Send it again once the
> +	 * dust has settled.
> +	 */
> +	if (is_vendor && (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) &&
> +	    hid_is_usb(hdev))
> +		schedule_delayed_work(&drvdata->reinit_work, msecs_to_jiffies(2000));
> +
>  	/* Laptops keyboard backlight is always at 0x5a */
>  	if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>  	    (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
> @@ -1639,6 +1663,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>  
>  	return 0;
>  err_stop_hw:
> +	cancel_delayed_work_sync(&drvdata->reinit_work);
>  	if (drvdata->listener.brightness_set)
>  		asus_hid_unregister_listener(&drvdata->listener);
>  
> @@ -1654,6 +1679,7 @@ static void asus_remove(struct hid_device *hdev)
>  	if (drvdata->listener.brightness_set)
>  		asus_hid_unregister_listener(&drvdata->listener);
>  
> +	cancel_delayed_work_sync(&drvdata->reinit_work);
>  	asus_worker_stop(drvdata->worker);
>  	hid_hw_stop(hdev);
>  }

Re: [PATCH v3 0/7] HID: asus: ASUS Zenbook Duo keyboard support

[Denis Benato]

On 10/14/26 15:21, Paolo Pisati wrote:
> On Tue, Oct 13, 2026 at 04:56:39PM +0300, Denis Benato wrote:
>> My greatest concern is with report size: every device needs its own and
>> hardcoding it is not an option anymore because no device can be fully
>> made happy (and working): xg mobile is 300, ally and new ROGs is 64,
>> some have 32, some 16 and I think TP is 15.
>>
>> I have yet to look at the patch that changes the report size but please
>> make the report size variable reading it from the descriptor.
> Isn't 5/7 what you are looking for?
>
> asus_kbd_set_report() looks up the feature report with the ID in
> buf[0] and never sends more than hid_report_len() of it, that is what
> the descriptor declares, report ID included. The Zenbook Duo declares
> 15 data bytes for report 0x5a, so the 64 byte backlight buffer goes
> out as 16 bytes, like the handshake, and the keyboard answers it.
> A device declaring 64 or more sees no change.
>
> No hurry, enjoy the vacation.
I just hadn't watched the patch yet. Now I did and yes: you are right
and if that works across devices it's a great thing for this driver as a
whole!

Thank you!

Re: [PATCH v3 1/7] HID: asus: Fix up Zenbook Duo report descriptors

[Denis Benato]

On 10/18/26 18:18, Rebecca Mara Müller wrote:
> On Sun, Oct 18, 2026 at 05:50:08PM +0200, Denis Benato wrote:
>> Does the zenbook duo really needs fixing the report descriptor? I think you can avoid this
>> altogether on this hardware.
> Welcome back, Denis. I tested exactly that on my UX8407AA today, docked
> over USB: v3 built as an out-of-tree module against a 7.0.11-based
> distribution kernel, once as posted and once with only the Zenbook Duo
> fixup disabled (QUIRK_ZENBOOK_DUO_KEYBOARD removed from the fixup
> condition, nothing else changed), my userspace workaround stopped.

Thank you Rebecca!

> Without the fixup, the hotkey interface gets no input device at all:
>
>   asus 0003:0B05:1CD7.000A: hiddev2,hidraw8: USB HID v1.11 Device [...] on usb-0000:00:14.0-6/input4
>
> With the fixup:
>
>   asus 0003:0B05:1CD7.000A: Fixing up Zenbook Duo keyb report descriptor
>   asus 0003:0B05:1CD7.000A: input,hiddev2,hidraw8: USB HID v1.11 Device [...] on usb-0000:00:14.0-6/input4
>
> Without the fixup, volume up/down and mute still work, as they come from
> another interface, but screen brightness, keyboard backlight, mic mute
> and Fn+F profile cycling are dead (checked with an evdev reader and
> /sys/firmware/acpi/platform_profile). With the fixup all of them work.
> So yes, as far as I can tell this keyboard needs it.

Okay... Noted. Is the forcing of a name required too? It has caused a debate
in the past, we used to rename all input devices on hid-asus and now we
don't anymore so if can be avoided it would be great to follow the now
preferred way.

> On the Assisted-by format: my original patch (7/7) was written with
> Claude Code using claude-fable-5, so following
> Documentation/process/coding-assistants.rst that would be
>
> Assisted-by: Claude:claude-fable-5
>
> Paolo, feel free to use that above my Signed-off-by in a respin.
>
> Thanks,
> Rebecca

Thanks for your time and effort,
Denis

Re: [PATCH v3 7/7] HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

[Rebecca Mara Müller]

On Sun, Oct 18, 2026 at 07:10:57PM +0200, Denis Benato wrote:
> So this patch is based on an arbitrary wait that is based on the
> assumption that some other device gets initialized...
>
> Can you try making this deterministic?

Since this part came from my patch, I went back and measured it on my
UX8407AA before trying to make it deterministic. The result: there is
nothing to fix, so please drop 7/7.

I built v3 as an out-of-tree module against a 7.0.11-based distribution
kernel, with only the schedule_delayed_work() call of 7/7 removed and my
userspace workaround stopped, and checked whether the keyboard stays in
hotkey mode (keyboard backlight key changing asus::kbd_backlight, plus
usbmon on the keyboard's bus for part of the runs):

- docking: 10 of 10
- loading the module with the keyboard attached: 2 of 2
- rebinding only the touchpad to hid-multitouch while docked: 4 of 4
- s2idle suspend and resume: 3 of 3
- reboot with the module loaded after hid-multitouch (rootfs only):
  2 reboots, 1 cold boot, all fine
- reboot with the module in the initramfs: 3 reboots, 1 cold boot,
  all fine

usbmon shows hid-asus sending the 0x5a handshake on interface 4 and
hid-multitouch sending feature reports 0x07, 0x03 and 0x05 to the
touchpad on interface 5 some 10-20 ms later, and the hotkeys keep
arriving as 0x5a reports on interface 4 afterwards. The same happens
when hid-multitouch reconfigures the touchpad on resume or on a rebind.

I also went back through my notes from August to see why I believed
otherwise. The conclusion came from a test where I rebound the touchpad
and the brightness keys then did nothing. At that point my test module
had neither the descriptor fixup nor the forced hid-input binding yet,
so the hotkey interface had no input device at all and the keys could
not have worked in either mode; my userspace workaround was stopped.
All later tests that day already included the re-send, so they showed
that the whole patch works, but never whether the re-send is needed.

I am really sorry for the extra work this caused, Paolo, for carrying
and adapting the patch, and Denis and everyone else for reviewing it.
This was my first time this deep into a driver, and I should have
tested the re-send on its own before sending it.

Unrelated, in case it is useful: with the series applied, the keyboard
backlight stays on while the laptop is in s2idle suspend.

Thanks,
Rebecca

Re: [PATCH v3 7/7] HID: asus: Re-send the Zenbook Duo keyboard handshake after probe

[Denis Benato]

On 10/18/26 21:18, Rebecca Mara Müller wrote:
> On Sun, Oct 18, 2026 at 07:10:57PM +0200, Denis Benato wrote:
>> So this patch is based on an arbitrary wait that is based on the
>> assumption that some other device gets initialized...
>>
>> Can you try making this deterministic?
> Since this part came from my patch, I went back and measured it on my
> UX8407AA before trying to make it deterministic. The result: there is
> nothing to fix, so please drop 7/7.

That's good! The probe function is unfortunately a bit chaotic as it
is already... After all this driver must handle many different wildly
different devices so keeping it simpler benefits the addition of new
devices.

> I built v3 as an out-of-tree module against a 7.0.11-based distribution
> kernel, with only the schedule_delayed_work() call of 7/7 removed and my
> userspace workaround stopped, and checked whether the keyboard stays in
> hotkey mode (keyboard backlight key changing asus::kbd_backlight, plus
> usbmon on the keyboard's bus for part of the runs):
>
> - docking: 10 of 10
> - loading the module with the keyboard attached: 2 of 2
> - rebinding only the touchpad to hid-multitouch while docked: 4 of 4
> - s2idle suspend and resume: 3 of 3
> - reboot with the module loaded after hid-multitouch (rootfs only):
>   2 reboots, 1 cold boot, all fine
> - reboot with the module in the initramfs: 3 reboots, 1 cold boot,
>   all fine
>
> usbmon shows hid-asus sending the 0x5a handshake on interface 4 and
> hid-multitouch sending feature reports 0x07, 0x03 and 0x05 to the
> touchpad on interface 5 some 10-20 ms later, and the hotkeys keep
> arriving as 0x5a reports on interface 4 afterwards. The same happens
> when hid-multitouch reconfigures the touchpad on resume or on a rebind.
>
> I also went back through my notes from August to see why I believed
> otherwise. The conclusion came from a test where I rebound the touchpad
> and the brightness keys then did nothing. At that point my test module
> had neither the descriptor fixup nor the forced hid-input binding yet,
> so the hotkey interface had no input device at all and the keys could
> not have worked in either mode; my userspace workaround was stopped.
> All later tests that day already included the re-send, so they showed
> that the whole patch works, but never whether the re-send is needed.
>
> I am really sorry for the extra work this caused, Paolo, for carrying
> and adapting the patch, and Denis and everyone else for reviewing it.
> This was my first time this deep into a driver, and I should have
> tested the re-send on its own before sending it.

Well you know how this things go... Only who does nothing can claim
to have made no mistakes. There's no problem for me, in fact it happened
to me too to do work based on assumptions that ended up being false...
It just happens and is nobody's fault!

I actually like reading these things so I know what was done and tested
and what to look for in case I find myself in similar situations (and what
to look for when bringing up new hardware in the fastest way possible).

> Unrelated, in case it is useful: with the series applied, the keyboard
> backlight stays on while the laptop is in s2idle suspend.

I haven't looked much at these models beside the wmi side so I don't
know if they are like ROGs/TUFs but ROGs and TUFs have the keyboard
backlight that can be configured in s2idle and/or hibernation, but even
if powered on usually the pattern changes... So I am concerned that
hardware isn't entering s2idle properly... Are you sure it is?

You can use the amd-s2idle tool even if the CPU is an intel one to check
that.

I don't want to speculate too much, but if it really is sleeping then we are
either missing a way to configure backlight enablement on power states
or a command to send while suspending.

> Thanks,
> Rebecca

Re: [PATCH v3 2/7] HID: asus: Add missing Zenbook Duo hotkeys

[Nathan Chancellor]

On Sun, Oct 18, 2026 at 05:55:02PM +0200, Denis Benato wrote:
> On 10/13/26 12:39, Paolo Pisati wrote:
> > Assisted-by: LLM
> 
> Assisted-by tags have harness:model like this:
> 
> Assisted-by: opencode:deepseek-v4.1-flash

Just an FYI, Assisted-by: was adjusted to Paolo's current format in

  816d9992d9ed ("coding-assistants: simplify attribution")

in 7.3 and it is being removed altogether in 7.4 with

  1e035297ffda ("docs: remove Assisted-by references")

currently sitting in -next.

-- 
Cheers,
Nathan

Re: [PATCH v3 2/7] HID: asus: Add missing Zenbook Duo hotkeys

[Denis Benato]

On 10/18/26 23:38, Nathan Chancellor wrote:
> On Sun, Oct 18, 2026 at 05:55:02PM +0200, Denis Benato wrote:
>> On 10/13/26 12:39, Paolo Pisati wrote:
>>> Assisted-by: LLM
>> Assisted-by tags have harness:model like this:
>>
>> Assisted-by: opencode:deepseek-v4.1-flash
> Just an FYI, Assisted-by: was adjusted to Paolo's current format in
>
>   816d9992d9ed ("coding-assistants: simplify attribution")
>
> in 7.3 and it is being removed altogether in 7.4 with
>
>   1e035297ffda ("docs: remove Assisted-by references")
>
> currently sitting in -next.
>
Oh I fell behind current rulings. Apologies.

Re: [PATCH v3 6/7] HID: asus: add prod-id, quirk for Zenbook Duo keyboard

[Nathan Chancellor]

On Sun, Oct 18, 2026 at 06:57:16PM +0200, Denis Benato wrote:
> 
> On 10/13/26 12:40, Paolo Pisati wrote:
> > From: Luke Jones <luke@ljones.dev>
> 
> A piece of mail header opening a commit? Never seen this.
> 
> I'd say remove this: that this comes from Luke can be deducted
> in the Signed-off-by.
> 
> My question is why has this not been accepted before? Did I miss
> this while we transitioned maintainer? If so apologies.

This is standard git send-email behavior to signify that Luke should be
the author in git when this patch is applied via 'git am' but Paolo is
the one sending it. If Luke originally authored this patch, then he
should proabably be the author in git history, especially since the
signoff chain would make no sense otherwise.

-- 
Cheers,
Nathan

Re: [PATCH v3 6/7] HID: asus: add prod-id, quirk for Zenbook Duo keyboard

[Denis Benato]

On 10/18/26 23:43, Nathan Chancellor wrote:
> On Sun, Oct 18, 2026 at 06:57:16PM +0200, Denis Benato wrote:
>> On 10/13/26 12:40, Paolo Pisati wrote:
>>> From: Luke Jones <luke@ljones.dev>
>> A piece of mail header opening a commit? Never seen this.
>>
>> I'd say remove this: that this comes from Luke can be deducted
>> in the Signed-off-by.
>>
>> My question is why has this not been accepted before? Did I miss
>> this while we transitioned maintainer? If so apologies.
> This is standard git send-email behavior to signify that Luke should be
> the author in git when this patch is applied via 'git am' but Paolo is
> the one sending it. If Luke originally authored this patch, then he
> should proabably be the author in git history, especially since the
> signoff chain would make no sense otherwise.
>
Never seen it... I ended up with the From: ... in path text so maybe I
am noticing this just because I did something stupid.