Re: [Libusb-devel] libusb-1.0 Windows backend when WinUSB is a filter driver

[Pete B. <pb...@gm...>]

On 2010.08.18 17:50, Peter Stuge wrote:
> Is there no way to enumerate also filter drivers?

Having now had a chance to play with the filter driver device, it looks 
like there's a "Device lower filters" entry that is being added when a 
filter driver is used and which contains the service name (eg "WinUSB" 
of a libusb0.sys filter driver device).
No idea what happens when there are multiple "Device lower filters" 
there (plural, so there could be more than one - space delimiter? 
semicolon?). If anybody knows, or has access to a device with multiple 
lower filters, feel free to enlighten us with what you see in the 
"Device lower filters" property.

Now, it seems we should be able to use the SPDRP_LOWERFILTERS key [1] to 
retrieve that property, so I am planning to add a fallback to lower 
filter to the code shortly. This should work fine as simply adding 
libusb0 to the list of known WinUSB API names allowed me to access a 
"filtered" device on my machine successfully and the libusb-win32 filter 
driver inf seems to work fine on my platform as well.

As to what we should do if both the filter driver and the regular driver 
are supported in our backend, right now my view would be to just ignore 
the filter driver always, unless we have specific scenario where we see 
being able to switch to lower filter as a must have. Otherwise we will need:
- either a new API call for driver backend selection or the creation of 
a fake composite parent device (with one additional interface per filter 
driver, though that would be probably abuse the composite device 
definition, and we could end up with interfaces of composite devices 
being "composite devices" themselves)
- code in most of the libusb API calls to prevent simultaneous access to 
the filtered and unfiltered device.

All in all, supporting user switching between filtered and unfiltered 
looks like a lot of effort, as well as adding a lot of complexity, for 
benefit that I don't really see ATM. We might however tweak the fallback 
between regular and filter driver to try filter first, as I suspect 
that, if somebody added a filter, they probably prefer that driver to be 
used over regular where possible.

In short, being able to use libusb as a filter driver for drivers which 
we don't currently support is a good thing, and should be 
straightforward enough to implement. On the other hand, being able to 
use libusb to switch between 2 drivers that we support looks like a more 
disputable feature to carry...

Regards,

/Pete

[1] http://msdn.microsoft.com/en-us/library/ff551967%28VS.85%29.aspx