Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

As someone who has programmed for USB and many of the other "legacy" ports, I think what it replaced was much simpler to work with; in comparison, USB is a huge mass of complexity at every level, from the signaling protocols to the driver interfaces.

There's no denying that some of the things that came with USB, like mass storage and video cameras, are really useful, but I don't think the same is true of trying to replace PS/2, serial, and parallel ports. E.g. USB keyboards do not support more than 6 simultaneous key presses without needing some special workarounds, while it is not a problem for PS/2 interface. Serial ports are still widely used, especially for working with embedded hardware - a UART makes for an extremely simple terminal interface. Parallel ports are easy to interface to, and essentially provide GPIO capability - you can use one to flash microcontrollers and EEPROMs, e.g. to recover from bad BIOS flashes and other similarly bricked devices ( http://www.fccps.cz/download/adv/frr/spi/msi_spi.html http://write-code.blogspot.ca/2012/08/parallel-port-spi-flas... ) And from my experience trying to install and troubleshoot a USB printer (the problem was driver-related), I'd rather stay with one connected to a parallel port.

Latencies are also much lower and more predicatable than USB because these are dedicated interfaces; there's a community of hobbyists using parallel ports to control CNC machines, and USB<>parallel adapters will not work for that.

My motherboard still has PS/2, parallel, and serial - and 8 USB ports. A little-known fact is that most if not all of the integrated I/O chips ("SuperIO") used on motherboards still have all the legacy port controllers, but the manufacturers don't bother connecting the pins to anything.

USB might not have been a great improvement for hardware developers, but as a low-end hardware user it's been a huge improvement. Any piece of hardware I come across can probably physically interface with any computer I own, and I have lots of options on how to hook it up (usually a number of slots on the computer, plus the option of using a hub).

The USB story seems similar to software like systemd and PulseAudio. As a software guy I like the simplicity USB has brought me as a user but I dread the complexity of systemd and PulseAudio.

I would agree if PulseAudio were anywhere near as reliable (to the end user) as USB is. But it isn't.

>USB keyboards do not support more than 6 simultaneous key presses without needing some special workarounds

This isn't totally true. If you want your USB keyboard to work as a boot keyboard (i.e. one that the BIOS understands) then the first 8 bytes of keyboard reports must follow the example (which does have this restriction). After boot though, there will be a Change Protocol request sent from the driver that signals you can use a non-Boot report (which doesn't have this limit).

Alternatively, you can always pack more keys into another report. The BIOS ignores everything beyond the first 8-bytes.

Theoretically, you are right.

However, gamer keyboards that care about compatibility opt to appear is several independent keyboards, each one responsible for at most 6 keys. I would be surprised if they chose this despite a "much simpler route" such as the one you describe.

Ducky Shine for instance has a "turn on N-key rollover" button which you press once you're booted to Windows.

Hot plugging a ps/2 mouse or keyboard used to be impossible (or at least, extremely unreliable). Hell, in older computers it could even physically damage your computer!

I for one am glad that it has been replaced. Those 'good old days' weren't as good as you seem to remember them.

The PS/2 connectors could glitch out, but generally it was okay to hot-plug those.

SCSI on the other hand was so temperamental that if you pulled a connection even accidentally you could blow the entire chain of devices.

Latencies are also much lower and more predicatable than USB because these are dedicated interfaces

This can't be stressed enough. The article is all raving about speed, but completely ignoring latency. Which is at least one of the reasons why USB hasn't completely replaced the other most common ports. USB only replaced ports for basic consumer devices without much special requirements in the timing department (and don't get me wrong, it did that in a fabulous way, the 'u' in the name was a good choice)

The most common usb-serial converter from FTDI does not have a completely predictable latency (mainly due to the software stack if I'm not mistaken) which can make it a pain to use with serial device which can only continuously stream data: small buffer size = no go.

Likewise, up until now, we still have some software using the parallel port because it's a readily avaiable GPIO with predictable sub-mSec latency, on Windows. USB doesn't even come close to replacing that, so we're switching to dedicated DAQ hardware.

> E.g. USB keyboards do not support more than 6 simultaneous key presses without needing some special workarounds,

Are USB MIDI piano keyboards[1] implementing one of those workarounds you're speaking of? They can send status of 10 simultaneous keys (10 fingers pressing piano chords.) Or that doesn't count because the multi key detection is done inside the keyboard and embedded into the MIDI data packet? Is that an example of a workaround?

[1]https://www.google.com/search?q=usb+midi+keyboard&tbm=isch

MIDI devices don't use USBHID, so they're not affected by this issue.

So they go lower level ? some kind of `UDP` usb packets ?

Mice and Keyboards use the "Human Interface Device" (HID) USB class.

MIDI devices use their own special class instead of HID: http://www.usb.org/developers/docs/devclass_docs/midi10.pdf

Same as how printers or scanners aren't HID, MIDI is different enough that it needs its own protocol.

Oh I see, I forgot there were other classes.

My graduate thesis project operated from the parallel ports of multiple 8088 DOS boxes.

There's a hack that might help that CNC application: At least one of the common USB<>serial interfaces will spit out a serial data stream at an utterly constant rate. I've used this to control stepping motors. You'd need something at the other end to interpret the serial data, some kind of MCU.

In general, I'd advise implementing USB using the simplest canned solution possible, i.e., and leave "rolling your own" low level implementation for applications that can't be done in any other way. Like you say, the complexity is onerous.

Why would someone press 7 or more keys at the same time?

Imagine two people playing a game.

Classic hot seat action games where 2 players share the same terminal such as Star control 2 hypermelee.

Playing 2-player games on the same keyboard, now less common but it was once very popular.

Edit: huh, quite a few gamers here :)

Doing stenography is one example - at any time you could be pressing up to 2 keys with every digit on your hands. If you were creating your own steno device, it'd be easier to make it HID compatible, since every system of importance supports it and would avoid the need to write new drivers. The Plover software (http://plover.stenoknight.com/) can be used to provide steno for regular HID devices - works with any N-key roll-over keyboard.

Emacs user? :-)

Reply on news.ycombinator.com