[Bug 43125] Device reports coming in too fast

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Jul 12 03:31:24 CDT 2018


https://bugs.winehq.org/show_bug.cgi?id=43125

--- Comment #4 from Kai Krakow <kai at 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... ;-)

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list