device filtering support

[Segher Boessenkool]

> I was thinking the same as you that the user should know
> the VID/PIDs of interests beforehand and therefore
> VID/PID filtering should be good enough, for all platforms.

For the most common case, yes.

> But then the desire from Hans is that he wants to filter
> on device class,

That is probably the next most common case.

We could have a libusb_init_with_device_class(), maybe a
list of classes.  The problem is that to implement more
complex filters, an OS backend might need to perform more
expensive operations, perhaps even send stuff on the bus.

The user can always ask for all devices (the third most
common case?), and do his own filtering perhaps.  The
filtering APIs we add should 1) be useful for most uses;
2) simplify the needed boilerplate code; and 3) make the
code more efficient, hopefully for as many backends as
possible.

> allow users to plug-in any unknown
> device and still the app should work. That can be done
> under Linux and probably Mac OS X (if the OS X
> kernel does not claim the device), but difficult under
> Windows unless using the libusb0.sys in class filter
> mode (which is unproven in terms of stability yet).

If there is no way in Windows to cheaply figure out the
device class from a device handle, that seems to me like
a rather big hole in the Windows APIs.

> The second best thing under Windows is to do GUID
> filtering.
>
> I understand that VID/PID filtering itself can help
> a lot but it may not cover Hans' use case.

I don't think it will no.

We should not aim to cover all use cases with the simple-
to-use APIs, and if the simple APIs are actually faster
than the more generic ones (because of underlying OS
problems) that is only a good thing, right :-)

And of course we should be able to make getting a full
list of devices a lot faster than it is now, so Hans'
case shouldn't feel that much pain.


Segher