[Bug 63807] No way to filter devices

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63807

--- Comment #3 from Fedor Lyakhov <fedor.lyakhov at gmail.com> ---
Hi Zeeshan,

The format string for the filter is the same as in RHEV-M USB filter editor
tool, and it is actually documented; the filtering is provided is part of
usbredirparser library, e.g.
http://cgit.freedesktop.org/~jwrdegoede/usbredir/tree/usbredirparser/usbredirfilter.h. 

Short description an example of that string is provided in e.g.
gtk/usb-device-manager.c, 

   /**
     * SpiceUsbDeviceManager:auto-connect-filter:
     *
     * Set a string specifying a filter to use to determine which USB devices
     * to autoconnect when plugged in, a filter consists of one or more rules.
     * Where each rule has the form of:
     *
     * @class, at vendor, at product, at version, at allow
     *
     * Use -1 for @class/@vendor/@product/@version to accept any value.
     *
     * And the rules are themselves are concatonated like this:
     *
     * @rule1|@rule2|@rule3
     *
     * The default setting filters out HID (class 0x03) USB devices from auto
     * connect and auto connects anything else. Note the explicit allow rule at
     * the end, this is necessary since by default all devices without a
     * matching filter rule will not auto-connect.
     *
     * Filter strings in this format can be easily created with the RHEV-M
     * USB filter editor tool.
     */
    pspec = g_param_spec_string("auto-connect-filter", "Auto Connect Filter ",
               "Filter determining which USB devices to auto connect",
               "0x03,-1,-1,-1,0|-1,-1,-1,-1,1",
               G_PARAM_READWRITE | G_PARAM_CONSTRUCT | G_PARAM_STATIC_STRINGS);

I agree that having a string-based API is sub-optimal. I'm not good in library
API nor in GLib/GTK though - but guess it is written in C on purpose. 

I can think of exposing an API which accepts something like an array of rules
(from usbredirfilter.h) instead of the filter string:

struct usbredirfilter_rule {
    int device_class;       /* 0-255, -1 to match any class */
    int vendor_id;          /* 0-65535, -1 to match any id */
    int product_id;         /* 0-65535, -1 to match any id */
    int device_version_bcd; /* 0-255, -1 to match any version */
    int allow;              /* 0: deny redir for this device, non 0: allow */
};

const presets for filtering e.g. HIDs may be added easily:
const struct usbredirfilter_rule USBREDIRFILTER_RULE_DENY_HID =
{
    0x03,
    -1,
    -1,
    -1,
    0
}

Guess this isn't really convenient as well. Ok, what we need to filter usually?
Let's think that we already have a low-level API that may be inconvenient for
users. OK, users need to filter by device class. So we can add a convenience
API:

GPtrArray* spice_usb_device_manager_get_devices_filtered_by_class(
SpiceUsbDeviceManager *self, const GArray *usb_device_classes_to_exclude);

Then to get the filtered list of devices you'd be able to write something like:

GArray * usb_device_classes_to_exclude = g_array_new(false, false,
sizeof(guint));
g_array_append_val(usb_device_classes_to_exclude, USB_CLASS_HID);
g_array_append_val(usb_device_classes_to_exclude, USB_CLASS_AUDIO);
spice_usb_device_manager_get_devices_filtered_by_class(usb_device_manager,
usb_device_classes_to_exclude);

We can define these USB_CLASS_xxxxx as described at
http://www.usb.org/developers/defined_class: 
const guint USB_CLASS_AUDIO 0x01
...
const guint USB_CLASS_HID 0x03

Highly probably they're defined somewhere in Spice or e.g. libusb already, so
maybe we should reuse them from there.

Will this convenience function satisfy you? 

Hans, is it feasible to add something like this to SpiceUsbDeviceManager? I can
work on this.. I need a hint on what container to use (i.e. is GArray a right
choice here?)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-bugs/attachments/20130615/4a47770a/attachment.html>