I wish either (a) USB-IF would stop being evil and start assigning small PID blocks for a reasonable price, or (b) someone would sue the fuck out of USB-IF for antitrust violations.
That's what people do with https://www.eff.org/awards/coop/rules (we continue to get claims regularly that ignore every single required element, warning, and instruction).
> that ignore every single required element, warning, and instruction
I suspect it isn't that they've read and ignored the instructions. More likely it is complete ignorance: that they have not even bothered to read that document properly, if at all.
It is easier to throw out an attempt and hope for the best, than to make an actual effort to be compliant. After first refusal people will either give in ("it was worth a try, but I really don't care that much"), make more of an effort second time around ("the lazy way didn't work, so maybe I'll make some effort") or bitch & moan about how unfair the system is like a child who isn't allowed more cookies until he tidies his room.
Very few people care to take the time to read the rules on public facilities. They even openly admit it: hence all the forum posts that start "please delete if not allowed" which basically means "I don't care if this is allowed or not, I want to post it so I'm going to whatever your rules say so fuck you".
You can also just squat on one. As long as you avoid using the trademarks ("usb" and the logo) there is nothing that can be done to you even in the US. This is basically what most Chinese products do.
Yeah... please don't do this. There exist better options than polluting a shared namespace. It's just like putting your private network in IP space you don't own.
Not everybody wants to open source and give away for free everything they do, nor pay $5,000 to license something that is actually just a number. This is especially true for USB devices that follow the hid spec. They don't need drivers, so even if you happen to have one associated with that vendor ID and product id, the OS will not load it.
MAC is different because you need one by device, so having to buy them in "bulk" is a lot more reasonable. USBIDs ought to be purchasable individually (or large enough that you wouldn't have to purchase them).
I wonder if either openmoko or pid.codes actually check that the open hardware in the applications actually exist and work as advertised.
Like, I could create a stub project and publish it under an FOSS/OSHW license, but nothing in it actually works yet. Wouldn't it be a waste to allocate a PID to such project?
I know that pid.codes checks that you have actual, published open source code before he'll allocate you one. There's no reason to have one before that point anyway: you can always use a test code. It's only once the general public will be using it that you need a real, unique code.
That would only escalate the war. People would start out as an open source hardware project with minimal commits/docs and turn "evil" the moment they got assigned a code. Then they would have to account for that. War escalates again, go to step 1.
Does anyone know of a low cost way of getting a Product ID for a commercial product? I've been working on software for an embedded board and am using the USB port as a debug port. It works fine now as a USB serial link, but it would be nice to have our own PID, just not worth $5000 for a single product.
You can license PIDs inexpensively from MCS Electronics in the Netherlands. They bought VID 16D0 before the USB IF prohibited reselling product IDs.
At this point I believe 16D0 has been revoked by the asshats at USB IF, but that's not the customer's problem. It's not as if they'll ever be able to assign VID 16D0 to anyone else.
USB IDs are idiotic and should 100% be just squatted on.
There is no reason such a stupid design should be enforced by any open source organisation.
If you want to have an identification for a device, standardise capabilities tags and provide some free form fields for perhaps at least manufacturer and description.
What's stupid is that USB IDs should have a large enough range that allocation wouldn't have to be centralized and monetized. Something like a UUID. I doubt the overhead would be significant enough to justify saving a few bytes. This is artificial scarcity.
Sure you can - you can look at the manufacturer / product strings. And for standard device classes (eg mass storage or CDC ACM, aka USB serial) you can just use interface descriptors to identify them.
Would be nice if more systems used the strings embedded in the device, like eg FreeBSD does, instead of looking up PID/VID in a static table.
Yes you can. On Mac you can use userspace USB drivers by default so you can use any other method to identify your device. On Windows you can use WCID to get it to automatically install WinUSB (Windows' userspace USB driver) irrespective of the product / vendor ID. On Linux I believe you just have to set up some udev rule and then you can use libusb.
Once you have userspace access there's basically no downside to squatting. The only minor one is if you happen to squat on an ID that also happens to have a kernel driver. But just pick a long defunct vendor and that's pretty damn unlikely.
As Raymond Chen would say, what if two devices did this? Suppose you have Widget A, which is squatting on ID 1234:5678, and Widget B, which is also squatting on ID 1234:5678. You plug both on the same computer. How would the driver, no matter whether kernel or userspace, know a newly plugged device with that ID is Widget A and not Widget B?
