Ihor Dutchak
Ihor Dutchak
Nevertheless thanks for great investigation. No one has check it this deep in context of HIDAPI. I'll keep this ticket open for now. Maybe there will be more findings/details.
Can you verify that you're not trying to call `hid_close` concurently with any other HIDAPI function? Can I assume you're using latest `master`/latest release of HIDAPI?
HIDAPI is not thread-safe. You definitely shouldn't call both hid_write and hid_close concurently. That is undefined behavior.
> @returns > This function returns the number of bytes read plus > one for the report ID (which is still in the first > byte), or -1 on error....
> Just wondering what you mean by the above. I believe that is a though process "out loud", i.e. "it is probably would be clean to have an API where...
That's exactly my point. Having report ID at the beginning of the buffer - means not extra buffer "prepending" on HIDAPI side.
> If we just want to unify the behavior across platforms, then we only need to fix Output Report write length reporting to the user. I tend to think we...
50 is definitely too much (that is a lot of flood on the driver/bus in some cases when `EPIPE` is even expected. I cannot imagine a case, where the `ioctl`...
In that case maybe make the number of retries configurable. Make it small (5?) by default and give some means to configure it for projects like SDL. > This happens...
Making a draft for now, until we have a better implementation.