device filtering support

[Vitali Lovich]

On Tue, Feb 7, 2012 at 5:05 PM, Xiaofan Chen <xiaofanc at gmail.com> wrote:
> On Wed, Feb 8, 2012 at 8:36 AM, Segher Boessenkool
> <segher at kernel.crashing.org> wrote:
>>>>> Right now I am more inclined to Segher's compromised
>>>>> proposal of give user the option of using filter to reduce
>>>>> unnecessary traffic (please refer to my previous reply).
>>>>
>>>> Yeah, I'm pretty sure it's possible to convert VID/PID to GUIDs, or
>>>> to determine the VID/PID without actually querying the device;
>>>> after all, the VID & PID are encoded in the device instance path.
>>>
>>> My thought is that GUID can be a filter for Windows.
>>
>> That will make your code Windows-only.  If you also do not implement
>> the VID/PID filter, you cannot build any code written on another
>> platform; if you do implement it but stub it out, it will run but
>> just as insanely slow as it does now; and if you have the VID/PID
>> filter implemented in such a way that it does in fact reduce traffic
>> as it should, then what do you need a filter on GUID for?
>>
>> I see no up side to this idea, sorry.
>
> 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.
That is (guessing) about 90% of libusb users (i.e. user-space drivers).

> But then the desire from Hans is that he wants to filter
> on device class, allow users to plug-in any unknown
> device and still the app should work. That can be done
That's the other 20% & is still a valid use-case IMO.

> 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).
But that's separate from libusbx - it's not like stability is
something that's unsolvable (or even present; I'm guessing it's just a
lack of confidence due to no/minimal testing, right?).

> The second best thing under Windows is to do GUID
> filtering.
What about when the HID driver or WINUSB is loaded for the device?
It's possible to write applications based off the device descriptors
(in theory) without worrying about the VID/PID (i.e. you process all
devices & match based on capability).

> I understand that VID/PID filtering itself can help
> a lot but it may not cover Hans' use case.
How do you deal with composite devices?  Do you hide the interfaces
for which a driver isn't installed?  Or is it if a driver is installed
at all, then you report it in the enum?