Wayland が「いつ枯れるのか」という問いは、単に「いま動くかどうか」ではなく、「長期運用の基盤として、故障時の切り分けと回避が確立し、周辺機能まで含めて挙動が収束しているか」という問いである。Wayland は X11 の後継として明確に普及している一方で、枯れた基盤と呼べるかは、用途と評価軸で結論が変わる。ここでは、まず用語を整理し、次に成熟が遅く見える理由を分解し、最後に「枯れた」と言える条件と、保守的な運用での現実的な意思決定まで落とし込む。
1. まず「Wayland」と「枯れる」を定義する
Wayland は、アプリケーション（クライアント）と表示側（コンポジター）が会話するためのプロトコルと、その参照実装群を指す名称であり、X11 のような「巨大な一枚岩の表示サーバー」を置き換える目的で設計された。Wayland の公式サイトは、Wayland を「X11 の置き換えであり、より開発・拡張・保守がしやすいことを狙う」と説明している[1]。プロトコル仕様自体も公開されており、Wayland は非同期のオブジェクト指向プロトコルとして設計されている[2]。
一方で「枯れる」は主観語なので、運用上の意味に分解しておく。本稿では、Wayland が枯れたと言える条件を「日常利用の快適さ」ではなく、次のような運用条件の達成として扱う。
1.1 枯れたと言うための到達条件
| 到達条件 | 意味 | なぜ重要か |
|---|---|---|
| 互換レイヤー依存の縮小 | Xwayland のような互換層に頼らず、主要アプリがネイティブ Wayland で成立する状態を指す。 | 互換層は便利だが、故障時の切り分け点が増え、運用の不確実性が増える。 |
| 周辺機能の一般解 | 画面共有やリモートデスクトップのような運用機能が、特定実装の癖ではなく、標準的な枠組みで再現できる状態を指す。 | 基盤としての安定性は、機能そのものより「誰でも再現できる解の存在」に依存する。 |
| 障害時の解決可能性 | 典型障害のパターン、調査手順、回避策、代替策がコミュニティとドキュメントに蓄積し、対応が定型化している状態を指す。 | 保守運用では「壊れない」より「壊れても直せる」が価値になる。 |
2. 結論から言うと Wayland はいつ枯れるのか
結論から言うと、Wayland が「ほぼ問題なく使える標準基盤」として枯れるには約 10〜15 年規模の時間がかかる傾向があり、実質的には 2028〜2032 年ごろが安定完成期と考えられる。ただし「どのレベルを枯れたとみなすか」で評価は変わる。日常利用で大きな不満が出にくい段階と、保守運用で例外処理が少なくなり「壊れても型で直せる」段階は別物である。この文書は後者まで含めて「枯れる」を扱うため、結論が長期に寄りやすい。
この時間感覚は Wayland 固有の遅さというより、GUI 基盤が持つ歴史的な成熟周期に近い。大きな互換資産を抱える UI 基盤は、置換が始まってから「標準基盤」として収束するまでに長い時間が必要になりやすい。
| 技術 | 初期登場 | 実用安定期（目安） | 期間 |
|---|---|---|---|
| X11 | 1987 | 1995〜2000 | 約 10〜15 年 |
| Linux Desktop（GNOME/KDE） | 1998〜1999 | 2008〜2012 | 約 10 年以上 |
| systemd | 2010 | 2020 前後 | 約 10 年 |
| Wayland | 2008 | 2028〜2032 | 約 20 年規模 |
Wayland は 2008 年にプロジェクトとして始まり、その後にプロトコルと参照実装（Weston）を軸に発展してきた[1]。一方で X11 は 1987 年に X11 がリリースされ、以後長い時間をかけて実装と運用知が積み上がった。GNOME 1.0 は 1999 年に公開され、KDE 1.0 は 1998 年に公開されている。systemd も 2010 年に初期の発表があり、主要ディストリビューションに標準採用されるまで時間差があった。つまり UI 基盤の移行は「技術の完成」だけでなく、互換・運用・周辺スタックが収束するまでの時間を含む。
この観点から Wayland を段階化すると、2020 年代前半は「実用化段階」、2020 年代後半は「安定化段階」、そして 2030 年前後は「完熟段階」というペースが自然になる。以降の章では、なぜ UI 周辺が最後まで尾を引くのか、なぜ実装分岐が成熟を遅らせるのか、そして保守運用で何を満たせば「枯れた」と言えるのかを、具体的に分解して説明する。
3. 成熟に時間がかかる理由は「置換」ではなく「再設計」だから
Wayland は、X11 の機能をそのまま移植する思想ではなく、表示スタックを整理し直す思想であるため、単純な置換にならない。特に、X11 で長年「当たり前」だった前提が Wayland では別の方法に置き換わるため、周辺ツール・デスクトップ環境・アプリケーションが追随する時間が必要になる。Wayland の設計思想は、プロトコル自体の説明や仕様に「コンポジターが中心になり、クライアントと会話する」というモデルとして現れている[2]。
この「再設計」の結果として、過渡期には互換レイヤーが必要になる。代表例が Xwayland であり、Xwayland は「Wayland のクライアントとして動く X サーバーで、旧来の X クライアントを Wayland セッションに橋渡しする」と説明される[3]。つまり、しばらくの間は「ネイティブ Wayland アプリ」と「Xwayland 経由の旧来アプリ」が同居し、問題の所在が複数に分かれる。
3.1 X11 と Wayland の構造比較
| 観点 | X11 の構造 | Wayland の構造 | 移行期に起きる問題 |
|---|---|---|---|
| 基本設計 | 表示サーバーとクライアントが明確に分離された汎用ネットワーク透過モデルである。 | コンポジターが中心となりクライアントと直接通信するローカル最適化モデルである。 | 設計思想の違いにより従来の動作前提がそのまま成立しない場合がある。 |
| 互換性 | X11 アプリケーションは同じプロトコルで直接動作する。 | Xwayland を介して旧来アプリケーションを動作させる構成になる。 | 問題が Wayland 側か Xwayland 側かアプリ側か判別しにくくなる。 |
| 表示処理 | ウィンドウ管理と描画は分離されウィンドウマネージャが外部プロセスとして動作する。 | コンポジターが描画とウィンドウ管理を一体として処理する。 | デスクトップ環境ごとに挙動が異なり問題の再現性が低くなる。 |
| アプリケーション移行 | 長年の資産がそのまま利用できる。 | Wayland 対応のツールキットや API が必要になる。 | 対応状況にばらつきが出て移行期間が長くなる。 |
| 運用上の切り分け | 問題は X サーバーかアプリケーションに収束しやすい。 | コンポジター・Wayland プロトコル・Xwayland・ツールキットに分散する。 | 障害解析に時間がかかり成熟が遅く感じられる。 |
4. Wayland は単一の製品ではなく、実装が分岐する
X11 の世界では「Xorg」という巨大な実装が中心だったが、Wayland はプロトコル中心で、コンポジター実装が複数存在する。参照実装としての Weston は「Wayland コンポジターの参照実装であり、それ自体が有用な環境でもある」と説明されている[4]。一方で実用デスクトップでは、GNOME や KDE Plasma といったデスクトップ環境が独自のコンポジター実装を持ち、さらに wlroots のようなライブラリーを使って多様なコンポジターが作られる。wlroots は「Wayland コンポジターを作るためのモジュラーなライブラリー」と明示している[5]。
この構造は、健全さと引き換えに、成熟を遅く見せる。理由は単純で、実装が複数あると「同じプロトコルでも挙動差が出る」ためであり、ユーザーが遭遇する問題は「Wayland 全体」ではなく「特定のコンポジター＋特定のツールキット＋特定のアプリ」の組み合わせとして現れる。
4.1 Wayland コンポジター実装の分岐構造
| 分類 | 代表例 | 役割 | 成熟への影響 |
|---|---|---|---|
| 参照実装 | Weston | Wayland プロトコルの標準的な動作モデルを示す実装である。 | 仕様理解には有用だが実運用環境とは構成が異なるため問題再現に差が出る。 |
| デスクトップ統合型 | GNOME (Mutter), KDE (KWin) | デスクトップ環境と一体化したコンポジターとして動作する。 | 環境ごとに挙動差があり問題が環境依存になりやすい。 |
| ライブラリー型 | wlroots | 独自コンポジターを構築するための共通基盤として使われる。 | 実装の多様性が増え標準的な動作像が見えにくくなる。 |
| 軽量コンポジター | sway など | wlroots を利用した軽量な Wayland 環境を提供する。 | 構成差による問題のばらつきが増え成熟が遅く見える。 |
5. 低レイヤーより「ユーザーが触る周辺機能」が最後まで尾を引く
多くの基盤技術は、コアが整っても周辺が遅れる。Wayland の場合、日常利用で不可視な部分より、ユーザーが直接触る周辺機能が「基盤としての未成熟」を体感させやすい。代表は画面共有とリモート操作で、Wayland では安全性のために「勝手に画面を覗けない」設計になり、アプリが画面を取得するにはポータルを介した許可と仲介が必要になる。XDG Desktop Portal は、デスクトップ統合のための D-Bus インターフェイス群を公開し、アプリが安全に外部リソースへアクセスする枠組みを提供する[6]。
画面共有やリモートデスクトップに直接関係するのが RemoteDesktop ポータルであり、仕様として「リモートデスクトップセッションを作成し、デスクトップの遠隔操作を許可する」ことが定義されている[7]。この枠組みは、従来の「X11 のフックで画面を読む」設計からの大きな転換であり、成熟にはアプリ側の追随が必要になる。
5.1 周辺機能が不安定に見えやすい領域
| 領域 | Wayland での扱い | 運用上の含意 |
|---|---|---|
| 画面共有・録画 | ポータル経由で許可を取り、映像は PipeWire 等で配信する構成になりやすい。 | 従来の手法がそのまま通らず、アプリ側の対応有無が体験差になる。 |
| リモートデスクトップ | コンポジターとポータルを中心に「許可された範囲で」遠隔操作する方向へ設計が寄る。 | ヘッドレスや常時リモート前提の運用では、設計思想の差が摩擦として出る。 |
| 入力（IME を含む） | 入力はセキュリティと整合性の影響を強く受け、環境依存の不具合が体感されやすい。 | 業務用途では「入力が不安定」は致命傷になり、保守運用は保守側へ傾く。 |
| マルチモニター・スケーリング | 高 DPI と複数出力の整合はコンポジター実装差が出やすい領域になる。 | 特定環境でのみ起きる不具合が残ると、基盤としての信頼が積み上がりにくい。 |
6. 「普及」と「枯れた基盤」は違う
Wayland は普及している。例えば Fedora は Fedora 25 を対象に GNOME の既定を Wayland にする変更を宣言し、必要時には Xorg にフォールバックすると説明している[8]。Ubuntu も 17.10 のリリースノートで「対応するシステムでは Wayland が既定であり、必要ならログイン画面から Xorg を選べる」と明記している[9]。Debian も Wayland に関する公式 Wiki を用意し、Wayland を X Window System の置き換えとして扱っている[10]。
ただし、普及は「デフォルトで選ばれる」ことを意味し、基盤として枯れていることは「運用上の不確実性が小さい」ことを意味する。ここを混同すると、日常用途では満足しているのに、運用用途では違和感が残るという状況が生まれる。
6.1 普及を示す事実と、それが直ちに「枯れた」を意味しない理由
| 普及を示す事実 | 一次情報 | それでも残る論点 |
|---|---|---|
| Fedora が GNOME で Wayland を既定にした | Fedora 25 を対象に Wayland を既定化し、条件により Xorg にフォールバックすると説明されている[8]。 | フォールバックが必要な場面が残る限り、運用では「例外処理」が発生し続ける。 |
| Ubuntu が対応環境で Wayland を既定にした | Ubuntu 17.10 のリリースノートで Wayland 既定が明記されている[9]。 | 既定化は採用の意思決定であり、長期運用の成熟度とは別軸である。 |
| Debian が Wayland を既定セッションとして扱う | Debian の「New in Buster」では GNOME の既定セッションが Wayland である旨が記述されている[11]。 | 「既定である」ことは「ヘッドレス・遠隔運用まで含めて安定」を保証しない。 |
7. 保守運用で効くのは「壊れたときに直せるか」という成熟度
保守運用では、平常時の快適さより、障害時の復旧可能性が価値になる。X11 は長年の蓄積があり、診断ツールと回避策が定型化している。一方 Wayland は、設計として安全性が高い代わりに「従来の便利な抜け道」を閉じている部分があるので、運用手順が新しくなる。たとえば、GNOME Remote Desktop は RDP と VNC のバックエンドを持ち、画素ストリーミングに PipeWire を使うことが明記されている[12]。このように、Wayland 環境のリモート系は「コンポジター＋ポータル＋PipeWire＋デスクトップ環境の統合」という形で成立しやすく、構成要素が増える。
また、ディストリビューションや企業ドキュメントの側でも、この設計を前提にした運用が整理されつつある。Red Hat のドキュメントは、GDM の設定で Wayland を無効化して X11 に寄せる手順を明示しており、運用上「Wayland を切り替え可能にする」需要が現実にあることを示している[13]。この事実は、Wayland が未成熟というより、運用要件が多様であり、過渡期には切り替えが必要になるという構図を示す。
1 2 | [daemon] WaylandEnable=false |
7.1 保守運用の観点から見た成熟度の指標
| 観点 | X11 の状況 | Wayland の状況 | 運用上の意味 |
|---|---|---|---|
| 障害解析手法 | 長年の運用知により診断手順が定型化している。 | 構成要素が多く切り分け手順が確立途上にある。 | 障害復旧に必要な時間と経験値に差が出る。 |
| 構成の単純さ | X サーバーを中心とした比較的単純な構成である。 | コンポジターやポータルや PipeWire など複数要素の統合で成立する。 | 問題発生時の調査対象が増える。 |
| 回避手段 | 設定変更やツールで部分的に回避できる場合が多い。 | 設計上許されない操作があり回避手段が限定される。 | 運用手順を事前に整備する必要がある。 |
| 切り替え可能性 | X11 を前提として運用されている。 | Wayland と X11 を切り替える運用が現実的な選択肢になる。 | 過渡期にはフォールバック手段が重要になる。 |
| 再現性 | 環境差が比較的小さく再現しやすい。 | コンポジターやデスクトップ環境によって挙動差が出る。 | 障害の共有と解決に時間がかかる。 |
8. サーバー運用やヘッドレス運用で Wayland が難しく見える理由
Wayland は「ローカルのユーザーセッションが存在し、そのコンポジターが画面を管理する」ことを前提にした設計になりやすい。そのため、ヘッドレスでのリモートログインや、ログイン前のグラフィカルセッション制御のような運用は、セキュリティ上の意図も含めて難しくなりやすい。KDE Plasma の世界でも、Wayland セッションを RDP で提供するための取り組みとして KRdp が紹介されており、Wayland セッションを RDP で公開するための「必要な接着剤」を提供すると説明されている[14]。これは裏を返せば、従来のやり方がそのまま通らないため、Wayland に適合した新しい部品が必要になった、という意味でもある。
GNOME 側でも、リモートログインを含む形で GDM と統合し、RDP 経由で複数ユーザーへリモートログイン機能を提供する、という説明が Red Hat のドキュメントにある[15]。つまり、Wayland の世界でもヘッドレス運用を成立させる道筋は整備されつつあるが、設計思想の転換により「従来の簡便さ」と「安全な標準化」のトレードオフが表面化しやすい。
8.1 どういう運用で摩擦が出るか
| 運用要求 | X11 での直感 | Wayland での現実 |
|---|---|---|
| ログイン前に GUI へ入る | 表示サーバーが独立していて、そこへ接続する発想になりやすい。 | デスクトップ環境と統合した仕組みが必要になり、構成が大きく変わる[15]。 |
| 画面共有を常時有効化 | 画面取得は比較的自由で、ツール側で完結しやすい。 | 許可と仲介が前提となり、ポータルとストリーミング基盤が関与する[7]。 |
| 旧来アプリを大量に使う | X11 上で動く前提なので、問題の切り分け点が比較的少ない。 | Xwayland が介在し、問題が「アプリ」「互換層」「コンポジター」に分割される[3]。 |
9. 「いつ枯れるか」を考えるための時間軸モデル
ここまでの観点を踏まえると、「枯れるまでの年数」を一つの数で言い切るのは本質ではない。重要なのは、成熟が段階を持つことを理解し、自分の用途がどの段階を要求しているかを明確にすることだ。Wayland の仕様やリリースは現在も更新されており、Wayland Protocols のリリース告知も継続している[16]。これはプロジェクトが活発であることを示すが、同時に「周辺機能も含めた標準の固まり方」は時間を要することも示唆する。
9.1 成熟を三層に分ける
| 層 | 何が満たされると到達か | 体感として何が変わるか |
|---|---|---|
| 技術的成熟 | プロトコルと基本実装が安定し、主要デスクトップで日常利用が成立する。 | 「普通に使える」と感じるユーザーが増える。 |
| 実用成熟 | 画面共有や入力などの周辺が大きく破綻せず、既定設定で困る人が減る。 | 「デフォルトで困らない」が増える。 |
| 基盤成熟 | 運用の定型手順が確立し、互換層依存が縮小し、障害対応が型として共有される。 | 保守運用でも「想定外が減る」と感じる。 |
ディストリビューションが Wayland を既定にする事例は増えているが[8][9]、保守的な運用が欲しいのは多くの場合「基盤成熟」である。だから保守運用の視点では、普及の波に合わせるのではなく、「運用ノウハウと代替策が固まった時期」を待つのが合理的になる。
9.2 Debian の時間軸で見ると「基盤成熟」はいつ来るか
「いつ枯れるのか」を現実の意思決定に落とすとき、保守的なユーザーにとって使いやすい物差しが Debian の時間軸である。Debian は新技術を段階的に取り込み、stable に入るまでに testing/unstable で十分に揉まれるため、Debian stable での採用状況は「実用成熟」よりも一段高い成熟度を示すことが多い。Debian の現行 stable が Debian 13（trixie）であり、2025 年 8 月 9 日の初回リリースと、その後の点更新が公式に案内されている[17][18]。また Debian Wiki の DebianReleases は、stable/testing/unstable の位置づけを継続的に更新しており、次期 testing が Debian 14（Forky）であることも示している[19]。
重要なのは、Debian が「リリースは ready になったら出す」という文化を持ちながらも、近年は概ね 2 年程度の周期で新しい stable を出してきたという点である。Debian 13 の公式リリース告知でも、前回リリースからの開発期間として約 2 年が明記されている[18]。Debian Wiki の FAQ でも、近年のリリースが 2 年程度の間隔で進んでいることが説明されている[20]。
| 観点 | Debian 目線での読み替え | なぜ基盤判断に効くか |
|---|---|---|
| 既定セッションになる | 日常利用における「実用成熟」が進んだサインである。 | ただし運用の例外処理（互換層や周辺機能）はまだ残り得る。 |
| 複数世代の stable で定着する | 障害の型と回避策が蓄積し、問題が「既知化」していく段階である。 | 保守運用で重要な「壊れても直せる」に近づく。 |
| 運用機能が標準スタックで収束する | ポータルや PipeWire など周辺スタックが「当たり前の解」として定着する段階である。 | 個別実装の癖に依存しない運用手順が作りやすくなる。 |
この枠組みで考えると、「Debian stable で Wayland が既定」は必要条件ではあるが十分条件ではない。保守的運用が欲しいのは、次のような状態である。第一に、Xwayland が「あると便利」ではなく「なくても困らない」側へ縮むこと。第二に、画面共有・リモートデスクトップ・入力などの周辺が、ディストリビューション既定の標準スタックで再現でき、障害時の切り分け点が限定されること。第三に、障害の型が Debian のバグトラッカーや Wiki、各デスクトップ環境の運用知として蓄積し、同種障害の再発時に「型で直せる」状態になることである。
9.3 「10 年見る」という直感はなぜ合理的か
保守的ユーザーが「あと 10 年は見ておく」と言うと過剰に聞こえることがあるが、基盤技術の成熟周期としては典型的である。ポイントは、Wayland の普及が進んだ後に、運用上の例外が収束するまでに時間がかかる点にある。Debian のように stable の採用で判断する場合、2 年周期を仮定しても 3〜4 世代で 6〜8 年が経過し、その間に周辺スタックが定着し、障害対応の知が積み上がって初めて「基盤成熟」と呼べる感触が出てくる。加えて、次期 Debian 14（Forky）が 2027 年ごろになる可能性が報じられているように[20]、次の数世代を待つという発想自体が現実のロードマップと整合しやすい。したがって、2026 年時点で保守運用の基盤として判断するなら、2030 年代前半までを視野に入れる、という時間軸が合理的な結論になりやすい。
10. 保守的ユーザーのための現実的な移行戦略
保守的ユーザーにとって合理的なのは、全面移行でも全面拒否でもなく、「リスクを局所化しつつ学習する」ことである。Wayland は設計として安全性を高める方向に進んでおり[1]、ディストリビューションも採用を進めている[8][9][11]。一方で、ヘッドレスや遠隔運用のように、構成要素が増えて複雑化しやすい領域では、実装と運用がもう一段落ち着くまで待つ価値がある[15]。
10.1 メイン環境と検証環境を分ける
| 構成 | 狙い | 具体像 |
|---|---|---|
| メイン環境は枯れた基盤を維持 | 日々の作業と長期運用の不確実性を最小化する。 | 必要な間は Xorg を主軸に置き、Wayland は必須要件になった時点で移す。 |
| 検証環境で Wayland を育てる | 将来の移行コストを下げ、問題の種類を把握しておく。 | 別マシンや VM、あるいは別ユーザーで Wayland セッションを常用して癖を掴む。 |
| 運用機能は標準スタックで固める | アプリ個別の裏技ではなく、標準化された経路へ寄せる。 | 画面共有やリモートはポータル仕様と実装を前提に設計する[7]。 |
11. 結論：Wayland が「枯れた基盤」になるのはいつか
結論として、Wayland はすでに広く普及しており[8][9][11]、一般的なデスクトップ用途では「日常利用できる」段階に入っている。一方で、本稿で定義した「枯れた基盤」という意味では、互換層依存の縮小、周辺機能の一般解、障害時の解決可能性という三点が揃うまで待つのが、保守運用では合理的である。特に、リモートデスクトップやヘッドレス運用は、Wayland の安全な設計へ適合した新しい標準スタックが必要になりやすく[7][12][15]、そこが運用基盤としての「収束」を遅く見せる。
したがって、時間軸の見立ては一つの数字ではなく、用途に依存して二段階に分けるのが実用的である。日常のデスクトップ用途では「いま使える」が成立しやすいが、保守的な基盤用途では「運用が収束してから主力化する」という判断が自然になる。ディストリビューション採用が進み続ける限り[8][9]、基盤成熟も進むが、最終的に「枯れた」と感じられるのは、標準スタックが当たり前になり、切り分けと回避が型として共有された後である。
11.1 用途別に見た Wayland の成熟段階
| 用途 | 現在の成熟度（2026 年時点） | 基盤成熟の条件 | 成熟時期の目安 |
|---|---|---|---|
| 一般デスクトップ利用 | 日常利用が可能な実用段階に達している。 | 主要アプリケーションがネイティブ Wayland で安定動作すること。 | 2020 年代後半 |
| 開発用途 | 概ね利用可能だが環境依存の問題が残る。 | ツールキットやデバッグ手法が安定すること。 | 2028 年前後 |
| リモートデスクトップ運用 | 標準構成が定まりつつある過渡段階にある。 | PipeWire やポータルを含む標準スタックが一般化すること。 | 2030 年前後 |
| 保守的基盤用途 | X11 依存がまだ残る移行段階にある。 | Xwayland 依存が減少し障害対応手順が確立すること。 | 2030 年前後〜2030 年代前半 |
12. 補遺：運用で重要になる周辺スタックの一次情報
Wayland が「枯れた基盤」へ近づく過程で、現場の体験差を生みやすいのは、プロトコル本体よりも周辺スタックである。特に、画面共有・録画・リモート操作の多くは、ポータル（許可と仲介）と、映像・音声の配信基盤に依存するため、運用の観点では「このスタックの一次情報を押さえているか」がトラブル対応力を左右する。
ポータルの全体像は公式ドキュメントにまとまっており、アプリ開発者・デスクトップ開発者・ディストリビューション向けに概念と規約が整理されている[21]。また、文書アクセスの仲介は Documents ポータルとして仕様化され、アプリへ安全にファイルを渡す仕組みが説明されている[22]。
映像・音声の配信基盤としては PipeWire が中核になりやすく、PipeWire は「低遅延でオーディオとビデオを扱う」こと、そしてコンテナ化されたアプリとの相性を含むセキュリティモデルを重視することを公式サイトで説明している[23]。より詳細な設計と用語は PipeWire の公式ドキュメント（Overview）でも整理されている[24]。
加えて、参照コンポジター Weston のふるまいを追うことは、Wayland の「基準点」を理解するうえで有用であり、Weston の man ページは Weston を参照実装と位置づけ、複数のバックエンドを持つことを明記している[25]。設定ファイル weston.ini の探索順や意味も man ページで整理されている[26]。
12.1 保守運用で押さえるべき一次情報の地図
| 要素 | 役割 | 一次情報 |
|---|---|---|
| XDG Desktop Portal | サンドボックスやデスクトップ統合のために、ファイル選択や画面共有などを安全に仲介する枠組みである。 | 公式ドキュメントで概念と規約が整理されている[21]。 |
| Documents ポータル | 外部世界のファイルを制御された形でアプリへ渡すための仕様である。 | Documents ポータル仕様の説明がある[22]。 |
| PipeWire | オーディオとビデオの低遅延処理と、安全な入出力を担う基盤である。 | 公式サイトと公式ドキュメント（Overview）がある[23][24]。 |
| Weston | Wayland の参照実装として、ふるまいと基準点を提供する。 | Weston の man ページと weston.ini の man ページがある[25][26]。 |
参考文献
- Wayland. https://wayland.freedesktop.org/
- The Wayland Protocol (Documentation). https://wayland.freedesktop.org/docs/html/
- Xwayland(1) – Arch manual pages. https://man.archlinux.org/man/Xwayland.1.en
- Weston documentation. https://wayland.pages.freedesktop.org/weston/
- wlroots (swaywm/wlroots). https://github.com/swaywm/wlroots
- XDG Desktop Portal (GitHub). https://github.com/flatpak/xdg-desktop-portal
- Remote Desktop – XDG Desktop Portal documentation. https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html
- Fedora Project Wiki: Changes/WaylandByDefault. https://fedoraproject.org/wiki/Changes/WaylandByDefault
- Ubuntu Wiki: ArtfulAardvark/ReleaseNotes. https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes
- Debian Wiki: Wayland. https://wiki.debian.org/Wayland
- Debian Wiki: NewInBuster. https://wiki.debian.org/NewInBuster
- GNOME Remote Desktop (gnome-remote-desktop). https://gitlab.gnome.org/GNOME/gnome-remote-desktop
- Red Hat Documentation (RHEL 9): すべてのユーザーの Wayland を無効にする. https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/proc_disabling-wayland-for-all-users_assembly_overview-of-gnome-environments
- KDE Planet: Remote Desktop using the RDP protocol for Plasma Wayland (KRdp). https://planet.kde.org/arjen-hiemstra-2023-08-08-remote-desktop-using-the-rdp-protocol-for-plasma-wayland/
- Red Hat Documentation (RHEL 10): GNOME Remote Desktop を GDM と統合してヘッドレスサーバーのリモートログインを提供する. https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html-single/administering_rhel_by_using_the_gnome_desktop_environment/index
- Wayland Release News. https://wayland.freedesktop.org/releases.html
- Debian 13 “trixie” released. https://www.debian.org/News/2025/20250809
- Debian News. https://www.debian.org/News/
- Debian Releases. https://wiki.debian.org/DebianReleases
- Debian FAQ – Release Lifecycle. https://www.debian.org/doc/manuals/debian-faq/
- XDG Desktop Portal documentation (overview). https://flatpak.github.io/xdg-desktop-portal/docs/
- Documents – XDG Desktop Portal documentation. https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Documents.html
- PipeWire (official site). https://pipewire.org/
- PipeWire documentation: Overview. https://docs.pipewire.org/page_overview.html
- weston(1) – the reference Wayland server (Ubuntu manpages). https://manpages.ubuntu.com/manpages/noble/man1/weston.1.html
- weston.ini(5) – configuration file for Weston (Ubuntu manpages). https://manpages.ubuntu.com/manpages/noble/man5/weston.ini.5.html