What Really Happens Inside the OS When You Press a Keyboard Key?

Preface

Keyboards are the most frequently used input devices, but what actually happens inside the operating system when you press the “A” key?

Device Controllers

Each I/O device (keyboard, mouse, display, network card, disk, printer, speaker, etc.) is managed by a dedicated device controller (e.g., disk controller, video controller). The controller contains logic and registers that communicate with the CPU.

Typical registers are:

Status Register : indicates whether the controller is idle or has completed an operation.

Command Register : receives commands from the CPU to start I/O.

Data Register : holds the actual data to be transferred.

Controllers expose these registers through either port‑I/O or memory‑mapped I/O, allowing the CPU to read or write them with instructions such as in / out or ordinary memory accesses.

I/O devices are classified as block devices (fixed‑size blocks, e.g., hard disks, USB drives) or character devices (byte‑oriented streams, e.g., mouse). Block devices use a data buffer so that the CPU writes only when the buffer holds enough data, reducing the number of device accesses.

I/O Control Methods

Two basic ways for the CPU to interact with a controller are polling and interrupts. Polling continuously reads a status register until the operation completes, wasting CPU cycles. Interrupts let the controller signal the CPU via an interrupt controller; the CPU then saves its context and runs an interrupt handler.

Interrupts can be software‑generated with the INT instruction or hardware‑generated by the controller. For high‑throughput devices such as disks, interrupt‑driven I/O can still cause excessive context switches, so Direct Memory Access (DMA) is used.

DMA allows a device to transfer data directly to or from main memory without CPU involvement. The typical DMA workflow is:

CPU programs the DMA controller with the transfer size and destination address.

DMA controller commands the disk controller to move data into its internal buffer.

Disk controller copies the buffer to main memory; upon completion it signals the DMA controller.

DMA controller raises an interrupt to notify the CPU that the transfer is finished.

Device Drivers

Because each controller has its own register layout and buffering scheme, the operating system uses device drivers to hide these differences. A driver runs in kernel space, issues commands to the controller, and provides a uniform interface to the rest of the OS.

When a device finishes an operation, it generates an interrupt. The driver registers an interrupt handler that:

Saves the current process context.

Invokes the device‑specific interrupt routine.

Performs the necessary I/O processing.

Restores the original process context.

Linux Generic Block Layer

Linux abstracts all block devices behind a generic block layer, which sits between the file system and the actual disk drivers. It provides a standard block‑device interface upward and performs I/O scheduling downward.

The layer implements five scheduling algorithms: No scheduler, FIFO, Completely Fair Scheduler (CFS), Priority scheduling, and Deadline scheduling, each suited to different workload characteristics.

Storage System I/O Software Stack

The Linux storage stack consists of three layers:

File‑system layer : virtual file system and concrete file‑system implementations; forwards I/O requests to the block layer.

Generic block layer : queues, schedules, and dispatches block I/O to the device layer.

Device layer : hardware devices, their controllers, and drivers that perform the actual data transfer.

From user space, programs use the familiar read, write, and ioctl system calls; the kernel treats devices as special files.

To mitigate the inherent slowness of storage I/O, Linux employs several caches: page cache, inode cache, directory entry cache, and a block‑device buffer cache.

What Happens When a Keyboard Types a Letter?

When a key is pressed, the keyboard controller generates a scan code and stores it in an internal register, then raises an interrupt request.

The CPU receives the interrupt, saves the current process context, and transfers control to the keyboard driver’s interrupt handler.

The handler reads the scan code from the controller’s buffer, translates it to the corresponding ASCII character (e.g., scan code → ‘A’), and places the character into a read‑buffer queue.

The display driver periodically reads from this queue, copies the data into its own write‑buffer, and writes the bytes to the display controller’s data register, causing the character to appear on the screen.

Finally, the OS restores the original process context, and normal execution resumes.