Ehhh.

So, the initial, and real reason that NKRO was introduced was to deal with inexpensive keyboards that used grid encoders. This requires that each key be assigned a place on a grid, with each row and column having a wire associated with it. When you push a key, it sends the associated pair of wires high voltage. The keyboard encoder chip has those wires running to its pins.

Such a scheme can permit detecting any one key going down, which will always set two wires to high voltage. It can permit detecting any two keys going down, since that will always set at least one more line to high voltage, which will uniquely identify the key. But beyond that, additional keys may not be possible to uniquely identify (and, in fact, pushing one may send only lines that are already high to high, which is totally invisible to the encoder), and so it may ignore additional keys.

This prevents a grid-based encoder from doing NKRO.

If you want to do NKRO, you have to have a unique line coming from every keyswitch, which costs money.

There is a second issue with NKRO.

You can have a keyboard that can have NKRO to the encoder, rather than a grid. And can have a USB interface to talk to the computer.

But last I looked, USB has a protocol limitation that cannot support NKRO, and this was a major reason that you could still get some dual-interface keyboards with PS/2 support and USB recently.

PS/2 is edge-triggered by a key. A key goes down, the computer gets a message. A key goes up, the computer gets a message. All that message says is “this key went down” or “this key went up”. The computer maintains a list of keys and its idea of the up or down state of them.

This is also why PS/2 keyboards can sometimes have keys that appear to be “stuck” that get unstuck when you tap them — if the computer misses the “up” message for some reason, then it only gets notified about it next time the key changes state and the computer gets a message about it.

USB doesn’t work like that. When a USB keyboard sends an event, it contains a dump of the keyboard state. Every keypress, new dump. However, there’s a restriction on the size of the message. It can only contain…I think it’s seven keys that are down, plus modifier keys.

kagis

Six keys.

In practice, six is probably enough for pretty much anyone. The real problem was grid encoders, as a video game player might legitimately hit three or four keys at once. But…it still isn’t, strictly-speaking, NKRO unless it can do all.

It looks like there are basically two approaches that keyboards have used to try to provide a similar effect. One is to just invent a proprietary protocol, and rely on that and a driver rather than the standard USB keyboard behavior.

The other is to tell the computer that the keyboard is a whole array of keyboards. Since most OS environments can use multiple keyboards and just use their input, such a keyboard can pretend to have multiple keyboards pressing buttons.