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?"
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.
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].
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.
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.
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.
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?
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.
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.
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.
I believe the 32-bit id you select needs to be unique from all the ids your OS knows about or else it will install the wrong driver and may crash / encounter other issues. Of course the user could manually uninstall that driver and install a driver you provided.
But randomly selecting an id doesn't make much sense. For example here are all the ids Linux knows about: http://www.linux-usb.org/usb.ids. Obviously don't select Logitech, Microsoft, Canon, Samsung, etc. manufacture id. Either select an unused manufacture and then randomly select the device id. Or select a manufacturer id that is no longer used like US Robotics (I doubt they are making any new modems) and then randomly select a device id.
As soon as make your device, connect it to a Windows machine which will try and find a driver -- if it doesn't, probably no conflict. If there is a conflict, it's with a product that distributes it's driver manually - so you don't have to worry. Or a product that doesn't exist yet, which could be an issue.
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!
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.
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).
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.
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/