[fpc-pascal] USB Human Interface Devices

[Stefan V. Pantazi]

I agree with you: the libusbhid_interrupt_read and 
libusb_interrupt_transfer are very close semantically and returning as a 
result either the length of transferred data or the error code would 
make a lot of sense. But in rare cases one may still need to check both 
parameters:

http://libusb.sourceforge.net/api-1.0/group__syncio.html#gac412bda21b7ecf57e4c76877d78e6486
"Also check transferred when dealing with a timeout error code. libusb 
may have to split your transfer into a number of chunks to satisfy 
underlying O/S requirements, meaning that the timeout may expire after 
the first few chunks have completed. libusb is careful not to lose any 
data that may have been transferred; do not assume that timeout 
conditions indicate a complete lack of I/O."

At any rate, switching around and returning both: the error code as the 
result of libusb_interrupt_transfer and the length of data transfer as 
an out parameter maybe the right thing to do. That would probably make 
the semantics of libusbhid_interrupt_read and libusb_interrupt_transfer 
almost identical.

On 8/28/19 5:03 AM, James Richters wrote:
> Thanks for adding the hotplug functions and the sample program.  I will give that a try.
> 
> I have come up with another solution before I saw you added the hotplug functions:
> 
> My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower,  so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore.
> I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed.  But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions,  they only return the number of bytes transferred.  Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again.  The first read that produces an error will stop the thread.
> 
> I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout.  https://github.com/Zaaphod/libusbxhid/tree/Test
> 
> 
> James