device filtering support

Hans de Goede hdegoede at redhat.com
Wed Feb 8 14:44:50 EST 2012


Hi,

On 02/08/2012 05:08 PM, Pete Batard wrote:
> On 2012.02.08 15:54, Hans de Goede wrote:

<snip>

>> 2 functions:
>> int libusb_get_device_manufacturer_string(libusb_device *dev, char *buf,
>> int buf_len);
>> int libusb_get_device_product_string(libusb_device *dev, char *buf, int
>> buf_len);
>>
>> Which would first call a platform specific function to get the
>> manufacturer / product strings
>> from the device without opening it (as the user may not have the rights
>> to open the device) and
>> if that fails, lookup the vid + pid in usb.ids to return the relevant
>> string.
>
> Yes, I understood that. But then why limit our solving to just this issue when we can have a more long term cross platform solution to all our enumeration woes, including the problem you have?
>
>> So rephrasing my question: What do people think about adding
>> the 2 proposed functions to libusb? Good or bad idea?
>
> As long as we don't know where we're headed with hotplug and enum, I can only see it as stopgap solution.
> We want a solution to that issue, yes. But this is enum related, and hotplug is likely to be a game changer for enum, so we may add these calls only to find out we might have been able to do something better and more generic.

I see the 2 things (adding this API versus hotplug) as more of an orthogonal thing,
hotplug will change how apps get libusb_device-s, but in the end the app will still
get a libusb_device from us. The implementation of the 2 new proposed functions may
need to change as a result of hotplug / device info caching, just like the implementation
of libusb_get_device_descriptor() will likely need to change. But that does not mean
that we cannot add the API already.

But if people prefer to delay this till after hotplug that is fine with me, I've
already implemented parts of this in my own code, since I needed this yesterday,
I would like to eventually move this to libusb, but what I've works for now.

Regards,

Hans



More information about the libusbx mailing list