4 ms·

The part that makes me feel most uncomfortable about usb VID/PIDs is that they are only 16bits each. While I don't think 4billion unique commercial USB devices

The part that makes me feel most uncomfortable about usb VID/PIDs is that they are only 16bits each. While I don't think 4billion unique commercial USB devices is limit we will reach anytime soon, efficiently managing the available address space is a different question. And unlike IPv4 addresses a range of USB VID/PIDs can't be as easily reused without making the VID/PID meaningless.

crote 2y ago
By that time they'll just add an extra field to the protocol and assign a special "see other field" VID/PID pair. For a lot of products the VID/PID combo isn't that important on a protocol level, and there's technically no reason why two completely unrelated products couldn't be using the same pair. In practice you're mainly going to use them for software to target a specific device, for example the Linux HID driver uses it to work around hardware/firmware bugs. But HID devices are self-describing, and that's the main mechanism used by the driver to figure out what has been attached and how to behave. If modern OSes can do the same to distinguish hardware with the extra field, sharing the same value for backwards compatibility with legacy machines really isn't going to be a big deal. It's not like MAC or IPv4 addresses where a clash will essentially kill all communication.
anymouse123456 2y ago
The problem isn't the combined limit, it's the hard limit on Vendor IDs at 65,535. Since very few companies have 65,535 products, almost all Product IDs in any given Vendor ID namespace are unused. That is the maximum number of organizations on Earth that can be issued a USB Vendor ID until the spec is modified. They'll likely introduce a special Vendor ID that indicates to clients they should look elsewhere for the real (and longer) one. While the rules were more lax many years ago, and some vendors are grandfathered in and can therefore share their Product ID allocation, these behaviors are explicitly prohibited by the USB-IF for newly issued Vendor IDs.

crote 2y ago

By that time they'll just add an extra field to the protocol and assign a special "see other field" VID/PID pair. For a lot of products the VID/PID combo isn't that important on a protocol level, and there's technically no reason why two completely unrelated products couldn't be using the same pair. In practice you're mainly going to use them for software to target a specific device, for example the Linux HID driver uses it to work around hardware/firmware bugs. But HID devices are self-describing, and that's the main mechanism used by the driver to figure out what has been attached and how to behave. If modern OSes can do the same to distinguish hardware with the extra field, sharing the same value for backwards compatibility with legacy machines really isn't going to be a big deal. It's not like MAC or IPv4 addresses where a clash will essentially kill all communication.

anymouse123456 2y ago

The problem isn't the combined limit, it's the hard limit on Vendor IDs at 65,535. Since very few companies have 65,535 products, almost all Product IDs in any given Vendor ID namespace are unused. That is the maximum number of organizations on Earth that can be issued a USB Vendor ID until the spec is modified. They'll likely introduce a special Vendor ID that indicates to clients they should look elsewhere for the real (and longer) one. While the rules were more lax many years ago, and some vendors are grandfathered in and can therefore share their Product ID allocation, these behaviors are explicitly prohibited by the USB-IF for newly issued Vendor IDs.