この記事ではIvonがLinuxシステムの「X Window System」と「Wayland」の発展状況を議論し、Waylandの長所と短所を検討して、あなたがWaylandへ切り替えるべきかどうかを決められるようにする。最後には最新のWayland技術を最速で体験できるLinuxディストリビューションも付けておく。
事態は変化しつつある。Linuxコミュニティでは、X11を捨ててWaylandセッションへ切り替えるべきかがよく議論される。では、X11とは何か？Waylandとは何か？
X Window Systemは、あなたのLinuxコンピューターの画面をどのように表示するかを決めるソフトウェア群である。しかしそれは古すぎて問題が多い。現在はWaylandプロトコルを採用したソフトウェアがあり、現代的なコードでこの古いソフトウェアを置き換えようとしている。ただしWaylandにも問題が山積みで、Linuxシステムで採用が増えているにもかかわらず、発展から10年経った今もX Window Systemは完全には置き換えられていない。以下でその理由を探る。
1. 変化の契機：X11とWaylandの比較#
X Window SystemとWaylandはいずれもLinuxの画面表示を担当するソフトウェア群である。両者の低層原理比較については、私の知識が浅いため恥をさらすのはやめておく。ネット上にはすでに多くの資料があり、文末の「関連読書」にも詳しく読める面白い記事を多く載せている。ここでは私個人の理解を簡単に述べる。
X Window System、略してXは、Linuxより早く生まれた。X Window Systemは1987年に登場し、グラフィカル環境の表示に使われた。当時はまだUnixの時代だった！今ではすでに30年以上の歴史がある。
なぜLinuxには「X Window System」をインストールしないと画面が出ないのか？それはLinuxカーネルには本当に画面表示のソフトウェアがないからだ。
Linuxユーザーが見るデスクトップ環境（たとえば GNOME、KDE Plasma、XFCE）は、画面を直接制御しているわけではなく、X Window Systemが提供するグラフィック表示機構の上に構築されている。X Window Systemは最下層のウィンドウ表示と入力イベントを担当し、デスクトップ環境はユーザーインターフェースと操作体験を担当する。
ここで、X Window Systemは各デスクトップ環境が従う低層の共通標準となった。
当初の設計者はXの通信プロトコル(protocol)標準だけを制定し、Xの実装方式(implementation)を詳しく規定しなかった。そのため各社のXウィンドウソフトウェアが登場した。2000年頃、X.org組織が開発したX.orgソフトウェアがXFree86を置き換え、徐々に公認の標準となり、APIなども彼らが決めた。X.orgはこうして各大デスクトップ環境に採用された。X.orgが採用したX通信プロトコルがX11版だったため、彼らが開発したXサーバーもX11と呼ばれる。
X Window Systemがサーバー(server)と呼ばれる理由は、複数のXクライアント(client)の同時接続を受け付けられるからだ。つまり「クライアントサーバー構造」であり、昔のメインフレーム時代の需要に応え、ネットワーク透過性(Network Transparency)を通じて通信する。原理は下図を参照。
ネットワーク透過性とは何か？Xサーバーを通じて、別のコンピューターのウィンドウをネットワーク経由で転送し、あなたのコンピューターに表示できる。これにより、多くの人が同時に同じホストへ接続して作業できるわけだ。
さらにX Window Systemは個人コンピューター上でもクライアントサーバー構造に従って通信する。各ソフトウェアのウィンドウは一つのXクライアントであり、あなたのコンピューター上のXサーバーと通信し、その結果画面を表示する。
デスクトップのウィンドウがどんな見た目になるべきかについて、X Window Systemのプロトコルは詳細に規定していない。これがデスクトップ環境開発者に大きな操作空間を与えた。開発者はcompositorを通じてウィンドウの外観を決められる。閉じるボタンの位置、タイトルバー、アニメーション効果なども含まれる。だからCompizのようなクールな3Dアニメーションデスクトップが登場した。
クライアントサーバー構造はX Window System設計の長所でもあり短所でもある。長所はリモート作業が非常に便利で、柔軟性が大きいことだ。
短所は、この方式では安全性が高くないことだ。誰が「サーバー」は必ずリモートで実行されると言った？Xサーバーはあなたのコンピューター上でもクライアントサーバー構造の関係を維持しており、プログラム間の転送は暗号化されていない。他のプログラムに簡単に傍受され、たとえばキーロガーに使われうる。しかもクライアントとサーバー間の頻繁な転送はグラフィック効率の悪化を招き、画面 tearing を引き起こす。
tearing問題は大部分のデスクトップ環境とGPUドライバーが回避策を講じているが、Nvidiaはなお放置している。彼らのドライバーはオープンソースではなく、しょっちゅう問題を起こすからだ。
X Window Systemの問題には、もっとよい解決策があるべきだ…そこでWaylandが登場した。Waylandは2008年に現れ、かつてX11プロジェクトに参加していた開発者によって始められた。
WaylandはX Window Systemのクライアントサーバー構造を徹底的に変え、プログラムがグラフィックハードウェアをより効率的に利用できるようにする。Wayland自体は通信プロトコル仕様であり、実際にウィンドウを描画するソフトウェアはWayland compositorと呼ばれる。
つまりWayland開発者は通信プロトコルの仕様だけを規定し、compositorをどう実装するかについて詳細には規定していない。彼らは"Weston"という参考実装を一つ出しただけである。
こちらがWaylandの原理図だ。Xサーバーが消え、すべてがcompositorによって担当され、通信過程全体がかなり簡略化され、ネットワーク透過性も切り落とされていることが分かる。
では「X」Waylandとは何なのか？大量のXサーバー下の古いプログラムが使えなくなることを防ぐため、Wayland開発者はXWaylandという過渡的方案を提出した。Wayland下でXサーバーを一つ走らせ、それらの古いプログラムがWayland下で動作できるようにするものだ。とはいえ、XWaylandは古いXプログラムとの100%互換性を保証しない。一部の奇妙なAPIは使えない可能性があり、開発者はやはりプログラムを書き直し、ネイティブWaylandプログラムへ修正するほうがよい。
Waylandが出たなら、X11はどうなるのか？X11はすでに基本的に開発停止していることを知っておくべきだ。Linux世界の多くの新機能はWayland側へ発展を移しており、たとえばHDRコンテンツ対応のコードがそうだ。
Phoronixの報道によれば、近年X11の開発速度は史上最低に達し、基本的に動いていない。
なぜか知っているか？全世界でX Window Systemの全コードを読める人は三人しかいないらしい。あなたも知っている、私も知っている、しかし独眼竜は知らない。独眼竜ですら知らないものなら、開発者も古びたXサーバーのコードをどう修正すればよいか手の付けようがない。多くのXサーバーの設計は現代では時代の需要に合わない。Xを捨てる時が来たので、開発者はいっそ新しいものを作った。
しかしさまざまな問題により、執筆時点の2024年になってもWaylandはまだXを置き換えられていない。
2. なぜWaylandを使うのか？#
Waylandの比較的明らかな長所は以下の通り：
- GNOMEでもKDEでも、WaylandのアニメーションはX11よりずっと滑らかに見える。
- グラフィック性能がよりよい。画面tearing問題を徹底的に解決し、Nvidiaプロプライエタリドライバーのユーザーにも恩恵がある。
- HiDPI画面の非整数スケーリング、異なる画面で異なる解像度、HDR映像、VRR可変リフレッシュレート……など現代的なグラフィック機能をサポートする。
- ブラウザが二本指ズームをサポートする。
- タッチジェスチャー対応がよりよい。GNOMEとKDE Plasmaではタッチパッドジェスチャーでデスクトップを切り替えられ、FirefoxとGoogle Chromeでは二本指ズームや左右スワイプで前のページへ戻ることができる。これらはWaylandでのみ使える。
- PipeWireとXDG Desktop Portal技術を活用し、スクリーンショット、画面録画、音声処理、画面共有、リモートデスクトップ、ファイル選択の経路を統一する。
- システム安全性を強化し、キーロガープログラムを根絶する。
現段階では、Waylandが好きでなくても、ログイン画面(Display Manager)でいつでもX11セッションへ切り替えられ、両者は共存できる。
3. なぜWaylandを使わないのか？#
Waylandの短所を語り始めると終わらない。
Linuxコミュニティでこの画像を貼ると殴られるらしい。
最も乱暴な理由：Waylandにはキラーアプリケーションが欠けており、「Waylandでなければならない」プログラムがほぼない。
probonopd（AppImage形式の提唱者）が書いたこの記事は非常によくまとまっており、Waylandでまだ解決されていない問題を一つ一つ列挙し、リアルタイムで更新している。毎日その下で誰かが喧嘩しているXD
最初この文章のタイトルは"Boycott Wayland. It breaks everything.“だったと記憶している。最初は人々にWaylandをボイコットしろと言っていたが、後にWayland採用前に必ず三思せよへ変わった。
より具体的なWayland問題を見るなら、KDE開発者が整理した一覧を参照してほしい：Plasma/Wayland Known Significant Issues
なぜWaylandの争議はこれほど大きいのか？それはユーザーインターフェースと密接に関わるからだ。Waylandが引き起こす問題は肉眼で見えるものであり、ユーザーがLinuxシステムを操作する体験に大きく影響する。上のprobonopdリンク内で語られていることは、あなたがLinuxの日常ユーザーなら必ず遭遇する。
より実際的な問題を語るなら、ブラウザから始めよう。Firefox最新版はデフォルトでWaylandセッションを使い、ほぼ問題がなくなった。しかしChromium系ブラウザ（Chrome、Brave、Edge、Vivaldi、Opera）は、現時点のv131版でもWayland対応がまだよくない。ChromiumはWayland下でもデフォルトでXWaylandモードで動いている！その結果、性能が振るわない。
起動パラメータを強制的に追加し、chromium --ozone-platform-hint=autoコマンドで純Waylandモードへ入ると、何が起きると思う？Fcitx5で中国語入力ができなくなる！Fcitx5 Wikiの説明によれば、さらに--gtk-version=4パラメータを追加して起動すれば正常になるらしい。うん、問題は私が追加してもまだ駄目だったことだ。実は--enable-wayland-imeパラメータもあるのだ！たとえChromiumが純Waylandモードをきちんと設定してくれたとしても、なんとVA-APIハードウェアアクセラレーションに対応していない？この機能は2024年1月になってようやく直った。
善意の注意：Electronで書かれた多くのプログラムもChromiumの影響を受ける。Chromiumのbugは同じくElectronプログラムにも反映される。たとえばVisual Studio Codeだ。開発者がElectronコアバージョンを更新しないなら、この問題はさらに深刻になるだけだ。
別のプログラムを例に取ると、OBS StudioはWayland下でのウィンドウキャプチャに時々問題があり、ポップアップでウィンドウを選ぶとき真っ黒になる。何らかのworkaroundを使わないと正常に作業できないかもしれない。GNOMEでもKDEでも、Waylandを使う限りこの種の問題は時々発生する。しかしX11セッションではほとんどこの問題は起きない。
さらに、Wayland下では多くのリモートデスクトップソフトウェアが問題を起こす。WayVNCとWayPipeは登場しているものの性能はあまりよくなく、RustDeskとSunshineだけがWayland対応を追加している。
Windowsプログラムを変換するWine（Steam Deck Protonの上流プロジェクト）は、今年の最新9.0版でようやく実験的なWaylandドライバーを追加した。今でもSteamでは、ネイティブゲームでWaylandに対応するものは少なく、多くのゲームは依然としてXWaylandで動いている。そのためWayland環境でゲームをすると性能問題が出る。
WaylandはHiDPI画面の問題を改善し、任意のスケーリング係数を指定できる。しかし旧版XWaylandプログラムはそれに合わせてスケーリングされない。XWaylandプログラムを強制的にスケーリングすればぼやける。GNOMEもKDEも、この問題を処理するよい方法を持っていない。
KDE 6.0はWayland対応に重大な改善があると称しているが、KDE自身のプログラムでさえ、今でもGwenviewウィンドウが超巨大になる、マウスが超巨大になる、Kateが意味不明なフローティングウィンドウを出すなどの奇妙なbugが出る。KDEフォントビューアは今でもWaylandに対応していない。
X11下で長年使われてきたカラーマネジメントシステムも、Waylandではまだ実現されておらず、KDE 6になって初めてある。
ああもう。X11デスクトップは開封即用だが、Waylandデスクトップは問題だらけである。
もしプログラムがWayland下で正常に使えるようになるために、ユーザーが手動で大量の作業をしなければならないなら、それはWaylandが根本的にまだ準備できていないということだろう！
ああ、これはデスクトップ開発者のミスだと押しつけてもいいだろう。彼らがcompositorを書ききれていないのが悪いのだから。
そう！標準の不一致こそWayland最大の問題の一つだ！
この図はうまく説明している：
Waylandは実はX11の直接的な代替品ではなく、ほぼ別物になっている！多くの旧来のプロトコルにはWayland上で対応するものがなく、開発者が一つずつ実現するのを待たなければならない。
ソフトウェア開発者にとっても、Waylandの変化に適応しなければならない。もっとはっきり言えば、プログラム全体を書き直す必要がある。
過去、皆が使っていたのはX.orgのX Window System実装であり、従うべき統一APIがあった。各社はそれに基づいてウィンドウcompositorを開発した。しかしWaylandへ入るとXサーバーはなくなり、各社は自分でWayland compositorを作る方法を考えなければならない。
Linux世界には中央集権的な開発というものがない。これが各社標準不一致の状況を引き起こした。前に述べたように、Wayland開発者は通信プロトコルだけを規定し、compositorをどう実装するかについては詳細に規定していない。今やWayland compositorは少なくとも10種類以上あるだろう。GNOMEのMutterにはMutterの実装があり、KDEのKwinにはkwinの実装があり、Hyprlandにも自分の実装がある。
オープンソース組織同士は標準を調整し、GTKやQTのような有名ライブラリもWayland対応に追随し、システム下層のものを抽象化して開発者の負担を減らしている。しかしどうしても統一できない標準がある。
Fcitx5の開発者はBlogでこの問題を愚痴ったことがある。彼は各大デスクトップ環境をサポートするため、4種類の入力メソッドプロトコルを実装し、さらにはKDEへPRを提出して彼らのcompositorを改善した。
プログラムがXWaylandモードで動いていても、100%完璧な解決策ではない。それはアプリケーション性能低下を招き、スケーリングもぼやける。中にはクリップボード共有やドラッグ＆ドロップ貼り付けすらできないものもある。しかしWayland開発が不完全なため、多くの開発者はなおこの折衷的な解決方法を選び、ネイティブWaylandプログラムを開発せず、XWaylandで放置している。
以上をまとめると、もしWaylandの問題を本当に細かく掘り下げれば、最終的にあなたは半分Linux開発者になる。
才能があるなら、wlrootsというライブラリを見つけ、自分のWayland compositorを書き始めるかもしれない！Sway、Hyprland、river、Wayfireなどの開発者たちの列に加わるのだ。
4. しかし、Waylandは依然として未来の趨勢#
事態は変化しつつある。WaylandはSystemd、PulseAudio、PipeWire、Avahiと同じで、出たばかりの頃は罵声だらけだったが、彼らは最後には徐々に大衆に受け入れられた。
なぜか？上で語ったWaylandの短所、bug、欠陥は、未来にゆっくり解決されるからだ。この記事で触れたWaylandの問題は、数か月後には消えているかもしれない。
Kansasの歌があなたに教えてくれている：CARRY ON MY WAYLAND SON!
Waylandは問題だらけとはいえ、世界各地の開発者が非常に真剣にbugを修正している。各大Linuxディストリビューションも徐々にWaylandをデフォルト選択肢にしている。
商業会社RedHat、Canonical、SUSEはWaylandをデフォルト選択肢として強く推進しており、RedHatは RHEL 10でX.orgを完全に削除する準備さえしている。
ValveとAMDは協力してSteam Deck上のWaylandにHDRを対応させた。ドライバーを死んでもオープンソースにしないNvidiaでさえ、Wayland対応を徐々に改善しており、さらに多くの新特性が進行中である。
今後数年で、GNOMEはX11のログイン選択肢を徹底的に削除し、純Wayland環境になる可能性がある。連動してGTKも正式にX11サポートを放棄するだろう。ただし、ここで私が語っているのはローリングリリースのスケジュールであり、Ubuntu LTSやDebian Stableのような安定更新のディストリビューションは、純Wayland環境に入るまでさらに時間がかかるかもしれない。
X11が完全に死ぬには何年かかるのか？私はさらに十年待つと予想する。Debian StableとUbuntu LTSの「デフォルト」もWaylandになって初めて、本当に成熟したと言える。現在Ubuntu 24.04のデフォルトはなおX11セッションである。
5. Waylandへ切り替えるには？#
上述の通り、Waylandは単一のソフトウェアではなく、デスクトップ環境が個別に実装するものだ。
最大の考慮要因は、常にあなたのLinuxディストリビューションの更新速度、そしてデスクトップ環境のWayland対応度である。
自分がX11を使っているのかWaylandを使っているのかをどう知るか？端末を開き、以下のコマンドを入力すれば多少分かる。
echo $XDG_SESSION_TYPEX11とWaylandの間で切り替えたいなら、通常システムのログイン画面(Display Manager)に選択肢がある。
執筆時点の各デスクトップ環境のWayland対応状況：
- GNOME 48：Linux界のデスクトップの兄貴分。GNOME 42以後は対応が良好で、ほぼbugがない。ただしbugがないことは、X11の機能を完全に置き換えられることを意味しない。
- KDE Plasma 6.4：どんどん良くなっているが、問題はまだ多い。KDE 5.27以前のバージョンについては、まあ、戒慎恐懼。KDEは最初に5.4版でWaylandに対応したとはいえ、私はまだあまり使う勇気がない。画面崩れ、タスクバークラッシュ、何でも来る。
- XFCE 4.20：すでにWaylandを初歩的にサポートしている。
- Cinnamon 6.0：すでにWaylandを初歩的にサポートしている。
- LXQT 1.4：2024年にWayland対応予定を発表した。
- i3wm、dwmなどのタイル型ウィンドウマネージャー：移植できない。Sway、Hyprlandで置き換えられる。この種のタイル型ウィンドウマネージャーを使う高手なら、私が言わなくても自分で適不適を判断できるはずだ。
Wayland環境へ切り替えたいなら、まず「GNOME」デスクトップ環境を搭載したLinuxディストリビューションを試すとよい。GNOMEはLinuxデスクトップ環境の兄貴分であり、Wayland対応度が最良だ。
Linuxディストリビューション部分については、Wayland更新とバグ修正を早く受け取りたいなら、ローリングリリース（Arch Linux、Fedora、openSUSE Tumbleweed、Debian Sid、Gentoo）ユーザーのほうが有利で、安定リリース（Debian Stable、Ubuntu LTS、openSUSE Leap、Rocky Linux）ユーザーはより長く待つ必要がある。
関連読書：Wayland開発進捗を追跡する#
- WaylandのFreeDesktop.org公式ページ：https://wayland.freedesktop.org
- Wayland環境でまだ解決されていない問題：Think twice about Wayland. It breaks everything!
- 私たちはもうWaylandへ移行できるのか：Are we Wayland yet?
- KDE開発者が書いた週記： Does Wayland really break everything?
- 揮棒成功が書いた記事。X Window Systemの原理を生き生きと解説している：【心得】Linux 出專欄啦！ （14）:桌面環境系列=〉x11 和 wayland ，談技術債與財源問題（厲害吧！！）
- HTML5でX11とは何かを理解させる：Explanations - X Window System Basics
