Identify USB Devices Beyond Vendor/Product IDs

[sl33nyc]

Before I endeavor on potentially coding this myself (because I kind of want an excuse to learn Rust), I want to sanity check the following enhancement request.

In the non-Windows source, I noticed that the USB device matching ultimately uses rusb::DeviceDescriptor insteadofrusb::Device. Thus, fields like Device.bus_numberandDevice.addresscannot be matched upon. The callback receivesrusb::Device, so I wonder if display_switchmatching criteria could be expanded to also match uponrusb::Devicelike bus/address/port. This would enable thedisplay_switch` instance on my Ubuntu host to detect a constant set of USB peripherals hooked into a single USB switch relocating from the "Ubuntu host" USB port to another, the "Windows 10 VM host" port.

I haven't deeply checked whether or not the Windows-specific display_switch implementation can support additional matching criteria. (A quick read of the Windows code tells me that the code compares a set of vendor/product strings before and after a WM_DEVICECHANGE event, so I'm guessing my enhancement might have to be libusb specific.) Such functionality would still be awesome for libusb-supported hosts.

[haimgel]

@sl33nyc I think this should be possible, at least in the realm of libusb... I'm not sure if this is desirable, though, since it's basically overloading the meaning of one field with two possible sets of values, and both are 32-bit integers.

I wonder if it's possible to match on something more descriptive, other than bus/address/port. I always wanted to just allow saying =descriptive-name there and not ask users to hunt for descriptor IDs... E.g. allowing "Ubuntu host" and "Windows 10 host" there, if possible, is much more desirable IMO.

[sl33nyc]

I generally agree that overloading the field's value isn't great but I don't think that it'd be too terrible if the value of usb_device is prefixed with something to distinguish the existing, expected USB descriptor values from the newer format which is prefixed with something like magic-v2-string:. Alternatively, we could create a new usb_device-like field.

I also agree that it'd be cool if the device matching was abstracted away into something that ultimately could be represented by a descriptive-matcher-name. Perhaps a libudev based solution for Linux, but I'm unsure what's a maintainable equivalent for Windows. I wonder if integrating with libudev would enable Bluetooth display switching?