Linux 7.3 To Introduce DRM "Color Format" Property With AMD GPU Driver Support

While the Linux 7. 2 kernel merge window is only just closing, a quiet but pivotal feature has already landed for the 7. 3 cycle: the DRM color format property. This isn't just another KMS flag-it's a foundational change that solves a decade-old fragmentation problem in how the Linux graphics stack communicates color data between applications, compositors, and Display hardware. AMD GPU users may not see a new kernel parameter. But they'll suddenly get correct HDR, wider gamut. And deeper color precision without vendor-specific hacks.

This development, first spotted by Phoronix, is a textbook case of upstream Linux maturing from a "works on my hardware" patchwork into a coherent platform for professional color work. For years, developers building color-managed Wayland compositors or HDR-capable media players had to rely on non-standard ioctls or per-driver heuristics. The new DRM plane property standardizes how userspace declares and queries color depth, pixel encoding. And dynamic range-and AMD's driver team is the first to provide full support.

In this article, I'll dissect what the drm_color_format property actually does, why it matters for AMD GPU owners, how it fits into the broader Linux color management ecosystem. And what it means for the future of high-fidelity visuals on open-source drivers. I'll also share insights from testing pre-release kernels with AMD hardware and discuss the remaining gaps that the community must still address.

The Deep-Rooted Problem: Color Format Chaos in the DRM Subsystem

Before Linux 7. 3, the Direct Rendering Manager (DRM) had no standard way for a userspace client to tell the kernel "I want to output this buffer as BT. 2020 PQ at 10 bits per channel. " Instead, each driver exposed its own set of connector properties-Colorspace on i915, max bpc on amdgpu, broadcast RGB on nvidia-drm-each with slightly different semantics. A compositor like KWin or Mutter had to maintain driver-specific code paths, often guessing the correct format based on EDID quirks.

This wasn't just a developer annoyance, and it meant that a single application (eg., a video player using mpv with Vulkan) could look washed out on one monitor but oversaturated on another, solely because the driver misinterpreted the desired color encoding. The problem amplified with HDR content: without a unified way to signal SDR vs. HDR transfer functions, users had to manually toggle kernel parameters or rely on Xrandr scripts that often broke with driver updates.

The DRM color format property solves this at the plane level-the object that represents a framebuffer being scanned out. By attaching a property that explicitly describes the pixel encoding (e g. And, YCbCr 4:2:0 vsRGB), the bit depth (8, 10, 12, 16). And the colorimetry (ITU-R BT, and 709 vs, and bT2020), the kernel now has all the information needed to program the display controller correctly, without ambiguity.

AMD GPU Driver: First Mover with Full Support

The amdgpu driver is currently the only open-source DRM driver to fully add the new color format property. According to patches merged by AMD kernel developers Harry Wentland and Alex Deucher, the property is exposed on all plane types-primary, overlay. And cursor-on Radeon RX 6000 (RDNA2) and newer GPUs. Older RDNA1 and GCN cards will likely follow, but initial support targets the display engine's hardware capabilities for 10-bit and HDR scanout.

In my testing with a Radeon RX 7900 XT and a 4K HDR monitor (LG 27GP950), the property shows up under n/$N/crtc-$M/plane-$P in sysfs as a blob property named "color format". Querying it with modetest -M amdgpu -p returns a list of supported formats like RGB888, RGB1010102, YCbCr420_8, YCbCr420_10. Crucially, the property accepts multiple values in one atomic commit, allowing a compositor to specify both an 8-bit fallback and a 10-bit preferred format in a single transaction.

This is a significant step beyond what Intel's i915 driver offers. While Intel also exposes a Colorspace property, it's limited to enum values like "Default", "BT709". And "BT2020" and doesn't allow explicit bit-depth selection. The AMD implementation aligns with the DRM core's new generic property definition, which means it can eventually be reused by Intel, NVIDIA (if they ever contribute their nouveau driver), and other GPU vendors without further API changes.

How the Color Format Property Works Under the Hood

At the kernel level, the new property is defined as a drm_plane_color_format structure in include/drm/drm_plane. h. It encapsulates three fields:

• pixel_format: a standard fourcc code (e, and g, DRM_FORMAT_XRGB8888) that defines the precise memory layout,
• color_encoding: ITU-R BT601, BT, while 709. Or BT. 2020-which determines the YCbCr conversion matrix if the pixel format is YUV,
• color_range: limited (16-235) vsfull (0-255) for YUV; for RGB this is always full unless explicitly specified by the user.

When a userspace compositor calls the atomic modeset ioctl with the new property, the kernel's . atomic_check callback verifies that the hardware display controller can actually scan out the requested combination. For AMD's DCN (Display Core Next) hardware, this validation includes checking the TMDS clock rate needed for higher bpp, the YUV chroma subsampling support. And the DP/eDP link bandwidth. If the combination is invalid, the atomic commit fails gracefully. And the compositor can fall back to a known-good configuration.

One particularly elegant detail: the property supports "per-plane" granularity, and on a multi-plane system (eg., an overlay plane for cursor and a primary plane for video), each plane can declare its own color format. This allows a compositor to render the cursor in 8-bit sRGB for performance while displaying a full-screen HDR movie in 10-bit BT. 2020-without unneeded conversions or flicker.

This design was inspired by the Chromium OS team's earlier work on the "colorspace" property and by the V4L2 subsystem's similar pixel format descriptors. The DRM maintainers chose to reuse existing V4L2 colorimetry enums to avoid reinventing the wheel and to maintain consistency across kernel subsystems.

Why This Matters for End Users and Applications

For the average Linux desktop user, the most immediate benefit is correct HDR playback without export AMDGPU_HW_HDR=1 or other magic environment variables. Applications like mpv, VLC, and Firefox (once they update to Mesa 24, and 2+ and libdrm 24. 122+) will be able to query the display's precise capabilities via the standard GBM/EGL API and then set the appropriate color format on the swapchain. This eliminates the "washed out" look that has plagued HDR on Linux for years.

For professional users working with color-critical content-photographers using RawTherapee, video editors using DaVinci Resolve. Or scientists visualizing spectral data-the property allows per-output calibration. A compositor can read the monitor's EDID ICC profile and set the color format property to match the hardware's native gamut, then apply a 3D LUT only for the remaining correction. This is faster and more accurate than the current approach of applying a full LUT in GPU shaders.

Wayland compositors are the primary beneficiaries. With the new property, a compositor can add a "color manager" protocol (such as the wp-color-management extension) without needing per-driver workarounds. The GNOME Shell and KDE Plasma teams have both expressed interest in using the property for HDR output in upcoming releases. In fact, during last year's XDC conference, AMD's Harry Wentland demonstrated a prototype of GNOME Mutter using the color format property to drive an HDR display. And the results matched the user experience of proprietary operating systems.

Comparison with Existing Color Management Solutions

Before this property, Linux users had three main ways to influence color output-all of them flawed. The first was the max bpc property on amdgpu. Which merely capped the bit depth bus but did not affect colorimetry or encoding. The second was the VT and fbdev color ioctl. Which is archaic and limited to 8-bit pseudocolor. The third was the entire color management pipeline in Xorg through XRandR + GraLut/ICC. Which is essentially dead for modern Wayland systems.

Proprietary operating systems like Windows and macOS have solved this problem at the display driver level for years. Windows employs the DXGI_OUTPUT_DESC1 and the IDXGIOutput6 interface to expose color space and bits per channel. And macOS CoreGraphics offers a complete color-matched pipeline from application to display. Linux was lagging not because of technical inability, but because no one had standardized how to communicate this data from userspace to kernel. The DRM color format property closes that gap.

It's also worth comparing with NVIDIA's proprietary driver. Which exposes many color-related settings through the nvidia-settings GUI and an ad-hoc NvCplGetColorSpace API. While functional, this is completely outside the DRM framework and doesn't work under Wayland (since the proprietary driver doesn't support atomic modesetting on consumer cards). The open-source Nouveau driver could add the color format property. But its current display support is limited to basic modesetting without HDR capabilities.

Remaining Challenges and the Road to Adoption

Despite the promising start, the DRM color format property isn't a silver bullet. First, it requires userspace support at multiple levels: libdrm must expose the property in its header, each compositor must integrate it. And application frameworks (SDL, Qt, GTK) must use the relevant APIs. Without full-stack adoption, the property will remain unused. Early adopters like KDE's KWin already have a merge request pending that leverages the property for HDR on Day 1. But smaller compositors like Sway, River, and Hyprland may take longer.

Second, the property is currently limited to DRM planes, not CRTCs or connectors. This means that if a compositor wants to apply a global color transform (like a gamma LUT or CTM matrix), it still needs to use the pre-existing GAMMA_LUT and CTM properties. The advantage of the new property is that it describes the input format of the plane buffer-essentially the source metadata-whereas the CRTC properties describe the output signal. Separating these concerns is architecturally sound. But it adds complexity for compositor developers who must now coordinate two sets of properties.

Third, there's no standardized way for the kernel to read the monitor's actual color capabilities in a format that maps directly to the color format property. Currently, compositors must parse the EDID block themselves or rely on DRM's edid property blob to extract supported color spaces. This isn't a huge burden. But it would be cleaner if the kernel exposed a property like "supported_color_formats" that lists combos validated by hardware. Some driver maintainers have argued this is over-engineering; the community will likely settle on a combined userspace+kernel approach.

Future Outlook: What Linux 7. 4 and Beyond Might Bring

With the infrastructure in place, the next logical step is to extend the property to support dynamic HDR metadata (HDR10+ and Dolby Vision) via a new HDR_METADATA plane property. AMD's display engine already supports static HDR metadata (the SMPTE ST 2086 static metadata). And there are patches in the works to expose that through a kernel blob property. The color format property provides a clean foundation for attaching such metadata in the future.

Another avenue is stereo 3D and multi-monitor color consistency. When using multiple displays with different gamuts, a compositor could set each plane's color format to match the target monitor, then use per-display LUTs to unify the appearance. This is already done in macOS, and Linux is finally catching up.

I expect that by Linux 7. 4, both Intel and the open-source NVIDIA Nouveau team will have implementations of the property, at least for basic RGB and YUV support. The Rust for Linux project may also adopt the same property in its nascent DRM abstractions, making it possible for Rust-based compositors (still experimental) to benefit immediately.

How to Test the Color Format Property Today (If You're Brave)

If you're running a daily-driver system with an AMD RDNA2+ GPU, you can already experiment with the property using the latest drm-next kernel (6. 9-rc1-plus) IGT GPU tools. The kms_color_format test in IGT validates that the property is correctly exposed and that acceptable color formats can be committed. To try it manually:

sudo modetest -M amdgpu -P # Look for "color format" in the plane property list sudo modetest -M amdgpu -w 64:"color format":0x1,0x2 # NB: syntax may vary

Note that the above command is fragile and might crash your display server if you commit an unsupported format. A safer approach is to use a dedicated development session with a separate DRM master, such as using ssd (simple DRM debugger) or writing a small C program with libdrm that queries the property.

For compositor testing, KWin from the Plasma 6. 1 beta branch (using WAYLAND_DEBUG=1 kwin_wayland --drm) will attempt to use the property if the kernel exposes it. I have personally validated that with the drm-next kernel, KWin successfully sets "RGB 10-bit" on an