Obtaining a VID and PID

Most people who have worked with USB for more than a few minutes have discovered its dirty little secret; you can’t sell a USB compatible/compliant (note there is a difference, the latter requires a large payment) devices without first obtaining a unique VID/PID combination for your product. A VID, or Vendor ID, is a 16-bit value which is supposed to identify the exact manufacturer of a USB device, via a gigantonormous lookup table from the USB-IF. A PID, or Product ID, is supposed to identify a particular product manufactured by the vendor, so that when used together it forms a 32-bit unique code for each and every USB product on the market.

Note that this value is unique for a particular product, not device — each device can optionally have a unique serial number, but the VID/PID alone simply identifies to the host what the device is (e.g. “Happy Fun Technologies’ USB Webcam Model E123”). The problem with this is that for such a scheme to work, you need the USB-IF to act as a central registry for VID values, so that no two manufacturers release products to the market with the same VID/PID pair.

This is a problem only because the USB-IF charges companies out the rear for a VID value. Each VID value grants a company the ability to make a full 65,536 different USB products, which is a good thing — but it means that tiny businesses with only one or two products get shafted, since they’re stuck picking up the tab for a large keyspace that they simply don’t use. While 65,536 products is a lot for a single company, having only 65,536 different VIDs available means that most of the possible VID/PID combinations are wasted.

A few years ago, some smart businessfolk came up with a good idea; pony up the US$2000 or so per year it takes to secure a VID, and then resell the PID values to private buyers in small blocks. That was great for them and great for the buyers, since they could sell blocks of 10 or so at a reasonable price, and small companies could then use the purchased PIDs in their small line of products. Unfortunately, the USB-IF, never one to be cheated out of milking developers dry, threatened to sue all such resellers, and attempted to retroactively add in a clause to their license preventing resale.

So where does this leave us? Up the USB creek with no VID/PID. If you’re not interested in having full USB-IF endorsement (and the rights to use the USB logo on your products, etc.) you can still find people willing to resell you a PID block who bought a VID from before the license was updated. You could also bite the bullet and fork over your first-born – plus around US$2000 – to the USB-IF to buy a whole VID. Other options would be to ask your USB chip vendor, as some such as Microchip and FTDI will hand them out for free to customers requiring them. Finally, you could purchase a license to use a USB stack where the vendor has bought a VID, since in that case you’re buying the rights to use the stack, and just get the PID “for free” as part of the deal.

Do I find it ironic that people are forced to buy a license to a software USB stack implementation, just so they can bin it and just use the included VID/PID combination with the completely free LUFA stack? Yes I do. Am I grumpy about it? Yes I am. The USB-IF’s daft implementation of the VID/PID combination scheme has brought untold irritation to developers worldwide. Had they used a GUID implementation like Microsoft uses (where there is no need for a central repository, as the keys are partly time based and the key space is massive) or even a reliance on unique vendor/product descriptor strings we wouldn’t all be in this mess.

So go forth people, and source your precious VID/PID. Just make sure you tell the USB-IF how unhappy you are about the situation, regardless of how you obtain it.


Comments: 38

Leave a reply »


Very interesting writing.

I wasn’t aware of this issue and certainly wouldn’t pay around $2000. Buying a whole 16 bit space is absolutely overkill!


There are two other options I’ve seen out there as well: just pick a random number, which is probably fine for hobby stuff, and what I’ll call negative rights, which is somewhat more legit for real devices, and also the model that V-USB is using

The first option is picking random VIDs and PIDs. In practice, the VID/PID pair tells the operating system what drivers to load for the USB device. So as long as you pick an as-yet unused number, your device will work fine. The drawback is that if in the future, some device legitimately takes that number, then any system you’ve installed your device on won’t recognize the rightful owner of the VID/PID’s device, since the OS will load up the drivers for your device, and it’s awkward.

The second option, negative rights, is much more interesting. If you purchase a VID from the USB-IF, basically what you’re buying is the guarantee that the USB-IF will never, ever, ever give someone else that VID. Now, the USB-IF won’t let you give out the legal rights to PID blocks. However, (and something that I don’t think has been tested in the legal system) there isn’t much to stop a VID owner from promising someone else that they won’t use a certain number or block of numbers. Hence, the developer would not be buying the right to use a number, but rather the promise that that VID/PID will never be used by its owner. The difference I assume would be that if you bought a PID from someone, you might have some legal claim to the rights of being a member of the USB-IF, while if you’re buying this “negative right”, you’re still violating the USB-IF’s contract (for using a VID/PID that you don’t own), but your device will be guaranteed not to conflict with someone else’s in the future.

This brings me to my final point, which is that it seems to be that the USB-IF’s actual legal recourse for punishing people who use unlicensed VID/PID pairs is to sue them for breach of contract. If you join the USB-IF and get a VID, you sign documents saying that you will only use the VID that’s been assigned to you by the USB-IF. Since a 16 bit number isn’t copyrightable, though, if you don’t join the USB-IF, you can use any number and there’s not much they can do about it. Of course, if you’re not a member of the USB-IF, you can’t get your stuff USB certified (even though it still works), and you can’t use any USB markings, since that belongs to the USB-IF. Of course, I’m no lawyer, so this should all be taken with a grain of salt, but the ideas are some I’ve seen elsewhere. From personal experience, I know that any USB Guitar Hero controllers will only work with the games if they have the proper VID/PID pairs, and the number of unlicensed third party controllers seems to indicate that the USB-IF at least isn’t too concerned with them, even if Activision and Harmonix have sued some makers over other stuff.


Very good point Alan. I’ll be bringing up something related to your Guitar Hero point in my next blog/rant entry. However, while I do realise that the USB-IF exists to make money, I think it’s deplorable that they make it near-impossible for hobbyists to break into the world of USB without violating a contract somewhere. LUFA uses PIDs in the Atmel range explicitly granted to me by Atmel for use in the project, which makes me lucky, however others have limited options. I’ve tried to help out somewhat by making it allowable to use the LUFA PIDs in *hobbyist non commercial* projects compatible with the official LUFA demo, but it’s still a royal pain. Comparing values is cheap and even the cruddiest embedded host can do it; if the USB-IF had expanded it to a 128-bit GUID system like Windows uses we wouldn’t be in this mess, they could still charge for USB certification/advertisement, and things would still work as they do now except small businesses and hobbyists wouldn’t be screwed.

I think MCS Electronics’ resale of their VID uses your negative rights idea; even though the extra clauses weren’t in the agreement they signed, the USB-IF revoked their purchased VID when they found out people had an alternative to sending them piles of money high enough for them to swim in. Since products already exist with the “blacklisted” VID value the USB-IF cannot relicense it, so MCS still sell out the PID space since it’s guaranteed not to clash. You loose the rights to use the USB logo on your product, but that’s where the “compatible/compliant” difference comes in and to the consumer, nothing matters so long as it has a plug that fits one of the holes on their computer.

– Dean


A similar situation exists with Ethernet devices (IEEE OUI for $1650). But the IEEE has the good sense to sell smaller blocks (IEEE IAB, which is very much like sharing a VID) for only $550, and there doesn’t appear to be a renewal fee, unless you want to keep your name secret.


I recently bought a licence to V-USB, only for the VID+PID combo. The actual use is for a completely different USB stack on an STM32. The V-USB guys don’t seem to care what you use it for though.
For the $11aud it cost, it seemed like cheap insurance that the USB device would always be unique

I see the V-USB path as the more “right” way than they MCS electronics way, since MCS were/are just blatantly selling PID’s and have since been blacklisted. V-USB is more like what Microchip or FTDI do.

Someone is making a lot of money selling these things. For a cost of around $0.03, selling them for $10 is easy money. Reserve the first few thousand for yourself/your company and use the rest to pay for the exorbitant USB-IF fees.

The way I see it, yes it is bad how the USB-IF works, but at the end of the day, you’re going to be using these id’s on some form of hardware. Unless your giving away this hardware you are probably making some money selling said hardware, so if you are serious enough to want to be “legit” you probably should be able to afford to pay the $2000 fee.
Is $2000 too much? Yes and no. Once you are selling 100, 1000, 10,000 of something, these costs come right down, combined with the fact that you get 2^16 id’s to use it’s actually good value, *For a company*.


Absolutely, in volume the price goes down – like anything. However the issue is that it severely restricts small projects, or small manufacturing runs of “widget X”. Using a Vendor ID was daft in the first place as USB is *supposed* to abstract away the manufacturer-specific details and present an implementation-agnostic interface to the host, so it shouldn’t need a VID in the first place. I’m not against the USB-IF making money, but it’s when it’s at the expense of hobbyists and entrepreneurs that it becomes a problem. Case in point; I wouldn’t be able to make a LUFA device and sell it tomorrow, because I can’t front the $2000 outlay required for a freaking 16-bit number.

– Dean


Yes it’s crazy that a 16/16 key space is used for unique product ID.

Just how many VIDs have been issued so far anyway?

One would imagine that if the cost of VID ownership was reduced to something sensible then the VID key space would soon be used up. – oh great, so the USB-IF can justify their license to print money on the back of a poor technical decision.

” … near-impossible for hobbyists to break into the world of USB without violating a contract …”

I’m not so sure about that. Maybe this is a problem for professional developers, but hobbyists?… Hmm, what contract? I certainly never signed one.

” …I’ve [made] it allowable to use the LUFA PIDs in *hobbyist non commercial* projects …”

Where are the license conditions that stipulate this? Perhaps you would have a legal case to claim damages against someone re-using the LUFA VID/PID block against your terms, but I suspect it would be tenuous at best. – btw, I am playing devils advocate here.

Oh, and here’s an idle thought train – let’s take the negative rights idea a step further:-

1) identify a VID that is yet uncommitted (I presume there is a list). Choose a number that has some vague recognition value, say 0xF055 (FOSS), but don’t call it a VID, it’s just the name of an online community.

2) start (i.e. publicise) an online community to support development of USB Free Open Source Software. Membership is free for proven FOSS developers.

3) Members get a membership number, you gussed it… from 1 to 65535. It’s not a PID it’s a membership number!

4) Doesn’t matter how large the USB-FOSS community is, the appearance of growing support should be enough that eventually no commercial vendor is going to want to be issued with VID 0xF055.

I suppose the USB-IF could sue the USB-FOSS organizer(s) for loss of revenue. Now IANAL, but my guess is that wouldn’t stand up well in court.

Even if the USB-IF money printing machine wanted to pursue this it only adds publicity so in the end is self defeating.

Hmm. 😉


The part that always bugged me was that even if your device is a 100% pure implementation of a generic USB device type (Mass storage, mouse, keyboard, serial port) you STILL need a VID/PID just to use the built-in microsoft driver. Even though your device behaves and appears to the system exactly like a com port (or whatever) and exactly like every single other generic serial port usb device.

What a racket!

I have to say grummund’s idea of the hobbyist/FOSS community just hijacking a VID has a certain appeal to it, but I’m not sure who would be willing to stick their neck out to organize it.

I’m assuming USB 3.0 has the exact same problem?


[…] now to my rant of today. This is a follow up to my previous grumpy rant about USB VIDs and PIDs and is on a related topic; Defined Class […]


I recently suggested to the FSFE that they talk to the USB-IF to get a Vendor ID for open source software/hardware projects. I haven’t heard back though.

What other organizations would be willing to just talk to the USB-IF about this, and just run a PID registry? This is becoming more and more of an issue, what iwth the open source hardware movement really taking off lately.


The problem with such a scheme is that according to the new USB-IF rules, you cannot resell PID values in a VID space (which is utter crud, since if someone’s willing to pay you a $2000 “administrative fee” for a 16-bit number, they can do whatever the hell they want with the address space given). There’s a legal gray area where you can give them away with a purchase, like V-USB does (free PID with every license sold) but unless the FSF gave them away for free the USB-IF would just invalidate the VID allocation. Giving them away for free would be great, but only if they were passed out with a justification, to prevent them from being exhausted too quickly.

– Dean


That’s the idea — an organization gets a Vendor ID, then gives out PIDs for free to projects that have a design for a widget that is demonstrably published under a free/open license (GPL, CC etc). That will avoid people grabbing tons of them just for fun; every PID would point at a single widget, which you can actually make or buy.

Such projects will never apply for a $2000 VID from the USB-IF, so it’s no loss for them.

If you have ideas for organizations that would take this on, please let me know.


Sounds great to me – and like you said, the experimenters wouldn’t be purchasing whole VIDs anyway so the USB-IF can’t complain too much. And if they do &^%# them, since they wouldn’t be able to re-allocate the VID once its sold anyway (which is why MCS Electronics is still able to sell PIDs even though their purchased VID was officially revoked). Actually, I’m starting to warm to Alan’s idea of just hijacking a VID, since with enough use the USB-IF wouldn’t be able to allocate it to a paying customer, and they’d have no recourse (devices not sold, not use the USB logo, etc.).

As for organizations to cover it, that I can think of: FSF, Linux Foundation, GNU Foundation (is this a separate organization?). IIRC the Linux foundation already has a VID, so perhaps they can be persuaded to hand out PIDs to deserving free projects.

– Dean


Could someone help answer if the $2000 fee a yearly or once off fee ?



I’m not sure. This page (http://www.usb.org/developers/vendor/) has the possible ways to get a VID from the USB-IF, with the $2000 non-membership logo licensed fee being valid for two years. However, it also indicates a $2000 non-membership non-logo- licensed fee without stating the VID lease duration.

From the VID form, it looks like PIDs cannot be leased or given away, so it turns out the donated PIDs from Atmel (and the “licensed” PIDs from V-USB and others) are technically invalid even though I didn’t purchase the former. Interesting — I vote we just hijack a VID for FSF use and tell the USB-IF to ram their expensive leases up their wazoo.

– Dean


I wonder if it is possible to use different devices with the same VID/PID, but with different manufacturer and product strings. So only one free VID/PID combination needs to be allocated for it, which doesn’t load a driver and then it is at least possible to use it for HID devices, because at least in Windows in the enumartion process with SetupDiEnumDeviceInterfaces you can use HidD_GetManufacturerString and HidD_GetProductString for getting theses strings. Of course, this is not a solution for products which want to autostart some program when you plugin an USB device and other protocols than HID, but should work for most projects, where you first start a program for communicating with the device (because then the program can enumerate all devices) and where you don’t need high transfer speed.


Given the fact that a VID/PID in fact exclusively identifies a PROTOCOL, an interesting legal argument is that it is similar to the #defines in errno.h (and other standard API headers). In the SCO Linux debacle these common “interface” values were found to be uncopyrightable.

You could argue that the VID/PID in fact is the only identifier of a particular hardware “interface” and is therefore also uncopyrightable.

This argument is bolstered by the existence of the manu and product string since THOSE are used to identify the vendor and product.


my 2 cents : IC manufacturers ( people that actually make SILICON can , at their sole discretion, hand out a their VID and multiple PID’s to their users to allow the user to do
1) development with the intended silicon
2) not require a vid / pid of his own
provided that the product is NOT SOLD.

So it is perfectly legal for a chip manufacturer to give a user of his silicon a PID in his range. this end user may use this combination for all development work.

All semiconductor manufacturers have a VID. That is why FTDI , Atmel and others can legally hand out a PID to their customer and they will not be sued.

Again , afaik , and i may be wrong here – doublecheck-. this is only true if you are 1) a SEMICONDUCTOR DEVICE manufacturer 2) the handed out PID is used ONLY on your silicon and 3) it is ONLY for experimentation.

so no using an atmel pid on a cypress vid and selling it !

silicon manufacturers typically have two vid’s. one for products released to market and one that falls in this ‘experimental’ category.


oops. typo in previous post. it should read the VID/PID combination is used only on the correct silicon. so no using the Atmel VID/pid on Cypress silicon, and so on.



I thought maybe if USB-IF could just re-organize the VID/PID scheme from 16:16 to like 24:8, there would be multiple VID owners but guaranteed allocation of blocks small enough for individual organizations and hobbyists.

I am sure this does not affect the current driver framework since VID is only a number, PID will still be unique and the vendor string descriptor can be anything.

And since they can sell the same VID to 256 people, the cost can come down to 2000/256 – less than $10 per block. USB-IF can actually make $2560 instead of $2000 and still everybody else will be happy too!

– Girish


They may have to move towards that in the near future, since the current VID address space is nearly exhausted. Personally I’m in favour of buying the remainder and selling it back to them in single VID chunks for a ludicrous sum each, just so they feel the same frustration.

– Dean


> And since they can sell the same VID to 256 people … can actually make $2560 instead of $2000!

Think about blocks of only 16 PIDs (28:4 instead of 24:8) – they could sell such a block for 1$ to have 4096$ per VID.

I have another proposal however the HW manufacturers would have to cooperate:

The VID:PID identifies the IC used in the device, not the device itself. This is now already the case when using FTDI ICs without EEPROM in a product.

The semiconductor manufacturer (lets say it’s VID is 0x1234) defines two PIDs (let’s say 0xFFFD and 0xFFFE) and a string descriptor (let’s say #2).

For VID:PID=0x1234:0xFFFE a device has a defined USB class (e.g. storage class); in this case the OS will use the built-in driver.

For VID:PID=0x1234:0xFFFD a generic driver (Windows: WinUSB, Linux: libusb) is used. The actual manufacturer and product type is taken from string descriptor #2 (e.g. “myCompany:myMicrocontrollerCircuit”).

– Martin


I read that a company in the netherlands is still selling single PIDs for 10$/each.

It is not tolerated by the USB-IF however it is legal by law.

You will not be allowed to use the USB logo on your device and maybe not be allowed to name the device an “USB device” but the VID:PID will be unique.



MCS Electronics does this – they bought their VID before the USB-IF changed the licensing to disallow resale of PIDs. The USB-IF tried to get them to stop and even cancelled their purchased VID, but MCS still sells the PID values for a reasonable price since they bought it fair and square under the original contract. Despite the VID now being technically valid, the purchased VID/PID combination is still guaranteed to be unique since the USB-IF can’t sell the VID value again for fear of clashes.

In retrospect, selling smaller blocks would have made more sense (and earned the greedy jerks more money anyway) but I suppose it’s too late now.

– Dean


http://www.USB.org provides a pdf of obsolete vids:

What would stop someone from using one of these?


Nothing stops you from using any VID/PID, so long as you don’t need official certification and compliance branding. You run the risk of collisions however if the VID/PID value isn’t guaranteed unique – which is the case with a legitimate one purchased from the USB-IF, or a gray-market one from someone like MCS Electronics.

– Dean


When the USB-IF revolked MCS’s VID, MCS should have sued them for breach of contract, since under law in the Netherlands you can’t change the terms of a contract once the product was sold (unless the buyer agrees I would assume). So by revolking the “product” the USB-IF breached the terms of the original sale, hence breaching the contract. It also means that everyone who bought the PID’s lost certification, so they should sue for MCS breach of contract (who would then sue USB-IF for the damages for the customer suits!). IANAL, but I would LOVE it if this logic holds up!


I like the 0xF055 solution, and it seems to me that it could be implemented without anybody having to stick their head out. The VID itself would be tainted just by giving it enough publicity from enough sources to protect everybody. Perhaps a large number of people could email usb.org, asking for confirmation of the rumor that the VID 0xF055 is now available for free use, for devices not requiring a specific driver. If there was enough of this, they might blacklist the VID just to protect themselves.

The only problem is how to keep track of the PIDs, since publishing a list would expose the publisher. Perhaps a Wikipedia article could be used to list the “claimed” PIDs. This is of course volatile, but the FOSS community would be sufficiently invested to keep it up-to-date.

Any other ideas of how to keep a reliable registry without exposing the keeper of the registry? I know there are some clever people here.

As several people have noted, many of us don’t care about having the official blessing of USB-IF; we just don’t want our devices to fail to operate due to USB-IF’s bad design decision (the 16-bit VID). Did USB-IF really think there would never be more than 65536 makers of USB devices; that USB would never fall into the hands of the unwashed hordes? They made our previous simple and universal connection to PCs (the RS-232C serial port) obsolete. Did they just think hobbyists would just go away?

Actually, hobbyists DID go away, for a while. Just as the graphic user interface raised the price of entry into the software arena by requiring expensive SDKs and introducing a complex programming model with a very steep learning curve, USB raised the price of entry into peripheral hardware, by defining an interface that could not be implemented without expensive tools. From what I can see, the once-thriving computer hobby world (of the 1980s) is only now beginning to re-emerge from the dark ages, with the availability of USB hardware and software/firmware at a level that’s accessible to just about everybody. It is inevitable that this will lead to a crisis in unique VID/PID combinations unless some concession can be made to allow registering multiple products to the some generic VID/PIDs, at least for products that can use generic drivers. Keep in mind that these could still be uniquely identified using the manufacturer string, if necessary. Does anybody really CARE who made this keyboard or that mouse?

Also, I find it offensive that small-quantity producers have to beg for VID/PID scraps (single PIDs), and are often given the stipulation that we can’t sell our products, or that we may only distribute a small number of them. I believe this is an anti-competitive practice, which may be illegal in the U.S. and probably many other countries.


It looks like someone already bought the 0xf055.org domain (purchased on October 22, 2013). Looks like someone’s about to stick their neck out and setup the registry. The whois info is marked as private, so it’ll probably be pretty hard to track whoever is setting up the list down, but I’m sure USB-IF will try.


Here is http://f055.cc , an « unique numbers annuary » for open hardware projects. Just in case 🙂


I just got a slightly crazy idea. An easy way to get around the MAC address limitation is to buy an EEPROM/FLASH from Microchip, Maxim, etc. that contains a unique mac address. They can do this because they are selling a product. What if someone were to do this with USB PIDs? If there is enough interest, I will start a KickStarter campaign for this. Either email me at admin[at]wlinux[dot]mobi, or respond at (https://docs.google.com/forms/d/1R4yUz4M4maP-wdHVX9PNNRAd7d7fi75FpTHefjEHL_Y/)


Not as strange as you think – that reminds me of Raymond Chen’s anecdote.

– Dean


Small update. The costs for a VID have risen to $5000 by now: http://www.usb.org/developers/vendor/


Did the ATMEL has a free VID/PID for the ATmega IC user for the single product in small company, if so, where did we can get it. We need a free VID/PID for our single product that use Atmel mcu.


You can use their demo VID/PIDs subject to their license agreement (see this link for more information) if your product’s descriptors matches an example. If not, you need to find your own VID/PID, such as MCS Electronics’s sublicensed values from their website.

– Dean


Only from the sample application, How about the vid/pid in their official usb products, I gues its have a vid/pid. Well I see MCS electronics, it mentioned that we still need to buy a pid.. in europe.


I plan to furnish a USB Sniffer program that displays all the usb interfaces currently on a machine. I am designing my USB cards with ability to set the VID/PID to any value. if the VID/PID that is in the card when shipped is on the target system, the end user must unplug the other card or connect the card to a system that doesn’t have that address in use and run a furnished setup program to change the VID/PID of my card to a new value in flash memory. Since Windows Programs (as can Linux Programs) uses the product string in the device identification, programs connect to the same card even if VID/PID address is changed. For my cards the VID/PID is a user configurable item like Ethernet socket ports. I plan to start out with a VID address of 0xF055 and PID of a random number with lots of non-zero digits.


Leave a Reply

(will not be published)


Vital Stats

  • 32 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts