18 ms·

Get your own USB PID

528 points by oxplot 12y ago

otoburb 12y ago
Thank you! This addresses a real need in the open source hardware community. Is USB-IF aware of this[1]? Would they see this as a violation of the spirit of the current terms in the sense of the revenue loss, and come after pid.codes for every $500 application they feel you might owe them? I'm optimistically hoping that you've discussed this with USB-IF and that although they may not officially endorse or support, they won't actively try to stop what you're doing. [1] >>This site is in no way supported or endorsed by USB-IF. EDIT: I should have read the FAQ[2] where you address this question specifically under "Won’t you get in trouble?" [2] http://pid.codes/faq/ http://pid.codes/faq/
- etimberg 12y ago
  I think it would be pretty mean spirited of the USB-IF to go after open source hardware projects. It's not like these are projects that will be earning someone money. Unfortunately, lawyers will probably get overzealous.
  - otoburb 12y ago
    I also think it would be mean spirited, albeit somewhat consistent with their current stance of not giving any open source hardware projects a break on the $5K VendorID registration & assignment fee[1]. [1] http://www.usb.org/developers/vendor/ http://www.usb.org/developers/vendor/ EDIT: Fortunately, other organizations have done something similar, such as OpenMoko[2], without incurring USB-IF's wrath. [2] http://wiki.openmoko.org/wiki/USB_Product_IDs http://wiki.openmoko.org/wiki/USB_Product_IDs
- aceperry 12y ago
  I don't think the USB-IF had given much thought to the maker community, and makers weren't as big back then when USB-IF put together this program. I agree with you and hope as well that the USB-IF gives the open-source maker community a break. Although, recently, the Bluetooth SIG (Bluetooth equivalent of the USB-IF) started to charge fees to anyone utilizing Bluetooth in their products, even if you used a module that was already qualified and paid fees. Hopefully the USB-IF won't do the same.
aw3c2 12y ago
This makes me wish I was a hardware hacker just to get 0451.
ipsin 12y ago
I didn't know much about USB PIDs, but I expect that with 64k available on one VID, they'll go pretty quickly. Are there any attempts to expand the id space as part of the standard?
- akiselev 12y ago
  USB vendor/product IDs are for unique hardware designs/firmware so that they are easily recognized by their respective drivers, not each unique piece of hardware. For example, Logitech's vendor ID (they probably have a few) allows them 64,000 different keyboard, mouse, etc. products of which they can manufacture millions of units. I don't know of any vendor ID that has exhausted their product ID space which includes companies like Microchip which give away PIDs on their VID when you use their USB chips (with under 10k units in production)
- uxp 12y ago
  USB PIDs aren't like NIC MAC addresses, two identical items (keyboards, webcams, etc.) are supposed to have the same PID in order for the OS to recognize them as being the same and to apply the same driver to them. The VID is just a namespacing convention.
Serow225 12y ago
Very nice, both in concept and execution! I don't have anything useful to add here, other than saying kudos for a job well done :)
- zymhan 12y ago
  This is definitely one of my favorite things about the open-source ethos - that unnecessarily complex barriers can be broken by, essentially, just sharing.
deleted 12y ago
[deleted]
derekja 12y ago
Excellent! Well done.
quadstick 12y ago
For non-open source projects, an inexpensive alternative source of PIDs is http://www.mcselec.com http://www.mcselec.com. Do a product search for PID. They assert the same rational for selling PIDs under the old license.
- pki 12y ago
  > USB-ORG wrote a letter that they revoked our VID ehh...
  - tokenizerrr 12y ago
    If you read the entire story[1] USB-ORG seems to have made some puzzling decisions. On top of that I do not think they can practically reissue the same VID so revoking it is meaningless. [1]: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 http://www.mcselec.com/index.php?page=shop.product_details&f...
seba_dos1 12y ago
Openmoko Inc. is also giving USB PIDs for free to open hardware projects: http://wiki.openmoko.org/wiki/USB_Product_IDs http://wiki.openmoko.org/wiki/USB_Product_IDs And I think Qi-Hardware Inc. does it as well.
csense 12y ago
What's preventing you from just picking at random an ID that hasn't been assigned? If you're a small-volume project, then presumably people will need to have custom kernel patches anyway and will be unlikely to actually have a device with a conflicting ID.
- nitrogen 12y ago
  This would lead to potential ID collisions as the VID space isn't very big. So just use a well-known debugging ID and have your driver detect your device using other USB descriptor fields.
  - userbinator 12y ago
    Given that the full identification of a device is a VID:PID pair, and that's a 32-bit space, picking one at random is not very likely to result in a collision. Furthermore, this assumes true randomness and not "randomly pick one and then check online to see if some other device has already claimed it." It also assumes that your project isn't close enough to some existing one that you really need to define a completely new interface instead of just using or extending that of an existing device.
    - tedivm 12y ago
      People tend to confuse the odds of two arbitrary strings colliding with the chances of a set of strings having a collision. 32bit space is not that big, and you have to take into account the birthday problem. If you do out the math it turns out there's a 50% chance of collision after only 77,163 hashes. http://preshing.com/20110504/hash-collision-probabilities/ http://preshing.com/20110504/hash-collision-probabilities/
      - deleted 12y ago
        [deleted]
        nitrogen 12y ago
BillinghamJ 12y ago
This is awesome. Could do with something similar for allocating bluetooth UUIDs.
- adestefan 12y ago
  There are no restrictions on 128-bit Bluetooth UUIDs. You do need to register for 16-bit UUIDs, but with SDP it's not needed.
fpgaminer 12y ago
I don't know if it's still the case, but for example STM would assign you a PID for free under their VID if you were using their USB enabled microcontrollers in your product. This was about two years ago when I last did it. The whole USB PID/VID problem is a cruddy and unnecessary situation. Bluetooth seems to support full UUIDs, and that's a low bandwidth protocol!
- aceperry 12y ago
  Microchip also has a program to assign a free PID to users of their USB products.
  - danellis 12y ago
    FTDI, too.
mindslight 12y ago
If this proves to be popular, then before they're close to running out they should switch to assigning a few well-known VIDs and then splitting up that space with device serial numbers or other well-defined scheme. There's no need to be limited to 16 bits. Also, "open source" seems a bit underpowered (as usual). Why not use their position to guarantee that users can easily modify the software running on the device?
- eridius 12y ago
  > Why not use their position to guarantee that users can easily modify the software running on the device? Because that's not an ideology that everyone supports.
raku1234 12y ago
Great Work
cbhl 12y ago
Why do unique devices need to have their own PID/VID? What prevents us from having one PID/VID and "driver" for all USB devices, and then chainloading to a device-specific user-mode driver based on some user-mode UUID?
- maxerickson 12y ago
  In a pedantic sense, the PID/VID are required if you want to use the usb logo to advertise compatibility. It isn't "USB" if it doesn't have a valid (in the sense that it is licensed) PID and VID. It's also user friendly for a device model to have an identifier (because this is the typical way to match up the driver). I don't think there is really any technical enforcement of it (but that's based on what I remember from briefly fooling around with a non compliant device). Edit: [I had something here that was wrong]
- anonymfus 12y ago
  That's basically how WinUSB works.
Animats 12y ago
That's necessary if your USB device is unique. If your device is an instance of a known standard class (keyboard, storage device, speaker, etc.) there's a generic ID.[1] You only need a PID if your device needs its own driver. [1] http://www.usb.org/developers/docs/devclass_docs http://www.usb.org/developers/docs/devclass_docs
- mmastrac 12y ago
  Is that true? I thought that you still needed a VID/PID, but you could use generic drivers if you support the proper HID or alternate interface types (ie: generic USB camera / speakers).
  - ryan-c 12y ago
    There are a bunch of USB device classes with generic drivers that will work even with an unrecognized VID/PID. Mass Storage and HID (keyboard/mouse) are the most common ones. I have only experimented a little, but it seems that unless your device requires a special driver, you can use the VID/PID of another device that doesn't require a special driver (e.g. some generic keyboards), there won't be any problems. There are probably horrible corner cases that I haven't encountered, though, so don't do this.
    - digi_owl 12y ago
      Wish there was something akin on ad-hoc NFS for transfer between devices. UMS assumes a dumb device at one end, and MTP is a mess and a half.
nfoz 12y ago
> you need a USB Vendor ID and Product ID to uniquely identify your device to computers. What's the technical reason why this is part of the USB spec? Why do devices need unique identifiers, or what benefit does this provide?
- deleted 12y ago
  [deleted]
- ricardobeat 12y ago
  License fees.
  - zaroth 12y ago
    IMO, this is the only right answer. Otherwise, the ID would be a 64-byte GUID and that would be the end of it. dd if=/dev/urandom of=~/guid bs=64 count=1 od -t x1 ~/guid # the following step optional bitcoind sendtoaddress '1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt' '19.72'
    - TillE 12y ago
      The USB spec was developed twenty years ago, when the computer industry looked very different and the internet barely existed for normal people. It's a suboptimal decision perpetuated by backwards compatibility, nothing more.
- deleted 12y ago
  [deleted]
- mdwrigh2 12y ago
  We use it for basic device recognition so we can do things like normalize keymappings on Android. See https://source.android.com/devices/input/key-layout-files.html https://source.android.com/devices/input/key-layout-files.ht...
- gizmo686 12y ago
  Drivers. When you plug a device into a computer, it uses the ID to determine what driver knows how to run it.
sova 12y ago
you guys rock
anyfoo 12y ago
I like how they just use Github as the database for the assignments. I've seen other instances before, but here I noticed it in particular. My first instinct would probably have been to have a traditional SQL database of sorts. That database needs to run somewhere. If I don't want to manage the database manually, I further need a whole web interface running somewhere. Account management. Provisions for users to recover their password if they lose it. And so on. If you just use GitHub, it's up to the users to create a GitHub account and just send you a pull request. If you like what you see, you merge it. Virtually no effort needed. And the database in form of the repository has complete history and is easily replicated or moved, by design. It even makes it easy for someone else to pull the database into their own projects, should they feel a need.

528 points by oxplot 12y ago

Thank you! This addresses a real need in the open source hardware community. Is USB-IF aware of this[1]? Would they see this as a violation of the spirit of the current terms in the sense of the revenue loss, and come after pid.codes for every $500 application they feel you might owe them? I'm optimistically hoping that you've discussed this with USB-IF and that although they may not officially endorse or support, they won't actively try to stop what you're doing. [1] >>This site is in no way supported or endorsed by USB-IF. EDIT: I should have read the FAQ[2] where you address this question specifically under "Won’t you get in trouble?" [2] http://pid.codes/faq/ http://pid.codes/faq/

etimberg 12y ago
I think it would be pretty mean spirited of the USB-IF to go after open source hardware projects. It's not like these are projects that will be earning someone money. Unfortunately, lawyers will probably get overzealous.
- otoburb 12y ago
  I also think it would be mean spirited, albeit somewhat consistent with their current stance of not giving any open source hardware projects a break on the $5K VendorID registration & assignment fee[1]. [1] http://www.usb.org/developers/vendor/ http://www.usb.org/developers/vendor/ EDIT: Fortunately, other organizations have done something similar, such as OpenMoko[2], without incurring USB-IF's wrath. [2] http://wiki.openmoko.org/wiki/USB_Product_IDs http://wiki.openmoko.org/wiki/USB_Product_IDs
aceperry 12y ago
I don't think the USB-IF had given much thought to the maker community, and makers weren't as big back then when USB-IF put together this program. I agree with you and hope as well that the USB-IF gives the open-source maker community a break. Although, recently, the Bluetooth SIG (Bluetooth equivalent of the USB-IF) started to charge fees to anyone utilizing Bluetooth in their products, even if you used a module that was already qualified and paid fees. Hopefully the USB-IF won't do the same.

aw3c2 12y ago

This makes me wish I was a hardware hacker just to get 0451.

ipsin 12y ago

I didn't know much about USB PIDs, but I expect that with 64k available on one VID, they'll go pretty quickly. Are there any attempts to expand the id space as part of the standard?

akiselev 12y ago
USB vendor/product IDs are for unique hardware designs/firmware so that they are easily recognized by their respective drivers, not each unique piece of hardware. For example, Logitech's vendor ID (they probably have a few) allows them 64,000 different keyboard, mouse, etc. products of which they can manufacture millions of units. I don't know of any vendor ID that has exhausted their product ID space which includes companies like Microchip which give away PIDs on their VID when you use their USB chips (with under 10k units in production)
uxp 12y ago
USB PIDs aren't like NIC MAC addresses, two identical items (keyboards, webcams, etc.) are supposed to have the same PID in order for the OS to recognize them as being the same and to apply the same driver to them. The VID is just a namespacing convention.

Serow225 12y ago

Very nice, both in concept and execution! I don't have anything useful to add here, other than saying kudos for a job well done :)

zymhan 12y ago
This is definitely one of my favorite things about the open-source ethos - that unnecessarily complex barriers can be broken by, essentially, just sharing.

deleted 12y ago

[deleted]

derekja 12y ago

Excellent! Well done.

quadstick 12y ago

For non-open source projects, an inexpensive alternative source of PIDs is http://www.mcselec.com http://www.mcselec.com. Do a product search for PID. They assert the same rational for selling PIDs under the old license.

pki 12y ago
> USB-ORG wrote a letter that they revoked our VID ehh...
- tokenizerrr 12y ago
  If you read the entire story[1] USB-ORG seems to have made some puzzling decisions. On top of that I do not think they can practically reissue the same VID so revoking it is meaningless. [1]: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 http://www.mcselec.com/index.php?page=shop.product_details&f...

seba_dos1 12y ago

Openmoko Inc. is also giving USB PIDs for free to open hardware projects: http://wiki.openmoko.org/wiki/USB_Product_IDs http://wiki.openmoko.org/wiki/USB_Product_IDs And I think Qi-Hardware Inc. does it as well.

csense 12y ago

What's preventing you from just picking at random an ID that hasn't been assigned? If you're a small-volume project, then presumably people will need to have custom kernel patches anyway and will be unlikely to actually have a device with a conflicting ID.

nitrogen 12y ago
This would lead to potential ID collisions as the VID space isn't very big. So just use a well-known debugging ID and have your driver detect your device using other USB descriptor fields.
- userbinator 12y ago
  Given that the full identification of a device is a VID:PID pair, and that's a 32-bit space, picking one at random is not very likely to result in a collision. Furthermore, this assumes true randomness and not "randomly pick one and then check online to see if some other device has already claimed it." It also assumes that your project isn't close enough to some existing one that you really need to define a completely new interface instead of just using or extending that of an existing device.
  - tedivm 12y ago
    People tend to confuse the odds of two arbitrary strings colliding with the chances of a set of strings having a collision. 32bit space is not that big, and you have to take into account the birthday problem. If you do out the math it turns out there's a 50% chance of collision after only 77,163 hashes. http://preshing.com/20110504/hash-collision-probabilities/ http://preshing.com/20110504/hash-collision-probabilities/
    - deleted 12y ago
      [deleted]
      - nitrogen 12y ago

BillinghamJ 12y ago

This is awesome. Could do with something similar for allocating bluetooth UUIDs.

adestefan 12y ago
There are no restrictions on 128-bit Bluetooth UUIDs. You do need to register for 16-bit UUIDs, but with SDP it's not needed.

fpgaminer 12y ago

I don't know if it's still the case, but for example STM would assign you a PID for free under their VID if you were using their USB enabled microcontrollers in your product. This was about two years ago when I last did it. The whole USB PID/VID problem is a cruddy and unnecessary situation. Bluetooth seems to support full UUIDs, and that's a low bandwidth protocol!

aceperry 12y ago
Microchip also has a program to assign a free PID to users of their USB products.
- danellis 12y ago
  FTDI, too.

mindslight 12y ago

If this proves to be popular, then before they're close to running out they should switch to assigning a few well-known VIDs and then splitting up that space with device serial numbers or other well-defined scheme. There's no need to be limited to 16 bits. Also, "open source" seems a bit underpowered (as usual). Why not use their position to guarantee that users can easily modify the software running on the device?

eridius 12y ago
> Why not use their position to guarantee that users can easily modify the software running on the device? Because that's not an ideology that everyone supports.

raku1234 12y ago

Great Work

cbhl 12y ago

Why do unique devices need to have their own PID/VID? What prevents us from having one PID/VID and "driver" for all USB devices, and then chainloading to a device-specific user-mode driver based on some user-mode UUID?

maxerickson 12y ago
In a pedantic sense, the PID/VID are required if you want to use the usb logo to advertise compatibility. It isn't "USB" if it doesn't have a valid (in the sense that it is licensed) PID and VID. It's also user friendly for a device model to have an identifier (because this is the typical way to match up the driver). I don't think there is really any technical enforcement of it (but that's based on what I remember from briefly fooling around with a non compliant device). Edit: [I had something here that was wrong]
anonymfus 12y ago
That's basically how WinUSB works.

Animats 12y ago

That's necessary if your USB device is unique. If your device is an instance of a known standard class (keyboard, storage device, speaker, etc.) there's a generic ID.[1] You only need a PID if your device needs its own driver. [1] http://www.usb.org/developers/docs/devclass_docs http://www.usb.org/developers/docs/devclass_docs

mmastrac 12y ago
Is that true? I thought that you still needed a VID/PID, but you could use generic drivers if you support the proper HID or alternate interface types (ie: generic USB camera / speakers).
- ryan-c 12y ago
  There are a bunch of USB device classes with generic drivers that will work even with an unrecognized VID/PID. Mass Storage and HID (keyboard/mouse) are the most common ones. I have only experimented a little, but it seems that unless your device requires a special driver, you can use the VID/PID of another device that doesn't require a special driver (e.g. some generic keyboards), there won't be any problems. There are probably horrible corner cases that I haven't encountered, though, so don't do this.
  - digi_owl 12y ago
    Wish there was something akin on ad-hoc NFS for transfer between devices. UMS assumes a dumb device at one end, and MTP is a mess and a half.

nfoz 12y ago

> you need a USB Vendor ID and Product ID to uniquely identify your device to computers. What's the technical reason why this is part of the USB spec? Why do devices need unique identifiers, or what benefit does this provide?

deleted 12y ago
[deleted]
ricardobeat 12y ago
License fees.
- zaroth 12y ago
  IMO, this is the only right answer. Otherwise, the ID would be a 64-byte GUID and that would be the end of it. dd if=/dev/urandom of=~/guid bs=64 count=1 od -t x1 ~/guid # the following step optional bitcoind sendtoaddress '1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt' '19.72'
  - TillE 12y ago
    The USB spec was developed twenty years ago, when the computer industry looked very different and the internet barely existed for normal people. It's a suboptimal decision perpetuated by backwards compatibility, nothing more.
deleted 12y ago
[deleted]
mdwrigh2 12y ago
We use it for basic device recognition so we can do things like normalize keymappings on Android. See https://source.android.com/devices/input/key-layout-files.html https://source.android.com/devices/input/key-layout-files.ht...
gizmo686 12y ago
Drivers. When you plug a device into a computer, it uses the ID to determine what driver knows how to run it.

sova 12y ago

you guys rock

anyfoo 12y ago

I like how they just use Github as the database for the assignments. I've seen other instances before, but here I noticed it in particular. My first instinct would probably have been to have a traditional SQL database of sorts. That database needs to run somewhere. If I don't want to manage the database manually, I further need a whole web interface running somewhere. Account management. Provisions for users to recover their password if they lose it. And so on. If you just use GitHub, it's up to the users to create a GitHub account and just send you a pull request. If you like what you see, you merge it. Virtually no effort needed. And the database in form of the repository has complete history and is easily replicated or moved, by design. It even makes it easy for someone else to pull the database into their own projects, should they feel a need.