Which Release Shipped Wayland Color Management — The Five-Year Deployment Timeline of a Protocol, and the X Server in 2026

Introduction — Checking "Linux Does HDR Now" Against Repository Records
A Five-Year Merge Request — the Road to color-management-v1
Which Release Shipped It — Pinned by Compositor
The Protocol Kept Moving After the Merge — v2, v3, color-representation
What Is Still Not Smooth — Friction the Repositories Tell You About
The X Server Over the Same Period — Measured Instead of "Abandoned"
A Practical Checklist
Closing
References

Introduction — Checking "Linux Does HDR Now" Against Repository Records

Since last year, the phrase "Linux desktop HDR" has shown up often in news headlines. But headlines usually conflate two different things — the moment a protocol merged as a standard, and the moment it actually shipped in your compositor's release. The gap between the two ranges from a month at the shortest to over a year at the longest, and in practice, it is always the latter that matters.

So this post reads repository records instead of press releases. By examining wayland-protocols' per-tag directory trees, Mutter's NEWS file, the tag each KWin commit first landed in, wlroots release notes, and commit counts from the X server repository directly, it pins "the chronicle of when color management and HDR actually shipped on the Linux desktop" to specific version numbers. All dates and figures are verified directly against the GitLab/invent.kde.org APIs and git tags as of July 17, 2026 (tag dates are the date of the commit each tag points to). The big picture across the desktop ecosystem was covered in The Linux Desktop in 2026 — COSMIC, GNOME 47, KDE Plasma 6.3, Wayland, Asahi, NixOS, and Immutable Distros, Deep Dive; this post digs into one piece of that — the display stack — at the source level.

A Five-Year Merge Request — the Road to color-management-v1

Let's start with the numbers. wayland-protocols' MR !14, "staging: add color management protocol", opened on January 23, 2020 and was not merged until February 13, 2025. That is five years and three weeks. Four days later, on February 17, 2025, wayland-protocols 1.41 shipped with the protocol in its staging directory — comparing the per-tag directory trees confirms color-management is absent from 1.40's tree (2025-01-30) and present in 1.41's.

It is the MR that is five years old — the discussion itself goes back even further. The title of a retrospective by Collabora, long involved in the protocol's development, is literally "12 years of incubating Wayland color management".

Why it took so long is explained by the protocol's own shape. color-management-v1 is a large protocol with 9 interfaces (as of 1.49). Clients can declare their content's color space either as an ICC profile or parametrically (primaries + transfer function + luminance), and it also handles mastering display metadata (maxCLL/maxFALL, etc.) and rendering intent. Even after the merge, the XML commit log keeps accumulating corrections — a redefinition of set_luminance, transfer-function swaps — and that post-merge history is itself evidence of how hard it is to pin color science down in protocol wording.

Which Release Shipped It — Pinned by Compositor

There is one core question: "From when does wp_color_management_v1 actually show up on my desktop?" Organized by the official (merged) protocol, here is the answer.

Implementation	First release with the official protocol	Date (by tag)
Mutter (GNOME)	Mutter 48.0 — GNOME 48	2025-03-16
KWin (KDE Plasma)	Plasma 6.4.0	2025-06-12
wlroots (Sway, etc.)	wlroots 0.19.0	2025-05-15
Weston	A pre-merge draft implementation has been in the tree since 14.0.0 (2024-09-04)	—

The table alone does not show each project's texture, so let's go through them one at a time.

Mutter. Reading the NEWS file release by release makes the trajectory clear. In the 47 cycle (47.0 tag: 2024-09-14), "experimental color management protocol support" appeared as a 47.rc entry — this predates the protocol merge, so it is a draft implementation. 48.rc (2025-03-03) shipped the official protocol as "Support wp_color_management_v1 protocol," and GNOME 48's release notes called it "the first introduction of system-level HDR support" — the same notes honestly note that "the number of apps that currently support HDR is limited," and that because turning on HDR often disables hardware brightness controls, a software-emulated brightness control was added alongside it. 48.1 (2025-04-01) disabled HDR on non-atomic (legacy) KMS drivers. 49.0 (2025-09-14) shipped a color-representation protocol implementation, and 50 (2026-03-15) added protocol v2 support (MR !4905, merged 2026-02-20), HDR screen sharing, an "sdr-native" color mode, and CRTC KMS color property support.

KWin. The commit history on invent.kde.org gives an interesting detail. KWin did not wait for the merge — it landed an experimental (xx-) versioned implementation on January 29, 2024 (first included in tag v6.0.90, i.e., the Plasma 6.1 series), and on February 13, 2025, the very day the protocol merged, pushed a commit switching to the official protocol. Because the Plasma 6.3.0 tag had already landed a week earlier, on 2025-02-06, the first release in which this switch reached users was Plasma 6.4.0 (tagged 2025-06-12). The v2 implementation landed in a 2026-01-12 commit and shipped in Plasma 6.6.0 (tagged 2026-02-12).

wlroots. The 0.19.0 release notes (2025-05-15) list "color-management-v1 for HDR10 support" as a new protocol implementation, with the caveat kept verbatim in parentheses: "renderer and backend bits have not yet been merged" — meaning the protocol can speak, but the rendering pipeline plumbing was not there yet. That plumbing arrived in 0.20.0 (2026-03-26): full support across the Vulkan renderer, backend, and scene graph, color primaries/HDR metadata passthrough in the DRM backend, a color-representation-v1 implementation, and support up to protocol minor version 2. For wlroots-based compositors (Sway, etc.), HDR is effectively a 0.20-generation story.

Weston. The reference compositor's libweston/color-management.c has been in the tree since 2024-02-14, a full year before the merge (included in 14.0.0), and its color-representation implementation landed on 2025-12-19, shipping in 15.0.0 (2026-02-19).

To sum up — from the protocol merge (February 2025) to official-support releases across the three major implementations took 1 to 4 months, while the "finished" form, including rendering plumbing and v2, arrived in the first half of 2026. Shipping was a process, not an event.

The Protocol Kept Moving After the Merge — v2, v3, color-representation

Landing in staging is not the end. The interface version keeps climbing. Checking the version attribute of the XML tag by tag:

v1 — from wayland-protocols 1.41 (2025-02-17) through 1.46.
v2 — 1.47 (2025-12-15). Summarizing the pre-merge commit titles: adding a ready2 event, adding the absolute_no_adaptation rendering intent, introducing wp_image_description_reference_v1, transfer-function cleanup such as swapping in a two-piece transfer function and banning advertisement of deprecated entries, and relaxed maxCLL/maxFALL constraints.
v3 — 1.49 (2026-06-07). The centerpiece is a single request, create_windows_bt2100. Carried over from the XML description as-is, it is a predefined image description that reproduces "the way Windows 10 handles its own defined BT.2100 color space for HDR displays driven in BT.2100/PQ signal mode."

Why v3 was needed is answered by KWin's commit log — 2025-12-18, "add workaround + setting for Windows HDR apps," and 2026-02-21, add wine64-preloader to the Windows executable name list. Because Windows games running under Wine/Proton expect Windows' HDR encoding conventions (scRGB, Windows-BT.2100), this lets the compositor speak that convention at the protocol level. The reality that Linux HDR's main customer is gaming is stamped right into the protocol's version history.

For the record, as of this writing (2026-07-17) I have not confirmed any major compositor that has shipped a v3 implementation in a release — the Mutter 51.alpha NEWS has no related entry, the last commit to touch KWin's color-management source files is 2026-04-23 (before the v3 release), and the wlroots 0.20.0 notes go only up to "minor version 2." Since 1.49 landed only a little over a month ago, that lag is unsurprising.

There is a sibling protocol too. color-representation-v1 (describing a buffer's color encoding and range — YCbCr coefficients, full/limited range, alpha mode) merged in 1.44 (2025-04-27), and Mutter 49 (2025-09), wlroots 0.20 (2026-03), and Weston 15 (2026-02) all shipped implementations. This is what is needed for color accuracy in video playback pipelines.

What Is Still Not Smooth — Friction the Repositories Tell You About

The deployment chronicle alone reads like smooth sailing, but the same repositories also record friction. If you are evaluating adoption, this is the part to read more carefully.

Tone mapping is currently off (Mutter). Mutter 50.rc's NEWS has "Disable tone mapping with HDR." The description on MR !4897 explains why — the current tone-mapping implementation does not work correctly with the current blending color space, luminance mapping needs to be handled separately from tone mapping, and HDR tone mapping is meaningless as long as the full PQ range up to 10,000 nits — which no real display can reproduce — is always used. It is an honest commit that shows the distance between an HDR pipeline "turning on" and actually "looking right."

Legacy drivers are excluded. Mutter 48.1 disabled HDR on non-atomic (legacy) KMS drivers, and the same release added a fallback to the default color mode when an HDR monitor loses its HDR capability. On older GPU/driver combinations, HDR will not come up even with a compositor version that otherwise supports it.

The client ecosystem is still adjusting. KWin's color-management file history shows a back-and-forth: "work around Firefox" (2026-01-13) → reverted (2026-01-20) → "work around Firefox again" (2026-01-22) → reverted again (2026-04-23). A protocol becoming a standard does not mean clients use it correctly, and for now the compositor pays that cost in workarounds.

App support is still narrow. Borrowing GNOME 48's release notes' own wording again, the number of apps that support HDR is "limited." Even once the compositor speaks the protocol, toolkits and apps still have to catch up, and that landscape is outside this post's scope — check it yourself before adopting.

Translating this into a practical call — if you only work in SDR, this stack gives you no reason to change anything right now. If color accuracy is a contractual requirement of your workflow (print proofing, video mastering), it is safer to assume it is too early to get on the Linux HDR path without your own verification, until the friction items above settle. Conversely, if your goal is HDR gaming (Proton in particular) and HDR media consumption, the first-half-2026 releases (built on Plasma 6.6, GNOME 50, wlroots 0.20) are a genuine starting line.

The X Server Over the Same Period — Measured Instead of "Abandoned"

On the other side of this chronicle sits the X server. Instead of asserting "Xorg is dead," I counted the repository directly (method: clone xorg/xserver as a tree:0 partial clone and use git rev-list --count, measured as of 2026-07-17).

Starting with the release train. xorg-server's last major release was 21.1.0 (2021-10-27), and only 21.1.x patch releases have followed since — the latest is 21.1.24 (2026-07-08). Xwayland, now split off as an independent release, has likewise had no new major since 24.1.0 (2024-05-15), only 24.1.x continuing on, with the latest at 24.1.13 (2026-07-08). Both of these latest releases are fixes for the security advisory (CVE-2026-55999, CVE-2026-56000) that came out the same day. In other words, security response is still active.

Commit counts. But trying to count commits, I found one premise had collapsed. In February 2026, the xserver repository closed its master branch. Alan Coopersmith's xorg-devel proposal email (2026-01-20) explains the background — master had accumulated commits that were later reverted, "commits that a developer had prepared for work that was planned but will now not be entering our repository," and changes other developers did not agree with, so the proposal was to branch a new main from February 2024 and re-upload only the curated commits worth keeping. As of the proposal, the plan was to keep only 835 of the 1,386 post-divergence commits on master, with selection criteria explicitly stating "exclude commits that did not follow license notice requirements," "exclude commits whose churn outweighs their benefit," and "exclude known ABI/API breaks." The same email also contains this line — "last year this mess derailed the plan for a 25.1 release of Xwayland and the X server, and this year I am hoping we can cut a 26.1 branch."

Measuring what actually happened: master was declared closed as of a 2026-02-08 commit (adding a "defunct" notice to the README), and the divergence point between the two branches is a 2024-02-10 commit. Post-divergence commit counts are 1,428 on the master side and 1,108 on the current main side (including new work since the rebuild). By author, the sharpest drop is in Enrico Weigelt's commits, going from 804 on master to 399 on main — which also means over half of master's post-divergence commits (804/1,428) belonged to one person.

Because of this rebuild, "commits per year" depends on which counting method you use. Since the rebuilt main recommitted past commits in January 2026, counting by commit date distorts the picture — author date is closer to actual activity:

xorg/xserver, current main branch, annual commit counts by author date (measured 2026-07-17)
2020: 224   2021: 341   2022: 215   2023: 265
2024: 631   2025: 224   2026: 235 (through July 17)

Note: by commit date on the closed old master, 2024: 772, 2025: 666 —
     that gap (mass commits and their reverts, plus what fell out
     of the rebuild) is the scale of the incident described above.

Among the 235 commits authored in 2026, the top authors are Peter Hutterer (99), Alan Coopersmith (72), and Olivier Fourdan (30). Steady maintenance by a small number of people — that is the picture the measurements show. "Abandoned" is wrong, and so is "developed like it used to be."

And the feature gap is structural. Xwayland's build definition (hw/xwayland/meson.build) has no reference whatsoever to the color-management protocol. In other words, the color-management/HDR stack covered in the first half of this post is a path that never reaches X11 apps. Meanwhile, on the GNOME side, per Jordan Petridis's announcement, the X11 session was disabled by default in GNOME 49 (September 2025) — as the announcement specifies, "this doesn't affect Xwayland, this is about the X11/Xorg session" — and Mutter 50 (March 2026) removed the X11 backend itself entirely, via MR !4505. X11 apps keep running on top of Xwayland, but the shift in center of gravity toward the Wayland session and new features is now a released fact, not a plan.

A Practical Checklist

Check the version first. To use color management/HDR, the floor is GNOME 48 / Plasma 6.4 / wlroots 0.19-based, and in practice the real starting line is the GNOME 50 / Plasma 6.6 / wlroots 0.20 generation, where v2 and rendering plumbing are in place. Checking your distro's compositor version against this table is enough.

Remember the hardware/driver constraints. HDR is disabled on the legacy KMS path (Mutter 48.1). If you do not see an HDR toggle, suspect the driver before the compositor version.

If you are an app developer — check wp_color_management_v1's version negotiation (v1: 1.41, v2: 1.47, v3: 1.49), and keep in mind that needing Windows conventions (scRGB, BT.2100) is a Wine-family special case, not the general one. For video, also check color-representation-v1 support.

If your workflow depends on X11 — the urgent task is building an inventory that separates app-level dependence (solved via Xwayland) from session-level dependence (no longer possible as of GNOME 50). The X server itself keeps getting security patches, so it is not an immediate risk, but the list of Wayland-only features — like color management and HDR — will only keep growing.

Closing

To sum up: Wayland color management was a five-year merge request, opened in 2020 and merged in February 2025, shipping in Mutter, KWin, and wlroots releases within 1 to 4 months of the merge, and moving close to "finished" in the first half of 2026 with v2, rendering plumbing, HDR screen sharing, and Windows compatibility (v3) added. Over the same period, the X server kept getting security patches and maintenance from a small number of people, while paying a governance cost steep enough to require rebuilding its repository history — and a new release train (26.1) is still just a hope.

"Linux does HDR now" is true these days — but it is true with three conditions attached (compositor version, driver, and app), and there are pieces still switched off, like tone mapping. Base your adoption decision on the version table and friction record above, not on headlines. Repositories are more honest than press releases.