Can I finally start using Wayland in 2026?

2026-01-04

2026年、ついにWaylandを使い始められるのか？

Waylandは、Linuxのグラフィックスタックを担うXサーバー（X11、Xorg）の後継です。Waylandプロジェクト自体は2008年に始まりました。私がX11用のタイリングウィンドウマネージャーi3を作った2009年の1年前のことです。しかし、この18年間（！）、Waylandは私のコンピューターでは一度もまともに使えたことがありません。時代遅れのソフトウェアに縛られたくはないので、毎年Waylandを使い始めようと試しています。この記事では、2026年時点でWaylandへの移行を妨げているものについてまとめます。

歴史的背景

最初の数年間、Waylandは私のマシンでは起動することすら稀でした。運よく何かが表示されても、デモ用コンポジターのWestonでおもちゃのようなデモアプリを動かせる程度でした。

2014年頃、GNOMEがWaylandをサポートし始め、数年後にKDEがそれに続きました。FirefoxやChrome、Emacsといった主要なアプリケーションのWayland対応はより遅く、ごく最近まで、あるいはgeeqieのように今日に至るまで、独自のフラグや環境変数で実験的な実装を有効にする必要がありました。

残念ながら、ドライバーのサポート状況は長年貧弱なままでした。私の8Kモニターをサポートする唯一のカードであるnVidiaのグラフィックスカードでは、Waylandはまったく動かないか、ひどいグラフィックの乱れやクラッシュを引き起こしていました。

2020年代に入ると、ますます多くのディストリビューションがデフォルトでWaylandに切り替える、あるいはX11セッションを廃止すると発表し、RHELはXサーバーへのコントリビューションを縮小しています。

Asahi Linux（Mac向け、独自のGPUドライバーを備えています！）のようなモダンなLinuxディストリビューションは、Waylandを主要なデスクトップスタックと明確に位置づけており、X11のサポートはベストエフォートに留まっています。

Waylandへの移行圧力は高まる一方です。では、もう使えるようになったのでしょうか。何が足りないのでしょうか。

Waylandを起動させるまで

ハードウェア

今回の検証は、2022年のハイエンドLinux PCを少しアップグレードしたラボ用PCで行っています。

セットアップの詳細はstapelberg uses this: my 2020 desk setupで紹介しています。

この記事で最も重要なのは、Dellの32インチ8Kモニター（解像度は7680x4320！）を使っていることです。私の経験上、このモニターはnVidiaのグラフィックスカードでしか正しく動作しません（他のカードも時々試しています）。

そのため、ラボ用PCもメインPCもnVidia GPUを搭載しています。

ラボ用PCはnVidia GeForce RTX 4070 Tiを搭載しています。
メインPCはnVidia GeForce RTX 3060 Tiを搭載しています。

（なぜメインPCで古いカードを使っているのか不思議に思われるかもしれませんが、一度クラッシュした際にGPUが原因かと疑い、4070から以前の3060に戻したためです。）

nVidiaドライバーのサポート

長年、nVidiaドライバーはWaylandではまったくサポートされていませんでした。

nVidiaはWaylandが採用していたAPIのサポートを拒否し、自社のEGLStreams方式の方が優れていると主張していたようです。幸い、2021年後半のnVidiaドライバー495で、GBM（Generic Buffer Manager）のサポートが追加されました。

しかし、GBMに対応しても、多くのWaylandセッションは起動できるようになったものの、スムーズには動作しませんでした。ひどいグラフィックの乱れやアーティファクトが発生し、まともに作業できる状態ではありませんでした。

この乱れを解決したのがexplicit syncへの対応でした。nVidiaドライバーはAMDやIntelのようにimplicit syncをサポートしていないため、Wayland（そしてwlrootsやsway）側でexplicit syncのサポートが必要だったのです。

Sway 1.11（2025年6月）とwlroots 0.19.0が、explicit syncをサポートした最初のバージョンです。

動かないもの：8KモニターのTILEサポート

nVidiaドライバー自体はWaylandで動くようになりましたが、私の環境でWaylandを使うにはまだ十分ではありません。Dell UP3218Kモニターは、MST（Multi Stream Transport）を使った2本のDisplayPort 1.4接続とTILEサポートを必要とします。この組み合わせは、X11では8年以上まったく問題なく動いていました。

GNOMEは7680x4320@60というネイティブ解像度でモニターを正しく設定できますが、swayではモニターが誤って2台の別々のモニターとして認識されてしまいます。

この挙動の原因は、wlrootsがTILEプロパティをサポートしていないこと（2019年からのissue #1580）にあります。幸い、2023年にコントリビューターのEBADBEEF氏がドラフトのマージリクエスト !4154を送り、TILEプロパティのサポートを追加してくれました。

しかし、そのTILEパッチを当てても、私のモニターは正しく動作しませんでした。モニターの右半分が真っ黒のままなのです。grimでスクリーンショットを撮ると全体が写っているので、出力側の問題のようです。2025年8月からEBADBEEF氏と何度かやり取りしましたが（見ていただきありがとうございます！）、原因は分かりませんでした。

3か月後、コーディングアシスタントのClaude Code（執筆時点ではOpus 4.5）を使って複雑な問題のデバッグで良い経験をしていたので、もう一度試してみることにしました。2日間にわたっていくつものテストを実行し、Claudeにswayやwlroots、Xorg、mesaなどのソースコードを解析させ、手動で実行できるテストプログラムを作らせて問題を絞り込みました。

最終的に、Waylandとは独立した最小の再現プログラムにたどり着き、SRC_XというDRMプロパティがnVidiaでは動作しないこと（一方でIntelなどでは動作します！）を示すことができました。nVidiaフォーラムに動画付きでバグ報告を投稿しましたので、nVidiaのエンジニアが見てくれることを期待しています！

重要なのは、バグを特定できたことで、Claudeに回避策を実装してもらえたことです。画面の右半分（SRC_X=3840の位置）を別のバッファにコピーし、そのバッファをSRC_X=0で表示するというものです。

そのパッチを当てたことで、初めて8KモニターでSwayを使えるようになりました！🥳

ちなみに、GNOMEがネイティブ解像度で正しく設定できると書きましたが、それはGNOMEでモニターが実用的に使えるという意味ではありません！GNOMEはタイリングディスプレイをサポートしていますが、個々のタイルの更新が同期されていないため、画面中央でひどいティアリングが発生し、X11で見たどの症状よりもひどい状態です。GNOME/mutterのマージリクエスト !4822で改善されることを期待しています。

ソフトウェア：NixOS

2025年の間に、すべてのコンピューターをNixOSに切り替えました。宣言的なアプローチのおかげで、システムを確実に以前のバージョンに戻せるため、このようなテストにはとても便利です。

NixOS 25.11のインストールでWayland/swayセッションを使えるようにするため、NixOSの設定ファイル（configuration.nix）に以下の行を追加しました。

# GDM display manager (can launch both X11/i3 and Wayland/Sway sessions)
services.displayManager.gdm.enable = true;
services.displayManager.gdm.autoSuspend = false;

# enable GNOME (for testing)
services.desktopManager.gnome.enable = true;

programs.sway = {
  enable = true;
  wrapperFeatures.gtk = true;
  extraOptions = [ "--unsupported-gpu" ];
};

さらに、environment.systemPackagesに以下のWayland関連プログラムも追加しました。

environment.systemPackages = with pkgs; [
  # …
  foot          # terminal emulator
  wtype         # replacement for xdotool type
  fuzzel        # fuzzy matching program starter
  wayland-utils # for wayland-info(1)
  gammastep     # redshift replacement
];

なお、この設定を有効にすると、実行中のX11セッションがあれば終了するので注意してください。

念のため、設定変更後にマシン全体を再起動しました。

実験結果

このセットアップで、丸一日Waylandセッションで作業してみました。実際に仕事をしようとすると、ちょっと触っただけでは分からない問題が次々と見つかります。結局、その日の大半はWaylandの問題修正に費やしました😅。以下のセクションでは、そこで学んだことや気づいたことを説明します。

デスクトップ：i3 → sway

何年も前、Waylandが普及し始めた頃、i3のissueトラッカーでi3をWaylandに移植する予定はあるかと聞かれました。私は断りました。自分のどのコンピューターでも動かない環境に、どうやってプログラムを移植できるでしょうか。それに、フルタイムの仕事をしながら、Wayland開発の初期段階から関わる時間はないことも分かっていました。

この姿勢がきっかけで、2016年頃にDrew DeVault氏がSwayプロジェクトを立ち上げました。これはi3のWayland版を目指すものです。私はSwayを競合とは考えていません。むしろ、i3プロジェクトを気に入って、わざわざ別の環境向けに似たプログラムを作ってくれるなんて素晴らしいことだと思いました！とても嬉しい賛辞です😊

Swayはi3の設定ファイルとの互換性を目指しており、実際ほぼ互換性があります。

参考までに、Swayのデフォルトから私が変更した点を紹介します。主に使っているNEOキーボードレイアウトに合わせてキーバインドを入れ替えたり、以前は自分の~/.xsessionファイルで設定していたinput／outputブロックを設定したりしたものです。

デフォルトのSway設定からの変更点

--- /home/michael/src/sway/config.in	2025-09-24 19:08:38.876573260 +0200
+++ /home/michael/.config/sway/config	2025-12-31 15:50:38.616697542 +0100
@@ -9,19 +9,76 @@
 # Logo key. Use Mod1 for Alt.
 set $mod Mod4
 # Home row direction keys, like vim
-set $left h
-set $down j
-set $up k
-set $right l
+set $left n
+set $down r
+set $up t
+set $right d
 # Your preferred terminal emulator
 set $term foot
 # Your preferred application launcher
-set $menu wmenu-run
+set $menu fuzzel
+
+font pango:Bitstream Vera Sans Mono 8
+
+titlebar_padding 4 2
+
+# Make Xwayland windows recognizeable:
+for_window [shell="xwayland"] title_format "%title [Xwayland]"
+
+workspace_layout stacking
+
+# Open two terminal windows side-by-side on new workspaces:
+# https://github.com/stapelberg/workspace-populate-for-i3
+exec ~/go/bin/workspace-populate-for-i3
+
+exec gammastep -l 47.31:8.50 -b 0.9
+
+input * {
+   xkb_layout "de"
+   xkb_variant "neo"
	repeat_delay 250
	repeat_rate 30
+}
+
+input * {
+	accel_profile adaptive
+	pointer_accel 0.2
+}
 
 ### Output configuration
 #
-# Default wallpaper (more resolutions are available in @datadir@/backgrounds/sway/)
-output * bg @datadir@/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill
+output * bg /dev/null fill #333333
+output * scale 3
 #
 # Example configuration:
 #
@@ -33,14 +90,41 @@
 #
 # Example configuration:
 #
-# exec swayidle -w \
-#          timeout 300 'swaylock -f -c 000000' \
-#          timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' \
-#          before-sleep 'swaylock -f -c 000000'
+exec swayidle -w \
+         before-sleep '~/swaylock.sh' \
+         lock '~/swaylock.sh'
 #
 # This will lock your screen after 300 seconds of inactivity, then turn off
 # your displays after another 300 seconds, and turn your screens back on when
 # resumed. It will also lock your screen before your computer goes to sleep.
+bindsym $mod+l exec loginctl lock-session
+
+  # Notifications
+  bindsym $mod+period exec dunstctl close
 
 ### Input configuration
 #
@@ -63,11 +147,13 @@
     # Start a terminal
     bindsym $mod+Return exec $term
 
     # Kill focused window
-    bindsym $mod+Shift+q kill
+    bindsym $mod+Shift+x kill
 
     # Start your launcher
-    bindsym $mod+d exec $menu
+    bindsym $mod+a exec $menu
 
     # Drag floating windows by holding down $mod and left mouse button.
     # Resize them with right mouse button + $mod.
@@ -142,12 +228,11 @@
     bindsym $mod+v splitv
 
     # Switch the current container between different layout styles
-    bindsym $mod+s layout stacking
+    bindsym $mod+i layout stacking
     bindsym $mod+w layout tabbed
-    bindsym $mod+e layout toggle split
 
     # Make the current focus fullscreen
-    bindsym $mod+f fullscreen
+    bindsym $mod+e fullscreen
 
     # Toggle the current focus between tiling and floating mode
     bindsym $mod+Shift+space floating toggle
@@ -156,7 +241,7 @@
     bindsym $mod+space focus mode_toggle
 
     # Move focus to the parent container
-    bindsym $mod+a focus parent
+    bindsym $mod+u focus parent
 #
 # Scratchpad:
 #
@@ -192,37 +277,25 @@
     bindsym Return mode "default"
     bindsym Escape mode "default"
 }
-bindsym $mod+r mode "resize"
+#bindsym $mod+r mode "resize"
 
 #
 # Status Bar:
 #
 # Read `man 5 sway-bar` for more information about this section.
 bar {
-    position top
 
     # When the status_command prints a new line to stdout, swaybar updates.
     # The default just shows the current date and time.
-    status_command while date +'%Y-%m-%d %X'; do sleep 1; done
+    status_command i3status
 }

Swayでは以下の問題に遭遇しました。

以前と同じlibinput設定をどうやって再現すればいいのか分かりません。xinput-list-props-mx-ergo.txtにX11での設定を載せていますが、Swayで利用できるaccel_profileの設定は、以前使っていたものと一致しないようです。
マウスカーソル／ポインターの動きがもたつくように感じます。トラックボールを動かしてから反応するまでに時間がかかり、画面を移動する動きも滑らかではありません。
Simon Ser氏によれば、nVidiaドライバーでは現在ハードウェアカーソルのサポートがうまく動いていないことが原因かもしれないとのことです。
Xwaylandのスケーリングができません。Xwayland経由で起動したプログラムは、デフォルトではぼやけ、Xft.dpi: 288を設定すると二重に拡大されてしまいます。これはSway特有の制限です。KDEでは2022年に修正されています。Swayのissue #2966を見る限り、Swayの開発者は何らかの理由でこのアプローチを好まないようですが、私の移行にとっては非常に残念です。古いプログラムをXwayland経由で動かすという後方互換の手段が、実質的に使えないのです。
ときどき、キーボードショートカットが二重に実行されることがあります！たとえば、スタックに積まれた5つのChromeウィンドウのうち最初の1つにフォーカスして別のワークスペースに移動しようとすると、1つではなく2つのウィンドウが移動してしまうのです。また、以下のようなメッセージも表示されます（ただし、このメッセージと二重実行の問題が厳密に対応しているわけではありません）。
```
[ERROR] [wlr] [libinput] event0  - https: kinT (kint36): client bug: event processing lagging behind by 32ms, your system is too slow
```
これはおかしいと思います。ハイエンドLinux PCが遅いということは、どう考えてもありえません。

GTK：フォントサイズ

GIMPやEmacsのようなGTKプログラムを初めて起動したとき、すべてのフォントが大きすぎることに気づきました。どうやらスケーリング関連の設定が残っていたようで、以下のようにリセットする必要がありました。

gsettings reset org.gnome.desktop.interface scaling-factor
gsettings reset org.gnome.desktop.interface text-scaling-factor

デバッグのヒント：GNOMEの設定はdconf dump /で確認できます（~/.config/dconfに保存されています）。

GTK：バックエンド

geeqieのような一部のプログラムは、明示的にexport GDK_BACKEND=waylandという環境変数を設定しないとXwaylandで動いてしまうようです。奇妙です。

フォントレンダリング

フォントのレンダリングもX11とWaylandで違うことに気づきました。この違いは、たとえばChromeのブラウザタブのタイトルやURLバーなどで確認できます。

最初はWaylandではフォントのアンチエイリアスやヒンティングのデフォルト設定が違うのかと思い、以下の設定（デフォルトはfont-antialiasing=grayscaleとfont-hinting=slightです）をいろいろ試してみましたが、以前と同じようにはなりませんでした。

gsettings set org.gnome.desktop.interface font-antialiasing 'rgba'
gsettings set org.gnome.desktop.interface font-hinting 'full'

追記：WaylandではGTK3が~/.config/gtk-3.0/settings.iniの設定ファイルを無視し、dconfだけを使うことをHugo氏に教えていただきました！以下のdconf設定を行うと、フォントレンダリングが一致するようになります。

gsettings set org.gnome.desktop.interface font-name 'Cantarell 11'

スクリーンロック：swaylock

i3lockのWaylandでの代替はswaylockです。

すぐに、両者のアーキテクチャの違いに気づきました。

i3lockはスクリーンロック用のウィンドウを表示します。i3lockをkillすれば画面のロックは解除されます。
swaylockをkillすると、Red Screen Of Death（赤い死の画面）になってしまいます。
この状態から抜けるには、swaylockを再起動してロックを解除する必要があります。コマンドラインからswaylockプロセスにSIGUSR1を送ることでロックを解除できます。

これはとても驚きでしたが、（Waylandの）仕様なのです！詳細はSwayのissue #7046や、ext-session-lock-v1 Waylandプロトコルの次の一節をご覧ください。

「コンポジターはレンダリングを停止し、通常のクライアントへの入力提供を止めなければならない。代わりにコンポジターは、通常のコンテンツが完全に隠れるように、すべての出力を不透明な色で塗りつぶさなければならない。」

つまり、SSH経由でテストのためにswaylockを起動したときは、Ctrl+Cでキャンセルするのではなく、必ずロックを解除するようにしてください。そして、決してクラッシュしないことを祈るしかありません。

以前はi3lockをラッパースクリプト経由で起動していました。このスクリプトはモニターの電源を切り（入力で復帰します）、以下のように動作します。

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

revert() {
    xset dpms 0 0 0
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM
xset +dpms dpms 15 15 15
(sleep 1 && xset dpms force off) &
pactl set-sink-mute @DEFAULT_SINK@ 1
i3lock --raw 3840x2160:rgb --image ~/i3lock-wallpaper-3840x2160.rgb -n 
revert

Waylandでは、DPMSの挙動はswayidleを使って別の方法で実装する必要があります。

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

swayidle -w \
  timeout 5 'swaymsg "output * dpms off"' \
  resume 'swaymsg "output * dpms on"' &
swayidle=$!

revert() {
    kill $swayidle
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM

pactl set-sink-mute @DEFAULT_SINK@ 1
swaylock --image ~/i3lock-wallpaper-3840x2160.jpg
revert

i3 IPC自動化

i3ウィンドウマネージャーは、IPCインターフェース（プロセス間通信）を通じて拡張できます。

私はこのインターフェースを使う小さなツールをいくつか使っています。

Swayでこれらのツールを使った際に、以下の問題に気づきました。

go.i3wm.org/i3/v4 Goパッケージを使っているツールは、現在特別なソケットパスのフックが必要です。移行を楽にするために、パッケージ側で透過的に対応すべきでしょう。
Swayの設定ファイルからexecで起動したツールが、Swayを終了（swaymsg exit）して新しいセッションにログインしても、予期せず動き続けてしまいます！
私のworkspace-populate-for-i3が動きませんでした。
- Swayはi3のレイアウトの保存／復元を実装していません。Drew氏が2017年に「複雑でハック的すぎる割に利点が少なすぎる」と判断したためです。残念です。気に入っていたレイアウトがいくつかあるので、別の方法で再現する必要があります。
- Swayは[con_id]条件でワークスペースノードにマッチしません。これを修正するプルリクエスト #8980（5日前に独立して投稿されたもの）があります。
私のwsmgr-for-i3は部分的に動きました。
- ワークスペースの復元（wsmgr restore）は動作しました。
- Swayのrename workspaceコマンドの実装は、ターゲット名からワークスペース番号を拾ってくれないようです。

ターミナル：foot

X11ではrxvt-unicode（URxvt）というターミナルエミュレーターを使っています。高速で見た目がミニマルなだけでなく、以下のようなQOL機能を手放したくないと思っています。

スクロールバック（＝コマンドの出力）を逆方向に検索する
キーボードショートカットでスクロールバック内のURLを開く
同じ作業ディレクトリで新しいターミナルウィンドウを開く
シェルからターミナルのタイトルを更新する

以前の検証ではAlacrittyやKittyも試しましたが、どちらも満足できませんでした。

anarcat氏のブログ記事「Wayland: i3 to Sway migration」のおかげで、footターミナルエミュレーターという良さそうな選択肢を見つけました！

URxvtの設定に合わせたfoot.ini設定ファイルを作り始めましたが、少なくとも一部の色が一致しないことに後で気づきました（緑や赤の背景のテキスト行が違って見えました）。なぜなのかはまだ調べていません。

footを使っていて、以下の問題に気づきました。

Ctrl+Enterを押すと（私は間違えてよく押してしまいます）、エスケープシーケンスが入力されてしまいますが、URxvtではCtrl+Enterは単なるEnterとして扱われます。
これはシェル（私の場合はZsh）側で回避できます。詳細はfootのissue #628をご覧ください。
マウスでURLの一部をダブルクリックすると、URLは選択されますが（期待通り）、https:というスキームの接頭辞が含まれません！マウスを使いたいときに不便です。
Ctrlを押しながら選択すれば回避できます。そうするとfootはポインターの下にあるものを次の空白文字まで選択してくれます。
footの中でscreen(1)を起動すると、screenセッション内で動くプログラムで色がサポートされなくなります。おそらくterminfo関連の問題でしょう…？GNOME端末でも同じ問題を再現できます。しかし、URxvtやxtermでは正常に動作します。
テキストを選択すると、行全体ではなく行内のテキストだけがハイライトされます。これは私が慣れている他のターミナルエミュレーターとは違いますが、変更するオプションは見当たりません。
「kthreadd」の右側でトリプルクリックした後のfootのスクリーンショットです。
しかし、echoの出力行でトリプルクリックすると、行全体ではなく内容だけがハイライトされます。

テキストエディター：Emacs

EmacsのWaylandサポートにはかなりがっかりしました。標準のEmacsはX11のみをサポートしているため、SwayではXwaylandで起動します。SwayがXwaylandでのスケーリングをサポートしていないため、Emacsはぼやけて表示されます（上／背景のウィンドウ）。

ネイティブなWaylandサポート（下／前面のウィンドウ）は、pgtk版のEmacs（NixOSではemacs-pgtk）でのみ利用できます。pgtkは以前は別ブランチでしたが、Emacs 29（2023年7月）でマージされました。X11ではpgtkに問題があるようで（X11でEmacs-pgtkを起動すると警告が出ます）、今のところ2つの別々のバージョンが必要なのです…

残念ながら、pgtkのテキストレンダリングはネイティブなX11のレンダリングとは違って見えます！行の高さや文字間隔が違うようです。

なぜ違うのか分かりません！以前と同じようにする方法をご存知の方はいますか？

テキストレンダリングの違い以外に、私にとって大きな問題は入力の遅延です。Emacs-pgtkはEmacsよりも明らかに反応が遅く感じられます。これはRedditでも何度か報告されており（スレッド1、スレッド2）、Emacsのバグ #71591でも報告されていますが、解決策は見つかっていないようです。

Emacsをリモートで実行する方法も必要になります。これまではSSH経由のX11フォワーディングを使ってきました（光回線なら低遅延で問題なく動きます）。waypipeを試すべきかもしれませんが、まだ試す機会がありません。

ブラウザ：Chrome

Chromeを起動してchrome://gpuのデバッグページを確認すると、一見問題なさそうです。

しかし、ブラウザウィンドウを移動したりリサイズしたりするとすぐにGPUプロセスが落ち、たとえばWebGLのハードウェアアクセラレーションが効かなくなります。以下のようなメッセージが出ます。

ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Scanout|Rendering|Texturing
ERROR:ui/gfx/linux/gbm_wrapper.cc:405] Failed to create BO with modifiers: Invalid argument (22)
ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Texturing
ERROR:gpu/command_buffer/service/shared_image/shared_image_factory.cc:981] CreateSharedImage: could not create backing.
ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:397] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
ERROR:components/viz/service/gl/exit_code.cc:13] Restarting GPU process due to unrecoverable error. Context was lost.
R:gpu/ipc/client/command_buffer_proxy_impl.cc:321] GPU state invalid after WaitForGetOffsetInRange.
ERROR:content/browser/gpu/gpu_process_host.cc:1005] GPU process exited unexpectedly: exit_code=8704

もちろん、ハードウェアアクセラレーションなしのブラウザを使うのは、特に高解像度では非常にストレスが溜まります。--disable-gpu-compositingを付けてChromeを起動するとGPUプロセスが落ちるのは回避できるようですが、それでもX11のときほどスムーズには感じられません。

私にとってもう一つの大きな問題は、SwayではChromeウィンドウが閉じたときのワークスペースで開き直されないことです。_NET_WM_DESKTOPというEWMHアトムを追跡・復元するサポートは、i3には2016年1月に、Chromeには2016年5月に、Firefoxには2020年3月に追加されました。

私はいつも5つ以上のワークスペースと、さらに多くのChromeウィンドウを開いているので、毎朝（仕事用PCを起動するたびに）10個以上のChromeウィンドウを手作業で振り分け直さなければならないのはとても面倒です。

Simon Ser氏によれば、これは新しいWaylandプロトコル（xdg-session-management、マージリクエスト !18）で対応されるとのことです。

画面共有

私はリモートワークが多いので、画面共有は必須の機能です。ブラウザでの画面共有をほぼ毎日、さまざまなシーンや要件で使っています。

X11では、Chromeで次のような使い心地に慣れています。「ウィンドウ」タブをクリックするとウィンドウのプレビューが表示され、ウィンドウを選んで確定すると、その内容が共有されます。

Wayland/swayで画面共有を動かすには、xdg-desktop-portalとxdg-desktop-portal-wlr（後者はswayが使っているwlroots専用です）をインストールする必要があります。

これらのパッケージを設定した状態で、私が確認した挙動は以下の通りです。

Chromeのタブは共有できます。
モニター全体は共有できます。
特定のウィンドウは共有できません（モニター全体が1つのウィンドウとして表示されます）。

これはxdg-desktop-portal-wlr（およびその他）の制限で、今後のSway 1.12リリースで対応されるはずです。

試すために、NixOSの設定をswayとwlrootsをgit版を使うように変更しました。「ウィンドウ」タブをクリックすると、ウィンドウを選択するためのチューザーが表示されます。

ウィンドウを選択すると、Chromeにはそのウィンドウの内容だけがプレビュー表示されます。

確定すると、もう一度チューザーが表示され、再度ウィンドウを選択する必要があります。なお、この2回目のステップでプレビューされたウィンドウと実際に選択するウィンドウは連動していません。別のウィンドウを選べば、そちらが共有されます。

これでそのウィンドウの画面共有自体はできるようになりました（機能としては動くようになって良かったです！）が、残念ながら低解像度で表示され、同僚からは文字がぼやけて見えてしまいます。

これについてはxdg-desktop-portal-wlrのissue #364として報告し、間違ったスケールファクターが適用されていることが原因のようです。issueで提示されたパッチで私の環境では直りました。

ただ、大局的に見ると、フロー全体がおかしいと感じます。Chromeの「ウィンドウ」タブをクリックしたときにチューザーが表示されるべきではありません。すべてのウィンドウのプレビューが表示されるべきです。別途チューザーではなく、Chromeの中でウィンドウを選択できるべきです。

スケーリングの不具合

出力のスケーリングを有効にしていると、非常に気になる不具合にも気づきました。（一部の）ウィンドウの内容が、ウィンドウ（タブやスタックコンテナ内）やワークスペースを切り替えるたびに「ぴくっと動く」のです。

最初に気づいたのはfootターミナルエミュレーターで、挙動は以下の通りです。

ワークスペースを切り替えるか、スタックやタブコンテナ内でフォーカスを切り替えて、別のfootターミナルにフォーカスを移す。
新しいfootターミナルが、テキストの内容が少しずれた状態で表示される。
数ミリ秒以内に、footのテキストが正しい位置にピョンと移動する。

フォーカスを切り替えた直後、内容が数ピクセル動いている瞬間をiPhoneで捉えたフレームです。

後になって、Chromeのウィンドウも切り替え直後に一瞬ぼやけて表示されることにも気づきました。

私の推測では、Swayが非表示のウィンドウに対してスケールファクターを1に設定しているため、フォーカスを切り替えたときに、アプリケーションがスケール3のコンテンツバッファを提供するまでの間、スケール1のコンテンツバッファが見えてしまうのではないかということです。

通知：dunst

dunstはWaylandをネイティブにサポートしています。dunst 1.13を試しましたが、特に問題は感じませんでした。

ピッカー：rofi

rofiはv2.0.0（2025-09-01）からWaylandで動作します。

私は絵文字ピッカーとしてrofimojiと組み合わせてrofiを使っています。テキスト入力ではxdotoolの代わりにwtypeが使えるようです。特に問題は感じませんでした。

スクリーンショット：grim？

いつも使っているmaim(1)の代わりにgrim(1)を試してみましたが、残念ながらgrimの-Tフラグでキャプチャするウィンドウを選ぶ方法は使いにくい上に、1倍のスケールでキャプチャされてしまいます。

何か良い代替案をご存知の方はいますか？

まとめ

ようやく、私の環境でWaylandセッションを動かすところまで進展がありました！

このWayland/swayの実験について結論を述べる前に、私のX11/i3での体験は本当に快適だということを説明させてください。日々のコンピューター利用でティアリングやその他のアーティファクト、不具合を目にすることはありません。コンポジターを使っていないので、入力遅延も非常に小さいです。かつてEmacsでのX11環境で、自作キーボードを使って約763マイクロ秒と計測したことがあります（出力遅延を除く）。詳しくはkinX: latency measurement（2018）をご覧ください。

ですから私の視点では、この既存の、（私にとっては）完璧に動いているスタックからSwayに乗り換えても、デメリットしかありません。以前にはなかった新たなグラフィックの不具合が見られます。最も多くの時間を費やしているプログラム（ChromeとEmacs）の動作は明らかに悪くなります。実装が違うため、あるいはプログラム自体を乗り換える必要があるため、大量の新しいバグに遭遇します。

初めて、同等のWayland体験が手の届くところまで来たように感じますが、現実的にはまだ数週間から数か月の作業が必要でしょう。私の経験では、グラフィックスカードを交換したりモニターの配線をやり直したりしてバグを絞り込む必要があるため、デバッグセッションはすぐに何時間にもなってしまいます。残念ながら、これらの数多くの問題の修正に多くの時間を割く余裕はないので、当面はX11/i3を使い続けようと思います。

私にとって、Wayland/Swayセッションが日常使いに耐えるようになる条件は以下の通りです。

Swayでときどきキーバインドが二重に発火する（「ゴーストキープレス」）ことがなくなること
Swayでウィンドウやワークスペースを切り替えたときに不具合が見られなくなること
Chromeが継続的にハードウェアアクセラレーションされること
起動時にChromeウィンドウが以前のワークスペースに復元されること
Emacsが以下のいずれかを満たすこと
- Xwayland経由で動作し、Sway側でスケーリングが正しく動くこと
- あるいはpgtk版の入力遅延の問題が修正され、テキストのレンダリングを以前と同じにできること