https://bugs.winehq.org/show_bug.cgi?id=43125
--- Comment #4 from Kai Krakow kai@kaishome.de --- (In reply to seirra blake from comment #3)
really the impression i get from what you're saying is that there are simply just too many reports? so perhaps it needs to negotiate that 'sweet spot' where it doesn't drop any? perhaps some saved values for known gamepads with a fallback option for unknown ones where it will automatically work it out? (then perhaps prompt the user to send in a report with the values)
I've got feedback from the original creator of the code.
The explanation for my instance of the error reports seems to come from a very high axis sampling rate of the xbox controllers.
So yes, there are too many reports and the driver design is a bit difficult here. Problem is to dequeue a report fast enough. But some of the called routines have a little overhead and everything is single-threaded. If you need to feed more than one reader with device reports, the overhead just grows. When the next HID report comes in, it needs to overwrite the buffer. If you would implement a queue here, your controller inputs would drift in latency which may not be wanted.
But I'll be looking into it with helper of the author. Let's see if we can come up with an improved solution.
@Nikolay: Your issue seems to be a bit different although the same (not yet invented) fix may solve it. Maybe it comes from the gaming mouse. If it has a high sampling rate, too, it may be the same issue. OTOH, I'm not sure if the mouse should be presented on winebus.sys through SDL...
BTW: Also Gentoo here... ;-)