Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 用仓库记录来验证「Linux 也能上 HDR 了」这句话
一份耗时五年的合并请求 — color-management-v1 是如何走到今天的
究竟是哪个版本发布的 — 按合成器逐一钉死
协议合并之后仍在演进 — v2、v3、color-representation
尚未理顺的地方 — 仓库自己讲出来的摩擦
同一时期的 X 服务器 — 不谈「被抛弃」，只谈测量值
实务检查清单
结语
参考资料

引言 — 用仓库记录来验证「Linux 也能上 HDR 了」这句话

从去年开始，「Linux 桌面 HDR」这个说法频繁出现在新闻标题里。但标题通常会把两件不同的事混为一谈 — 协议合并为标准的那一刻，与它实际在你所用合成器的发行版本中落地的那一刻。这两者之间，短则相差一个月，长则超过一年，而实务中真正重要的，永远是后者。

因此本文不读发布通稿，而是读仓库记录。通过逐一核对 wayland-protocols 按标签划分的目录树、Mutter 的 NEWS 文件、KWin 提交最初被纳入的标签、wlroots 的发布说明，以及直接统计 X 服务器仓库的提交数，把「色彩管理与 HDR 究竟何时真正部署到 Linux 桌面」这件事钉死在具体的版本号上。文中所有日期与数字，均为截至 2026 年 7 月 17 日、直接从 GitLab / invent.kde.org 的 API 及 git 标签中核实的数值(标签日期以该标签所指向提交的日期为准)。桌面生态整体的全貌，已在《2026 年的 Linux 桌面：COSMIC、GNOME 47、KDE Plasma 6.3、Wayland、Asahi、NixOS 与不可变发行版深度解析》一文中讨论过；本文则把其中显示栈这一块，下沉到源码层面来解剖。

一份耗时五年的合并请求 — color-management-v1 是如何走到今天的

先看数字。wayland-protocols 的 MR !14「staging: add color management protocol」，于 2020 年 1 月 23 日发起，直到 2025 年 2 月 13 日才被合并。整整五年零三周。四天后，2025 年 2 月 17 日，wayland-protocols 1.41 把这份协议纳入 staging 目录并发布 — 对比按标签划分的目录树可以确认，1.40(2025-01-30)的树里没有 color-management，而 1.41 有。

花了五年的是这份 MR，讨论本身其实更早就开始了。长期参与该协议开发的 Collabora 所写的一篇回顾文章，标题就直接叫「12 years of incubating Wayland color management」。

为什么耗时这么久，协议本身的形态给出了答案。color-management-v1 是一个拥有 9 个接口(以 1.49 为准)的大型协议。客户端既可以用 ICC 配置文件来声明自己内容的色彩空间，也可以用参数化方式(原色坐标 + 传递函数 + 亮度)来声明，还要处理母版显示元数据(maxCLL/maxFALL 等)以及渲染意图。而且合并之后，XML 的提交日志里仍在不断累积修正 — set_luminance 的重新定义、传递函数的替换 — 这段合并后的历史本身，就说明了把色彩科学固定成协议文字有多难。

究竟是哪个版本发布的 — 按合成器逐一钉死

核心问题只有一个：「wp_color_management_v1 从什么时候起，在我的桌面上真正能用？」按正式(已合并)协议来梳理，结果如下。

实现	首次搭载正式协议的发布版本	日期(按标签)
Mutter (GNOME)	Mutter 48.0 — GNOME 48	2025-03-16
KWin (KDE Plasma)	Plasma 6.4.0	2025-06-12
wlroots (Sway 等)	wlroots 0.19.0	2025-05-15
Weston	合并前的草案实现自 14.0.0(2024-09-04)起就在代码树中	—

光看表格，看不出各个项目的具体面貌，下面逐一细说。

Mutter。 逐个发布版本读 NEWS 文件，脉络很清晰。在 47 周期(47.0 标签：2024-09-14)中，「实验性色彩管理协议支持」作为 47.rc 的条目出现 — 这时协议还没合并，所以是草案实现。48.rc(2025-03-03)以「Support wp_color_management_v1 protocol」实现了正式协议，GNOME 48 的发布说明称其为「系统级 HDR 支持的首次引入」 — 同一份说明也如实写道，「目前支持 HDR 的应用数量有限」，并且由于开启 HDR 后，硬件亮度调节往往失效，因此同时加入了软件模拟的亮度调节。48.1(2025-04-01)在非 atomic(旧式)KMS 驱动上禁用了 HDR。49.0(2025-09-14)实现了 color-representation 协议，50(2026-03-15)则加入了协议 v2 支持(MR !4905，于 2026-02-20 合并)、HDR 屏幕共享、「sdr-native」色彩模式，以及 CRTC KMS 色彩属性支持。

KWin。 invent.kde.org 的提交历史给出了一个有趣的细节。KWin 没有等待协议合并，早在 2024 年 1 月 29 日就提交了一份实验性(xx-)版本号的实现(最先被纳入的标签是 v6.0.90，即 Plasma 6.1 系列)，并在协议合并的当天，也就是 2025 年 2 月 13 日，提交了切换到正式协议的提交。不过由于 Plasma 6.3.0 的标签比它早了一周，打在 2025-02-06，所以这次切换真正触达用户的第一个发布版本是 Plasma 6.4.0(标签 2025-06-12)。v2 实现则是通过2026-01-12 的提交加入，并搭载在 Plasma 6.6.0(标签 2026-02-12)中。

wlroots。 0.19.0 的发布说明(2025-05-15)把「color-management-v1 for HDR10 support」列为新协议实现，同时在括号里原样保留了这句提醒：「renderer and backend bits have not yet been merged」 — 意思是协议本身能「说话」，但渲染管线的管道部分还没接通。这部分管道在 0.20.0(2026-03-26)中补齐：Vulkan 渲染器、后端、场景图的全面支持，DRM 后端对色彩原色和 HDR 元数据的透传，color-representation-v1 的实现，以及对协议次版本 2 的支持。对于基于 wlroots 的合成器(Sway 等)来说，HDR 实质上是从 0.20 这一代才真正开始的故事。

Weston。 作为参考实现的合成器，Weston 的 libweston/color-management.c 早在合并前一整年，也就是 2024-02-14 就已经在代码树中(包含于 14.0.0)，color-representation 的实现则在 2025-12-19 加入，搭载在 15.0.0(2026-02-19)中。

归纳一下 — 从协议合并(2025 年 2 月)到三大实现的正式支持发布版本，用了 1 到 4 个月；而算上渲染管线和 v2 的「完成形态」，则要到 2026 年上半年。部署是一个过程，不是一个事件。

协议合并之后仍在演进 — v2、v3、color-representation

进入 staging 目录并不是终点，接口版本还在持续提升。逐个标签核对 XML 的 version 属性，情况如下：

v1 — 自 wayland-protocols 1.41(2025-02-17)起至 1.46 为止。
v2 — 1.47(2025-12-15)。归纳合并前的提交标题：新增 ready2 事件、新增 absolute_no_adaptation 渲染意图、新设 wp_image_description_reference_v1、诸如替换为两段式传递函数以及禁止声明已弃用条目在内的传递函数整理，以及放宽了 maxCLL/maxFALL 约束。
v3 — 1.49(2026-06-07)。核心只有一个请求，create_windows_bt2100。照搬 XML 的描述，这是一个预定义的图像描述，用来复现「Windows 10 对以 BT.2100/PQ 信号模式驱动的 HDR 显示器，处理其自定义 BT.2100 色彩空间的方式」。

v3 为什么需要，KWin 的提交日志给出了答案 — 2025-12-18「为 Windows HDR 应用添加变通方案 + 设置项」，2026-02-21「在 Windows 可执行文件名列表中加入 wine64-preloader」。由于跑在 Wine/Proton 上的 Windows 游戏，预期的是 Windows 自身的 HDR 编码惯例(scRGB、Windows-BT.2100)，这让合成器得以在协议层面表达这套惯例。Linux HDR 的主要客户是游戏这一现实，就这样被刻进了协议的版本历史里。

顺带一提，截至撰写本文时(2026-07-17)，我还没能确认哪个主要合成器已经在正式发布版本中搭载了 v3 实现 — Mutter 51.alpha 的 NEWS 里没有相关条目，KWin 色彩管理源文件最后一次被触及的提交是 2026-04-23(早于 v3 发布)，wlroots 0.20.0 的说明也只提到「次版本 2」为止。考虑到 1.49 发布至今才刚过一个月出头，这个时间差并不意外。

还有一个姊妹协议。color-representation-v1(描述缓冲区的色彩编码与范围 — YCbCr 系数、full/limited 范围、alpha 模式)于 1.44(2025-04-27)合并，Mutter 49(2025-09)、wlroots 0.20(2026-03)、Weston 15(2026-02)都已实现。视频播放管线要做到色彩准确，需要的正是这一部分。

尚未理顺的地方 — 仓库自己讲出来的摩擦

只看部署编年史，好像一路顺风；但同样这些仓库里，也留下了摩擦的记录。如果你在评估是否要采用，这部分更值得仔细读。

色调映射目前是关闭的(Mutter)。 Mutter 50.rc 的 NEWS 里有一条「Disable tone mapping with HDR」。MR !4897 的说明是这样的 — 当前的色调映射实现，与目前的混合色彩空间配合得并不正确；亮度映射需要与色调映射分开处理；而只要始终使用真实显示器无法还原的、一直延伸到 10,000 尼特的 PQ 全量程，HDR 色调映射本身就没有意义。这是一条诚实的提交，它展示了 HDR 管线「打开」与真正「看起来对」之间的距离。

旧式驱动被排除在外。 Mutter 48.1 在非 atomic(旧式)KMS 驱动上禁用了 HDR，同一版本还加入了处理逻辑：当 HDR 显示器失去 HDR 能力时，回退到默认色彩模式。在较老的 GPU / 驱动组合上，即便合成器版本达标，HDR 也不会亮起来。

客户端生态仍在调整之中。 KWin 色彩管理文件的历史里，留下了一段来回拉锯：「work around Firefox」(2026-01-13) → 撤销(2026-01-20) → 「work around Firefox again」(2026-01-22) → 再次撤销(2026-04-23)。协议成为标准，并不代表客户端就会正确使用它，这笔成本目前暂时由合成器用变通方案来承担。

应用支持依然狭窄。 再借用一次 GNOME 48 发布说明的措辞，支持 HDR 的应用数量是「有限的」。即便合成器已经会说这套协议，工具包和应用也得跟上才行，而这片版图不在本文讨论范围内，采用前需要各自确认。

落到实务判断上 — 如果你的环境只用 SDR，这套技术栈本身不构成现在就该改动什么的理由。如果色彩精度是工作流的合同条件(印刷打样、影像母版制作)，在上述摩擦记录尚未理顺之前，不经自行验证就搭上 Linux HDR 这条路，稳妥的判断是为时尚早。反过来，如果目标是 HDR 游戏(尤其是 Proton)与 HDR 媒体消费，2026 年上半年的这批发布版本(基于 Plasma 6.6、GNOME 50、wlroots 0.20)已经是一条实打实的起跑线。

同一时期的 X 服务器 — 不谈「被抛弃」，只谈测量值

这份编年史的另一面，是 X 服务器。与其断言「Xorg 已死」，不如直接数一数仓库(方法：以 tree:0 的 partial clone 拉取 xorg/xserver，用 git rev-list --count 统计，截至 2026-07-17)。

先从发布节奏说起。 xorg-server 最后一个大版本是 21.1.0(2021-10-27)，此后只发布过 21.1.x 的补丁版本 — 最新是 21.1.24(2026-07-08)。已经拆分为独立发布的 Xwayland 也一样，自 24.1.0(2024-05-15)之后再没出过新的大版本，只延续着 24.1.x，最新是 24.1.13(2026-07-08)。这两个最新版本，都是同一天发布的安全公告(CVE-2026-55999、CVE-2026-56000)的修复版。也就是说，安全响应到现在仍在运转。

提交数。 但真去数提交数的时候，发现有一个前提已经不成立了。2026 年 2 月，xserver 仓库关闭了 master 分支。Alan Coopersmith 的 xorg-devel 提案邮件(2026-01-20)解释了背景 — master 上积累了不少后来被撤销的提交、「某位开发者为一项本已计划、但如今不会再进入我们仓库的工作而准备的提交」，以及其他开发者并不认同的改动，于是提案是从 2024 年 2 月这个时间点分出一个新的 main 分支，只挑选值得保留的提交重新提交上去。按提案当时的估算，master 分叉之后的 1,386 个提交里，只打算保留 835 个，挑选标准中明确写着「排除未遵守许可证声明要求的提交」「排除收益相对折腾程度过大的提交」「排除已知会破坏 ABI/API 的提交」。同一封邮件里还有这样一句话 — 「去年这场混乱让 Xwayland 和 X 服务器的 25.1 发布计划落空了，希望今年能切出 26.1 分支。」

实际测量发生的情况是：master 在一条 2026-02-08 的提交处被宣告关闭(在 README 里加上了「defunct」字样)，两条分支的分叉点是 2024-02-10 的一个提交。分叉之后的提交数，master 一侧是 1,428 个，目前 main 一侧是 1,108 个(含重建之后的新工作)。按作者拆分来看，降幅最大的是 Enrico Weigelt 的提交，从 master 的 804 个变成了 main 的 399 个 — 这也意味着，master 分叉后的提交里有一半以上(804/1,428)出自一个人之手。

由于这次重建，「按年份统计的提交数」会因统计方式不同而不同。重建后的 main 在 2026 年 1 月把过去的提交重新提交了一遍，所以按提交日期统计会失真，按作者日期(author date)统计更接近真实活动情况：

xorg/xserver，当前 main 分支，按作者日期统计的年度提交数(2026-07-17 测量)
2020: 224   2021: 341   2022: 215   2023: 265
2024: 631   2025: 224   2026: 235 (截至 7 月 17 日)

注:按已关闭的旧 master 的提交日期统计则是 2024: 772，2025: 666 —
     这一差值(大量提交及其撤销，以及重建过程中被剔除的部分)，
     就是正文中所描述事件的规模。

2026 年提交的 235 个当中，作者排名靠前的是 Peter Hutterer(99)、Alan Coopersmith(72)、Olivier Fourdan(30)。少数人稳定地做维护工作 — 这就是测量数字给出的画面。「被抛弃了」是错的，「还和以前一样在开发」也是错的。

而且功能差距是结构性的。 Xwayland 的构建定义(hw/xwayland/meson.build)里，完全没有任何对色彩管理协议的引用。也就是说，本文前半部分讲的色彩管理/HDR 技术栈，是一条根本不会触达 X11 应用的路径。与此同时在 GNOME 这一侧，按照 Jordan Petridis 的公告，GNOME 49(2025 年 9 月)默认禁用了 X11 会话 — 正如公告所明确的那样，「这不影响 Xwayland，说的是 X11/Xorg 会话」 — 而 Mutter 50(2026 年 3 月)通过 MR !4505 直接删除了 X11 后端本身。X11 应用仍会在 Xwayland 之上继续运行，但会话与新功能重心的转移，如今已不再是计划，而是已经发布的事实。

实务检查清单

先核对版本。 想用色彩管理/HDR，最低门槛是基于 GNOME 48 / Plasma 6.4 / wlroots 0.19；实际上真正的起跑线，是 v2 与渲染管线都已就绪的 GNOME 50 / Plasma 6.6 / wlroots 0.20 这一代。把发行版的合成器版本对照这张表就够了。

记得硬件和驱动的限制。 在旧式 KMS 路径上，HDR 会被禁用(Mutter 48.1)。如果看不到 HDR 开关，按顺序应该先怀疑驱动，而不是合成器版本。

如果你是应用开发者 — 请确认 wp_color_management_v1 的版本协商情况(v1: 1.41，v2: 1.47，v3: 1.49)，并分清楚需要 Windows 惯例(scRGB、BT.2100)只是 Wine 系的特殊用途，而不是一般情形。涉及视频的话，还要一并检查 color-representation-v1 的支持情况。

如果你的工作流依赖 X11 — 当务之急是把「应用级依赖(可以靠 Xwayland 解决)」和「会话级依赖(自 GNOME 50 起已不可能)」区分开来，做一份清单。X 服务器本身仍在持续发布安全补丁，所以不是眼下的风险，但像色彩管理、HDR 这类只会堆积在 Wayland 一侧的功能列表，只会越来越长。

结语

归纳一下：Wayland 色彩管理是一份 2020 年发起、2025 年 2 月才合并的、耗时五年的合并请求；合并后 1 到 4 个月内，就搭载进了 Mutter、KWin、wlroots 的发布版本；到 2026 年上半年，随着 v2、渲染管线、HDR 屏幕共享、Windows 兼容(v3)相继加入，越来越接近「完成形态」。同一时期，X 服务器一边持续获得安全补丁和少数人的维护，一边也付出了不得不重建仓库历史这样一笔治理成本，而新的发布节奏(26.1)目前还只是一个愿望。

「Linux 能上 HDR 了」这句话如今是真的 — 但这是一句附带三个条件(合成器版本、驱动、应用)的真话，其中也有像色调映射这样至今仍处于关闭状态的部分。是否采用，请依据上面的版本表和摩擦记录来判断，而不是标题。仓库，比发布通稿更诚实。