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

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

[Ahmed Yaseen]

On some ASUS ROG N-Key keyboards, a second input-less interface is
exposed for RGB control. Polling this interface causes keypress reports
on the first keyboard interface to be dropped: a lost key-down drops a
letter, a lost key-up leaves the key stuck. Any hidraw reader opening
the node is enough to trigger it, including SDL/Steam Input or a plain
cat.

This patch skips the poll if no input reports exist for an interface. A
device with no input reports has no benefit from being polled, so
instead of adding a new quirk, I have opted to skip it entirely.

Devices other than the ASUS ones are unaffected. HID core already
discards whatever arrives on the interrupt IN endpoint of an interface
that declares no input reports: hid_get_report() matches nothing, so
neither ->raw_event() nor hidraw and hiddev are ever reached.

The affected machines are 2024-2025 Strix SCAR 16/18 (G635L/G835L) and
G16/G18 (G615L/G815L) laptops, and the bug is widely reported across
distributions, so I would appreciate this being considered for the
current cycle. Reports:

https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823
https://github.com/ublue-os/bazzite/issues/4590

v1: https://lore.kernel.org/all/20260605113952.38435-1-yaseen@ghoul.dev

Changes since v1:
- Added a short comment above the condition in usbhid_open() explaining
  the reason for skipping there.
- Added Cc: stable@vger.kernel.org; v1 was not marked for backport. The
  bug reaches every tree carrying 4ac74ea68f64, i.e. v7.0 onwards.
- Added Link: tags for two of the downstream bug reports.
- No functional change: the hunk is byte-identical to v1 apart from the
  new comment, so the Tested-by and Reviewed-by tags carry over.

Since v1, this patch has been adopted by three downstream kernels, with
no regressions reported by any user since:
- OGC kernel: from v7.1.3-ogc5 (2026-07-21) onwards
- Nobara kernel: from 7.1.4 onwards
- G14 kernel: from 7.1.4 onwards

Ahmed Yaseen (1):
  HID: usbhid: skip interrupt IN polling for devices with no input
    reports

 drivers/hid/usbhid/hid-core.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)


base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
-- 
2.55.0

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

[Ahmed Yaseen]

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.

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@vger.kernel.org
Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
Tested-by: GameBurrow <gameburrow@pm.me>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
---
 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
-- 
2.55.0

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

[Thorsten Leemhuis]

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.

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@vger.kernel.org
> Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
> Tested-by: GameBurrow <gameburrow@pm.me>
> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
> Reviewed-by: Denis Benato <denis.benato@linux.dev>
> ---
>  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

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@leemhuis.info> 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@vger.kernel.org
> > Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
> > Tested-by: GameBurrow <gameburrow@pm.me>
> > Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
> > Reviewed-by: Denis Benato <denis.benato@linux.dev>
> > ---
> >  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
>
>

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

[Ahmed Yaseen]

On 10/13/26 18:11, Antheas Kapenekakis wrote:
> On Tue, 13 Oct 2026 at 14:55, Thorsten Leemhuis
> <regressions@leemhuis.info> 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 Thorsten,

Yes, this patch is still very much needed upstream. The current status of this patch is as follows:

On upstream kernel, this is still waiting to be merged.
On the OGC Kernel this has been available since 7.1.3 (since July 21)
On Nobara kernel and G14 kernel, this has been available since 7.1.4 (since around mid July)
On CachyOS kernel some users have opened an issue and a PR on the CachyOS kernel repo and kernel patches repos respectively.

The issue itself is still present in upstream kernel and I'm still waiting for a response from the maintainers. I hope this can be merged upstream ASAP.

It is still a major issue and I have recently encountered users who had switched away from Linux to other operating systems for this reason as well. Reports of this issue still come to us in varying ways and we ask these users to use one of the kernels with fixes installed. In the case of Fedora and Arch users, this would mean the OGC kernel, Nobara, or G14 kernel. For Debian-based distros, the issue is not yet present as the patch that made this issue become visible is not yet available there. However, when the patch 4ac74ea68f64 ("HID: asus: early return for ROG devices") is available in an LTS kernel, all users of Debian-based distributions will get this regression as well, so I believe some urgency is also required here.

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

Hi Antheas,

As explained above, we do still get these reports. We have users in the (previously ASUS now OGC) discord server, cachyos forum, bazzite repo issues, reddit, etc that do report these issues and multiple commenters who claim they have the same issue.

Some of these issues that I found at the time of writing it are linked in the cover letter of this patchset. Other users reported this in the discord server later, and many users write it off as a one-off issue or a bug with a certain game and those who hit the issue repeatedly either report to us, roll back kernel, or even switch to an alternative like Windows. Kerim and GameBurrow who helped with my testing for example, were users who were able to reliably recreate the issue in certain games. The reproduction cases in the patch description (e.g. running cat on the hidraw node) came from them and trigger it consistently.

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

This fix has not caused any regressions so far, and I do not see a scenario where it would. The patch only affects devices with 0 input reports. Additionally, we have the patch on so many widely used kernels and has been present in them for the last 3 months, along with multiple users who added this patch manually with my guidance. The fix itself is to simply not poll any devices that have no input reports to provide. The reason why other devices are unaffected is explained in the patch description and my additional proof is the hundreds of users that use the Nobara kernel, G14 kernel, and the OGC kernel collectively.

> 
> 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

As one of the maintainers of asusctl myself, I believe I can comment on this as well. There was an issue in asusctl previously that opened the hidraw, and it was patched by Denis months ago. However this did not fix the issue that polling the hidraw by other means (Steam/Proton and even a simple cat does this) still triggered the bug. That is what my patch fixes.

I would like to also highlight that this is originally a logical issue in the kernel that should not have been there in the first place, and if a device regresses because of this fix, it is a device that needs quirking and not the other way around. That said, even for malformed input reports which you have described in your v1 response, they would still be unaffected as we only skip when there are 0 reports. The quirk HID_QUIRK_ALWAYS_POLL exists exactly for this reason, and anything without that quirk and no input reports has no business being polled.

If the maintainers still prefer it, I would be happy to have this as a quirk for only the ASUS keyboard device instead. I have explained all my reasoning for this approach in the cover letter and as mentioned, no regressions have been reported so far.

Best Regards,
Yaseen

> 
> 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@vger.kernel.org
>>> Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
>>> Tested-by: GameBurrow <gameburrow@pm.me>
>>> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
>>> Reviewed-by: Denis Benato <denis.benato@linux.dev>
>>> ---
>>>  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

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

[Antheas Kapenekakis]

On Wed, 14 Oct 2026 at 00:29, Ahmed Yaseen <yaseen@ghoul.dev> wrote:
>
> On 10/13/26 18:11, Antheas Kapenekakis wrote:
> > On Tue, 13 Oct 2026 at 14:55, Thorsten Leemhuis
> > <regressions@leemhuis.info> 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 Thorsten,
>
> Yes, this patch is still very much needed upstream. The current status of this patch is as follows:
>
> On upstream kernel, this is still waiting to be merged.
> On the OGC Kernel this has been available since 7.1.3 (since July 21)
> On Nobara kernel and G14 kernel, this has been available since 7.1.4 (since around mid July)
> On CachyOS kernel some users have opened an issue and a PR on the CachyOS kernel repo and kernel patches repos respectively.
>
> The issue itself is still present in upstream kernel and I'm still waiting for a response from the maintainers. I hope this can be merged upstream ASAP.
>
> It is still a major issue and I have recently encountered users who had switched away from Linux to other operating systems for this reason as well. Reports of this issue still come to us in varying ways and we ask these users to use one of the kernels with fixes installed. In the case of Fedora and Arch users, this would mean the OGC kernel, Nobara, or G14 kernel. For Debian-based distros, the issue is not yet present as the patch that made this issue become visible is not yet available there. However, when the patch 4ac74ea68f64 ("HID: asus: early return for ROG devices") is available in an LTS kernel, all users of Debian-based distributions will get this regression as well, so I believe some urgency is also required here.
>
> Best Regards,
> Yaseen
> >
> > Hi Thorsen,
> > there haven't been widespread issues with stuck keys on Asus recently,
> > except one regression with the fan key that merged recently.
>
> Hi Antheas,
>
> As explained above, we do still get these reports. We have users in the (previously ASUS now OGC) discord server, cachyos forum, bazzite repo issues, reddit, etc that do report these issues and multiple commenters who claim they have the same issue.
>
> Some of these issues that I found at the time of writing it are linked in the cover letter of this patchset. Other users reported this in the discord server later, and many users write it off as a one-off issue or a bug with a certain game and those who hit the issue repeatedly either report to us, roll back kernel, or even switch to an alternative like Windows. Kerim and GameBurrow who helped with my testing for example, were users who were able to reliably recreate the issue in certain games. The reproduction cases in the patch description (e.g. running cat on the hidraw node) came from them and trigger it consistently.
>
> >
> > This fix targets hid core, so merging it could cause regressions on
> > other devices.
>
> This fix has not caused any regressions so far, and I do not see a scenario where it would. The patch only affects devices with 0 input reports. Additionally, we have the patch on so many widely used kernels and has been present in them for the last 3 months, along with multiple users who added this patch manually with my guidance. The fix itself is to simply not poll any devices that have no input reports to provide. The reason why other devices are unaffected is explained in the patch description and my additional proof is the hundreds of users that use the Nobara kernel, G14 kernel, and the OGC kernel collectively.
>
> >
> > 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
>
> As one of the maintainers of asusctl myself, I believe I can comment on this as well. There was an issue in asusctl previously that opened the hidraw, and it was patched by Denis months ago. However this did not fix the issue that polling the hidraw by other means (Steam/Proton and even a simple cat does this) still triggered the bug. That is what my patch fixes.
>
> I would like to also highlight that this is originally a logical issue in the kernel that should not have been there in the first place, and if a device regresses because of this fix, it is a device that needs quirking and not the other way around. That said, even for malformed input reports which you have described in your v1 response, they would still be unaffected as we only skip when there are 0 reports. The quirk HID_QUIRK_ALWAYS_POLL exists exactly for this reason, and anything without that quirk and no input reports has no business being polled.
>
> If the maintainers still prefer it, I would be happy to have this as a quirk for only the ASUS keyboard device instead. I have explained all my reasoning for this approach in the cover letter and as mentioned, no regressions have been reported so far.
>
> Best Regards,
> Yaseen
>
> >
> > 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@vger.kernel.org
> >>> Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
> >>> Tested-by: GameBurrow <gameburrow@pm.me>
> >>> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
> >>> Reviewed-by: Denis Benato <denis.benato@linux.dev>
> >>> ---
> >>>  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)) {

Ok, I remember our conversation a few months ago.

The hid descriptor should not affect device behavior.

Just because a hid descriptor does not have input reports, you should
not change the kernel's functionality.

During development, it can be the case a hid device has a partial hid
descriptor. hidraw does not look at or care about the hid protocol of
a device. This is what hiddev is for.

As it stands this is a heuristic

If the kernel has a bug with how it handles polling on devices without
input reports, you need to find the underlying issue and fix that. if
not, you should quirk hid-asus by appending HID_QUIRK_ALWAYS_POLL if
dev->tp. You never responded to my comment so at least by my side I
considered the problem resolved.

Antheas

> >>>               res = 0;
> >>>               goto Done;
> >>>       }
> >>>
> >>> base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
>
>
>

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

[Denis Benato]

13 ott 2026 15:55:33 Thorsten Leemhuis <regressions@leemhuis.info>:

> 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 Thorsten,

This is very much needed and we had to include it in OGC kernel to avoid hid devices resetting constantly.

It is a very important fix and we are waiting for inclusion upstream because games becomes flat out unplayable with certain combination of tools.

Best regards,
Denis Benato

> 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@vger.kernel.org
>> Tested-by: Kerim Kabirov <the.privat33r+linux@pm.me>
>> Tested-by: GameBurrow <gameburrow@pm.me>
>> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
>> Reviewed-by: Denis Benato <denis.benato@linux.dev>
>> ---
>> 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