Bug: HID/input - Input misses when rapidly pressing consumer control keys on Logitech Media Keyboard K200

Description:
When consumer control buttons such as volume up/down, pause/play etc
of the Logitech Media Keyboard K200 are rapidly pressed, most of the
inputs don't register properly.

Environment used:
- linux kernel 7.20.rc-4-dirty
- qemu-system-x86_64 version 11.0.50. The arguments used were(This
passes the keyboard through to qemu):
    -kernel "$BZIMAGE"
    -machine "q35"
    -cpu max
    -vga std
    -display gtk
    -device qemu-xhci,id=xhci
    -usb -device usb-host,bus=xhci.0,vendorid=0x046d,productid=0xc31d
    -initrd "$INITRAMFS_CPIO"
    -m 1G
    -smp 4
    -no-reboot
    -virtfs "local,id=lkmpg,path=$PROJECT_ROOT,security_model=none,mount_tag=lkmpg"
    -append "nokaslr"
(this is a slightly modified version of the qemu environment specified
at the start of the Linux Kernel Module Programming Guide)
- Qemu itself runs in a distrobox container running an Ubuntu 26.04 LTS
- My host is Fedora Kinoite 43 with kernel version
6.17.12-300.fc43.x86_64(where I first noticed the issue)
- The keyboard's vendorId : productId -> 046d:c31d

Steps for reproduction:
- Run hexdump -v on the appropriate /dev/input/event entry
- Press the volume up button on the keyboard, slowly
- Given enough time between key presses all presses cause a change in
output with corresponding press/release entries
- Rapidly press the volume up button on the keyboard
- Notice that output either:
   1. Doesn't change at all.
   2. or after some time, it sort of gets flushed and you see a bunch
of entries output all together.

Expected Behaviour:
Each button press/release should correspond to an event.

Some Notes and Logs:
- I concluded that this isn't likely to be a hardware issue as the
expected behaviour was shown on    Windows 11.
- I noticed this issue first in kernel 6.12.12, and later I tested it
in 7.20.rc-4-dirty and discovered      that the issue still persists.
- I hacked on the kernel in an attempt to figure out the problem
myself, adding pr_info statements dumping state in evdev_read,
input_event_dispose and hid_irq_in and saw the following(linked is my
raw dmesg output without my changes, output grepping my pr_info
statements and my .config. I have delimited the 3 sections by using a
bunch of '=' characters):

https://pastebin.com/59FsWsvq

It seems to me that there are a lot of unnecessary SYN_REPORT calls
with a disposition that triggers a flush of the device's inputs such
as:

[  110.907511] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[  110.907543] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10
[  111.035339] hid_irq_in device: 1133:49949 status: 0
[  111.035412] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[  111.035431] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10

...but I couldn't get any further than that.
- Also, I noticed that the polling rate for consumer/system control is
set to 255 ms whereas the main keyboard is set to 10 ms(I got this
from the bInterval value while debugging).

Would appreciate guidance on this.