Get your own USB PID | Hacker News Reader

Get your own USB PID

pid.codes

528 pointsoxplot50 comments

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/

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.

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/

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

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.

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

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).

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.

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.

Openmoko Inc. is also giving USB PIDs for free to open hardware projects: http://wiki.openmoko.org/wiki/USB_Product_IDs

And I think Qi-Hardware Inc. does it as well.

For non-open source projects, an inexpensive alternative source of PIDs is http://www.mcselec.com. Do a product search for PID.

They assert the same rational for selling PIDs under the old license.

> USB-ORG wrote a letter that they revoked our VID

ehh...

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&f...

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?

> 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.

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.

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.

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.

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.

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/

A good rough rule is to halve the power of two: so 2^16 = 65536, which is close enough to 77163.

That's really cool. I tried it with the birthday problem[1] (real answer 23) and got 16 if I used whole exponents[2] and 19 with fractional exponents[3]. They're a little off but it gives you an idea of the value.

[1] https://en.wikipedia.org/wiki/Birthday_problem

[2] 256 days=2^8, 16=2^4

[3] 365 days=2^8.51, 19=2^4.255

That doesn't matter to an individual developer. Why should they care if the set of all in use USB PIDs has collisions? It's only becomes a problem for them if their PID suffers a collision.

The Birthday Problem is only relevant to find collisions between any 2 strings, but in this case the developer is only concerned about the probability of his own string clashing with someone else’s, thus the probability of a collision is only Number of taken strings / Number of total strings.

Nothing, which is why it is arguably a short-sighted move for USB-IF to charge such a large amount to hobbyists and such.

I'm surprised that the USB-IF itself doesn't have several hobbiest vendor ids that then hand out single PIDs for use (say at $25USD)

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 :)

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

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!

Microchip also has a program to assign a free PID to users of their USB products.

FTDI, too.

> 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?

License fees.

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'

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.

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.ht...

Drivers. When you plug a device into a computer, it uses the ID to determine what driver knows how to run it.

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?

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]

That's basically how WinUSB works.

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?

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)

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.

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

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.

Excellent! Well done.

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

you guys rock

Great Work

Reply on news.ycombinator.com