Skip to content

[FEATURE] Include usbhid fix for ASUS ROG N-Key dropped/repeated keystrokes #1012

Description

@spinualexandru

Pre-flight checklist

  • I have searched existing issues/PRs and this has not been requested before.
  • I have read the Contributing Guidelines.

Request type

  • New patch / patchset inclusion
  • Kernel config change (enable/disable option)
  • New kernel variant
  • Scheduler tuning / addition
  • Compiler / LTO / PGO optimization
  • Security hardening
  • Driver or hardware enablement
  • Other

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?

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions