device filtering support

[Pete Batard]

On 2012.02.04 19:10, Segher Boessenkool wrote:
> Can your you translate from VID:PID to those GUID things in your
> backend? Maybe query the registry or something?

Not that I know of. And I think I may have stated that using multiple 
APIs as one of the reason why we were doing multiple passes during enum 
on Windows, but that's not accurate. We very much use multiple APIs 
during each pass, but the main reason behind each pass is to retrieve 
the GUIDs we need to access the devices on Windows. The main API we use 
(SetupAPI) relies heavily GUIDs.

For instance, the Windows enum starts with a generic pass (using the 
most generic USB GUID), that provides VID:PIDs, but it doesn't provide 
the device interface GUID which is required to open the device itself, 
or even the GUID that should be fed to SetupAPI to obtain the device 
interfaces GUIDs. So we have to query these additional GUIDs during a 
multi-pass system.

While I can not speak for Travis, I suspect that the filtering he would 
like to have is for libusbx users to have a means to provide a GUID (eg 
the GUID for a specific class of driver, such as libusbK, a.k.a. class 
GUID) that can help return the device interface GUIDs we need to open 
devices, and stop there.

While one of the problems I see is that these class GUIDs are not 
guaranteed to be unique (it is provided in the driver installation 
files, and there's no official guideline as to what it should be set to)
I don't necessarily see an issue with adding a Windows specific API that 
does filtering on them. But it will leave out some of the data that 
libusbx is expected to provide, therefore I don't see it working as the 
only API we provide for enum on Windows.

Regards,

/Pete