Device diagnostics research
Why Some Key Combinations Do Nothing
Pressing three keys sometimes registers only two. Is that the browser, the operating system, or the keyboard itself?
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.
Reviewed 2026-09-20 by BeanNest Studio
The row-and-column matrix model
The definition set models a keyboard as switches at row and column intersections scanned by a controller. Pressing a switch connects one row to one column, so the controller infers key state from the electrical matrix rather than reading an independent wire for every key.
Why a rectangle creates ambiguity
The recorded ghosting mechanism is three pressed keys forming a rectangle that makes the fourth corner appear pressed. The same matrix ambiguity is also why a third key can be blocked on a two-key-rollover design. Both effects occur before the browser receives keyboard events.
Rollover terms describe different limits
The evidence distinguishes 2KRO, 6KRO, NKRO, and anti-ghosting. Two-key rollover guarantees at most two simultaneous keys; USB boot protocol represents up to six simultaneous non-modifier keys plus modifiers; NKRO uses a custom HID report descriptor; and anti-ghosting is a vendor term that is not standardised and does not imply NKRO.
Diodes address the matrix path, not the browser
The definition set records blocking diodes as the mechanism behind the anti-ghosting claim: they prevent an unintended current path through the matrix. That is a hardware property. It does not give a normal web page visibility into the physical switch state or the matrix scan.
What the browser actually receives
A browser receives keydown and keyup after the keyboard controller and operating system have already produced a key state. The page cannot see the matrix and cannot distinguish a key that was physically pressed but blocked from a key that was never pressed. A browser test can report only the events it actually observed.
A rectangle on the grid, step by step
Call the four corners of a rectangle on the matrix A, B, C and D, where A and B share a row, A and C share a column, and D is the corner opposite A. Press A, B and C. When the controller drives the row shared by C and D, current can flow through C to the column of A, through A to the row shared with B, and through B to the column of B and D. That column now shows a signal even though D is not pressed, so the controller can report D as a ghost key. Whether a keyboard reports the ghost, blocks one of the real keys, or handles the combination correctly depends on its matrix layout and on whether it has blocking diodes, so two keyboards can behave differently for the same three physical keys.
What Keyboard Test shows when a key is missing
Keyboard Test lists the key events the browser received, with the physical key code and whether the event was a repeat. If you press three keys and only two appear, the page cannot say whether the keyboard blocked the third, the operating system dropped it or the press never completed. The list is a record of what reached the browser, which is the same list any web page would get.
A fairer way to run a rollover check
Hold the same combination in the same order several times, then try a different rectangle on another part of the keyboard, because blocking depends on which row and column each key uses. Note which keys produced events each time. A missing key tells you something about the whole path from switch to browser; it does not by itself prove a faulty keyboard or establish its rollover rating.
How to phrase a browser keyboard result
A supportable result names the keys that produced events, their order, and their event timing. It should not diagnose a matrix fault, claim a specific rollover capability for unmeasured hardware, or infer a physical press that never reached the page. Those stronger conclusions require evidence outside this browser event stream.
Scope of this guide
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.
Method and evidence
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 kept with the evidence files. 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.
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: 2026-09-20. Re-review trigger: Re-review when the definitions file changes or when the Web keyboard API surface changes.
Evidence files: kept in BeanNest's source repository, not published on this site.
docs/research-evidence/device/definitions-2026-09-20.jsondocs/research-evidence/device/README.md
What this guide does not claim
- measurements for any named keyboard model
- claims that a browser can detect a blocked key
- statements that a specific rollover rating is sufficient for all uses
- diagnoses of hardware faults