Keyboard Tester

Hold down A and W in a game, reach for G, and on some keyboards nothing happens. The key is not broken. That third press was never sent, and the reason is wiring.

A keyboard looks like a row of independent switches, one per letter, each with its own line to the computer. It is not. Between a fingertip and a program sit four editors: a grid of shared wires that the keyboard’s own chip has to interrogate, a timer that waits for contacts to stop rattling, a report with room for only so many keys, and an operating system that keeps some keys for itself. Each of them drops something. A web page stands at the very end of that line, which makes a browser an honest place to look, provided it admits what never arrived.

So the useful question about a keyboard is not whether a key works. It is how much of what your hands did survives the trip, and where the rest went.

A grid of wires that has to guess

The usual construction is a membrane: two flexible sheets carrying a grid of conductive traces, columns on one and rows on the other, held apart by a spacer until a key presses one column against one row. The open-source QMK firmware documents the other half: its controller sends a signal down the columns one at a time and reads every row at once, a routine it calls matrix scanning. The reason is thrift. Without a matrix, QMK notes, each switch would need its own wire to the controller.

One key down is unambiguous: exactly one column meets exactly one row. Two keys are fine as well. Three are not always. When three pressed keys sit on three corners of a rectangle, current finds its way backwards through them and the fourth corner looks pressed too. Count the cases: any three of the four corners, or all four, give the same pattern, five sets of keys in all, and a controller that sees only connected or not connected cannot tell them apart. That phantom fourth key is the ghost.

Modern keyboards do not type the phantom. They detect the ambiguous pattern and ignore the third key instead of reporting a wrong one. The name for that is jamming: the first two keys jam the third. Loosely, people call the swallowed press ghosting as well. Either way the player meets a missing key, as in the example above, A and W held while G is pressed. Which keys jam together differs from one brand and model to the next.

Makers have three ways out. They can route the grid so that popular combinations avoid the trap, which only moves the problem to combinations people are less likely to press. They can add wires. Or they can put a diode beside every switch. A diode passes current one way only, so the backward path never forms and every key can be read on its own. That is n-key rollover. It costs a diode for every one of a hundred-odd keys, and to keep cost and complexity down most keyboards go without.

Advertising blurs all this. A box that promises up to some large number of keys is telling the truth even when only a single combination of that size works and many three-key ones do not.

Six keys and one byte of modifiers

Suppose the grid is perfect. The keyboard still has to tell the computer, which over USB means a report. The USB specification for human interface devices prints the basic keyboard report in an appendix: 8 bytes, of which one holds the modifier keys as individual bits, one is reserved, and the remaining six each name one key that is down. Room for 6 keys, plus modifiers, is all it has. The same document says what must happen at the seventh: the keyboard reports a phantom state in every slot. It also requires a report to list the keys held now, not presses and releases.

That format exists so that firmware as simple as a BIOS can read a keyboard before any driver loads, and it is not the only one allowed. A keyboard may describe a larger report of its own for an operating system to use, which is how full rollover gets across. The catch is the firmware: a very limited host such as a BIOS uses only the simple boot format, so such a keyboard has to speak both.

Then there is the clock. A USB keyboard does not speak when a key moves; it answers when the computer asks. Microsoft’s driver documentation gives the schedule: for a low-speed device, any requested interval up to 15 becomes a polling period of 8 milliseconds, or 125 questions a second, while a full-speed device may ask for 1 millisecond. Dan Luu, an engineer who timed keyboards with a logic analyzer, notes that low speed is what most keyboards use and works out the cost: an average wait of 4 ms at the slower rate against 0.5 ms at the faster.

Even the stream of letters from a held key is the computer’s doing. The specification assigns the repeat rate and the delay before the first repeat to the host, not the keyboard.

Contacts bounce before they settle

Before any of that, the switch itself has to make up its mind. Metal contacts do not close once. They hit, rebound and hit again, and the embedded-systems engineer Jack Ganssle put numbers on it with a collection of switches and an oscilloscope. Setting aside two badly behaved ones, the other 16 bounced for an average of 1,557 microseconds, with a worst case of 6,200. One of the two outliers, a pushbutton he describes as nice, once took 157 milliseconds to settle when it opened. Read naively, each bounce is another keystroke.

Firmware therefore debounces. QMK’s documentation describes two families of method. An eager one reports a change at once and ignores everything for the debounce time afterwards; a deferred one waits until nothing has changed for that long before it reports. The first is quick and not resistant to electrical noise, the second is steady and slightly later. QMK’s default debounce time is 5 milliseconds. Luu makes a related point: debouncing done well does not have to add noticeable delay.

Chatter is what happens when a switch bounces for longer than the firmware waits; QMK notes that settling time varies with a switch’s type, its age and even how it is pressed. The key reports a release and a fresh press that no finger made, and a double letter lands on the page. It is the one electrical fault a browser can catch in the act, because the evidence survives the trip: a new press of the same key, not marked as an automatic repeat, a few milliseconds after its release.

Suppose that second press comes 8 ms after the release. With a tester’s window set to 20 ms it counts as one chatter event. Narrow the window to 5 ms and the count returns to zero, because 8 is more than 5.

The verdict needs care. Whatever bounce the firmware removed never reached the computer, so a clean result says only that nothing got past it. False alarms are possible too. Mozilla’s documentation records that in some Linux desktop environments built on GTK, holding a key sends a release before every automatic repeat, and a page cannot tell that from real presses. A chatter count is a lead, not a diagnosis.

What a web page is told

A browser hands a page two names for every key event. One, called code, identifies the physical key; its specification says the value rests only on the key’s position and does not vary with the user’s locale. The other, called key, is what the press produced, taking the layout and the Shift key into account. Its example: the keys coded Digit2 and KeyQ give 2 and q under a US layout, and an accented e and an a under a French one. Mozilla adds that KeyQ is the apostrophe on a Dvorak layout. So a tester counts keys by code and prints key beside it, and a French or German keyboard labels itself.

The same document supplies a small sum that anyone can check. A modern keyboard of the standard 101 family has 104 keys: 61 in the alphanumeric block and 43 in the function row, the two small pads and the numeric pad, which accounts for 17 of them. Remove the numeric pad and 104 minus 17 leaves 87, the size sold as tenkeyless. Keep only the alphanumeric block and 61 remain, the 60 percent board. The European variant adds one key beside the left Shift, making 105. Choose those four layouts in the tester and its counter reads 104, 87, 105 and 61 before a key is pressed.

Some keys never produce an event at all. The specification says of Fn that it is typically a hardware key that generates no code of its own; on a compact board it reaches the missing function row. As QMK’s documentation observes, a 60 percent keyboard has no dedicated Escape key either, so its corner key stands in for two. Others are taken higher up. A W3C bug report lists Print Screen as firing only a key-up event in three browsers on Windows 7, and a tap of the Windows key opens the Start menu. Google’s developer documentation lists Esc, Alt with Tab and Ctrl with N among the keys captured by the browser or the operating system.

Even the clock on an event is second-hand. Its timestamp records when the browser created the event, not when a contact closed, and browsers round it as a defense against timing attacks and fingerprinting. Mozilla gives the figures: 0.1 ms in Chrome, 1 ms in Firefox and in Safari, and coarser still when stricter privacy settings are on. The gaps between key events are real measurements, but of the browser’s view.

What only hardware can measure

Latency is the clearest case. To time a keyboard, Luu pressed each key together with a button wired to a logic analyzer and watched for the packet on the USB cable, counting from the moment the key began to move. Across 21 keyboards the results ran from 15 to 60 ms, rounded to the nearest 5. A team at the University of Regensburg built a small computer that closes a device’s switch electrically and timed 36 keyboards, mice and gamepads; forcing a 1,000 Hz polling rate lowered the latency of some and not others. Both methods need a wire on the device. A web page has neither.

So a browser test has firm limits. It cannot report a scan rate, a polling rate or a response time, and a page that prints one is guessing. It cannot see Fn, or a key the system kept. It cannot prove full rollover, only that the combinations you tried arrived. What it can do is narrower and still useful: show every key the browser heard from, the most keys it ever saw held together, the three-key holds that came up one short, and the keys that pressed themselves twice.

That is less than the keyboard knows about itself. It is also exactly what your software will ever be given, and that is the part that decides whether a letter appears.