Re: libusb file descriptors

[Tim R. <ti...@pr...>]

terence12 wrote:
> Ok. With interrupt transfers in particular there is an internal polling
> mechanism which will receive an "in token" when data is about to be
> transmitted.

That's not correct.  If there is an outstanding read request, the host
controller driver will send an IN token to the device at its time
interval saying "it's now OK for you to send".  If there are no
outstanding read requests, the IN token will not be sent, and the device
must remain silent.


> How is there not anything that triggers a flag when interrupt
> data has been received?

There is -- the read request that caused the IN token to be sent will be
completed and sent back to the caller.


> Also, if I create a program for say a mouse which uses interrupt transfers,
> where the mouse is mostly transmitting packets to the controller, does that
> mean I have to continually call libusb_interrupt_transfer() on an in end
> pointer?

Absolutely correct.  The standard HID drivers submit a couple of read
requests at startup that block forever.  They'll sit in the host
controller's I/O queue until data arrives.  When data arrived, the HID
driver removes the data and immediately resubmits the request.  That's
how USB works.


> It doesn't seem practical and there doesn't seem to be a practical
> solution for concurrent devices controlled from the same program.

Certainly, there is!  You use asynchronous (non-blocking) requests.  You
can submit requests for multiple endpoints or multiple devices and have
them all outstanding at once.  In the event handler, you figure out
which device responded and handle it accordingly.

 
> Also is it safe to continually call libusb_interrupt_transfer() on an in end
> pointer from one thread, and occassionally use libusb_interrupt_transfer()
> to write to an out pointer for the same device?

The endpoints are independent.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.