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

[Antheas Kapenekakis]

On Fri, 5 Jun 2026 at 13:40, Ahmed Yaseen <yaseen@xxxxxxxxx> 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.

If it did have input reports, would starting the polling still cause
issues? Because if it would, the issue is in the polling itself.

Given the creativity of manufacturers when implementing hid protocols,
I find it certain that they do use the in endpoint even without input
reports. E.g., for feature reports. This could cause regressions.

> 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

cating a hidraw causing issues would be expected, so let's focus on the former.

Asusctl has a bug where if you add the quirk that separates the event
nodes per hid, this bug is reproduced as well. I chucked it to
complicated threading getting out of control. It is the reason we
skipped that patch that was in my series.

Now, you say SDL/Steam do a spurious read as well, can you identify
the codepath so we can look into it? What devices are affected? The
early return fixes a warning on the Z13, but it also feeds through the
universal lamp interface on the new Xbox Allies. Is this a bug on
those devices or keyboards? If yes, it could be caused by userspace
hanging on that node

Antheas

> 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.
>
> 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")
> Tested-by: Kerim Kabirov <the.privat33r+linux@xxxxx>
> Tested-by: GameBurrow <gameburrow@xxxxx>
> Signed-off-by: Ahmed Yaseen <yaseen@xxxxxxxxx>
> ---
>  drivers/hid/usbhid/hid-core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 96b0181cf819..90a8b34d9305 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -688,7 +688,8 @@ static int usbhid_open(struct hid_device *hid)
>
>         set_bit(HID_OPENED, &usbhid->iofl);
>
> -       if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
> +       if ((hid->quirks & HID_QUIRK_ALWAYS_POLL) ||
> +           list_empty(&hid->report_enum[HID_INPUT_REPORT].report_list)) {
>                 res = 0;
>                 goto Done;
>         }
> --
> 2.54.0
>
>
>