Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

USB Implementers Forum Says No to Open Source

hackaday.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: USB Implementers Forum Says No to Open Source

#91

Post by pyre »

nitrogen wrote: post #43
nraynaud wrote: post #29

Earlier quoted context omitted.

I think there's still a problem because that leaves still only 255 PID. Maybe we should just squat the VID, and then do a PID+(another field in the descriptor) as the discriminator for people who need special protocols (I do). For now I've stolen my MCU maker VID and used 255 as PID, because I couldn't even find an "experimental" PID/VID in the spec to use during development. It's a bug and urgent problem, I'm perfec…

I know I saw 0xffff or something like that being used for development in some source code, but it turns out searching for "VID" is impossible because it gets interpreted as "video".

Try searching this:

  development usb "vid" -video
First hit is someone asking about VID/PID in a motherboard forum.

Re: USB Implementers Forum Says No to Open Source

#92

Post by derefr »

eksith wrote: post #14
alcari wrote: post #10

Earlier quoted context omitted.

Read the article again. That's not the Forum, that's the VTM Group, which handles their marketing and legal concerns. The USB Implementers Forum itself didn't make a statement.

This idea did not sit well with VTM Group, the people serving as the management, PR, legal, and membership and licensing department of the USB Implementers Forum The hands, the mouth and collector of thoughts cannot be separated from a thing and still be called a whole. Besides even the title says, "USB Implementers Forum Says No to Open Source"

> The hands, the mouth and collector of thoughts cannot be separated from a thing and still be called a whole.

I don't know about that. Publishing houses are certainly separate from authors, and record labels from musicians.

Re: USB Implementers Forum Says No to Open Source

#93

Post by derefr »

Pxtl wrote: post #36
samworm wrote: post #5

Earlier quoted context omitted.

The way these things normally work is that you're only allowed to use the name and marks if you're an official licensee. So if you put the USB logo on your marketing and claim to have a "USB Mini" connector in your specifications then you could be in trouble on two fronts: (1) the usb folks can sue you for using their IP and (2) purchasers can claim the product is not "as described" which may given them certain right…

Considering how many cheap Chinese knock-offs out there seem to go unpunished, I don't think the USB folks are really successful at enforcement.

So... the FOSS hardware guys should operate Chinese manufacturing shell companies?

Re: USB Implementers Forum Says No to Open Source

#94

Post by lmz »

marcosdumay wrote: post #63
nraynaud wrote: post #58

Earlier quoted context omitted.

I always found so stupid they just don't put a bit of flash and the drivers in it. Or just an URL in the device descriptor.

Wow. If you tought a memory stick pretending that it's a keyboard was a serious enough problem, just wait untill somebody thinks loading random drivers from the device (or the web!) is a good idea. It will happen, that's a near certainty. Some day, somebody will think that's a good idea, and since it's easy, the scheme will get widely used.

Already has happened (although not automatically) for USB 3G modems[1] and HP printers[2].

[1]: http://www.draisberghof.de/usb_modeswitch/ [2]: http://www.hp.com/global/us/en/laserjet/hub/printer-installa...

Re: USB Implementers Forum Says No to Open Source

#95

Post by quesera »

tedunangst wrote: post #75
quesera wrote: post #51

Earlier quoted context omitted.

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

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.

Re: USB Implementers Forum Says No to Open Source

#96

Post by nraynaud »

comex wrote: post #73
nraynaud wrote: post #65

Earlier quoted context omitted.

If you don't trust the web or the device, where will you get the driver? Why did you plug the device in the first place?

Perhaps the Linux kernel you already have installed, which presently has drivers for just about everything included and developed in a centralized, controlled fashion... Whether this is actually better probably depends on your point of view. But loading (somehow OS-neutral?) drivers from a fixed store on the device seems like a great way to be stuck with out-of-date binary blobs forever.

That's why i proposed an URL, or an URL in the blob. Well, anything is better than the current situation.

Moreover, in my current forey into USB, I discovered that kernel device drivers are completely unnecessary. And a google chrome API (or the underlying libusb) is completely good enough for proprietary devices.

Re: USB Implementers Forum Says No to Open Source

#97

Post by cnvogel »

tedunangst wrote: post #75
quesera wrote: post #51

Earlier quoted context omitted.

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

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.

...and, additionally, connecting several ports to the same network segment/switch in many cases gave you immediate, effortless load-balancing.

Re: USB Implementers Forum Says No to Open Source

#98

Post by PhasmaFelis »

marcosdumay wrote: post #63
nraynaud wrote: post #58

Earlier quoted context omitted.

I always found so stupid they just don't put a bit of flash and the drivers in it. Or just an URL in the device descriptor.

Wow. If you tought a memory stick pretending that it's a keyboard was a serious enough problem, just wait untill somebody thinks loading random drivers from the device (or the web!) is a good idea. It will happen, that's a near certainty. Some day, somebody will think that's a good idea, and since it's easy, the scheme will get widely used.

> Wow. If you tought a memory stick pretending that it's a keyboard was a serious enough problem, just wait untill somebody thinks loading random drivers from the device (or the web!) is a good idea.

Oh, come now. Any competently-designed USB penetrator will have your system owned seconds after you plug it in, with no further interaction from you. Running drivers from the device poses no additional risk beyond what you've already taken.

Re: USB Implementers Forum Says No to Open Source

#99

Post by dylz »

nitrogen wrote: post #43
nraynaud wrote: post #29

Earlier quoted context omitted.

I think there's still a problem because that leaves still only 255 PID. Maybe we should just squat the VID, and then do a PID+(another field in the descriptor) as the discriminator for people who need special protocols (I do). For now I've stolen my MCU maker VID and used 255 as PID, because I couldn't even find an "experimental" PID/VID in the spec to use during development. It's a bug and urgent problem, I'm perfec…

I know I saw 0xffff or something like that being used for development in some source code, but it turns out searching for "VID" is impossible because it gets interpreted as "video".

Search Tools > Verbatim

Re: USB Implementers Forum Says No to Open Source

#100

Post by jmaygarden »

ajross wrote: post #31
candydance wrote: post #18

Earlier quoted context omitted.

Since a USB device gets paired with a driver through a VID/PID pair, buying a single VID allows you access to 65536 PIDs for that VID. They give out the PIDs for free but hold on to the VID for themselves. FTDI own a bunch of VIDs which are associated with "FTDI" devices. If you ask FTDI they'll reserve a small block of PIDs for you to use for your own products that use the FTDI USB chips. 8 PIDs cut out of a 65536 b…

USB devices are supposed to be detected via the class (es) declared in the descriptor actually. This allows for e.g. a single HID driver to work with input devices from all manufacturers. Linux drivers almost all work this way, using the vid/pid for quirk detection only. The windows world tends to be less clean.

That falls flat for custom/vendor classes. It's a fairly convenient route for a device that doesn't fit the other molds using libusb/WinUSB drivers.
Post reply on HN