メインコンテンツへスキップ

X11とWaylandを比較する。2026年、Waylandへ切り替えてX Window Systemを捨てるべきか

·
カテゴリー Linuxシステム FOSSをめぐる問題
タグ Wayland X Window Linux
目次

この記事では、IvonがLinuxシステムの「X Window System」と「Wayland」の発展状況を討論し、Waylandの長所と短所を整理して、Waylandへ切り替えるべきかどうかを判断できるようにする。最後には、最新Wayland技術を最も早く体験できるLinuxディストリビューションも添える。

物事は変化しつつある。Linuxコミュニティでは、X11を捨ててWaylandセッションへ切り替えるべきかがよく討論される。では、X11とは何か?Waylandとは何か?

X Window Systemは、あなたのLinuxコンピューター画面をどのように表示するかを決める一群のソフトウェアである。しかしこれは古すぎて問題が多く、現在はWaylandプロトコルを採用するソフトウェアが、この古いソフトウェアを現代的なコードで置き換えようとしている。ただしWaylandには問題も多いため、採用するLinuxディストリビューションが増えているにもかかわらず、十年以上発展してきた現在でも、X Window Systemを完全に置き換えることはできていない。

以下では、X11とWaylandの現状を探っていく。

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 Windowソフトウェアが登場した。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サーバーの「サーバー」が必ずリモートで実行されるなどと誰が言ったのか?Xサーバーがあなたのコンピューター上でローカル実行されているときも、クライアントサーバー構造の関係を維持している。プログラム間の転送は暗号化されておらず、他のプログラムに簡単に傍受される可能性がある。たとえばキーロガーだ。さらにクライアントとサーバー間の頻繁な転送は、グラフィック効率を悪化させ、画面ティアリングを引き起こす。

ティアリング問題については、多くのデスクトップ環境とGPUドライバーがなんとか回避しているが、Nvidiaはいまだに投げやりだ。ドライバーがオープンソースではないため、しょっちゅう問題が起きる。


X Window Systemの問題には、もっとよい解決策があるべきだ…そこでWaylandが生まれた。Waylandは2008年に登場し、かつてX11プロジェクトに参加していた開発者によって始められた。

WaylandはX Window Systemのクライアントサーバー構造を根本から変え、プログラムがグラフィックハードウェアをより効率的に利用できるようにする。Waylandそのものは通信プロトコル仕様であり、実際にウィンドウを描画するソフトウェアはWayland compositor(コンポジター)と呼ばれる。

つまり、Wayland開発者は通信プロトコルの仕様だけを規定し、コンポジターをどのように実装するかについては詳細に規定していない。彼らは"Weston"という参照実装を一つ出しただけである。

こちらがWaylandの原理図である。Xサーバーが消え、すべてがコンポジターによって担当され、通信プロセス全体が大きく簡略化されていることがわかる。ネットワーク透過性も削られた。

では「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を捨てる時が来たので、開発者は思い切って新しいものを作ったのだ。

しかしさまざまな問題により、執筆時点に至るまで、WaylandはまだXを完全に置き換えることができていない。WaylandとX.Orgの構造は互換ではなく、全体を壊して作り直すようなもので、プログラムを書き直す必要があるからだ。X.Orgでは簡単にできた多くの操作について、Waylandにはそもそも関連APIがなく、Waylandプロトコルの核心開発者が少しずつ改善する必要がある。

Waylandには問題が多いとはいえ、世界各地の開発者が非常に真剣にbugを修正している。各大Linuxディストリビューションも徐々にWaylandをデフォルトオプションにしつつある。

商業企業のRedHat、Canonical、SUSEはWaylandをデフォルトオプションとして強力に推進している。RedHatはすでにRHEL 10でX.Orgサポートを完全に削除し、ユーザーにWaylandデスクトップだけを使わせている。X11プログラムを動かすにはXWaylandを使う。

Ubuntu 26.04はデフォルトでWayland限定のデスクトップ環境を採用する。

多くの大企業がこのように動くことで、開発者が歩調を合わせ、できるだけ早くWaylandへ移行することが促されるはずだ。

2. なぜWaylandを使うのか?
#

Waylandの比較的明らかな利点は以下の通り:

  • GNOMEでもKDEでも、WaylandのアニメーションはX11より明らかにずっと滑らかに見える。
  • グラフィック性能がより良い。画面ティアリング問題を根本的に解決し、Nvidiaプロプライエタリドライバーのユーザーにも恩恵がある。
  • HiDPI画面の非整数スケーリング、異なる画面で異なる解像度を使うこと、HDR映像、VRR可変リフレッシュレート、色管理……など現代的なグラフィック機能をサポートする。
  • ブラウザーで二本指ズームをサポートする。
  • タッチジェスチャーのサポートがより良い。GNOMEとKDE Plasmaはタッチパッドジェスチャーでデスクトップを切り替えられ、FirefoxとGoogle Chromeは二本指ズームや左右スワイプで前のページに戻ることができる。これらはWaylandでしか使えない。
  • PipeWireとXDG Desktop Portal技術を活用し、スクリーンショット、画面録画、音声処理、画面共有、リモートデスクトップ、ファイル選択の経路を統一する。OBS Studioで画面録画でき、Rustdeskでリモートデスクトップ共有ができる。
  • text-input入力メソッドプロトコルを提供し、Fcitx5のような入力メソッドが各プログラム間で中国語を入力できるようにする。
  • システム安全性を強化し、キーロガーを根絶する。

現段階では、たとえWaylandが好きでなくても、ログイン画面(Display Manager)でいつでもX11セッションへ切り替えられる。両者は共存できる。

3. なぜWaylandを使わないのか?
#

Waylandの欠点を語り始めるときりがない。この記事は最初2024年に書いたものだが、2026年版へ改稿した後、以前触れた多くの問題が少しずつ解決されていることに気づいた!

過去、X11には共通のX.Org Serverがあり、各デスクトップは共通標準に従って機能を実装できた。Wayland時代になると、Waylandプロトコル自体が定義するものはごく一部で、残りはコンポジターによる実装に頼る。これにより、ユーザーが特定のデスクトップ環境へ縛られる問題が起きる。共通の解決策がないため、開発者にとってはかなり困る。たとえばウィンドウ位置を取得する機能はWaylandでは定義されておらず、GNOMEやKDE Plasmaが使うコンポジターがどのように実装するかを見る必要がある。これは挙動の不一致をもたらす。このとき開発者同士は、できるだけXDG Desktop Portalの標準を制定することで互換性を実現しようとするしかない。

たとえばグローバルショートカットの発火は、Wayland時代ではデスクトップ環境側の能動的なサポートが必要であり、X11のようにxdotoolで実現することはできない。また画面レイアウトを制御する設定も、デスクトップ環境による制御に頼る必要があり、xrandr一つで全部対応することはできない。

ブラウザーについて言えば、最新版FirefoxとChromiumはデフォルトでWaylandセッションを使用しており、ほとんど問題はない。しかしChromiumコアを使う一部のプログラム、たとえばElectronで書かれたものは、開発者がコアを更新しない場合、デフォルトでは今も旧来のXWaylandモードで動作する!そのため性能が振るわない。

さらにWayland下では、更新されない商用リモートデスクトップソフトウェアの一部に問題が出る。たとえばChrome Remote Desktopだ。Waylandに対応するにはTeamViewerやAnyDeskを使う必要がある。

Windowsプログラムを変換実行するWine(Steam Deck Protonの上流プロジェクト)は、最新10.0バージョンでネイティブWaylandドライバーを追加した。しかしSteamゲームでWaylandをサポートするものは少なく、多くのゲームはいまだにXWaylandで動いている。そのためWayland環境でゲームを遊ぶとグラフィックbugが出ることがある。これはグラフィックドライバーが「Explicit Sync」をサポートしなければ画面ちらつきを避けられない。最新版のNvidia、Intel、AMDドライバーはすでにサポートしているはずだ。

WaylandはHiDPI画面の問題を改善し、任意のスケーリング係数を指定できるようにした。しかしXWayland下で動くプログラムはWaylandデスクトップのスケーリングに追従しない。XWaylandプログラムを強制的にスケーリングするとぼやけてしまい、GNOMEもKDE Plasmaもこの問題をうまく処理する方法を持っていない。プログラム開発者ができるだけ早く純Wayland版を提供することを期待するしかない。

ここに挙げていない小さな問題もある。特定のプログラムを実行して初めてWayland非互換に遭遇し、X11へ戻さなければならないこともあるだろう。

4. Waylandへ切り替える方法
#

上で述べたように、Waylandは単一のソフトウェアではなく、各デスクトップ環境が個別に実装するものだ。

最大の考慮要素は、常にあなたのLinuxディストリビューションの更新速度と、デスクトップ環境のWayland対応度である。

自分がX11を使っているのかWaylandを使っているのかを知るには?端末を開き、以下のコマンドを入力すればわかる。

echo $XDG_SESSION_TYPE

X11とWaylandの間で切り替える場合、通常はシステムログイン画面(Display Manager)に選択肢が用意されている。

執筆時点での各デスクトップ環境のWayland対応状況:

  • GNOME 50:Linux界のデスクトップ兄貴分。GNOME 42以降はサポートが良好で、ほとんどbugはなくなった。ただしbugがないことは、X11の機能を完全に置き換えられることを意味しない。GNOME 50以後はX.Orgサポートを完全に削除し、Waylandだけが使える。
  • KDE Plasma 6.5:Waylandはおおむね安定しており、そう簡単にはクラッシュしないはずだ。KDE開発者はKDE Plasma 6.8でX11サポートを完全に削除する準備をしている。
  • XFCE 4.21:すでにWaylandをサポートしており、ユーザーがコンポジターを自由に選べる。自前のコンポジターXFWLをリリース予定。
  • Cinnamon 6.6.5:すでにWaylandをサポートしているが、すぐにX11を切り捨てることはない。
  • LXQT 2.3.0:すでに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更新修正を受け取るまで比較的長く待たなければならない。私個人の観察では、Debian 13とUbuntu 26.04に収録されているデスクトップ環境は、Wayland対応度が実際にはすでにかなり良い。

参考資料:Wayland開発進度を追跡する
#

関連記事


最後までお読みいただきありがとうございます。本サイトでは公開コメント欄を設けていません。私はソーシャルな反応やアクセス数を追い求めるためではなく、自分の考えを誠実に探求するために文章を書いています。記事を丁寧にお読みいただいたうえで、ご感想やご意見をお寄せいただければ幸いです。誤字・誤り・技術的な問題などを見つけた場合、またはフィードバックを共有したい場合は、Aboutページに記載しているメールアドレスまでお気軽にご連絡ください。