Linux Graphics Stack Explained Framebuffer DRM KMS X11 Wayland Mesa Vulkan [2026]

By Indie Kings | September 23, 2026

Updated September 23, 2026: Linux graphics work becomes easier to understand when split into layers: framebuffer memory, DRM and KMS display control, X11 or Wayland composition, GPU APIs, and userspace drivers. Shehab Khaled's September 21 Medium explainer supplies the map, while Linux Kernel, Wayland, X.Org, and Mesa documentation verify the roles.

Wayland client and compositor architecture diagram

Image: Wayland architecture diagram. Credit: Wayland project documentation.

From pixels to display

Per Shehab Khaled's Medium explainer, a framebuffer is a region of memory containing pixels. A program writes pixel values, a display controller is configured with the buffer address, resolution, format, and timing, and the controller repeatedly reads the memory to produce a display signal.

The useful distinction is simple: rendering produces pixel values in memory, while scanout reads completed pixel data and sends it toward the display. A framebuffer does not draw or display anything by itself, per the article's explanation.

Layer	Job	Typical example
Framebuffer	Stores pixel values	RGBA buffer in memory
Rendering	Produces pixel values	CPU or GPU writes a window
Scanout	Reads completed pixels	Display controller reads buffer
Display	Turns signal into visible output	Monitor receives HDMI or DisplayPort

DRM and KMS

Per the Linux Kernel DRM documentation, DRM is the kernel graphics subsystem. It exports interfaces for memory mapping, context management, DMA, fences, memory management, and output management. KMS is the display-management component inside DRM, covering display resources and mode setting.

Per the Kernel documentation, applications normally use a primary node such as /dev/dri/card0 for privileged display functions, while a render node such as /dev/dri/renderD128 serves rendering clients without modesetting or privileged ioctls.

Per the same documentation, render nodes let offscreen renderers and GPU applications use a device without a running graphics server or DRM master. They do not take over a monitor or change display modes, per the DRM userland interface rules.

Node	Primary role per Kernel docs	Display control
`card<num>`	Primary node, legacy plus KMS operations	Yes, for an authorized master
`renderD<num>`	Render client access	No modesetting or privileged ioctls
DRM master	Tracks clients controlling shared display hardware	One current master per device

X11 and Wayland

Per the X.Org Xorg manual, Xorg is an X11 server for Unix-like systems. An X11 application is a client that communicates with the X server, which coordinates display resources for multiple applications, per the manual.

Per the official Wayland introduction, Wayland is a display-server and compositing protocol. Applications allocate their own buffers and render their contents, while the compositor combines surfaces, presents the result, and mediates input, per the documentation.

Per the official XWayland documentation, Xwayland is a complete X11 server that acts as a Wayland client. The Wayland compositor supplies the X11 window-management role, allowing X11 and native Wayland windows to share one desktop, per the same chapter.

System	Who renders window content	Who combines output
X11	Application or X server path, depending on workload	X server plus compositor or window manager
Wayland	Client application	Wayland compositor
XWayland	X11 application	Wayland compositor through Xwayland bridge

GPU APIs and drivers

Per the official Mesa introduction, Mesa began as an open-source OpenGL implementation and later added OpenGL ES, OpenCL, VA-API, Vulkan, and EGL support. Mesa also provides drivers for software rendering, hardware acceleration, and layered APIs, per the project documentation.

Per Shehab Khaled's article, OpenGL and Vulkan are specifications rather than implementations. Applications call a common API, and a userspace driver translates those calls into commands the installed GPU understands. That is why one application can target several GPU families without carrying a separate native command language for each one.

Do not read this as one universal driver. Mesa lists separate hardware, layered, and software drivers, while vendor stacks can provide their own userspace implementations. The stable idea is the boundary: application API above, driver below, kernel interface underneath.

OpenGL: Graphics API specification with implementation beneath it.
Vulkan: Explicit graphics and compute API specification.
Mesa: Open-source userspace graphics stack with many drivers.
DRM: Kernel interface connecting userspace work to the device.

One frame, end to end

A modern Wayland application first renders a surface into a buffer, usually through a graphics API and driver. It attaches that buffer to a Wayland surface and commits it, per the Wayland protocol documentation.

The compositor receives the surface, combines it with other surfaces, wallpaper, cursor, and output state, then presents the composed frame through the display path. DRM and KMS handle the device-facing display side, while the application and compositor handle their own surfaces, per the layer split.

X11 applications follow the X11 request path to Xorg or Xwayland. The exact route changes with direct rendering, compositing, and driver choices, so a useful mental model beats a single universal diagram, per Shehab Khaled's layered approach.

FAQ

What is a framebuffer?
Per the Medium explainer, it is memory holding pixel values. It is not the display or scanout hardware itself.

What does DRM do?
Per Linux Kernel documentation, DRM is the kernel graphics subsystem for device, memory, rendering, and output interfaces.

What is KMS?
Per the Kernel documentation, KMS is the display-management component of DRM, including display resources and mode setting.

What is the difference between card0 and renderD128?
Per the Kernel docs, card0 is a primary node with display-related operations, while renderD128 serves render clients without modesetting.

Is Wayland a compositor?
Wayland is a protocol. A compositor such as Weston or KWin implements the server side, per the official Wayland documentation.

Does XWayland replace Wayland?
No, per the XWayland documentation. It provides an X11 server for legacy applications inside a Wayland session.

Bottom Line

Linux graphics is a stack, not one feature: memory holds pixels, DRM and KMS manage the device, X11 or Wayland organizes display state, APIs describe application work, and drivers translate it. Learn the boundary between layers first.