Two keys at once

One line, or it is not a key

The library's two reads each expect exactly one of four pins to come back 0. A second key pulls a second pin low in one of the reads, and that pattern is not one of the four. So getKey() returns 17, FAIL, and getChar() prints the F at position 17 of the keymap.

Hold two keys, then switch the reader to a scanner. Try three keys in an L — 1, 2 and 5.

The fourth key

With the scanner, three keys in an L light a fourth crossing. Keypads like these have no diode per key — the soft one is two printed films with nowhere to put one — so current can run backwards through a pressed key: from the driven column, up one held key, along a row, down another held key and into a second row. The empty corner's row and column end up joined, and a scanner cannot tell that from a press. This is called ghosting.

Keyboards that must read many keys at once put a diode on every key to stop it. A PIN pad normally does without.

Why FAIL is the better answer

A keypad for codes and menus wants one key at a time. Refusing anything else is honest: the library never reports a key that was not pressed. The cost is chords — no Shift-plus-key — and for a keypad with sixteen keys that is rarely a loss.

In practice the F shows up for a moment when somebody types fast and presses the next key before releasing the last. A sketch that ignores F and N and prints only when the answer changes never shows it.

Bounce

A key's contacts do not close cleanly: they touch, part and touch again for a few milliseconds. Reading every 20 ms is slower than the bounce, so each read sees either a settled press or a settled release. The sketches here do that. If a key still registers twice, read less often: 50 ms is still far quicker than anybody types.