• ↑↓ to navigate
  • ↵ to open
  • ⟶ to select
  • ⌘ ⌥ ↵ to open in a panel
  • ←→ to navigate
  • esc to dismiss
⌘ '
keyboard shortcuts

The Problem

When you press a key, the computer needs to know about it immediately. Without interrupts, the CPU would have to constantly poll (check) the keyboard, wasting cycles.

Core Idea

A keyboard interrupt is a hardware signal sent to the CPU when a key is pressed (or released). The keyboard controller converts the physical keypress into a scan code and triggers an interrupt for the OS to handle.

How It Works

  1. Key press: Physical switch closes in keyboard matrix
  2. Scan code: Keyboard controller generates scan code (e.g., g = code 0x22)
  3. Interrupt: Keyboard raises hardware interrupt (IRQ 1 on x86)
  4. OS handler: CPU jumps to interrupt handler, reads scan code
  5. To application: OS delivers key event to active app (browser)

USB keyboards poll at ~10ms instead of generating interrupts.

Visual Explanation

G Key Key Press (g) Controller Keyboard Controller generate scan code Key->Controller Interrupt Hardware Interrupt (IRQ 1) Controller->Interrupt OS OS Handler read scan code Interrupt->OS App Browser KeyDown: g OS->App

Key Properties

  • Scan codes are hardware-specific (not ASCII)
  • USB polls at ~10ms (not true interrupts)
  • OS converts scan codes to characters
  • Interrupt Vector Table maps IRQ to handler

Semantic Network

semantic_Keyboard_Interrupt THIS Keyboard Interrupt REL1 Related Concept THIS--REL1 related REL2 Builds Into THIS--REL2 builds into

Connections

Edge Cases & Gotchas

  • Key repeat triggers multiple interrupts (hold key down)
  • USB keyboards don’t use hardware interrupts (polling)
  • Some keys have two-byte scan codes (extended keys)
  • Interrupt storms can overwhelm CPU (too many fast keypresses)