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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
