[Bug 43125] Device reports coming in too fast

[wine-bugs at winehq.org]

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

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

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