device filtering support

Pete Batard pete at akeo.ie
Sat Feb 4 09:30:38 EST 2012


On 2012.02.04 11:10, Hans de Goede wrote:
>> The thing is that this may well work under Linux but certainly
>> not Windows. You still need to install drivers for your random
>> or all USB devices to talk to them and that is not feasible,
>
> There already exists closed source software doing exactly what I want
> on Windows, so it is feasible. I just want to have a FOSS implementation
> of the same functionality.

Can you point to the examples you have in mind.

As stated previously, our main issue here is the massive addon in size 
to be able to install a libusbx supported driver (WinUSB and libusbK 
require MS CoInstallers, which add about 2 MB in size - we can't just 
provide a mere driver there), as well as doing things that users may not 
want, such as for instance having to _uninstall_ the existing mass 
storage driver, in order to access to a mass storage device, and 
possibly leaving it uninstalled if the application crashes or is poorly 
written, which means that, even if end-users re-plug their devices, the 
libusbx compatible driver will still be in use, and standard Windows 
data access will be denied.

There's also the possibility that the driver installation can take 
minutes (we try to avoid that, but there will be cases where we can't), 
and at best, can hardly be considered instantaneous, and that we need to 
install a bunch of certificates to do silent installations

I'm afraid Windows is quite a different beast in terms of driver 
switching compared to other platforms (and not for the best...).

Also, with regards to points that were made earlier:
- The only reason I want to go the separate process route is to address 
the issue of polluting queries being issued when enumeration is ran on 
Windows. The only way I see to avoid that, outside of filtering, is if 
we integrate enum with hotplug and maintain and dispatch data, from a 
separate thread. The question then becomes: do we want to do that in 
each libusbx app (with the drawback that if a new libusbx app is 
launched, its initial enum will come pollute the bus) or do we want to 
do it in a common process.
- If we go with filtering, we can say goodbye to topology calls, because 
we won't have data from hubs.

Regards,

/Pete



More information about the libusbx mailing list