Writing an OS Kernel from Scratch – Part 26: User-Mode Display Server and Client — A True Graphics System Architecture
“An in-kernel Display Server is controllable but violates the microkernel philosophy; a real graphics system should be in userspace! Today, we move the Display Server and Client entirely to userspace, communicating via Unix domain sockets!”
In the previous two posts, we implemented:
- Framebuffer driver (kernel mode)
- Display Server + Client architecture (Server in kernel mode)
- Unix domain sockets (with FD passing support)
But keeping the Display Server in kernel mode has serious problems:
- Stability risk: Server crash → kernel crash
- Poor extensibility: can’t dynamically update Server
- Violates design philosophy: graphics system should be a userspace service
Real modern graphics systems (like Wayland, X11) all run in userspace!
Architecture Refactoring
Key changes:
- Display Server = normal user process
- Client communicates with Server via socket
- Server writes directly to screen via /dev/fb0
The kernel only provides basic services: Framebuffer device + Unix domain sockets + shared memory!
System Startup: init Process Coordination
- System boots → init starts display_server
- Server creates /tmp/.display.sock
- Terminal/Painter launch and connect to Server
- Client creates windows, passes shared memory
- Server composites multiple windows to /dev/fb0
Screen displays: Top-left: Terminal (text interface), Bottom-right: Painter (color gradient rectangle)
✅ Fully userspace graphics system running successfully!
Comments