Vendor names displayed by operating systems

[sol]

Hey there 👋

I noticed that lsusb under Linux will indiscriminately show OpenMoko, Inc. (instead of say the manufacturer reported by the USB device) if you use 0x1d50 as VID .

Alternatives:

• If you use the VID from pid.codes then lsusb will show Generic.
• If you use an unassigned VID then lsusb will show the manufacturer as reported by the USB device.

Behavior of other systems:

• Other places on Linux seem to show the manufacturer as reported by the USB device.
• Windows (tested via a VM) seems to only show the product name as reported by the device and omit vendor/manufacture entirely.

Questions:

• Would it make sense to work with upstream to get more sensible behavior here?
• Does anybody know where the upstream source for this is? I could only find http://www.linux-usb.org/usb.ids. https://github.com/vcrhonek/hwdata/blob/master/usb.ids
• Does anybody know what OS X does here?

[pabs3]

That situation seems sub-optimal indeed, thanks for mentioning it. @gregkh manages the usbutils project, perhaps he can give a response from a Linux kernel USB perspective, but I've listed below what I was able to find from a quick debugging/browsing session. Looking at the usb.ids file, the file format does not at first glance allow for a per-PID override of the VID manufacturer string. I also note that lsusb no longer uses usb.ids directly, instead it relies on the udev database, which is converted from usb.ids. The udev database however has 20-usb-vendor-model.hwdb in a more flexible file format that seems like it could in theory override the vendor string on a per-PID basis. However the file is just a direct conversion from usb.ids and other tools probably still use usb.ids. So right now, removing from usb.ids the PIDs of devices that shouldn't show OpenMoko or Generic seems like the way to go, as long as those devices properly report their manufacturer/device strings correctly. A longer-term fix for this issue would require extending the usb.ids file format to allow for this feature and then adapting udev and any other tools that use usb.ids to deal with the extension. Allowing one VID to appear twice in the file with different vendor strings and different PID sets would be an easy way to achieve this. Another potentially useful extension would be to make the absence of a string after the VID/PID mean show the device string instead, I expect this could be immediately useful for pid.codes for example. Looking at the usb.ids web page, it seems that the file is generated from entries in a database, which is managed by a web app. http://www.linux-usb.org/usb-ids.html https://usb-ids.gowdy.us/ So I think this will need to be discussed with the upstream usb.ids and linux-usb folks, please send a mail to both of them about this. http://www.linux-usb.org/mailing.html

…

-- bye, pabs https://bonedaddy.net/pabs3/

[laf0rge]

It never occurred to me that this could be considered an "issue" or a "bug". This has been how lsusb / usb-utils has always operated... use usb.ids for non-verbose and use the string descriptor for verbose output.

Keep in mind that sharing a USB Vendor ID for a variety of projects (OSHW or otherwise) is not how USB vendor IDs were originally anticipated to be used. I'm not sure if such a niche, non-standard use case would warrant a change in the related tools.

After all, this is just a minor cosmetic inconsistency. The Kernel log prints the string descriptor of the firmware/device, as do the libusb APIs to query the device itself.

[laf0rge]

Use "lsusb -v" and you'll get the string descriptors from the device instead of something from usb.ids -- Sent from a mobile device. Please excuse my brevity.