7 ms·

If I remember correctly, the good old PS/2 keyboards used to send "key down" and "key up" events - so no limit on number of simultaneous keypresses. Why was thi

by janci 6y ago

If I remember correctly, the good old PS/2 keyboards used to send "key down" and "key up" events - so no limit on number of simultaneous keypresses. Why was this not reflected in USB HID?

simias 6y ago
My guess is that the problem with sending events is that if you miss one you're in trouble (in this case it's especially bad if you miss/lose the "key up" message). Given the potential complexity of USB topologies making the protocol stateful might have caused more problem than it would've solved. Besides is there any use for NKRO besides being a meme feature for overpriced keyboards? The only use case I can think of is if you play two player games on the same keyboard but doesn't seem very common these days (and you can probably buy a decent gamepad for the price of a NKRO keyboard).
- smileybarry 6y ago
  While I can't reproduce it at-will I've definitely had occasional input problems in competitive shooter games with 6KRO + 125Hz. A depress would be processed "too late" to accidentally fall into the next window and affect movement then (e.g.: jump in wrong direction). Yes, the key combination probably doesn't go over 6 keys at once and I don't always have ~8-16ms presses but switching over to NKRO + 1000Hz (which are coupled on QMK) would stop this from happening.
- SuperPaintMan 6y ago
  Stenography! When stroking a chord you can have 6+ keys held down easily. I design and write firmware for QMK powered writers/ergonomic keyboards, and NKRO is absolutely vital if you don't want to resort to serial devices [1]. Plover uses this technique to allow for use of gaming keyboards as a low cost stenographic writer powered by FOSS. [1] https://www.gboards.ca/ https://www.gboards.ca/
- derefr 6y ago
  Would it be that expensive to put ~4K of RAM in the keyboard’s microcontroller to act as an event queue? Write keydowns/keyups into the buffer; then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK. (I presume USB does ACKs?) 4K would be more than enough to buffer all possible key events a pair of human hands could create in a reasonable polling interval (~16ms, i.e. 1 frame for a 60Hz game.) Add a clock chip to the HID device as well, and you could even get finer event-reporting granularity than the OS cares to poll for (i.e. the buffer delivered at (Polling Interval x N)ms, would contain events timestamped for (Interval x (N-1)) ms, (Interval x (N-1) + 1)ms, etc.) The timestamps could just be relative to the beginning of the interval, so they wouldn’t need to take up that many bits at all.
  - nitrogen 6y ago
    Some games run their physics engines at a higher framerate than 60, but also any added latency is not going to be acceptable.
  - magicalhippo 6y ago
    > then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK Two issues. Unless you use USB 2.0 high speed, USB "packets" (transactions) are small[1]. For low speed they can have 8 bytes of data, full speed 64 bytes. USB 2.0 HS is a lot more costly of course. Secondly, keycodes that are sent in the same report have no defined order[2]. Thus if two keys were not present in previous report and are present in current report, the order in which those two keys are pressed are indeterminate to the OS. So that would not be very helpful I think. [1]: http://www.usbmadesimple.co.uk/ums_3.htm http://www.usbmadesimple.co.uk/ums_3.htm (Interrupt Transfers) [2]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition... (Appendix C)
ajross 6y ago
It was. HID is a depressingly complicated specification though, and split the keyboard protocol in half: there is a "boot" protocol, which is designed to be simpler for firmware to implement, and a full event protocol. The latter looks exactly like you'd expect such a thing to look like, with arbitrary up/down events reportable independently for as many keys as you want to declare. But the boot protocol has a six key limit, so that's what many devices support.
- magicalhippo 6y ago
  > with arbitrary up/down events reportable independently for as many keys as you want to declare In "Appendix C - Keyboard Implementation" in the "USB Device Class Definition" document[1], it says: "The following are the design requirements for USB keyboards: - Non-modifier keys must be reported in Input (Array, Absolute) items. Reports must contain a list of keys currently pressed and not make/break codes (relative data)." Of course you could make some HID device which has relative key events, but would the OS then recognize it as a keyboard? [1]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition...
kps 6y ago
PS/2 key reports are initiated by the keyboard, whereas USB HID reports are polled. Since (as the article describes) they wanted a fixed-size report for the ‘boot protocol’, the best they could do is report the current state, rather than a log of events since the previous poll. (Well, I guess you could drop the oldest paired non-modifier events, but that would be more complicated. HID just does a bunch of stuff that seems weird now to minimize device-side resources — e.g. HID descriptors aren't a structure defining a report, they're a bytecode for building a structure defining a report on the host.)
JdeBP 6y ago
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.

by janci 6y ago

If I remember correctly, the good old PS/2 keyboards used to send "key down" and "key up" events - so no limit on number of simultaneous keypresses. Why was this not reflected in USB HID?

simias 6y ago

My guess is that the problem with sending events is that if you miss one you're in trouble (in this case it's especially bad if you miss/lose the "key up" message). Given the potential complexity of USB topologies making the protocol stateful might have caused more problem than it would've solved. Besides is there any use for NKRO besides being a meme feature for overpriced keyboards? The only use case I can think of is if you play two player games on the same keyboard but doesn't seem very common these days (and you can probably buy a decent gamepad for the price of a NKRO keyboard).

smileybarry 6y ago
While I can't reproduce it at-will I've definitely had occasional input problems in competitive shooter games with 6KRO + 125Hz. A depress would be processed "too late" to accidentally fall into the next window and affect movement then (e.g.: jump in wrong direction). Yes, the key combination probably doesn't go over 6 keys at once and I don't always have ~8-16ms presses but switching over to NKRO + 1000Hz (which are coupled on QMK) would stop this from happening.
SuperPaintMan 6y ago
Stenography! When stroking a chord you can have 6+ keys held down easily. I design and write firmware for QMK powered writers/ergonomic keyboards, and NKRO is absolutely vital if you don't want to resort to serial devices [1]. Plover uses this technique to allow for use of gaming keyboards as a low cost stenographic writer powered by FOSS. [1] https://www.gboards.ca/ https://www.gboards.ca/
derefr 6y ago
Would it be that expensive to put ~4K of RAM in the keyboard’s microcontroller to act as an event queue? Write keydowns/keyups into the buffer; then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK. (I presume USB does ACKs?) 4K would be more than enough to buffer all possible key events a pair of human hands could create in a reasonable polling interval (~16ms, i.e. 1 frame for a 60Hz game.) Add a clock chip to the HID device as well, and you could even get finer event-reporting granularity than the OS cares to poll for (i.e. the buffer delivered at (Polling Interval x N)ms, would contain events timestamped for (Interval x (N-1)) ms, (Interval x (N-1) + 1)ms, etc.) The timestamps could just be relative to the beginning of the interval, so they wouldn’t need to take up that many bits at all.
- nitrogen 6y ago
  Some games run their physics engines at a higher framerate than 60, but also any added latency is not going to be acceptable.
- magicalhippo 6y ago
  > then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK Two issues. Unless you use USB 2.0 high speed, USB "packets" (transactions) are small[1]. For low speed they can have 8 bytes of data, full speed 64 bytes. USB 2.0 HS is a lot more costly of course. Secondly, keycodes that are sent in the same report have no defined order[2]. Thus if two keys were not present in previous report and are present in current report, the order in which those two keys are pressed are indeterminate to the OS. So that would not be very helpful I think. [1]: http://www.usbmadesimple.co.uk/ums_3.htm http://www.usbmadesimple.co.uk/ums_3.htm (Interrupt Transfers) [2]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition... (Appendix C)

ajross 6y ago

It was. HID is a depressingly complicated specification though, and split the keyboard protocol in half: there is a "boot" protocol, which is designed to be simpler for firmware to implement, and a full event protocol. The latter looks exactly like you'd expect such a thing to look like, with arbitrary up/down events reportable independently for as many keys as you want to declare. But the boot protocol has a six key limit, so that's what many devices support.

magicalhippo 6y ago
> with arbitrary up/down events reportable independently for as many keys as you want to declare In "Appendix C - Keyboard Implementation" in the "USB Device Class Definition" document[1], it says: "The following are the design requirements for USB keyboards: - Non-modifier keys must be reported in Input (Array, Absolute) items. Reports must contain a list of keys currently pressed and not make/break codes (relative data)." Of course you could make some HID device which has relative key events, but would the OS then recognize it as a keyboard? [1]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition...

kps 6y ago

PS/2 key reports are initiated by the keyboard, whereas USB HID reports are polled. Since (as the article describes) they wanted a fixed-size report for the ‘boot protocol’, the best they could do is report the current state, rather than a log of events since the previous poll. (Well, I guess you could drop the oldest paired non-modifier events, but that would be more complicated. HID just does a bunch of stuff that seems weird now to minimize device-side resources — e.g. HID descriptors aren't a structure defining a report, they're a bytecode for building a structure defining a report on the host.)

JdeBP 6y ago

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.