3 ms·

I'm not sure I fully understand the article. What does the following mean? "Since other USB device vendors such as Microchip and FTDI give away USB PIDs for fr

I'm not sure I fully understand the article. What does the following mean? "Since other USB device vendors such as Microchip and FTDI give away USB PIDs for free" Does that actually mean, they give them for free? If so, how can they do that? Why does VTM allow them to do it? And what is the actual problem at all if you can get them for free?

NonEUCitizen 13y ago
A device has a Vendor ID (VID) and a Product ID (PID). For example, the following is output from lsusb: Bus 002 Device 013: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 0a12 is the VID for CSR, and 0001 is CSR's PID for "Bluetooth Dongle (HCI mode)." You can find a list at: http://www.linux-usb.org/usb.ids http://www.linux-usb.org/usb.ids Microchip has paid USB Forum for its VID 04d8. If you build a USB peripheral with one of their microcontrollers, you can ask Microchip to allocate you a PID (since they have 64K of these), and let you use their VID: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICENSE%20TO%20USB%20VID%20revised%2012110.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%...
- Aardwolf 13y ago
  Thanks a lot! What if more than 64K people have asked for a PID?
  - candydance 13y ago
    They'd just buy up another VID, the names associated with VIDs don't need to be unique.
    - femto 13y ago
      Alternatively, a bunch of cooperating projects could share a VID:PID pair and agree amongst themselves and agree on an alternative way to identify devices. The VID:PID would cause the USB driver to load a "sub driver" that would implement the alternative scheme. For that matter, by using such an extension the whole open source community could exist under a single VID:PID.
candydance 13y ago
Since a USB device gets paired with a driver through a VID/PID pair, buying a single VID allows you access to 65536 PIDs for that VID. They give out the PIDs for free but hold on to the VID for themselves. FTDI own a bunch of VIDs which are associated with "FTDI" devices. If you ask FTDI they'll reserve a small block of PIDs for you to use for your own products that use the FTDI USB chips. 8 PIDs cut out of a 65536 block is not a significant cost. I'm surprised that VTM still allows them to do it though, maybe it's a special case because you're using their IC. The problem is that VTM maintains an "official" list of VID/PID owners, so that they can keep drivers on seperate IDs and prevent clashes for users. Most hobbyists just pick a random VID/PID for their personal projects and hope for the best, but for small scale hobby releases it's problematic since "technically" they are going against the terms of service for the USB protocol. Sometimes there will be clashes if people pick random numbers, and VTM hates that. http://www.ftdichip.com/Support/Knowledgebase/index.html?caniuseftdisvidformypr.htm http://www.ftdichip.com/Support/Knowledgebase/index.html?can...
- ajross 13y ago
  USB devices are supposed to be detected via the class (es) declared in the descriptor actually. This allows for e.g. a single HID driver to work with input devices from all manufacturers. Linux drivers almost all work this way, using the vid/pid for quirk detection only. The windows world tends to be less clean.
  - jmaygarden 13y ago
    That falls flat for custom/vendor classes. It's a fairly convenient route for a device that doesn't fit the other molds using libusb/WinUSB drivers.

NonEUCitizen 13y ago

A device has a Vendor ID (VID) and a Product ID (PID). For example, the following is output from lsusb: Bus 002 Device 013: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 0a12 is the VID for CSR, and 0001 is CSR's PID for "Bluetooth Dongle (HCI mode)." You can find a list at: http://www.linux-usb.org/usb.ids http://www.linux-usb.org/usb.ids Microchip has paid USB Forum for its VID 04d8. If you build a USB peripheral with one of their microcontrollers, you can ask Microchip to allocate you a PID (since they have 64K of these), and let you use their VID: http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%20FOR%20SUBLICENSE%20TO%20USB%20VID%20revised%2012110.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/APPLICATION%...

Aardwolf 13y ago
Thanks a lot! What if more than 64K people have asked for a PID?
- candydance 13y ago
  They'd just buy up another VID, the names associated with VIDs don't need to be unique.
  - femto 13y ago
    Alternatively, a bunch of cooperating projects could share a VID:PID pair and agree amongst themselves and agree on an alternative way to identify devices. The VID:PID would cause the USB driver to load a "sub driver" that would implement the alternative scheme. For that matter, by using such an extension the whole open source community could exist under a single VID:PID.

candydance 13y ago

Since a USB device gets paired with a driver through a VID/PID pair, buying a single VID allows you access to 65536 PIDs for that VID. They give out the PIDs for free but hold on to the VID for themselves. FTDI own a bunch of VIDs which are associated with "FTDI" devices. If you ask FTDI they'll reserve a small block of PIDs for you to use for your own products that use the FTDI USB chips. 8 PIDs cut out of a 65536 block is not a significant cost. I'm surprised that VTM still allows them to do it though, maybe it's a special case because you're using their IC. The problem is that VTM maintains an "official" list of VID/PID owners, so that they can keep drivers on seperate IDs and prevent clashes for users. Most hobbyists just pick a random VID/PID for their personal projects and hope for the best, but for small scale hobby releases it's problematic since "technically" they are going against the terms of service for the USB protocol. Sometimes there will be clashes if people pick random numbers, and VTM hates that. http://www.ftdichip.com/Support/Knowledgebase/index.html?caniuseftdisvidformypr.htm http://www.ftdichip.com/Support/Knowledgebase/index.html?can...

ajross 13y ago
USB devices are supposed to be detected via the class (es) declared in the descriptor actually. This allows for e.g. a single HID driver to work with input devices from all manufacturers. Linux drivers almost all work this way, using the vid/pid for quirk detection only. The windows world tends to be less clean.
- jmaygarden 13y ago
  That falls flat for custom/vendor classes. It's a fairly convenient route for a device that doesn't fit the other molds using libusb/WinUSB drivers.