Linux: `serialport::available_ports()` returns generic USB strings instead of actual descriptor values
makkarpov opened this issue · 3 comments
On Linux, manufacturer and product strings for USB serial ports are populated with generic strings from VID/PID database instead of actual string descriptors as expected.
For example, for a test device with VID 0x1209
(https://pid.codes) and PID 0x0002
(reserved test value) you would get the following (a bit useless) enumeration:
SerialPortInfo {
port_name: "/dev/ttyACM0",
port_type: UsbPort(
UsbPortInfo {
vid: 4617,
pid: 2,
serial_number: None,
manufacturer: Some(
"Generic",
),
product: Some(
"pid.codes Test PID",
),
},
),
}
However, device itself contains much more detailed string data, which could be used to locate the device much more precisely:
[488989.469938] usb 11-4.1.4: new full-speed USB device number 48 using xhci_hcd
[488989.559135] usb 11-4.1.4: New USB device found, idVendor=1209, idProduct=0002, bcdDevice= 2.00
[488989.559143] usb 11-4.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[488989.559148] usb 11-4.1.4: Product: Your cool product
[488989.559151] usb 11-4.1.4: Manufacturer: Your manufacturer name
Alternate way of querying correct Linux device info could be found in pyserial repository: https://github.com/pyserial/pyserial/blob/master/serial/tools/list_ports_linux.py
udev also contains correct strings, but I'm not sure why serialport-rs extracts generic data instead.
Thank you for bringing up this issue! I can confirm this behavior. We are using udev for retrieving this information, strange, that it does not report the actual value from iManufacturer
and iProduct
.
Thanks for the pointer to pySerial. I will have a look there.
It looks like we are preferring the information from udevs hardware database over the one provided by the usb device itself. I'm working on #137 to sort this out. Could you please give these changes a try?
Sure, I tested these. These changes indeed give a correct results.
Thank you for promt response!