Wayland色管理はどのリリースに載ったか — 5年かかったプロトコルの配布年代記、そしてXサーバーの2026年

はじめに — 「リナックスもいよいよHDR」をリポジトリの記録で検証する
5年がかりのマージリクエスト — color-management-v1に至るまで
どのリリースに載ったか — コンポジター別のピン留め
プロトコルはマージ後も動き続ける — v2、v3、color-representation
まだ滑らかでないもの — リポジトリが語る摩擦
同じ期間、Xサーバーは — 「見捨てられた」ではなく測定値で
実務チェックリスト
終わりに
参考資料

はじめに — 「リナックスもいよいよHDR」をリポジトリの記録で検証する

昨年あたりから、「Linuxデスクトップ HDR」という言葉がニュース見出しによく載るようになりました。ただ、見出しはたいてい2つのことを一緒くたにします — プロトコルが標準としてマージされた瞬間と、それが実際にあなたのコンポジターのリリースに実装された瞬間です。この2つの間には短くて1か月、長ければ1年を超える差があり、実務で意味を持つのは常に後者です。

そこで本稿は発表資料ではなくリポジトリの記録を読みます。wayland-protocolsのタグ別ディレクトリツリー、MutterのNEWSファイル、KWinのコミットが最初に含まれたタグ、wlrootsのリリースノート、そしてXサーバーのリポジトリのコミット数を自分で数え、「色管理とHDRがLinuxデスクトップに実際に配布された年代記」を具体的なバージョン番号にピン留めします。日付と数値はすべて2026年7月17日時点で、GitLab / invent.kde.orgのAPIとgitタグから直接確認した値です(タグの日付は、そのタグが指すコミットの日付を基準にしています)。デスクトップ生態系全体の大きな絵はLinux デスクトップ 2026 — COSMIC / GNOME 47 / KDE Plasma 6.3 / Wayland / Asahi / NixOS 徹底ガイドで扱いました。本稿はそのうちディスプレイスタックという一部分を、ソースレベルで掘り下げます。

5年がかりのマージリクエスト — color-management-v1に至るまで

まず数字から見ましょう。wayland-protocolsのMR !14「staging: add color management protocol」は、2020年1月23日に開かれ、2025年2月13日にようやくマージされました。5年と3週間です。その4日後、2025年2月17日にwayland-protocols 1.41がこのプロトコルをstagingディレクトリに含めてリリースされました — 1.40(2025-01-30)のツリーにはcolor-managementがなく、1.41にはあることが、タグ別のツリー比較で確認できます。

5年かかったのはMRであって、議論そのものが5年というわけでもありません。プロトコル開発に長く関わってきた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のタグはそれより1週間早い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は、マージの1年前にあたる2024-02-14からツリーに存在しており(14.0.0に含まれる)、color-representationの実装は2025-12-19に入り、15.0.0(2026-02-19)に載りました。

まとめると — プロトコルのマージ(2025年2月)から主要3実装の公式対応リリースまでは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の新設、2ピース伝達関数への差し替えとdeprecated項目の広告禁止といった伝達関数の整理、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が出てからまだ1か月余りなので、この時差は自然です。

姉妹プロトコルもあります。color-representation-v1(バッファの色エンコーディング・レンジを記述 — YCbCr係数、full/limitedレンジ、アルファモード)は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は死んだ」という断定の代わりに、リポジトリを直接数えてみました(方法:xorg/xserverをtree:0のpartial cloneで取得し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)です。この2つの最新リリースは、同日に出たセキュリティ勧告(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」の文言が追加された)、2つのブランチの分岐点は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月にマージされた5年がかりのマージリクエストで、マージ後1〜4か月でMutter・KWin・wlrootsのリリースに載り、2026年上半期にはv2・レンダリング配管・HDR画面共有・Windows互換(v3)まで加わって「完成形」に近づきました。同じ期間、Xサーバーはセキュリティパッチと少人数による保守が続く一方、リポジトリの履歴を再構築せざるを得ないほどのガバナンスコストを払い、新しいリリース列車(26.1)はまだ希望に過ぎません。

「Linux HDRできます」は今や真です — ただし、コンポジターのバージョンとドライバとアプリという3つの条件が付いた真であり、トーンマッピングのようにまだオフになっているピースもあります。導入の判断は見出しではなく、上の版表と摩擦の記録で下してください。リポジトリは発表資料より正直です。