2026年にWaylandを使い始めることはできますか？

2026年1月4日原文(michael.stapelberg.ch)

概要

WaylandはLinuxの次世代グラフィックススタックとして注目されているが、nVidia環境や8Kモニター対応などに課題が残る現状。 2025年時点でNixOS上でWayland/Swayを本格的にテストした経験をもとに、移行時の問題点とその対処法を解説。 nVidiaドライバーやモニターのTILE対応、Swayの設定変更など、実運用で直面した具体的な障害点をまとめる。 Wayland移行の現状と課題、そして一部解決策を提示。今後の改善ポイントと期待されるアップデートも紹介。

Wayland移行の現状と課題

Wayland は X11（Xorg） の後継としてLinuxのグラフィックススタックを担うプロジェクト
Waylandプロジェクト は2008年に開始、しかし長年にわたり多くのPC環境で安定動作しなかった実情
GNOME は2014年頃からWaylandをサポートし始め、 KDE も数年後に追随
主要アプリ（ Firefox, Chrome, Emacs 等）はWayland対応が遅れ、実験的なフラグや環境変数での対応が主流
nVidia GPU は8Kモニター対応のため必須だが、Waylandでの安定動作やドライバー対応が長らく課題

ハードウェア構成とnVidiaドライバーの現状

テスト環境は Dell 8K 32インチモニター（7680x4320） ＋ nVidia GeForce RTX 4070 Ti/3060 Ti
nVidiaドライバー は長年Wayland未対応だったが、2021年末の ドライバー495 で GBM（Generic Buffer Manager） サポート追加
しかし、 グラフィックの乱れやアーティファクト が発生し、実用には程遠い状況
explicit sync 対応が必須で、 Sway 1.11 や wlroots 0.19.0 で初めて本格的に対応

8KモニターのTILEサポート問題

Dell UP3218Kモニター は DisplayPort 1.4 x2のMST＋TILE 必須
X11 では問題なく動作していたが、 Sway ではモニターが2台として認識される不具合
wlroots の TILEプロパティ未対応 （issue #1580, 2019年）が原因
2023年に EBADBEEF 氏がTILE対応のパッチをドラフト提出、だが片側が黒画面のまま
Claude Code （Opus 4.5）を活用し、バグ特定と暫定ワークアラウンド（画面右半分のバッファコピー）で初めて8K Swayが実用化
GNOME は一見8K表示可能だが、 タイル更新の同期ズレ で画面中央に激しいティアリング発生

NixOSによるWayland/Sway導入手順

NixOS の宣言的設定でWayland/Swayセッションの導入が容易
設定例（configuration.nix抜粋）：
- GDMディスプレイマネージャ 有効化
- GNOME と Sway を同時に利用可能
- Wayland専用ツール （foot, wtype, fuzzel, wayland-utils, gammastep等）をsystemPackagesに追加
設定変更後は X11セッションが強制終了 するため、念のため再起動を推奨

Sway設定変更と運用課題

i3 から Sway への移行は基本的にスムーズ、設定ファイルの互換性も高い
キーバインドや入力デバイス設定を NEOキーボード配列 向けに変更
ターミナルエミュレータ や アプリランチャ、 ワークスペース初期化 など独自設定を反映
入力デバイス（libinput） の細かな設定がX11と同等にできず、マウスカーソルの遅延や滑らかさに違和感
Sway でのモニター設定や通知システム（dunstctl）もカスタマイズ

実際の運用で発生した問題点

Waylandセッション で一日業務を試みたが、ほとんどの時間は不具合対応に費やされた
Sway 特有の問題や、X11時代の設定とのギャップが顕在化
マウス挙動の違和感、一部アプリのWayland非対応、タイルディスプレイの同期問題などが障壁

今後の展望と期待

nVidia や wlroots のバグ修正、 TILE対応 の本格実装が待たれる状況
GNOME/mutter のティアリング対策（merge request !4822）に期待
Wayland は今後も進化が続くが、 一部ハードウェア・ユースケース では依然としてX11の方が安定
NixOS のような環境ではテストやロールバックが容易なため、新機能検証には最適

このように、Wayland移行は着実に進歩しているものの、特定のハードウェアや高解像度環境では依然として課題が残る。今後のアップデートとコミュニティの対応に注目したい。

Hackerたちの意見

大きな問題は、Waylandがプロトコルであって実装ではないことだね。GnomeやKDE、wlrootsみたいに競合する実装がたくさんあるから、どれか一つで問題があっても、他では出ないこともあるんだ。リファレンスコンポジタのWestonは、日常使いにはあまり向いてないし。Xorgはしっかりした基盤があって、その上にデスクトップが実装されているけど、Waylandでは各デスクトップがゼロから作り直している感じで、グラフィックドライバーの癖に対処しなきゃいけないのが大変だと思う。Waylandのアーキテクチャには大きな問題があると思うな。全てのデスクトップが使える標準ライブラリが必要だよ。wlrootsがそれを目指しているけど、GnomeやKDEがすぐに移行するとは思えないな。

└

X.orgは適切な抽象化レベルを選んだと思う（実装は書き直しが必要かもしれないけど）。WMは生の入力を扱ったり、ドライバーとアプリの間で出力のプロキシをする必要はないはずだよ（必要があればそうすることもできるけど、ほとんどのユースケースで無駄な抽象化層を追加する理由はないからね）。それが複雑さや電力使用にも影響してると思う。Waylandは基本的にX11からの教訓を学べていないね。

└

あなたが一つのアプリで抱えている問題が、別のアプリでは現れないかもしれない。どちらもそれぞれのポータル実装やコンポジタを持っていて、それぞれに問題やサービス仕様の実装があるからね。KDEにはxdg-desktop-portal-kdeがあって、GNOMEにはxdg-desktop-portal-gnomeがある。さらに、それぞれ（まだ）独自のディスプレイサーバーも持っている。KDEはKWin、GNOMEはMutterを使ってる。 > 参照コンポジタのWestonは、日常使いにはあまり適していない。Westonはおそらく、キオスクモードでの実行とコンポジタの構築方法を示すためのものとしては良いだろう。だから、KDEやGNOMEを使っていないなら、少なくともxdg-desktop-portalを使うべきだよ。でも、これはバニラコンポジタ（フリーデスクトップのデスクトッププロトコルの実装なし）で、スクリーンショットや画面共有のようなことには対応していない。Hyprland以外のwlrootsベースのコンポジタを使っているなら、xdg-desktop-portal-wlrを使うべきで、これはorg.freedesktop.impl.portal.Screenshotやorg.freedesktop.impl.portal.ScreenCastのデスクトッププロトコルを実装している。Hyprlandを使っているなら、そのフォークであるxdg-desktop-portal-hyprlandを使うべきで、ファイル選択機能も内蔵されている。さらに、GTK（「GNOME」）やQT（「KDE」）のデスクトッププロトコルの実装を得るために、それぞれxdg-desktop-portal-gtkやxdg-desktop-portal-kdeを使うべきだよ。そして、xdg-desktop-portal-gnomeではなくxdg-desktop-portal-gtkを使うべきだ。なぜなら、xdg-desktop-portal-gnomeは他のアプリと共有するのが本当に嫌だから。 > Waylandでは各デスクトップが車輪を再発明している。これはあまり正しくない。前に言ったように、バックグラウンドでDE特有のディスプレイサーバーが動いているから（X11用のMutterやKWin-X11のように）、各コンポジタのグラフィックスはカーネルのグラフィックスドライバーによって直接駆動されている（KMS/DRMを通じて）。実際、理論上はアーキテクチャは本当に良さそうに見える：https://wayland.freedesktop.org/architecture.html。ただ、実際にはプロトコルレベルでかなり大きな機能が欠けているけど、フリーデスクトップの貢献者やGNOME、KDEのチームは最終的にはそこにたどり着くだろう。

└

俺はそれを日常的に使ってる。Swayを長いこと使ってて、ちょっとHyprlandを試して、今はniriを日常的に使ってる。Swayとniriはwlrootsベースだけど、Hyprlandはwlrootsプロトコルの拡張を待ちたくなくて独自に開発したみたい。時々、画面共有するためにGnomeに切り替えなきゃいけない。2026年になっても、wlrootsベースのものを使うとランダムな挙動の問題がたくさん出ると思う。Wineアプリは複数のディスプレイを使うとポインタの位置がランダムにおかしくなることがあるし、クラッシュやランダムなアプリでの動画共有の問題、10ビットの問題もある。2027年にはやっと解決するかも。でも、この20年の開発が4つ以上の実装に終わるのはもったいない気がする。

└

ポストXのコンポジタの本当の問題は、Waylandの開発者たちがコンポジタの開発者がディスプレイに特化した作業グループ（つまりWayland）の上に、入力プロトコルやウィンドウ管理プロトコルなどの追加の作業グループを開発するだろうと仮定していたことだと思う。Waylandは多くのプロトコルの一つであるべきで、もしWaylandに問題があっても、その範囲は小さくて簡単に置き換えられるという考えだった。今の段階でWaylandの代替を考えている人たちは、主にそれが気に入らないからだと思うけど、成熟した部分を再発明する時間を無駄にするだけで、残りの問題を解決する方法を考えるべきだよ。Waylandの開発者たちの理念についても誤解がある。彼らはWaylandをディスプレイ専用にしたいと思っているけど、だからといって入力プロトコルやウィンドウプロトコルに反対しているわけではない。ただ、すべてをWaylandの傘下にしたくないだけなんだよね、systemdみたいに。

└

X11の頃は、主要なデスクトップ環境ごとに独自のコンポジティング実装があったから、「簡単」だったことがより標準化されて、「難しい」ことはそのままだった。

へぇ、ほぼ同じ環境使ってるんだね。i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotoolで、ブラウザの選択（俺はFirefox）とターミナルマルチプレクサを使ってないくらいしか違いがないよ。>「だから、俺の視点からすると、この既存の完璧に動いてるスタックからSwayに切り替えるのはデメリットしかないよ。」マイケルが挑戦してるのはすごいと思うけど、今は自分の環境がちゃんと動いてる限り、新しいものを試す気にはなれないな。

└

マイケルに感謝。実際の問題を徹底的に文書化するために時間をかけてくれたことにも感謝。

まだWaylandを使いたい理由がわからないよ。メリットがコストを上回る感じがしないし、xorgは信頼できるからね。デスクトップグラフィックスの問題を解決するためのLinuxの記事やフォーラムの投稿は、「Waylandを使ってるなら、xorgに戻れ、そうすれば問題が解決するかも。」って始まることが多いし。動いてるものを「モダン」だからって新しいものに置き換える必要はないと思う。多分、ディストリビューションが強制的にWaylandを使わせるか、強いデフォルトにしない限り、Waylandの普及は進まないんじゃないかな。systemdの時みたいに。

└

作業用のフラクショナルスケーリング

└

xorg.confに何度もお世話になったよ。UbuntuでWaylandが（実験的な）オプションになった瞬間に切り替えて、それ以来戻ってない。Linuxを使ってる時はずっとAMDのカードを使ってたから、スムーズに動いてるのもあるかも。でも、Waylandの初期には何かが動かなかった記憶がうっすらあるな…WineかSteamの何かだったかも？とにかく、それはもう10年前のことだね。

└

それが長期的には技術的負債につながるよ。今はうまくいってるかもしれないけど、古くなるにつれてメンテナンスが難しくなるからね。

Hacker Newsで議論の続きを見る

ハクソク