Comments by "LoneTech" (@0LoneTech) on "What Happens When I Press a Key? - Computerphile" video.

As seen on his example rubber dome over PCB keyboard, there's typically minimal hardware and the debouncing in this case must be performed by the microcontroller that does the keyboard matrix scanning. Diodes are used in higher end keyboards to avoid ghosting (where multiple keys cause misdetection), but can be used for unidirectional debouncing in single switch circuits.
7
USB is most certainly not using set 2 - for the reason why, look up what the scancode is for the arrow keys, which have a prefix for set 1 compatibility, or the Pause key which is 7 bytes long. USB keycodes are in alphabetic order and Z in particular is 1D (see HID usage tables, section 10 keyboard). Your firmware might be translating it for legacy OS support, however. Set 3 was more logical in that it used a single bit for press/release and one byte for each event. Also, the polling in USB is performed by the host controller, not the CPU, so we still have an interrupt for when things have changed. There are also buffers in both keyboards and port controllers for PS/2, AT etc, but the CPU typically has to handle them byte by byte.
7
bob jones, interrupt handling varies with architectures. For instance, on a PC there's at least one PIC or APIC (P because the priorities are programmable) holding interrupt flags, priorities and masks, and on most microcontrollers interrupts are vectored, so there's no time spent finding which interrupt occurred. Some have event systems that can trigger other functions without involving the CPU at all. XMOS XS-1 might wake up a distinct hardware thread to be run concurrently with all that were already running. The basic function of an interrupt remains to reroute control flow in response to external events, which is why it was called the Sequence Break System on the PDP-1. I expect the professor is aware of several of these variations, even if the explanation here is cut short. For a low priority interrupt to not be processed would require quite an extraordinary delay; typically they're low priority specifically because the connected device is so slow that the risk of overflows is negigible. The most common source of such problems is instead buggy ISRs that fail to clear interrupt flags.
6
Quite right! That's part of what the program in that microcontroller handles. USB keyboards process things slightly differently, in that they report a list of currently pressed keys instead of press/release events.
3
Yep, those were the feelers.
2
The message from the keyboard to the computer doesn't tell the computer to check what was pressed, typically. The message sent already holds that information. From the CPU's perspective, keypresses are very rare, and spending time looking for them there would make little sense, particularly as switching tasks is quite costly. The interrupt allows it to jump to the keyboard handling routine only when the keyboard has sent new information.
1
Yep, this tradeoff between polling and interrupts does exist! Interrupts cause a context switch, which involves saving some state and jumping to another routine, possibly waking up a CPU that was sleeping entirely. Spinning the CPU on a single task can achieve faster reaction times on many, but not all, processors (the exceptions tend to have hardware contexts, like SPARC register windows, ARM fast interrupts or XMOS threads). The point I was making is that the CPU receives the interrupt when the message has arrived; it is not involved while the keyboard is transferring, and does not need a round trip to interrogate the keyboard. It's more like the mail man leaves the note at the desk you're already working than you answering the bell. (On PS/2, there's a high risk the CPU is fast enough to switch back and forth for each byte, which can get costly as many messages are several bytes long.)
1