- WaylandはX11の後継グラフィックスタックとして2008年に始まったが、筆者は18年間、自分のシステムでまともに使えなかったと評価している
- 2025年時点でnVidiaドライバのGBMおよびexplicit sync対応により基本的な起動は可能になったものの、依然として8KモニタのTILE未対応などにより完全移行は難しい
- Sway 1.11とwlroots 0.19.0で主要な技術的進展があったが、入力遅延・グラフィックのグリッチ・Xwaylandのスケーリング問題など実用上の障害が多数存在する
- 主要アプリケーションであるChromeとEmacsは、依然として性能低下、レンダリング差異、ハードウェアアクセラレーションの不安定さといった問題を抱えている
- 全体としてWaylandは「ようやく実用が視野に入ってきた」が、日常業務用途では依然としてX11/i3の組み合わせの方が安定しているという結論
Waylandの歴史的背景
- Waylandは2008年に始まったXサーバ（X11、Xorg）の後継プロジェクトで、筆者は2009年にX11向けタイル型ウィンドウマネージャi3を開発した
- 初期にはWestonデモコンポジタしか動かせず、2014年にGNOME、その後KDEがWayland対応を開始した
- Firefox、Chrome、Emacsなどの主要アプリケーションは、実験的フラグを通してのみWaylandを利用できた
- nVidia GPUは長年Wayland上で動作しなかったりグラフィックエラーを起こしたりし、8Kモニタとの互換性問題も続いていた
- 最近ではFedora、RHEL、Asahi Linuxなど主要ディストリビューションがWaylandを標準または唯一のデスクトップスタックとして採用し、移行圧力が高まっている
Wayland実行環境の構成
- テストシステムではnVidia RTX 4070 Ti（ラップトップPC）とRTX 3060 Ti（メインPC）を使用
- nVidiaドライバ 495（2021）からGBM対応が追加され、explicit sync機能がSway 1.11（2025）とwlroots 0.19.0で実装された
- しかし8K Dell UP3218KモニタのTILE属性未対応により、Swayでは画面が2つに分かれて表示される
EBADBEEFのパッチとClaude Codeの分析を通じてSRC_X DRM属性バグを発見し、回避パッチで全画面表示に成功
- GNOMEはTILEをサポートするが、画面中央で激しいティアリングが発生する
- NixOS 25.11環境でGDM、GNOME、Swayを並行して設定し、
foot、fuzzel、wayland-utilsなどWayland専用ツールを追加した
実験結果: Sway環境
- Swayはi3設定とほとんど互換性があり、筆者はNEOキーボードレイアウトと入力・出力設定を調整した
- 主な問題点:
- マウスポインタの遅延と滑らかでない動き（nVidiaのハードウェアカーソル未対応が原因と推定）
- Xwaylandアプリのスケーリング不可により、ぼやける、または二重に拡大表示される
- 一部ショートカットが**二重実行（ghost key press）**される現象
- GTKアプリは、初期フォントサイズが大きすぎる問題を
gsettings resetで解決
- GTK3はdconf設定のみ使用するため、レンダリングを一致させるには
font-nameをdconfで指定する必要がある
- swaylockはi3lockと異なり、終了時に「赤い画面」状態になり、
SIGUSR1でしか解除できない
- i3 IPCベースの自動化ツールは、ソケットパスの違い、プロセスの残留、レイアウト復元未対応などにより部分的な互換にとどまる
主要アプリケーションのテスト
- footターミナルは軽量だが、一部の色の違い、Ctrl+Enterの処理、URL選択、
screenの色問題などが見つかった
- Emacsは標準版がXwayland上で動作するためぼやけて表示され、
pgtk版には入力遅延と文字間隔の差異がある
- ChromeはGPUプロセスのクラッシュによりハードウェアアクセラレーションが停止し、ウィンドウ復元時に以前のワークスペース情報を保持しない
- 画面共有は
xdg-desktop-portal-wlrを通じて可能だが、ウィンドウ単位の共有未対応および低解像度での転送という問題がある
- 出力スケーリング有効時にウィンドウ内容が瞬間的にずれたりぼやけたりするグリッチが発生する
- dunst通知と**rofi（2.0.0以上）**は正常に動作し、grimスクリーンショットツールはウィンドウ選択機能が使いにくい
結論: 2026年のWayland利用可能性
- Wayland/Swayセッションは初めて実用レベルに近づいたが、依然として多くの欠陥が存在する
- X11/i3環境は遅延763μsレベルの低い入力遅延と完璧な安定性を提供する
- Waylandへ移行するとグラフィックグリッチ、入力遅延、主要アプリの性能低下が発生する
- 日常利用のために必要な条件:
- Swayの二重キー入力および切り替えグリッチの解消
- Chromeのハードウェアアクセラレーション安定化とウィンドウ復元対応
- **Emacs（pgtk）**の入力遅延とレンダリング改善
- 結論として、Waylandはまだ日常業務用としては準備が整っておらず、筆者はX11/i3を使い続ける予定だ
1件のコメント
Hacker Newsの意見
Xorgは1つの堅牢な基盤の上にデスクトップが載る構造だったが、Waylandでは各デスクトップが車輪の再発明をしているようなものだ
Westonは参考用としては良いが、日常利用には不向きだ
すべてのデスクトップが共通して使える標準ライブラリが必要だと思う。wlrootsがその役割を狙っているが、GNOMEやKDEがすぐに移行しそうには見えない
xdg-desktop-portal-wlrを、Hyprlandならxdg-desktop-portal-hyprlandを使う必要がある。Waylandの構造自体は公式アーキテクチャ文書のように理論上は良さそうに見えるが、実際にはプロトコルレベルで欠けている機能が多い
今Waylandを置き換えようとする試みは、結局すでに成熟した部分を作り直す無駄になりかねない
おそらくsystemdのようにディストリビューションが強制的にデフォルトへ切り替える頃になって、ようやく本格的な採用が進むのだと思う
GNOMEとKDEの立場では、X11を継続保守する負担を減らすためにWaylandへ移行したいというのが大きい。
今年は「欠点がないと言える水準」まで持っていくのが目標だと思う
すでにArchとUbuntuのGNOME 49はXorgをデフォルトから外しており、KDEもまもなく追随する予定だ。Xorgの時代は終わりつつある
そのためEGLStreamsというベンダー中立の代替案を提示した。
むしろfreedesktop側がNvidiaドライバーを動かせる構造を提供していなかったのが問題だった
もちろんNvidiaではない単純なハードウェアという条件もあるだろうが、Waylandがきちんと動作しうる点は強調したい
ただし、ウィンドウ位置の制御や他アプリの探索といった機能はGnome Shell Extensionで回避しなければならない
ただしAMDハードウェアだからかもしれない。人生はNvidiaの問題で浪費するには短すぎる
マルチ出力スケーリング対応のためにWaylandへ移ったが、その後また戻ったこともある
Waylandのおかげで解決されて大きな改善だ。ただ、すべてのディストリビューションがWaylandをデフォルトにしているわけではないのでUbuntuを選んだ。
Snap版Firefoxがハードウェアアクセラレーションを使わないので少し不便だった
MacOSは「1440pのように見せる」設定でも完璧で、Windowsは少しぼやける。
LinuxではX11は遅く、Waylandもまだ性能遅延がある
完璧に動くこのスタックをSwayに置き換えるのは得るものより失うものが大きい。
Michaelが試して文書化したのはすごいと思う
Waylandの最大の問題は、さまざまなWMプロジェクトが人手不足で移行できていないことだ。
XWaylandで回避はできるが、すでに完璧に動いている環境にわざわざレイヤーを追加したくない
またWaybackは、X11デスクトップ全体をWayland上で動かすプロジェクトだ
4Kモニター、単一画面への切り替え、fractional scalingのすべてに問題がない。
古いChromebookでも画面のティアリングがなくなり、滑らかに動く。
まだ欠点は感じておらず、むしろ「間違っている」と言われることだけが唯一の欠点だ
今後もXorgとOpenboxを使うつもりだ
結局、Waylandが唯一積極的に保守される選択肢になっていくだろう