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

[Travis <tra...@co...>]

> 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.

LowerFilters and UpperFilters are REG_MULTI_SZ (String array).  They are 
separated with a NULL and terminated with two (2) NULLS. IE:
WinUSB\0HidUsb\0\0

>
> 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.

Nice, You should probably check both Upper and Lower filters.

>
> 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.

I think the problem is how the devices are discovered. I did not change 
anything in libusbdotnet to get this to work.  Using the standard MSDN 
recommended methods for WinUSB works perfectly.
1) First find all the DeviceInterfaceGUIDs
2) find all the DevicePaths for each device in each device interface GUID
3) remove duplicate device paths and your golden.

Regards,
Travis