Re: [PATCH v2] HID: usbhid: skip interrupt IN polling for devices with no input reports

[Antheas Kapenekakis]

On Tue, 13 Oct 2026 at 14:55, Thorsten Leemhuis
<regressions@xxxxxxxxxxxxx> wrote:
>
> On 8/28/26 12:42, Ahmed Yaseen wrote:
> > usbhid starts polling a device's interrupt IN endpoint on open
> > (usbhid_open() -> hid_start_in()). If the report descriptor declares no
> > input reports there is nothing to read there, so the poll is useless,
> > and on some composite devices it is also harmful.
> >
> > The ASUS ROG N-Key keyboards expose a second, input-less interface used
> > only for RGB control via feature reports. Opening its hidraw node (any
> > hidraw reader does, including SDL/Steam Input or a plain cat) starts the
> > pointless IN poll and keypress reports on the keyboard interface get
> > dropped for as long as the node stays open: a lost key-down drops a
> > letter, a lost key-up leaves the key stuck. usbmon shows the dropped
> > reports never reach the URB layer.
> >
> > The useless poll itself is long-standing; commit 4ac74ea68f64 ("HID:
> > asus: early return for ROG devices") is what exposes it on these
> > devices by keeping the input-less interface alive instead of ejecting
> > it, so its hidraw node can be opened and the poll started.
>
> Hmmm, what's the status here? Ahmed, is this still needed, or was this
> fixed in some other way? From the the outside it looks a lot like this
> regression fix feel through the cracks, but would be good to get into
> 7.4-rc1 to finally fix the dropped keypress reports.

Hi Thorsen,
there haven't been widespread issues with stuck keys on Asus recently,
except one regression with the fan key that merged recently.

This fix targets hid core, so merging it could cause regressions on
other devices.

Denis can comment on whether he fixed the regression that primarily
lies in the software he maintains separately. I am not sure SDL causes
this issue

Best,
Antheas

> Ciao, Thorsten
> > Skip the poll in usbhid_open() when the device has no input reports.
> > Feature reports and hidraw output keep working over the control and OUT
> > endpoints, so the interface is otherwise unaffected.
> >
> > Fixes: 4ac74ea68f64 ("HID: asus: early return for ROG devices")
> > Link: https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823
> > Link: https://github.com/ublue-os/bazzite/issues/4590
> > Cc: stable@xxxxxxxxxxxxxxx
> > Tested-by: Kerim Kabirov <the.privat33r+linux@xxxxx>
> > Tested-by: GameBurrow <gameburrow@xxxxx>
> > Signed-off-by: Ahmed Yaseen <yaseen@xxxxxxxxx>
> > Reviewed-by: Denis Benato <denis.benato@xxxxxxxxx>
> > ---
> >  drivers/hid/usbhid/hid-core.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> > index 96b0181cf819..d7cf2b56e117 100644
> > --- a/drivers/hid/usbhid/hid-core.c
> > +++ b/drivers/hid/usbhid/hid-core.c
> > @@ -688,7 +688,14 @@ static int usbhid_open(struct hid_device *hid)
> >
> >       set_bit(HID_OPENED, &usbhid->iofl);
> >
> > -     if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
> > +     /*
> > +      * ALWAYS_POLL devices are already polled from usbhid_start(), and a
> > +      * device with no input reports has nothing to send on the interrupt
> > +      * IN endpoint. In some cases polling is harmful: on the ASUS ROG
> > +      * N-Key keyboards it makes the sibling interface drop keypresses.
> > +      */
> > +     if ((hid->quirks & HID_QUIRK_ALWAYS_POLL) ||
> > +         list_empty(&hid->report_enum[HID_INPUT_REPORT].report_list)) {
> >               res = 0;
> >               goto Done;
> >       }
> >
> > base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
>
>