[PATCH v3] winebus.sys: Handle device reports for hidraw devices

[Sebastian Lackner]

On 19.10.2016 10:50, Aric Stewart wrote:
> 
> I dont think that is a big problem. Not that it wont happen but that
> it is ok to have happen. The 2 ways to read from the
> minidriver/device layer is to either get the last report from the
> device or current device state (IOCTL_HID_GET_INPUT_REPORT) or to
> wait for the next report from the device(IOCTL_HID_READ_REPORT).
> 
> There is not specification of a need for a ring buffer or anything
> like that in the MSDN docs that I can see so it seem like keeping it
> simple and direct is the best.

Even if missing a report is not a problem, doesn't it cause an arbitrary
long delay when we have to wait for the next report? I have not been able
to find much information about buffering in HID drivers, but at least
some drivers seem to implement that. For example:

https://www.julianloehr.de/wp-content/uploads/2014/07/Paper_HIDWiimote.pdf
"""In case the Wiimote state changes when there is no read request
currently buffered, a flag is used to signal whether a newly received
read request shall be processed and completed immediately."""

In Wine we have to cache the last report anyway, so we could implement
something similar very easy. Do you think it makes sense? The
implementation of IOCTL_HID_GET_INPUT_REPORT and IOCTL_HID_READ_REPORT
would also not be much more difficult, as shown in the following
pseudocode:

--- snip ---
case IOCTL_HID_GET_INPUT_REPORT:
case IOCTL_HID_READ_REPORT:
    EnterCriticalSection(report_cs);
    ... start processing if not done yet ...
    if (ioctl == IOCTL_HID_READ_REPORT && (!last_report || last_report_seen))
    {
        ... async handling ...
        break;
    }
    ... synchronous handlng ...
    last_report_seen = TRUE;
    LeaveCriticalSection(report_cs);
    break;
--- snip ---

Regards,
Sebastian