[fpc-pascal] USB Human Interface Devices

[James Richters]

>I added libusbhid_test_with_thread.pp to github. In that test you will notice I also attempted to test sharing across threads a data structure with (hypothetical) pen positions, using critical sections. Seems to work ok, but more testing is needed to make sure there are no problems.

Thank you, I'll have a look!  

>The way I see this working in your particular context, would be that the shared data structure would be written to/updated in the read thread and read less frequently in the main thread in order to update the display.

Yes, that's the way I see it too.. data would be updated every cycle in the read thread, but only accessed by the main thread just before a display update, which would be much slower.

>-5 is LIBUSB_ERROR_NOT_FOUND - this may give a clue
>http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a0593f75beb99727bbe54

I only ever get that message if timeout is not 0... so it's the timeout's way of stopping things.

I suspect when the timeout time has been reached interrupt_read is calling libusb_cancel_transfer to stop waiting for the transfer.   It seems likely that what's happening is that once in a while it tries to cancel the transfer, but before libusb_cancel_transfer has a chance to cancel it, some data comes in real quick and now it's done and there is nothing to cancel.. that would explain why it happens only intermittently.. it just has to happen that some data comes in at almost the exact same time as the timeout time.  

Since this error is generated by:    LIBUSB_ERROR_NOT_FOUND if the transfer is not in progress, already complete, or already cancelled.   And nothing else could have cancelled it except the timeout, and the timeout would not have been issued if the transfer was in progress.. that leaves that the transfer popped in real quick and completed before the timeout was done calling for a cancel transfer.

So the question is... did I end up loosing the packet?  If this is what's happening... and interrupt_read timed out.. but then data came in before the timeout was complete.. does interrupt_read discard that data because it timed out so no point in doing anything with it.. or does it store the data if it comes in before LIBUSB_TRANSFER_CANCELLED is received.

Perhaps Linux is faster at getting the transfer finished than windows.. maybe windows has some buffer thing going on or?   But yes it could be an OS difference.