The serial_number returned by the list_devices function is in uppercase, while libusb returns it in normal case (lowercase).

[lethargy123]

I tested with my Xiaomi Mi 8 connected to a computer. Here is the code I used and the corresponding results

[kevinmehall]

Looks like you're on Windows. The Windows backend parses the serial_number from the instance ID, and I guess that's case insensitive like a Windows path and is getting uppercased by Windows.

Does the get_string_descriptor example show the correct lowercase value for your device?

I noticed that IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION (used by Device::get_string_descriptor) returns serial string descriptors even for suspended devices, which implies it's returning a cached value instead of performing IO. If that's true, we could change DeviceInfo to use that instead of parsing the instance ID.

Libusb makes you open a device and then you can read any descriptor and it may perform IO. The nusb Device methods for descriptors work like that too. I want list_devices to avoid making actual requests to the device, but it's nice to have serial numbers there to identify a particular device before opening it.

Also, the strings returned for manufacturer and product on Windows depend on the driver, and some drivers return their own fixed string instead of using the string descriptors. I'm not sure we should even return these on Windows, since we can't tell if they're wrong.

[lethargy123]

Looks like you're on Windows. The Windows backend parses the serial_number from the instance ID, and I guess that's case insensitive like a Windows path and is getting uppercased by Windows.

Does the get_string_descriptor example show the correct lowercase value for your device?

I noticed that IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION (used by Device::get_string_descriptor) returns serial string descriptors even for suspended devices, which implies it's returning a cached value instead of performing IO. If that's true, we could change DeviceInfo to use that instead of parsing the instance ID.

Libusb makes you open a device and then you can read any descriptor and it may perform IO. The nusb Device methods for descriptors work like that too. I want list_devices to avoid making actual requests to the device, but it's nice to have serial numbers there to identify a particular device before opening it.

Also, the strings returned for manufacturer and product on Windows depend on the driver, and some drivers return their own fixed string instead of using the string descriptors. I'm not sure we should even return these on Windows, since we can't tell if they're wrong.

The example code cannot run directly (it panics). I made some modifications to the example code, and now I am able to retrieve the correct Serial. However, I believe it should be possible to read the Serial without opening the device.

[kevinmehall]

Yes, I want list_devices to return as much information as the OS has already has available about the device, but I don't want it to make any new requests to a device unless you open it. I'm going to check if the Windows API used by Device::get_string_descriptor is suitable to use in list_devices to get the serial number, and if so will make it use that instead.

What was the RUST_BACKTRACE=1 panic message from the example?

[lethargy123]

是的，我想返回操作系统已经拥有的有关设备的尽可能多的信息，但我不希望它向设备发出任何新请求，除非您打开它。我将检查 使用的 Windows API 是否适合用于获取序列号，如果是，将改用它。list_devices``Device::get_string_descriptor``list_devices

这个例子的恐慌信息是什么？RUST_BACKTRACE=1

[Resonanz]

A watcher here… Very pleased to see this repository… Thanks for your efforts so far.

[kevinmehall]

@CCnut also points out that the current code also returns incorrect serial numbers when Windows assigns unique instance IDs for devices with duplicate serial numbers.

I tested using IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION to get the serial number and it seems to mostly work. It still doesn't handle duplicate serial numbers, though. Windows doesn't have the serial number cached on the second device, and so fails to get any serial number if the device is suspended. Still better than returning the generated part of the instance ID, I suppose.

Included that change in #57, all of which needs more testing.