Device diagnostics research

Why Some Key Combinations Do Nothing

A keyboard is not a bank of independent switches. It is a grid of rows and columns, and the controller scans that grid to decide which keys are down. When three pressed keys form a rectangle on the grid, the fourth corner can appear pressed too. That is ghosting, and it happens in the keyboard before any software is involved. Our evidence file records the mechanism and the rollover definitions that describe it.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

Pressing three keys sometimes registers only two. Is that the browser, the operating system, or the keyboard itself?

This research explains the keyboard matrix mechanism behind ghosting and blocking, and the reason a browser cannot detect the cause. It does not report a measurement for any specific keyboard model.

Try it on the anchor product: BeanNest Tools /device/.

The matrix model

Each key sits at the intersection of one row wire and one column wire. Pressing it connects the two. The controller drives one row at a time and reads the columns, so it infers which keys are down from which intersections conduct. This design reduces wiring dramatically and is why ghosting exists.

How three keys shadow a fourth

If three pressed keys form three corners of a rectangle on the matrix, current can flow through them as if the fourth corner were also pressed. The controller sees a closed path it cannot distinguish from a real fourth keypress. The reported key was never pressed, and the fourth key you did press can be masked by the ambiguity.

The rollover vocabulary

Our evidence file records four terms that describe how many simultaneous keys a keyboard guarantees. Two-key rollover guarantees at most two. Six-key rollover is the USB boot protocol limit. N-key rollover requires a custom HID report descriptor. Anti-ghosting is a vendor claim about blocking diodes and is neither standardised nor equivalent to NKRO.

Why a browser cannot diagnose it

A page receives keydown and keyup events. It cannot read the matrix, cannot see which row was being scanned, and cannot tell a blocked key from a key nobody pressed. The honest browser claim is which keys the page observed, never which keys were physically down. That distinction bounds every keyboard test result.

What a useful test can still do

A page can report which keys it received, in what order, and with what timing, and can repeat the result so a user can confirm it is stable. That is genuinely useful for confirming a key works. It is not a diagnosis of a combination failure, and a test that implies otherwise is overstating what the platform allows.

The practical way to isolate the cause

Test the same combination while watching a second sink, such as a text editor or a game's own key display. If the characters never appear anywhere, the keyboard or its controller is the likely cause. If they appear in one place but not another, the cause is above the keyboard. That split is worth more than any single-browser result.

Why keyboards use a matrix at all

A keyboard with one hundred and four keys could be wired as one hundred and four independent switches, each needing its own conductor back to the controller. That is impractical in a cable and expensive in a printed circuit. A matrix reduces the wiring to the sum of the rows and columns, so a seventeen by six grid addresses one hundred and two positions with twenty-three conductors. Every consumer keyboard uses this design, and every one of them inherits its electrical properties.

How the controller actually scans

The controller drives one row line at a time and reads every column line while that row is active. A closed switch connects its row to its column, so the controller sees a signal on that column. It repeats this for each row in sequence, typically hundreds of times per second. A key is reported as down when its row is driven and its column reads active, which is an inference about a pair of wires rather than a direct reading of a switch.

Why blocking differs from ghosting

Ghosting is a phantom key that the controller believes is down but nobody pressed, caused by current finding a path through three real keys. Blocking is the opposite failure: a real key that the controller cannot distinguish, so it reports nothing or reports fewer keys than are physically down. Both come from the same rectangular ambiguity, and both are invisible to software because the controller has already resolved the matrix before any event is sent.

Why gaming keyboards advertise specific numbers

A keyboard marketed as six-key rollover is describing a guarantee about USB boot protocol behaviour rather than a hardware matrix property. One marketed as N-key rollover is describing a custom report descriptor that can express every key simultaneously. Because neither claim is standardised in the same way, the numbers across brands are not directly comparable, which is why the evidence file labels anti-ghosting as a vendor claim rather than a specification.

Why the electrical model is not widely known

A keyboard presents itself as a set of independent keys, and its software interface confirms that impression by delivering independent key events. Nothing in that interface hints at a shared matrix, so the failure mode appears mysterious when it occurs. Understanding the scan is what converts an intermittent oddity into a predictable consequence, and the guide exists to make that conversion available to someone diagnosing a combination that does not work.

How many keys a typical matrix can report

In boot protocol mode a keyboard reports a fixed set of modifier bits and up to six simultaneous non-modifier keys, which is where the six-key rollover figure comes from. Beyond that set the protocol has no way to express additional keys, so a keyboard that supports more must present a custom report descriptor. The distinction between the protocol limit and the electrical limit explains why both two-key and n-key figures appear in marketing without contradicting each other.

Why diodes change the behaviour

A blocking diode at each switch prevents current from flowing backward through a path that was not intended, which removes the rectangular ambiguity that causes ghosting. Keyboards with diodes can therefore report any combination the protocol can express. The diode is a hardware addition, and the vendor term anti-ghosting describes it, which is why that term should not be read as equivalent to an n-key rollover claim, since a keyboard can have one property without the other.

What a browser can observe and what it cannot

The browser receives key events, which describe what the operating system decided was pressed. It cannot see the matrix scan, the protocol report, or the operating system's own filtering. A test can therefore report which keys produced events and in what order, and it cannot report whether a missing key was blocked by the matrix or simply not pressed. Stating that boundary is what keeps a keyboard test honest about its diagnostic reach.

How to isolate a suspected matrix problem

Watch the same combination in a second sink at the same time, such as a text editor or a game that displays its own key state. If the combination never appears anywhere, the matrix or the protocol is the likely cause. If it appears in one place but not another, the difference is above the keyboard. That split is a practical diagnostic that no single browser page can perform on its own, and the guide recommends it for exactly that reason.

How the scan rate relates to perceived responsiveness

A controller that scans several hundred times per second can register a keypress within a few milliseconds, which is far below the threshold at which a user would notice delay. The scan rate is therefore not usually the source of perceived input lag; the display sampling floor described in the adjacent guide is far larger. Keeping the two mechanisms distinct prevents a keyboard from being wrongly blamed for a delay introduced elsewhere in the chain.

Why the failure appears intermittent

Whether three keys form a rectangle depends on their physical positions in the matrix, which do not correspond to their positions on the keycaps. Two combinations that look adjacent on the board can behave differently because the keyboard's internal layout follows electrical convenience rather than visual grouping. That mismatch is why the failure seems arbitrary to a user and predictable to someone who knows the matrix.

What the protocol layer adds

Even a keyboard with a perfect matrix must express its state through a report. The boot protocol can express six non-modifier keys plus modifiers, so a seventh simultaneous key cannot be reported regardless of the hardware. A custom report descriptor removes that protocol limit. Two independent constraints, electrical and protocol, therefore both bound how many keys a page can observe.

How a test page should describe its own result

It should say which keys produced events, in what order, and with what timing, and it should avoid implying that a missing key was blocked by the hardware. A user who reads that description can then use the second-sink comparison the guide recommends to narrow the cause. A page that declared a hardware fault from its own event stream would be claiming more than the platform permits it to know.

First-party evidence and provenance

How we checked this

We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script. For this guide we derived the keyboard matrix scanning model and the rollover definitions from the electrical and protocol constraints, then recorded why a browser cannot observe the matrix directly.

Method: We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script.
Environment: Node.js on a desktop workstation. The evidence is a definition set with recorded reasons, not a hardware measurement on a specific device.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/device/definitions-2026-09-20.json
tools/research-evidence/device/README.md