https://bugs.winehq.org/show_bug.cgi?id=43125
--- Comment #9 from Kai Krakow kai@kaishome.de --- (In reply to Kai Krakow from comment #7)
I'm not sure what a HID report consists of: Is it single axes events and single button events? Or is it a structure of whole device state (axes position and button states)? In the latter case, an undelivered report could be coalesced into the one still sitting there, and maybe just degrade the error to a warning or remove it completely then.
I didn't have time to look into this completely but have some ideas.
Another idea of discussion: If the last report was not read yet: Should we overwrite the queued report or should be throw away the incoming report?
By a quick glance into bus_sdl.c it looks like a report consists of the complete state of the device which includes all buttons and axes.
So in the end, the design of not having a queue in the driver makes sense: You just overwrite the queued state with the most current state and continue to wait for all readers to read this state.
The only chance to miss button presses is when a button is pressed and released within the same cycle of readers. So if a reader is too slow to process events, it may miss button presses. For axes, this is an even minor problem if reports are absolute.
I think it makes sense to degrade the error to a warning and maybe only warn once per cycle, with a cycle being the switching of the read status between TRUE and FALSE.
In the end, we are probably only hitting this issue because of the high sampling rates of modern devices.