Re: [REGRESSION 6.18.48 -> 6.18.49] hid-asus: ROG N-Key keyboard dead, also in 6.12.y
From: Antheas Kapenekakis
Date: Tue Sep 22 2026 - 06:17:51 EST
On Tue, 22 Sept 2026 at 03:34, Grant King <gking@xxxxxxxx> wrote:
>
> Hi,
>
> Resending as plain text; the first copy went out as HTML and the lists will have dropped it. Apologies to those receiving it twice.
>
> The built-in keyboard on my ROG Zephyrus G14 (GA403UV) stops working on 6.18.49. 6.18.48 is fine. The N-Key controller enumerates, but hid-asus fails to initialise it:
>
> asus 0003:0B05:19B6.0004: using HID for asus::kbd_backlight
> asus 0003:0B05:19B6.0004: Asus failed to request functions: -75
> asus 0003:0B05:19B6.0004: Failed to initialize backlight.
> asus 0003:0B05:19B6.0004: input,hiddev98,hidraw3: USB HID v1.10 Keyboard
> [ITE Tech. Inc. ITE Device(8910)] on usb-0000:65:00.3-4/input0
>
> An input node still appears, the keyboard just does nothing. On 6.18.48 those two error lines are absent and /sys/class/leds/asus::kbd_backlight shows up.
>
> ASUS ROG Zephyrus G14 GA403UV, BIOS GA403UV.308
> keyboard 0b05:19b6 (ROG N-Key), usb-0000:65:00.3-4
>
> The culprit looks like d0754db7883c ("HID: asus: simplify RGB init sequence") in 6.18.y, a backport of 56d1b33e644c taken as Stable-dep-of: 02bf61dfb44f ("HID: asus: fix missing hid_is_usb() check"). Reading drivers/hid/hid-asus.c at each tag, v6.18.48 has the old code and v6.18.49 is the first with the merged init path; it is still there at v6.18.52. 6.12 LTS has it too, good at v6.12.107 and first bad at v6.12.108, still there at v6.12.110. 6.6.y never took the refactor and 7.1.y already has the mainline structure, so neither looks affected.
>
> Before the patch, the N-Key branch ran the init reports and never called asus_kbd_get_functions():
>
> if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
> ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
> ...
> ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
> ...
> ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
>
> After it, get_functions runs for every device and returns early on failure, so the 0x5d and 0x5e inits never happen when it fails. That is what kills the keyboard here.
>
> It fails because of a size mismatch. The controller declares feature report 0x5a as 62 bytes:
>
> 06 31 ff Usage Page (Vendor 0xFF31)
> 09 76 Usage (0x76)
> a1 01 Collection (Application)
> 85 5a Report ID (0x5a)
> ...
> 75 08 Report Size (8)
> 95 3e Report Count (62)
> b1 00 Feature
> c0 End Collection
>
> and asus_kbd_get_functions() asks for FEATURE_KBD_REPORT_SIZE, which is 16:
>
> readbuf = kzalloc(FEATURE_KBD_REPORT_SIZE, GFP_KERNEL);
> ret = hid_hw_raw_request(hdev, FEATURE_KBD_REPORT_ID, readbuf,
> FEATURE_KBD_REPORT_SIZE, HID_FEATURE_REPORT,
> HID_REQ_GET_REPORT);
>
> The device answers with all 62 bytes into a 16 byte control transfer, so it overflows and hid_hw_raw_request() returns -EOVERFLOW, the -75 above. The call cannot succeed on this device, which I assume is why the old code kept it out of the N-Key path. That descriptor came from /sys/bus/hid/devices/0003:0B05:19B6.0004/report_descriptor; I can send the whole thing if it is useful.
>
> The patch says "There should be no functional change with this patch", and in mainline that holds, because 0919db9f3583 ("HID: asus: always fully initialize devices") had already moved the init reports into asus_probe() where a failed get_functions only warns. 0919db9f3583 is not in 6.18.y or 6.12.y, so there the inits are still behind the call that fails.
>
> So either revert d0754db7883c in both trees and rework the hid_is_usb() fix against the old structure, or backport 0919db9f3583 alongside it. The revert looks like less risk for stable, but that is your call. Separately, asking for a fixed 16 bytes from a report the device declares as 62 seems wrong in any tree. Sizing the request from the report would make the call work here rather than just avoiding it.
0919db9f3583 came after. You mean e82ae34af29e910 is missing that
increases FEATURE_KBD_REPORT_SIZE to 64, correct?
Antheas
> Alpine has what looks like the same bug on a ProArt P16, same error string, same controller, bisected there to the same commit:
>
> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18451
>
> That reporter only loses the keyboard before root is mounted, mine is dead in the running session.
>
> Caveats. I am on a patched distro kernel (Fedora 44, Bazzite "ogc"), not a vanilla build. The function symbols in its hid-asus.ko match upstream v6.18.44's, so I do not think it patches this file, but I have not proven that. I have not bisected; the first-bad releases above come from reading the tags. I have not captured evdev output proving no key events get through, and the 6.12.y entry is from reading source, not from running it. The descriptor was read on 6.18.44, but it comes from the device so it should not vary by kernel.
>
> I can reproduce this on demand and have a USB keyboard for recovery, so I am happy to test patches or build a vanilla 6.18.49 if that would help.
>
> #regzbot introduced: v6.18.48..v6.18.49
>
> Thanks, Grant