The Direct Rendering Manager (DRM) is a subsystem found in the Linux kernel — and several other Unix-like operating systems — that exposes graphical functionality to userspace processes. When your application needs to interact with a GPU driver, display output on a screen, or allocate video memory, DRM is the kernel-level interface that makes it possible. Userspace programs access DRM by opening a device node (a character device file, typically located underDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Smithay/drm-rs/llms.txt
Use this file to discover all available pages before exploring further.
/dev/dri/) and issuing ioctl commands on the resulting file descriptor.
drm-rs provides a safe, idiomatic Rust interface to these ioctls. Rather than routing calls through libdrm (the userspace helper library shipped as part of the Mesa project), drm-rs communicates with the kernel directly, doing minimal abstraction to keep the interface both safe and close to the metal.
Two Core Roles
DRM serves two distinct but related purposes that together cover the lifecycle of a frame from memory to monitor.Graphics Execution Manager (GEM)
GEM is DRM’s subsystem for GPU memory management. Every buffer — whether it holds pixel data for a framebuffer, a texture, or intermediate rendering output — is managed through GEM. From userspace, a GEM buffer is identified by a 32-bit handle that is local to the process and file descriptor that created it. Handles are reference-counted by the kernel and can be shared between processes using either a global name (Flink) or, preferably, a PRIME file descriptor.Kernel Modesetting (KMS)
KMS is DRM’s subsystem for configuring display hardware. Before KMS, display configuration happened entirely in the X server with direct hardware access — one process owned the display pipeline, and switching virtual terminals or running a second display server was fraught with difficulty. KMS moved that responsibility into the kernel, so display configuration requires only the right privileges and a few ioctls. The kernel arbitrates access, preventing races and enabling safe VT switching.Historical Context
In the early days of Linux graphics, X11 operated in a Unified Memory Architecture (UMA) world where a single X server instance had near-exclusive, direct access to GPU hardware. This worked reasonably well on desktops, but it made multi-process GPU access impossible and created serious security concerns — any process that could trick X into executing code had hardware-level access. DRM was introduced to fix this. It added kernel-mediated access to GPU resources: multiple processes can open the DRM device, and the kernel ensures they do not interfere with each other. A DRM Master concept was introduced for operations that require exclusive access (like modesetting), and unprivileged processes can use render nodes to access the GPU for rendering without needing any special privileges.drm-rs vs. libdrm
Most userspace programs that speak DRM do so through libdrm, a C library that wraps the kernel ioctls in a slightly more convenient API. drm-rs deliberately bypasses libdrm entirely. The crate calls the kernel ioctls directly viadrm-ffi (which wraps drm-sys, the auto-generated kernel header bindings), providing:
- Zero libdrm dependency — no need to have Mesa installed on the target system.
- Rust type safety — resource handles are typed newtypes, not raw integers. Invalid handle combinations are caught at compile time.
- Minimal overhead — every public API maps almost directly to one or a small number of ioctls.
DRM is not a general-purpose GPU compute or 3D rendering interface. If you need to run shaders, perform GPGPU work, or render 3D scenes, use Vulkan, OpenCL, or OpenGL — those APIs are built on top of DRM but provide far higher-level abstractions suitable for those tasks. drm-rs is aimed at the display server layer: allocating buffers, configuring display outputs, and managing the presentation pipeline.
Key Resource Types
DRM KMS exposes a pipeline of hardware objects that together describe how pixel data reaches a display. The following types appear throughout drm-rs’scontrol module:
| Resource | Module | Role |
|---|---|---|
| Connector | control::connector | Physical output port (HDMI, DisplayPort, VGA, eDP, …) |
| Encoder | control::encoder | Converts CRTC pixel data into a signal the connector understands |
| CRTC | control::crtc | Scanout engine — reads from a Plane and drives an Encoder |
| Plane | control::plane | Holds a Framebuffer for scanout; three types: Primary, Cursor, Overlay |
| Framebuffer | control::framebuffer | Wraps a GEM buffer so it can be attached to a Plane |
Explore Further
Device Nodes
Learn about primary, control, and render nodes in
/dev/dri/ and how drm-rs represents them with DrmNode.Kernel Modesetting
Understand connectors, encoders, CRTCs, planes, and framebuffers — and how to configure them with drm-rs.
GEM Buffers
Explore GPU memory management: GEM handles, dumb buffers, and PRIME buffer sharing.
Device API
Full API reference for the
Device and control::Device traits.