There are some other pieces of information which can be used to select a device driver: a version number, the device class, subclass and protocol, and the interface class, subclass and protocol. (For the driver side of things on Linux, look at the USB_DEVICE macros. You can get an idea of the information available by looling at the output of lsusb -v.)
As you’d expect that’s still not enough, so before a driver is actually registered for a device, the kernel calls a probe function in the driver. That function gets to decide whether the device is actually supported by the driver. Generally speaking though, on Linux, devices with the same id but different implementations are handled by the same driver, which avoids having to map multiple drivers to one device. To see the exceptions to this rule, you can run
find /lib/modules/$(uname -r) -name \*.ko | xargs /sbin/modinfo | awk '/^filename:/ { filename = $2 } /^alias:/ { printf "%s %s\n", filename,$2 }' | sort | uniq -D -f 1 | uniq -u | less
which will list the few drivers which match conflicting ids (none of which are USB device drivers).
(I'll expand on both types of behaviour later.)
Best Answer
This information appears in the kernel logs — typically in
/var/log/kern.log, or/var/log/syslog, or some other file (it depends on your syslog configuration, different distributions have different defaults).If you'd like something pre-filtered, you can add an udev rule. Create a file
/etc/udev/rules.d/tkk-log-usb.rulescontaining something like:The environment of the program is populated with a lot of variables describing the device, including:
ACTION(addorremove)DEVICEis a path to the device if you want to access itID_MODEL_IDandID_VENDOR_IDcontain the model and vendor ID, andID_MODELandID_VENDORcontain the corresponding textID_SERIALcontains the serial number of the device (if available)