Hacker News new | past | comments | ask | show | jobs | submit login

Because the PS/2 keyboard interface is a mess.

The "good old" PC/XT keyboards worked that way. By the time of the PS/2, there were two different ways to signal break scancodes, three scancode sets only some of which were supported by any given keyboard, a mapping system to make one set of new scancodes look like the PC/XT, fake modifiers so that the system still thought that pause was Control+Numlock, and keys that for similar XT compatibility emitted a complete make+break sequence for several scancodes on press. And multimedia keyboards that threatened to exceed the limit on 7-bit scancodes were just around the corner.

The USB HID protocol is a lot less messy. No scancode set switching. No prefix bytes. No translation. No XT backwards compatibility. And conversely: A well-defined mechanism for vendor extensions. Well-defined usages for a whole bunch of extra keys that one might want to add, from media players to more complete calculator keypads.

It also places no limit on the number of simultaneous keypresses. A USB HID keyboard report is a very simple concept. It is a big bitmap of the instantaneous state of every key on the keyboard. The boot report format is constrained, by (mostly) using an inverted-array form for that bitmap, 8 bytes only permitting 64 keys in normal bitmap form; but a 16-byte report transmitted as a straight bitmap could handle a keyboard with 128 simultaneous keys if that were desired.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: