Pre-flight checklist
Request type
Summary
Hey,
Lately I've been having issues with keys randomly getting stuck for a while on my Asus ROG Strix SCAR 16 ( tried in multiple OS setups, never happens in BIOS or )
I found the following linux patch which fixes the issue(I tested it by using an OS where it's patched in(Nobara and G14 kernel, didnt test in OGC)): HID: usbhid: skip interrupt IN polling for devices with no input reports
The patch as far as I see prevents usbhid from starting interrupt-IN polling when the HID interface declares no input reports. ( which matches that it happens after I stop typing for a while ). On keyboards with the affected(because it doesn't happen to all) ASUS ROG N-Key, polling the input-less RGB/control interface can cause the sibling kb interface to drop reports... which then causes missed, repeated or stuck keys.
Motivation / use case
What would happen is that on my ASUS ROG Strix SCAR 16, I keep having random missed/repeated/stuck keystrokes across different apps (no particular key, app, game or desktop env)
The ASUS N-Key keyboard exposes two interfaces:
- Interface 00 which is the actual keyboard/input interface
- Interface 01 which is an input-less interface used for RGB/control functionality
When I use things that use SDL or steam input or any hardware controll util really, it opens the second hidraw node... which then the current usbhid implementation starts unnecessary interrupt-IN polling.
I see it affects multiple users:
https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823/8
https://www.reddit.com/r/cachyos/comments/1tt2884/keyboard_misses_keystrokes_or_repeats_them_while/
ublue-os/bazzite#4590
https://www.reddit.com/r/hardware/comments/1rvqfzr/asus_rog_laptops_ship_with_pcisig_specification/
ublue-os/bazzite#2970
A lost key-down appears as a missed character where as a key-up appears as a repeating or stuck key. ( Which made me think it's completely random )
Patch / upstream reference (if available)
Patch v2:
https://lkml.iu.edu/2608.3/09647.html
Patch-series cover letter:
https://lkml.iu.edu/2608.3/09648.html
The patch fixes the regression introduced/exposed by:
torvalds/linux@4ac74ea68f64
It has already been included downstream by OpenGamingCollective:
OpenGamingCollective/linux#62
According to the v2 cover letter,it was solved on:
- OGC kernel since
7.1.3-ogc5
- Nobara kernel since
7.1.4
- G14 kernel since
7.1.4
Testing / benchmarks
- Laptop: ASUS ROG Strix SCAR 16
G634JYR
- BIOS:
G634JYR.322
- Current kernel:
7.2.2-1-cachyos
- Keyboard: ASUSTek N-Key Device
- USB ID:
0b05:19b6
- Keyboard interface:
/dev/hidraw0, USB interface 00
- Input-less RGB/control interface:
/dev/hidraw1, USB interface 01
Observations:
- Random keys are missed
- Key releases are sometimes missed, resulting in repetition/stuck keys
- Happens across unrelated apps rather than in one specific app
- Happens on a vanilla setup as well ( I main Hyprland but also happens in Sway and Niri )
I look at the cachy's usbhid_open() implementation (https://github.com/CachyOS/linux/blob/cachyos-7.2.2-1/drivers/hid/usbhid/hid-core.c#L682) and it doesn't have the proposed list_empty(&hid->report_enum[HID_INPUT_REPORT].report_list) check
Additional context
My G634JYR model is not explicitely named in the pach v2 letter... which lists the newer models like G615L/G635L/G815L/G835. However... my laptop exposes the same affected ASUS-N-Key device(0b05:19b6) and the same two-interface layout: one keyboard interface plus one input-less RGB/control interface.
Related reports:
Could we have this targeted HID fix which is already in multiple kernels rather than waiting for it to propagate thru the upstream stable?
Pre-flight checklist
Request type
Summary
Hey,
Lately I've been having issues with keys randomly getting stuck for a while on my Asus ROG Strix SCAR 16 ( tried in multiple OS setups, never happens in BIOS or )
I found the following linux patch which fixes the issue(I tested it by using an OS where it's patched in(Nobara and G14 kernel, didnt test in OGC)): HID: usbhid: skip interrupt IN polling for devices with no input reports
The patch as far as I see prevents
usbhidfrom starting interrupt-IN polling when the HID interface declares no input reports. ( which matches that it happens after I stop typing for a while ). On keyboards with the affected(because it doesn't happen to all) ASUS ROG N-Key, polling the input-less RGB/control interface can cause the sibling kb interface to drop reports... which then causes missed, repeated or stuck keys.Motivation / use case
What would happen is that on my ASUS ROG Strix SCAR 16, I keep having random missed/repeated/stuck keystrokes across different apps (no particular key, app, game or desktop env)
The ASUS N-Key keyboard exposes two interfaces:
When I use things that use SDL or steam input or any hardware controll util really, it opens the second hidraw node... which then the current usbhid implementation starts unnecessary interrupt-IN polling.
I see it affects multiple users:
https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823/8
https://www.reddit.com/r/cachyos/comments/1tt2884/keyboard_misses_keystrokes_or_repeats_them_while/
ublue-os/bazzite#4590
https://www.reddit.com/r/hardware/comments/1rvqfzr/asus_rog_laptops_ship_with_pcisig_specification/
ublue-os/bazzite#2970
A lost key-down appears as a missed character where as a key-up appears as a repeating or stuck key. ( Which made me think it's completely random )
Patch / upstream reference (if available)
Patch v2:
https://lkml.iu.edu/2608.3/09647.html
Patch-series cover letter:
https://lkml.iu.edu/2608.3/09648.html
The patch fixes the regression introduced/exposed by:
torvalds/linux@4ac74ea68f64
It has already been included downstream by OpenGamingCollective:
OpenGamingCollective/linux#62
According to the v2 cover letter,it was solved on:
7.1.3-ogc57.1.47.1.4Testing / benchmarks
G634JYRG634JYR.3227.2.2-1-cachyos0b05:19b6/dev/hidraw0, USB interface 00/dev/hidraw1, USB interface 01Observations:
I look at the cachy's
usbhid_open()implementation (https://github.com/CachyOS/linux/blob/cachyos-7.2.2-1/drivers/hid/usbhid/hid-core.c#L682) and it doesn't have the proposedlist_empty(&hid->report_enum[HID_INPUT_REPORT].report_list)checkAdditional context
My G634JYR model is not explicitely named in the pach v2 letter... which lists the newer models like G615L/G635L/G815L/G835. However... my laptop exposes the same affected ASUS-N-Key device(
0b05:19b6) and the same two-interface layout: one keyboard interface plus one input-less RGB/control interface.Related reports:
CachyOS discussion:
https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823
Bazzite issue #4590:
Keyboard is dropping keyboard strokes on ASUS ROG Strix G16 during RTS Gameplay ublue-os/bazzite#4590
Bazzite issue #2970:
Built-in keyboard issues on ROG Strix SCAR 18 ublue-os/bazzite#2970
Could we have this targeted HID fix which is already in multiple kernels rather than waiting for it to propagate thru the upstream stable?