That's the humorous part of the whole discussion that the VTM group is trying to preserve revenue by ignoring the hobbyists and sticking with the people who think nothing of falsifying UL registry, falsifying FCC certifications, and violating patents, but I'm sure those guys would never turn against the VTM group and illegally use the USB trademark without permission, LOL.
Whereas the hobbyists, if you don't intentionally try to screw them over like they're trying to do, would probably be ridiculously loyal and obedient in comparison.
Fundamentally despite the "hate opensource" and "revenue generating middlemen" story, some of which probably is true, the fundamental problem is likely the lack of a point of contact. They probably like knowing there's a directory of real world contact information such that identification number 0x123456 is clearly a product of such and such for debugging purposes and interoperability and lack of duplicate IDs and the like.
Something similar happens with ethernet MAC addresses. Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
> Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
Android has an API to query a unique device ID, which is generated from a field that's supposed to be populated with a serial number by the manufacturer. It is (or was previously) used to identify you as a particular user in some games, as well as for ad tracking and analytics.
One line of phones (I forget which manufacturer) managed to NOT update that serial number correctly, and as a result the entire model of phone came up with the same "unique ID". This was not fun to debug, as lots of users were ending up with other users' saved games, and one particular "user" was showing up in analytics as having used dozens of apps thousands of times a day...
> Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
Sun used to use the same MAC address on each port of their QFE (quad fast Ethernet) cards. It was easy to fix with ifconfig, but always made me wonder two things: a) if I number these ports sequentially (:a, :b, ...) am I going to collide with some other QFE card from the same batch, possibly from this same order of a dozen cards? And b) who thought this was a good idea? Was Sun just conserving MAC addresses on the theory that most QFE cards are 75% underutilized??
That's because the MAC address is stored in system ROM on the motherboard, not in the NIC, iirc. The theory was 1) the ports would be used on different network segments, hence no problem and 2) storing the MAC in the motherboard meant you could swap NICs without updating all your DHCP/whatever config files.
We might be comparing Sun hw from different eras. The QFE cards I remember were in a very different address range from the onboard Ethernet (which was still 8:0:20:... I think). Seems like the QFE MAC must have been in PRAM on the NIC then, at least. And I am pretty sure I remember the MAC address following the card, too.
The problem I ran into was that when two same-MAC ports were connected to different segments/VLANs on the same layer 2 or 3 network device, that device wouldn't know what to do with the packets. Or it might send them down the wrong wire, which was a problem for me -- these were firewall boxes. :)
Eventually Sun added a boot param (or a kernel config? Set from OBP or from a shell) that would automatically number the QFE interfaces sequentially on boot. That fixed the problem for me.
Much later, they added the front-panel accessible smart cards that contained MAC, hostid, etc. I think that was the Netra series, intended for carrier grade RAIC installations.
I have a knock-off xbox controller that is an exact copy of the Xbox controller S, but claims USB ID ffff:ffff.
It turns out there is also some unrelated cheap IR receiver that does the same and if you are unlucky this driver gets loaded instead, leaving you wondering why the gamepad doesn't work.
From what I understand they clone existing VIDs because their functionality is exactly the same. If you have new functionality and need a new driver I don't think you can do that.
Yes. That's why people are saying the community should squat one that is still unused and then it will be ours by default, because no manufacturers will want it if its already used.
