device filtering support

[Hans de Goede]

Hi,

On 02/08/2012 01:22 PM, Xiaofan Chen wrote:
> On Wed, Feb 8, 2012 at 4:45 PM, Hans de Goede<hdegoede at redhat.com>  wrote:
>> 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.
>
> It is indeed useful use case.
>
>> 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.
>
> Okay, what kind of information you need from *all* USB devices?
> Some of them are easier to get, some of them are bit more
> difficult (at least for Windows), say the speed information
> or the topology information.

The information which I need is:
1) the device descriptors (so as to be able to show a pid/vid to
  the user in some use cases)
2) the config descriptors (to find out the interface classes
  needed for the class based filtering I have)
3) string descriptors (Product and Manufacturer string), to show
  user friendly descriptions of devices to the user.

Note no speed or topology info. I only need speed info after
opening the device, and I never need topology info (never say
never, but atm I don't need it).

3. Actually is a problem atm, since libusb requires the device
to be opened to get this. So for now I have Linux specific code
in my usbredir code to get these directly from sysfs where
Linux caches these and I'm working on code for going from 1.
to something resembling 3. using Linux's usb.ids file, since
some devices don't bother with reporting string descriptors
at all.

I'm thinking about adding support for getting the
manufacturer and product string from a libusb_device to
libusb itself, note the from a device not a device_handle!

The idea would be to have platform specific code to do this,
and when that fails fall back to getting the strings from usb.ids
(we could ship our own copy for non Linux platforms).

So a question from my side, what do people think about adding
such functions to libusb? Good or bad idea?

Thanks & Regards,

Hans