Can I finally start using Wayland in 2026?

2026-01-04

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

原文は Michael Stapelberg により 2026-01-04 に公開されました。このブログを購読する

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方式の方が優れていると主張していたらしい。幸い、nVidiaドライバ495（2021年後半）で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氏がTILEプロパティのサポートを追加するドラフトのマージリクエスト!4154を送ってくれた。

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

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

最終的に、SRC_XというDRMプロパティがnVidiaでは動作しない（しかし例えばIntelでは動く！）ことを示す、Waylandに依存しない最小の再現プログラムにたどり着いた。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" ];
};

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

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の開発を形作る時間もないと分かっていたからだ。

この姿勢がきっかけで、Drew DeVault氏が2016年ごろにSwayプロジェクトを始めることになった。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つではなく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'

追記：Hugo氏が指摘してくれたおかげで、WaylandではGTK3が~/.config/gtk-3.0/settings.iniの設定ファイルを無視し、dconfだけを使うことが分かった！以下のdconf設定を行うと、フォントレンダリングが一致するようになる。

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

画面ロック：swaylock

i3lockの当然の後継はswaylockだ。

すぐに2つのプログラムのアーキテクチャの違いにぶつかった。

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端末エミュレータを見つけ、とても良い選択肢に思えた！

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

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

Ctrl+Enterを押すと（私はよく間違えて押してしまう）エスケープシーケンスが出力されるが、URxvtではCtrl+Enterは単にEnterとして扱われる。これはシェル側（私の場合はZsh）で回避できる。詳細はfootのissue #628を参照。
URLの一部をマウスでダブルクリックするとURLが選択される（期待通り）が、https:というスキームのプレフィックスが付かない！マウスを使いたいときに煩わしい。Ctrlを押しながらにすると回避でき、ポインタの下にあるものを次の空白文字まで選択してくれる。
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月）でマージされた。pgtkはX11上で問題があるようで（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で次のような使い勝手に慣れている。「Window」タブをクリックするとウィンドウのプレビューが表示され、ウィンドウを選択して確定すると、その内容が共有される。

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

これらのパッケージを設定した上で、私が見た挙動は以下の通りだ。

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

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

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

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

確定すると、また別のチューザーが表示され、もう一度ウィンドウを選択する必要がある。注目すべきは、この2回目のステップではプレビューされたウィンドウと選択するウィンドウの間に何の紐付けもないことで、別のウィンドウを選べばそちらが共有される。

これでそのウィンドウが画面共有される（つまり機能自体は動くようになった。素晴らしい！）が、残念ながら低解像度で、共同作業者にはテキストがぼやけて見えてしまう。

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

しかし、大局的に見ると、このフロー自体が間違っているように思える。Chromeの「Window」タブをクリックしたときにチューザーが表示されるべきではない。すべてのウィンドウのプレビューが表示され、別のチューザーではなく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での私の体験は非常に快適だということを説明しておきたい。日常的なPC利用でティアリングやその他のアーティファクト、グリッチを見ることはない。コンポジタを使っていないので入力レイテンシも非常に良好で、自作キーボードでX11上のEmacsで計測したところ約763μs（＋出力レイテンシ）だった。kinX: latency measurement (2018)を参照。

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

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

私にとって、Wayland/Swayセッションがデイリードライバーとして使えるようになるのは、次の条件が満たされたときだ。

Swayでときどき一部のキーバインドが二重に発動しなくなる（「ゴーストキープレス」）
Swayでウィンドウやワークスペースを切り替える際にグリッチが見られなくなる
Chromeが常時ハードウェアアクセラレーションされる
Chromeウィンドウが起動時に以前のワークスペースに復元される
Emacsが以下のいずれかを満たす
- Xwayland経由で動作し、Swayがスケーリングを正しく機能させる
- あるいはpgtk版の入力レイテンシの問題が修正され、何らかの方法でテキストレンダリングを以前と同じにできる