ハクソク

世界を動かす技術を、日本語で。

Waylandコンポジタとウィンドウマネージャの分離

71日前原文(isaacfreund.com)

概要

Wayland の従来型コンポジタは モノリシック構造 で、コンポジタとウィンドウマネージャを一体化。 新しい river 0.4.0 はこれを分離し、ウィンドウマネージャを独立したプログラムに。 river-window-management-v1 プロトコルにより、ウィンドウ管理の柔軟性と パフォーマンス を両立。 開発体験の向上や多様なウィンドウマネージャ実装が可能に。 今後の課題やロードマップについても解説。

river 0.4.0：非モノリシックWaylandコンポジタの設計

  • 従来のWaylandコンポジタは コンポジタ ・ ウィンドウマネージャ を単一プロセスで実装
  • river 0.4.0ではウィンドウマネージャを 独立プロセス として分離
  • 複数のウィンドウマネージャがriverと 互換性 を持ち、選択肢が拡大
  • river-window-management-v1 プロトコルがウィンドウ管理の全権限をウィンドウマネージャに委譲
  • river本体は 描画 や低レベル処理、フレームパーフェクトなレンダリングを担当

WaylandとX11のアーキテクチャ比較

  • X11は ディスプレイサーバ ・ コンポジタ ・ ウィンドウマネージャ が別プロセス
    • 入力イベントやバッファのやり取りに ラウンドトリップ が発生し、遅延の原因
  • Waylandは ディスプレイサーバ と コンポジタ を統合し、 入力遅延 を解消
  • 伝統的なWaylandはさらに ウィンドウマネージャ も統合
    • riverはここを分離し、 設計の柔軟性 と 実装の容易さ を実現

river-window-management-v1 プロトコルの設計

  • ウィンドウマネージャに 最大限の制御権限 を付与しつつ、Waylandの 低遅延 や フレームパーフェクト な描画を維持
  • 毎フレームや毎入力イベントでのラウンドトリップ 不要、入力遅延の増加なし
  • フレームパーフェクト ：ウィンドウのレイアウト変更時も、隙間や重なりが発生しない描画
    • ウィンドウのバッファ提出を 短時間待機 し、応答なければ即描画でレスポンス確保

ウィンドウ管理状態マシン

  • 管理する状態を ウィンドウ管理状態 （サイズ、フォーカス等）と 描画状態 （位置、装飾等）に分離
  • river-window-management-v1はこれらの変更を アトミックにバッチ処理
  • manage sequence でウィンドウ管理状態、 render sequence で描画状態を更新
  • 変更がなければウィンドウマネージャは アイドル状態、必要時のみ起動
  • この仕組みはriver以前から存在し、 river-classicやsway にも類似実装あり

riverの分離設計による利点

  • ウィンドウマネージャ開発の敷居 を大幅に低減
    • ウィンドウ管理ポリシーに集中でき、Waylandコンポジタ全体の実装不要
  • クラッシュしてもセッションが維持 され、再起動や切替が容易
  • 高水準言語やGC搭載言語 での実装もパフォーマンスに影響しにくい
  • 多様なウィンドウマネージャ の登場を促進し、X11時代の多様性に近づく

現時点の制約と今後の展望

  • VRや3Dデスクトップ など、従来の2Dデスクトップから逸脱した用途は未対応
  • 複雑な視覚効果 （例：wobbly windows）は現状非対応、今後の課題
  • ウィンドウ管理ポリシーの制約はプロトコル拡張で対応可能
  • river 1.0.0 に向けて、ウィンドウマネージャの起動・切替UX改善を検討中
  • river 0.4.0対応のウィンドウマネージャは今後も 後方互換性 を維持予定

サポートと寄付のお願い

  • riverの開発は 持続的な資金支援 が必要
  • liberapay による定期寄付や、 GitHub Sponsors ・ ko-fi での支援を歓迎

river対応ウィンドウマネージャの例（ギャラリー）

  • Canoe ：クラシックな外観のスタッキング型ウィンドウマネージャ
  • reka ：Emacsベースのriver用ウィンドウマネージャ（EXWM類似）
  • tarazed ：集中力を重視したパワフルなデスクトップ体験
  • rhine ：再帰的・モジュラー設計とアニメーション対応

river の非モノリシック設計により、Waylandデスクトップの多様性と開発体験が大きく進化。今後の発展にも注目。

Hackerたちの意見

Waylandがプラグイン可能なWMを他の無関係なインフラを変えずに入れ替えられないっていうのは、X11に対してユーザーにとっての大きな損失だと思う。これを改善しようとしてる人たちは、まさに神の仕事をしてるね。

└

それはもう、wlrootsやSmithayみたいなライブラリでできるよ。

└

新しいWMやDEの開発にも影響が出るよね。自分のデスクトップのアイデアもあるから、いつか試してみたいんだけど、最初はX11ベースになると思う。だって、理解しやすくて、すぐに試行錯誤できるから。Waylandに反対してるわけじゃないし、X11にも問題があるから、もっと良いものに移行する価値はあると思うけど、これはWaylandの設計上の致命的な弱点だよ。

└

WMを拡張として実行するためのAPIを公開する単一の実装があればいいだけだと思う。なんで標準から特定のアーキテクチャデザインを強制するのが良いアイデアなのか、全然理解できない。

└

ただの損失じゃなくて、重要な機能が無効化されてる感じ。数十年同じカスタマイズしたウィンドウマネージャを使ってきたから、ウィンドウ管理のための完全に同等なインターフェースがない限りWaylandに移行するのは無理だよ。マウスクリックからキーボードショートカットまで、すべてが思い通りに動く必要があるからね。もしかしたら、Riverをサポートする既存のウィンドウマネージャや、最小限のWaylandコンポジタの上にX11デスクトップルートを再実装するWaybackレイヤーが必要かもしれないけど、今のWaylandコンポジタはその表面すらも触れてないよ。

└

正直言って、最高のLinux GUIスタックは、ルートWaylandサーバー（もちろんルートとしては動いてないけど）の中に、ユーザーごとのWaylandサーバーが入れ子になっていて、モニターにレンダリングするかオフスクリーンでリモートログインするかを切り替えられるようになってるって感じかな。その中にX11サーバーがあって、ハードウェアのことを気にしなくていい状態になってる。そしてその中で普通のウィンドウマネージャーが動いてるっていう。

Waylandがこれを解決できなかったら、ずっとX11を使い続けるつもり。必要なら、動かすためのコーディングエージェントも作るし。

└

xlibreを使う手もあるけど、冗談だって言う人もいるよ。

今は、自分好みに完全にコーディングしたRiverウィンドウマネージャを使ってる。Hyprlandではやりたいことができなかったから、これに切り替えたんだ（例えば、デフォルトでBSPじゃなくて、ウィンドウを均等にタイルすることとか）。この分離がどれだけ影響を与えたかの簡単な例だね。

└

BSP？

Waylandを使ったことはないけど（i3を約15年使ってる）、こういうプロジェクトが出るたびに、なんでWaylandが存在するのか疑問に思う。簡単なことに対して、いろいろと面倒なことが多すぎる。確かにX11には問題があるけど、基本的にやりたいことは何でもできる。Waylandは、切り替えることを考えるには摩擦が多すぎる気がする。

└

Swayは基本的にWayland上のi3だね。設定ファイルはほとんどそのままで（ちょっとした修正は必要だけど）、特にストレスは感じないよ。もちろん、それが理由ってわけじゃないけど、俺にとっては異なるスケーリング要件を持つ複数のモニターのサポートが決め手だった。

└

X11ではできない高リフレッシュレートを実現するために、やろうとした時は毎回苦労してる。

└

最近通ったハードル： "DeviceEvent"っていう、"Window event"よりも少し低レベルな入力の種類があるんだ。ウィンドウが「アクティブ」でなくても発生するんだけど、X11ではサポートされてるのにWaylandではマウスの動き以外はサポートされてないんだ。プログラムがLinuxで更新した後に動かなくなったのに気づいて、結局Window Eventsに切り替えたけど、やっぱりちょっとイライラするね。

└

KDEがWaylandを使えるようになった時から使ってる（KDE 5の頃ね）けど、Fractional HiDPIスケーリングがちゃんと機能してたから。ノートパソコンユーザーとしては、Waylandの一番の利点の一つだよ。それに、WaylandでVRRを動かすのはX.orgよりずっと簡単だし、HDRもサポートしてる。

└

i3からswayに切り替えた理由（約8年前）はDPIサポートだね。高DPIはXorgでは面倒だし、異なるモニターを使うとほぼ不可能なんだ。移行は一方通行だった。いろんなことがスムーズでシンプルになったし、Xorg.confに触れなくて済むようになったのは生活の質が向上したよ。今でも、異なるスケールファクターのモニターを使ってる。

└

同意だよ。X11にはここ数十年、大きな問題はなかったし。xorg.confを手動で編集しなくてよくなったのはいつだったか忘れたけど、私の要件はシンプルだったから、ノートパソコンと時々外部モニター一台だけだった。直面した問題はグラフィックスドライバーやNVIDIAのトラブルに関するものだったけど、X11に関するものではなかった。Waylandに移行してからは、視覚的に少しレスポンスが良くてクリスプになった気がするけど、正直言って、たくさんのプログラムを置き換えたり、ワークフローを大きく変えたり、以前はなかった新しい問題に対処する価値があったとは思えない。残念ながら、今はWaylandの勢いが完全にあるから、X11が完全にサポートされなくなるのも時間の問題だね。XLibreプロジェクトは素晴らしいアイデアだけど、数人の貢献者だけでは全体のエコシステムを維持するのは難しいよ。

└

理論はいろいろあるけど、シンプルなものとしては企業がもっとコントロールを求めたってことかな。systemdの台頭を見てみて - Waylandそのものとは関係ないけど、企業主導の影響があるよね。すべてのデザインが企業に支配されてるとは言わないけど、Waylandの宣伝にはたくさんのプロパガンダがあった。で、ある人たちがそれにうんざりして、「xorgは死んだ」っていう企業の押し付けをやめることにしたわけさ。興味深いのは、これからどうなるかってこと。GTKの開発者たちはGTK5でxorgを殺す手助けをすると言ってるし、KDEもxserverを排除したいみたい。もし企業に支配されてないエコシステムが生まれたら面白いよね。実現する可能性は低いけど、楽しそうだし、Waylandとの本当の競争も生まれるかも。Waylandは最大の約束を破ったんだよね。それはxorgサーバーの代替として機能するってこと。機能を失いたくないから、私にとってはマイナスだな。

これはすごく面白い方向性だね。コンポジタとウィンドウマネージャを分けるって、後から考えると当たり前のように思えるアイデアだけど、ここでのプロトコルやステートマシンの設計が、実際に実用化するのにどれだけの労力がかかったかを示してる。全員がフルコンポジタを作らなくてもWaylandのウィンドウマネージャを書くハードルが下がるのは大きな勝利だと思う。

└

あなたは人間ですか？もしそうなら、失礼な質問でごめんなさい。アカウントが新しいですね。

個人的には、Waylandが無駄な時間じゃないと感じたのは初めてだな。ディスプレイサーバは、表面管理の上にウィンドウ管理の複雑さを持つ必要はないんだ。著者の気持ちには共感するよ。> 「元のWaylandの作者たちがウィンドウマネージャとWaylandコンポジタを組み合わせることにした理由は確かにはわからないけど、単に抵抗が少ない道を選んだんだと思う。社会現象としてはそれが最も抵抗が少なかったかはわからないけど、取り組みやすい問題だったのは確かだね。もしかしたら、作者たちも同じことを意味しているのかも。」（それに、リモートアクセスの話も修正が必要だね。X11では普通に動くのに。90度のディスプレイオリエンテーションのシステムで試した時、入力が実際のものと90度ずれてた。もちろんこれはバグなんだけど、Waylandのアーキテクチャがこういうバグを作りやすくしてる気がする。）

└

X11では、ウィンドウマネージャーがウィンドウの装飾を扱ってるから、それを分けるとなると、ちょっと面倒なメッセージングや設定が必要になるかもしれないね。

└

X11のリモートアクセスはめちゃくちゃで、もう恋しくはないな。少なくともWaylandでは、みんなEGLかVulkanを通るから、その上にリモートアクセスを重ねる道筋がちゃんとあるんだ。

Waylandの重要なデザイン特徴の一つは、ウィンドウマネージャーとコンポジタを組み合わせることじゃなかったっけ？歴史にはあまり詳しくないけど、Waylandのデザイナーたちの考えについての発表や論文はきっとあるはずだよね。

└

ウィンドウマネージャーが別プロセスで、WMとディスプレイサーバーの間で非同期通信があると、フレームがずれて視覚的なアーティファクトが出ることがあるんだ。Waylandでは、ウィンドウマネージャーがコンポジタと同期して動くから、ずれることはないんだよ。

└

まさにその通り、この記事はそのことについてなんだ。Waylandは全てを一つのプロセスにまとめて、不要なコンテキストスイッチを避けるようにしてる。このプロトコルは、グラフィックスサーバーとウィンドウマネージャーの分離を維持しながら、Waylandのパフォーマンスの利点を保つことを目指してるんだ。

ここには変な誤情報がたくさんあるね。Waylandは何も選ばないんだ。ウィンドウの位置や、そのウィンドウがキー入力を受け取るかどうかはコンポジタが決める。プログラムは好きなところに描いたり、システム全体のキー入力を受け取ったり、他のプログラムの代わりに受け取ったりはできないんだ。適切に実装されていれば、スクリーンショットシステムはコンポジタに直接組み込まれてる。これはプログラムが画面の一部への読み取りアクセスを要求できるAPIで、コンポジタが承認すれば提供されるんだ。こうすることで、セキュリティが格段に向上するし、最近はこれがちゃんと機能してる。残念ながら、すべてのコンポジタがこれを実装しているわけじゃないけど、本当にこれを回避したいならkeydを見てみて - https://github.com/rvaiya/keyd バックグラウンドでルートサービスとして動くデーモンがあって、好きなものにキー入力を渡すための適切なシムを提供できるプロジェクトだよ。ちなみに、適切なセキュアモデルは、プログラムが「グローバル」ホットキーの登録を要求して、コンポジタが登録されたら適切なプログラムに渡すっていうもの。これはKDE Plasma 6ですでに実装されてて、ちゃんと動いてるよ。

Riverはこの分割が起こる前からすごく良かったから、今後の展開が楽しみだよ。待ってる間にNiriに切り替えたけど、また戻るかもしれない。もしXmonadユーザーなら、RiverがあなたにぴったりのWayland WMだと言える自信があるよ。

伝統的に、X11にはコンポジタがなくて、Waylandが取り除くために存在する余分なラウンドトリップも必要なかったんだよね。xlibre（または復活したらx.org）のようなプロジェクトが、コンポジタが埋めるはずだったギャップを埋めるためにX11プロトコルを更新する余地があるのか気になる。ちなみに、私はすべてのマシンをlxdeに移行してるんだけど、知らないうちにコンポジタなしのデスクトップに戻ってしまったみたい。高フレームレート、vsync/ティアフリー、高DPIも問題なく動いてる。分数スケーリングもできるけど、私はそれを無効にしてる。個人的には、仮想のX11開発者たちにはHDMIのVRRをリバースエンジニアリングすることに集中してほしいな（今は弁護士にブロックされてるけど）、HDRや拡張カラー空間もね。

└

あなたが探してるのはhttps://en.wikipedia.org/wiki/Compizだね。Compizはウィンドウマネージャーでもあるから、当時からコンポジタとウィンドウマネージャーは一体だったんだよ。