Writing an OS Kernel from Scratch – Part 24: Display Server and Client — Building a Shared Memory Graphics Architecture

Writing an OS Kernel from Scratch – Part 24: Display Server and Client — Building a Shared Memory Graphics Architecture

“Framebuffer lets you draw pixels, but how do multiple applications share the screen? Today, we implement a Display Server + Client architecture, achieving efficient graphics compositing via shared memory!”

In the previous post, we implemented the Framebuffer driver, allowing user programs to directly manipulate pixels. But this brings serious problems:

• Multiple programs writing to the screen simultaneously → screen tearing, content mixing
• No window concept → can’t implement GUI
• No permission control → any program can overwrite the entire screen

A real graphics system needs a Display Server:

• Sole owner of Framebuffer write permission
• Receives drawing requests from Clients
• Composites multiple windows and renders to screen

Clients efficiently submit drawing content via shared memory.

---

Architecture Design

Component	Responsibility
Display Server	Manage screen, composite windows, handle input
Client	Application (Terminal, Painter, etc.)
Shared Memory	Client draws content → Server reads for compositing
IPC Channel	Client sends commands (create window, submit frame)

Data flow: Client draws to shared memory → sends command via IPC → Server composites → writes to Framebuffer

Key: Clients cannot directly access Framebuffer, only indirectly display through Server.

---

Shared Memory Mechanism

1. System calls: shmget / shmat
2. Shared memory object management

Shared memory’s physical pages are shared across multiple processes, but virtual addresses can differ.

---

Display Server Implementation

1. Server initialization
2. Window management
3. Server main loop
4. Compositing and rendering (Blit)

Server is the sole entity that writes to Framebuffer!