device filtering support
Hans de Goede
hdegoede at redhat.com
Wed Feb 8 03:45:38 EST 2012
Hi,
On 02/08/2012 02:05 AM, Xiaofan Chen 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.
>
> 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
> 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).
> 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.
As said before, if class filtering is non trivial, don't
bother implementing it. I just mentioned it because I already
have filtering code in my usbredir code, and that does have class
filtering so I thought it might be useful (for others) to have
it in the libusb filter API too. My filtering happens at a
much higher level, after enumerating *all* the USB devices in the
system, so the libusb level filtering is of little use to me.
To be more specific, my filtering code is used to decide whether
or not to *automatically* redirect a device. A user will always be
able to manually redirect a device, so I still need to enumerate
all devices.
Regards,
Hans
>
More information about the libusbx
mailing list