device filtering support

[Hans de Goede]

Hi,

On 02/03/2012 01:58 PM, Kustaa Nyholm wrote:
> This mainly curiosity and not wishing to (not being competent to)
> get involved in the substance of this thread there are couple
> of things I'd like to be educated about, feel free anyone.
>
> On 2/3/12 14:17, "Hans de Goede"<hdegoede at redhat.com>  wrote:
>> But Unix users are used to not having to think about
>> multi threadedness, instead relying on a select based loop.
>
> This seems to imply and equate Unix users with certain type of
> application / usage. For me it is hard to think about
> a program/application that has a graphical user interface
> (and uses usb) which does not have multiple threads.

As someone who has done usb redirection to a "vnc" client,
with the client doing input handling and displaying /drawing
the vnc window while handling usb traffic to / from
multiple devices including a streaming usb2 webcam I disagree :)

As long as you only use the async API and integrate usb packet
completion into your event loop (see below) no multithreading
is needed.

Note: I did end up going multithreaded in the end, but it worked
fine single threaded too.


>
>>
>> So I think we need to make it really really really clear in the API docs
>> that
>> the device removed/added callbacks are called from a different thread, and
>> add an option for Unix API users to disable this behavior.
>
> Hmm ... for me in it looks pretty obvious that callbacks
> (in the absence of any standardized way of evoking them in
> the defining thread) are inevitable called from a different thread.
> But maybe I'm missing somethig ... or am not a real unix programmer
> at heart ;-)
>
>> Of course the
>> Unix API users need to use the pollfd "stuff" then to make sure the
>> callbacks
>> are called, but I think being able to this non multi-threaded is important
>> for Unix users.
>
> Ok, maybe I see the light here: is this pollfd "stuff" what I
> described above as "standardized way of evoking callbacks in
> the defining thread" ?

Yes, it gives the app a list of filedescriptors and tells it
to monitor those (using for example select), you can then
integrate these fd's into you GUI toolkit event loop for example,
and call libusb_handle_events() when there is any activity on
the fds.

Regards,

Hans