ハクソク

世界を動かす技術を、日本語で。

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

103日前原文(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年前のことだね。
└
それが長期的には技術的負債につながるよ。今はうまくいってるかもしれないけど、古くなるにつれてメンテナンスが難しくなるからね。
└
特に今の環境に問題がないなら、Waylandに切り替える理由はあまりないと思う。主な改善点は、X11があまり得意じゃなかった部分に集中していて、既存のX11環境ではあまり使われないだろうしね。Waylandで便利だったのは、ノートパソコンをドッキングして、異なるスケールファクターのディスプレイ間でアプリをシームレスに切り替えられること。さらに、Zoomみたいなプロプライエタリなアプリでも、スケールファクターの切り替えがスムーズにできたのが良かった。重要度は高くないけど、こういう細かいところが好きなんだよね。（正直、このブログ記事ではSwayのフットがこの切り替えをあまり上手く処理できてないって書いてあったけど。プロトコルはシームレスな切り替えを可能にするけど、アプリが常に完璧なフレームをレンダリングすることを保証するわけじゃないからね。）一方で、GNOMEやKDEのようなプロジェクトがWaylandに切り替えたい理由はたくさんあるし、X11のサポートを維持するよりも切り捨てたいってのもあるから、今後の問題を把握することは重要だと思う。このブログ記事にあるような取り組みが大事なのは、報告されないバグを直すのは難しいから。特にNVIDIAがそういうバグを見つけるために特別な努力をしているとは思えないし、彼らにとって報告がかなり重要だろうね。要するに、今年は「唯一の欠点」が「欠点なし」に移行する必要があるってこと。Wayland自体の推進力は、コンポジタ中心の世界でより良くできる機能に依存してるけど、大規模な切り替えの動機はX11とWaylandの両方のサポートを永遠に維持する負担を減らすことなんだ。（もちろん、XWaylandを通じたX11アプリのサポートは基本的に永遠に存在するべきだけど。）
└
Waylandが好きだな。Xorgよりもパフォーマンスがずっとスムーズだと思う。ただ、VRRは使わないし、フォントスケーリングによるわずかな遅延が嫌いだから、それも使ってない。けど、仕事で使わなきゃいけないアプリがあるからXorgに縛られてるんだ。 > おそらく、ディストリビューションがWaylandを強制したり、システムdのように強いデフォルトにしたときに、Waylandの採用が進むと思う。実際、すでにそうなってる。私の知る限り、ArchlinuxやUbuntuはすでにGnome 49に切り替えていて、再コンパイルなしではXをサポートしていない。だから、Gnome 49以上を使っているディストリビューションはデフォルトでXorgを提供しない可能性が高い。KDEもすぐにそうする予定だし。Xorgはもうすぐ消えると思う。これは正しい方向への一歩だと思うけど、唯一の問題は、面倒なアプリが私たちを引き止めていることだね。
└
x2x、xev、xdotoolを使った重要なワークフローがあるんだ。こういうのはWaylandのセキュリティモデルに反するらしいから、Xorgに縛られてるけど、それでも大丈夫。
└
私にとっては、主にHDRの実装が良くなってほしいな。
└
異なるディスプレイで異なるリフレッシュレートが使えるのは、私にとっては最高の機能だね。
└
私が考えられる主な理由はセキュリティだね。今のX11では、確か、あるアプリケーションがあなたのディスプレイにアクセスできると、同じディスプレイ上で動いている他のアプリケーションの内容を読み取れる。もしブラウザのタブがそれをできるようになったら、大変なことになるよね。だから、どうしてアプリケーションからはそれを受け入れるのか。とはいえ、これにもかかわらず、私はすべての欠点のためにWaylandではなくX11を使っている。
最近Linuxに切り替えたんだ。Windowsで変な問題が解決できなかったから。何度か切り替えようとしたことがあったけど、最初の頃の大きな問題はLinuxでフラクショナルスケーリングがちゃんとできなかったことだった。それが原因で、特定のハードウェアではLinuxがほぼ使えなかったんだ。Waylandがそれを解決してくれたから、その部分は大きな改善だよ。ただ、Waylandを使ってないディストロもあるから、選択肢が限られるのが残念。結局、いくつかの問題があったけど、またUbuntuに落ち着いたよ。一番イライラしたのは、FirefoxのSnap版がハードウェアアクセラレーションを使ってなかったことで、ほとんど使えなかったからね。
└
そうそう、Linuxで一番恋しいのはフラクショナルスケーリングだね。X11だと遅すぎてイライラする。Waylandでは…Waylandの問題がある。MacOSは完全には好きじゃないけど（デスクトップで動かせないから、笑）、フラクショナルスケーリングがすごくうまくて、4K解像度で「1440pに見える」スケーリングを選ぶと、どのアプリも完璧に見えるし、一貫性もある。パフォーマンスの影響も全然感じない。Windowsでも同じだけど、ちょっとぼやけることがある。Linuxでは、巨大なUI（x2スケーリング）か小さなUI（x1）か、パフォーマンスの遅延を我慢するしかないから、ほんとに作業が辛い。
もう数年Wayland（wlroots/swaywm）を使ってるけど、全く問題ないよ。eGPUでもね。ただ、AMDのハードウェアを使ってるから、それも影響してるかもしれない。LinuxでのNVIDIAのクソみたいなことにはもううんざりだ。
└
私も今は同じだよ。でも、以前はNVIDIAで動いてたし、そこそこ良かった。職場ではTILEパッチを使ったこともあって、5kのスクリーンでは結構良さそうだった。異なる出力での異なるスケーリングをサポートするために切り替えたけど、また戻っちゃった。
└
> 「LinuxでのNvidiaのクソみたいなことに人生を無駄にするには短すぎる。」 そんなにNvidiaが嫌われてるけど、23年間でLinux上のNvidiaで問題があったのは、古いGPUのサポートを切られた時だけだったな。iMacやMacBookみたいなプロプライエタリなハードウェアでもね。でも、好みはそれぞれだよね。
> NVIDIAはWaylandが使っていたAPIをサポートすることを拒否し、彼らのEGLStreamsアプローチが優れていると主張した。これは起こったことの一般的な誤解だね。このAPI、GBMはMesaの一部であるプロプライエタリなAPIだった。NVIDIAは自社のドライバーにGBMを追加できなかった。なぜなら、それはMesaの概念だから。だから、NVIDIAはどのグラフィックスドライバーでも使えるベンダー中立のソリューションを作ろうとした。これがEGLStreamsが登場する理由だ。EGL APIはWayland以外の埋め込み用途にも役立った。NVIDIAのプロプライエタリドライバーのGBMサポートに関しては、NVIDIA自身がMesaプロジェクトにサポートを追加し、新しいバックエンドを動的に読み込むことを可能にした。その後、自社のバックエンドを作ることができた。なぜかこの話が出ると、いつもNVIDIAが何かをサポートしていないという形で語られるけど、実際にはフリーデスクトップの人たちがNVIDIAドライバーが動作する方法を提供していないことが前提条件なんだ。
└
ごめん、でもMesaみたいなオープンソースプロジェクトがプロプライエタリAPIに依存するってどういうこと？
俺は何年もGnomeでWayland使ってるけど、全く問題ないよ。たぶん俺のハードウェアはシンプルだし、Nvidiaも使ってないからかも。でも、Waylandが叩かれることが多いけど、実際は結構うまく動くってことを言いたい。
└
俺もGnomeでWayland使い始めて1〜2年くらいかな、ずっとNvidiaのハードウェアで。今はまあまあ動くけど、2年前は全然ダメだったし、その前はすごく不安定だった。でも今はXorgよりもスムーズだと思う。今のところ、俺にとっての大きな問題はないかな。ウィンドウの位置を制御したり、他のアプリが何をやってるか見たいプログラムを再構築するのにちょっと時間かかったけど、最終的にはGnome Shellの拡張機能で簡単に回避できた。Waylandの設計上、そういうことはあんまり「許可」されてないけどね。今はWaylandよりも、ハイリフレッシュレートに対応してないゲームやウェブサイト、プログラムの方が問題が多い。
└
俺もそうだよ。最初は2016年にSway、その後KDE Plasma 6に移行した。全部完璧に動いてるし、Steamのゲーム以外はネイティブWaylandで動いてる。NVIDIAよりもずっと前からAMDかIntelのハードウェアが好き。
KDE Plasmaは去年のどこかでデフォルトでWaylandに切り替わったけど、今のところの主な問題は、好きな画面録画ツールがいくつか動かなくなったことかな。（特にsimplescreenrecorderが完全にメンテされてないみたい。）GPUの加速レンダリングで最初にちょっと不安定だったけど、すぐに解決したし、まあ普通に動いてる。ほとんど気にならない。実は、GPUの加速が最初に切り替えた理由なんだけど、何かの理由でこのGPU（Radeon VII）はX11で新しいウィンドウを開くたびにほぼ毎回クラッシュするけど、Waylandでは全然安定してる。ほんとにイライラする！だから、ちょっと勇気づけられて、plasma-waylandがちゃんと安定するのを待ってた。念のためにX11環境もインストールしてあるけど、数ヶ月間実際に使う必要はなかった。今のところの小さな痛点は、マウスの加速カーブが違ったり、スクリーンキャプチャがちょっと面倒なことかな。ほとんどのプログラムがOSレベルのポップアップを出して、その後に自分の矩形選択ツールを出してくるから、もう一回やらなきゃいけない。sdl2-compatでもちょっと問題があったけど、それが厳密にWaylandのせいかはわからないし、アップデートの後に自然に解決した。（俺は低遅延のオーディオ同期が必要なSDL2ゲームを開発してる。）
└
> 特にsimplescreenrecorderが完全にメンテされてないみたい 俺はそれをよく使ってるけど、使いやすいし、UIもコンパクトで分かりやすい。いつも完璧に動いてるよ。正直、今はメンテされてないことなんて気にしてない。
└
Waylandでウィンドウのシェーディングが機能しなくなったのがまだ悲しい。
最近、Ubuntu 25.10にアップグレードして、X.orgがデフォルトでインストールされなくなったからWaylandをもう一度試してみることにした。良いニュース：私のノートパソコン（Lenovo P53）は今、サスペンド/レジュームが成功するようになった。Ubuntu 25.04 / Waylandではうまくレジュームできなかったから、これは致命的だった。面倒なこと：wmctrlを使ってワークスペースを整理するスクリプトがあったんだけど、それがもう動かなくなったからgnome-shellの拡張を作らなきゃいけなかった。gnome-shellの拡張を作ったことがない私にとっては、ログアウトしてログインし直してテストするのがかなり面倒だった。結局うまくいったけど、まだちょっと不満が残ってる。全体的に見ると、ユーザーとしての私の視点では、Waylandへの切り替えがかなりの時間を無駄にしたし、目に見えるメリットは感じられない。でも、今は基本的には動いているみたいで、これが今後の方向性なんだろうな。追記：実際、mpvを動かしているときにgnomeがクラッシュするのを見たことがあるけど、それがWaylandのせいかは確信が持てない。
ウィンドウマネージャがWaylandをサポートするまで、私はWaylandに切り替えないつもり。誰もその作業をする時間がないみたいだから、DebianからXが削除されるときに、仕方なくXWaylandに切り替えることになると思う。Waylandの最大の問題は、代替のウィンドウマネージャを使っている人たちの長い尾だと思う。多くのプロジェクトは、完全な書き直しに必要な人手が足りていない。正直、WaylandとXのどちらが好みかはないけど、今のウィンドウマネージャを維持したい気持ちは強い。XWaylandはうまく動くらしいけど、既に自分が望むように動いているものに、余計なソフトウェアと設定の層を追加するために急ぐつもりはない。もしWaylandがXに対して素晴らしい利点を提供してくれれば話は別だけど、今のところ私を引きつけるものは見たことがない。