device filtering support

[Pete Batard]

On 2012.02.08 03:51, Travis wrote:
> At this point I don't know if we are talking about class GUIDs or device
> interface GUIDs but getting the class guid given a VID:PID is certainly
> possible. Getting the list of device interface guids given a VID:PID is
> also possible.

Well duh.

I said "a bit more complex" (my words exactly), because that's how it is 
if you're not poking the registry directly and try to use the Windows 
APIs: You need to do the multi-GUID pass dance.
I didn't say impossible.

The class GUIDs are what we use to get to the device interface GUIDs. 
And we also gather both VID:PID and device interface GUID in our current 
enum, so we can access the whole lot. And obviously, we don't need to 
poke descriptors for that data.

The reading/caching of descriptors and obtaining specific data about 
devices that may not be of interest (such as hubs) is an explicit 
_requirement_ from libusb (it's in libusbi.h), so that's why we do it. 
We can push that caching into a thread/process and do it once per app 
session/OS session, which is something I thought about doing for some 
time, but as far as I'm concerned that's a wasted effort unless we have 
hotplug.
And that's why I have been diligently waiting for libusb(x) to sort out 
hotplug and chose not to spend more time than I should on the 
caching-of-the-descriptors issue.

Does that make sense? Or are you still intent on solving a problem that 
would be better looked into after we have some idea of where we're 
headed with hotplug?

>> libusbx has to figure out what devices are there (it simply is
>> part of our API, and it makes sense). You can get a list of
>> the USB devices on your system pretty cheaply I would think
>> (in whatever format)? Certainly without causing traffic on the
>> USB?
>
> Yes, but not in the form of descriptors.

I think we all agree there. And we should agree that the libusb(x) 
explicit requirement to pre-emptively cache the device and config 
descriptors may cause a problem because there's nothing that says that 
the OS libusbx runs on will be able to avoid querying for them. And, 
because libusbx also doesn't currently have hotplug, it may also not be 
possible to escape having to query the same device more than once.

Ergo, if we don't want to change the current user expectations, we may 
want to look into a cross-platform way of doing such caching, one that 
probably leverages hotplug and that preferably does it once per OS 
session, rather than rely on each backend developer to come up with 
their own internal and potentially limited workarounds.

> However, you could nearly
> re-create the device descriptor with the information in the registry.

Or query and cache the _exact_ descriptors once per app/OS session, 
using the OS APIs...

Regards,

/Pete


PS: on the subject of "rather big holes in the Windows APIs", how about 
a device API that doesn't offer any means of identifying the parent of a 
device. Yup, that's one item the GUID based Windows SetupAPI cannot do 
(and one of the main reasons we have to use more than one API). Or how 
about an HID API that offers no means whatsoever of returning an actual 
HID report descriptors...
You'd be surprised how restrictive some of the Windows APIs can be.