device filtering support

[Travis]

On 2/3/2012 5:03 AM, Xiaofan Chen wrote:
>> If libusb has hotplug however, there's suddenly less of a requirement for
>> >  libusb to ask the OS for a list of USB devices over and over again, as we
>> >  should then be able to maintain a "permanent" internal list, that we update
>> >  according to hotplug events. Now, if we want to push this idea to its
>> >  logical conclusion and remove all unnecessary re-enum (which we very much
>> >  want to do on Windows), we may have to spawn a standalone process for our
>> >  very first enum, that all subsequent libusb processes can then query
>> >  (daemon, service, but in userspace) and that would be killed on libusb_exit
>> >  from the last libusb app currently running. It may add a bit of complexity,
>> >  but it doesn't look that unachievable to me. I also see many advantages
>> >  terms of avoiding duplicated resources and ensuring that libusb handles all
>> >  of its hotplug events from a single location.

This is a bad idea because then there will be no way to disable hot 
plug;  I assume you will be creating a background thread and top-level 
window at startup for this.  This will make the enumeration situation 
significantly worse. e.g. This "permanent" list will update whether the 
user needs it or not.

The real problem with enumeration is how it works in general.  It 
request descriptor information which is already cached at the driver 
(for every device, for each process, 1 device request, 2 config 
requests)  Imagine if all USB applications did that..  lol..  Our USB 
devices would spend all of their time returning descriptors.

Unfortunately, this type of enumeration will have to go entirely if 
libusb-1.0 is to be anything more than a diagnostic tool on windows.

You idea of spawning additional processes is a bit absurd considering 
the performance problems you already have, but again none of this solves 
the real problem.  Applications cannot enumerate every USB device using 
direct I/O requests;  I hope I'm not alone on this one.

Regards,
Travis