KMS (Kernel-Level video mode switching)

KMS (Kernel Mode Setting) is a technology that transfers control over screen resolution and color depth configuration from user-space programs directly to the operating system kernel. This allows mode switching without a graphics server.

KMS is used in modern Linux distributions, FreeBSD, and other Unix-like systems. It is mandatory for composite managers (Wayland, Xorg with modesetting drivers), as well as for the framebuffer console, early graphics initialization, and system recovery interfaces without running a full X server.

Typical KMS issues

The most common problems include incorrect monitor EDID detection, leading to a black screen after mode switching. Conflicts with proprietary drivers (NVIDIA) can cause KMS failures. Issues also arise when resuming from sleep due to graphics card state reset, and synchronization errors for multiple displays with different refresh rates.

How KMS works

During boot, the kernel video driver module gains direct access to the graphics controller registers via memory-mapped I/O (MMIO). KMS initializes the display controller (CRTC), encoders, and connectors, loading a pre-agreed video mode. Unlike classic User Mode Setting, where the X server held exclusive control, KMS allows mode switching from any console (tty), eliminates flickering during GUI startup, and enables the kernel to output error messages (oops) directly to the screen. A similar feature in Windows is called Windows Display Driver Model (WDDM), but there modes are also set from kernel mode, albeit with a different synchronization and graphics stack architecture. KMS is more tightly integrated with the framebuffer (DRM/FBDEV) and requires the driver to implement three key operations: mode verification, mode setting, and state restoration.

FBDev (Outputting graphics via frame buffer device)WDDM (Windows video subsystem management)DRM (GPU access coordination)

How Kernel Mode setting works

  1. Video Mode Management. KMS moves video mode initialization and switching from user space into the OS kernel. This allows the kernel to directly control display parameters such as resolution, refresh rate, and color depth without involving the X server or other user-space services.
  2. Early Video Buffer Access. Thanks to kernel-level implementation, the framebuffer and console output become available immediately after the video driver module loads. The user sees a smooth transition of video modes from bootloader to graphical environment login, without flickering or context-switch artifacts.
  3. Atomic Updates. KMS supports atomic operations for updating channel parameters. This means that changes to resolution, rotation, scaling, and color space are applied within a single interrupt, completely eliminating visible frame tearing or partial rendering of intermediate states.
  4. Multiple Independent Displays. The kernel manages each connected monitor as a separate DRM (Direct Rendering Manager) object. For each display, video mode, gamma, plane, and synchronization can be set independently, which is critical for multi-monitor configurations.
  5. Planes. KMS provides hardware planes for buffer overlaying without GPU compositing involvement. Planes can be primary (main image), cursor (hardware cursor), and overlay (video/sprites). Moving a plane requires only updating display controller registers.
  6. EDID and Hotplug Support. The KMS kernel module reads EDID (Extended Display Identification Data) via the I2C DDC bus. When a new monitor is detected, a uevent is generated, allowing udev and user-space display managers to dynamically change configuration without restarting the graphics subsystem.
  7. Scaling and Gamma. KMS manages hardware scalers and gamma correction tables. Scaling is performed directly in the display controller without using GPU shaders, reducing computational load and power consumption in static scenes.
  8. Manual Mode Switching. User-space utilities via DRM ioctl (e.g., modetest from libdrm) can enumerate available video modes, set arbitrary modelines, and change display layouts. This is the foundation of all graphics stacks, including Wayland, as the compositor communicates directly with KMS.
  9. Framebuffer Consoles. The fbcon driver works on top of KMS, using the same text output mechanism as graphics applications. When switching virtual terminals, KMS only changes the active buffer without reinitializing the video controller, taking microseconds.
  10. Vertical Sync Synchronization. KMS provides strict synchronization of video mode switching and frame presentation with the vertical sync pulse. A request to change video mode is blocked until the next vblank, preventing image tearing and signal timing violations.
  11. Pixel Format Support. The KMS system provides an exhaustive list of supported formats: RGB, ARGB, XRGB, YUV, NV12, and other planar formats. Applications can directly output compressed video streams to overlay planes without CPU color space conversion.
  12. Atomic Test-Only. The DRM_MODE_ATOMIC_TEST_ONLY flag allows an application to check the feasibility of applying a video mode before actual commit. This prevents video stream corruption from invalid configurations and is used by display managers for setting validation.
  13. Error Handling. When a set of parameters is unachievable (e.g., total width exceeds interface bandwidth), KMS returns an error code indicating the specific resource. The kernel video driver verifies all timings and frequencies before sending commands to the video controller.
  14. Property API. Each KMS object – connector, encoder, CRTC, and plane – has associated properties. For example, rotation, async page-flip, crop, and brightness. These properties are readable and writable via sysfs or ioctl.
  15. Flicker-Free Mode Switching. When changing video mode on the same CRTC, KMS keeps the active plane during timing reconfiguration. It uses an adaptive synchronized reprogramming mechanism where changes take effect after the next VSync packet.
  16. Direct Video Memory Management. KMS allocates buffers in video memory via GEM (Graphics Execution Manager). Buffer physical addresses are passed directly to the video controller, bypassing CPU page tables, allowing image output with minimal latency (one DMA cycle).
  17. Multiple CRTC Support. Each CRTC (CRT Controller) independently generates timing signals. KMS can link multiple CRTCs to different video outputs, enabling a display wall or different resolutions on multiple monitors from a single GPU.
  18. Power Management. When entering sleep mode, KMS saves all video mode states in kernel memory. On wake, the video configuration is restored without driver reload or re-reading EDID, accelerating resume from sleep to fractions of a second.
  19. Virtual KMS Modules. For testing and development, there is the VKMS (Virtual KMS) module that emulates video controller behavior. It allows debugging Wayland compositors and mode management utilities without real GPU hardware, valuable for CI/CD and embedded systems.
  20. DMA-BUF Integration. KMS framebuffers can be exported via DMA-BUF for sharing between different devices (GPU, video decoder, network adapter). This forms the basis for video capture and low-latency remote desktop systems.

Comparison with similar features

  • KMS vs UMS (User Mode Setting). KMS switches screen modes at kernel level, eliminating privileged crashes during resolution changes, whereas UMS delegates this to the X11 user-space driver, creating a risk of freezes when the graphics server crashes but offering more flexibility for experimenting with custom settings.
  • KMS vs EFI GOP (Graphics Output Protocol). EFI GOP works only during firmware boot stage before handing control to the OS, providing a basic framebuffer, while KMS takes over after kernel loads, offering hardware acceleration, console multitasking, and smooth mode switching without display reset.
  • KMS vs VESA BIOS Extensions (VBE). VBE is a legacy real-mode BIOS service operating via software interrupts and limited to 32-bit addressing, whereas KMS uses modern DRM drivers with 64-bit support, buffering, and monitor hotplug, delivering higher performance and stability.
  • VBE (Abstraction of graphics hardware via interrupt 10h)
  • KMS vs FBDEV (Framebuffer Device). FBDEV is a simple framebuffer interface without mode switching or modal control support, relying on a pre-set BIOS mode, while KMS dynamically changes resolution, color depth, and refresh rate, integrating with graphics stacks (Wayland, Xorg) via a common DRM layer.
  • KMS vs NVIDIA Kernel Mode (nvidia-drm.modeset). The proprietary NVIDIA driver uses its own KMS-compatible interface through the nvidia-drm module, but often suffers from delays and synchronization issues on Optimus laptops, unlike open-source KMS implementations (i915, amdgpu) that strictly follow kernel API and integrate better with evdev and Wayland.

OS and Driver Support

KMS is supported in all modern Linux kernels (starting from 2.6.29), as well as in FreeBSD, OpenBSD, and Solaris, where it is implemented as an interface between graphics drivers (i915, nouveau, amdgpu, radeon) and userspace, allowing resolution, color depth, and refresh rate to be configured directly from the kernel without requiring the X server for initial initialization.

Security

Because KMS moves display mode management from the privileged X server into the kernel, it eliminates attacks that swap video modes through userspace processes. Additionally, KMS provides each buffer via DRM objects with access control and supports isolated spaces for different virtual terminals, preventing video memory leaks between consoles.

Logging

KMS integrates with the kernel debugging mechanism (drm_debug, dyndbg), logging all significant events to the dmesg ring buffer: mode changes (mode_set), display synchronization errors (EDID CRC mismatch), PLL and timing configuration, as well as registration of CRTCs, encoders, and connectors. This allows developers to track failures and maintain video sequence integrity through ftrace points in the DRM subsystem.

Limitations

KMS does not provide hardware acceleration for 3D or video – that is the job of DRM TTM/GEM and GPU drivers on top of KMS. KMS also requires a framebuffer console driver (drm_fb_helper). Not all proprietary drivers (e.g., older versions of NVIDIA) support KMS without the nouveau module, and in multi-GPU configurations, conflicts may arise when switching modes of the active display.

History and Development

Development of KMS began in 2007 as part of the Linux kernel mode-setting project (first implementation in the i915 driver). It was officially merged into kernel 2.6.29 in 2009, displacing the legacy userspace mode setting from X.Org DDX. Subsequent evolution led to the creation of a universal API for atomic mode setting (2014), support for multi-plane updates without artifacts, and integration with Wayland via GBM/KMS – up to modern extensions for HDR, VRR, and variable refresh rate displays in the amdgpu and i915 drivers.