キーボードテスト Linux Wayland X11 違いと動作確認

Linux環境でキーボードテストを行う際、お使いのディスプレイサーバーがWaylandかX11（Xorg）かによって、キー入力をブラウザやテストツールがどのように受け取るかが異なります。本記事では、両者の基本構造の違いと、キーボードの動作確認における影響を詳しく解説します。

クイックアンサー

Linux環境におけるWaylandとX11の最大の違いは、セキュリティモデルと入力イベントの制御方法にあります。X11は全アプリケーション間で入力を共有しやすい一方、Waylandは各アプリの独立性を高めています。ブラウザ等でのキーボードテストではXWaylandを介するケースもあり、環境に応じた動作確認の理解が欠かせません。まずは echo $XDG_SESSION_TYPE で自分の土台を確認するのが第一歩です。

WaylandとX11（Xorg）の基本構造と違い

Linuxのデスクトップ環境で長年標準として使われてきたX11（Xorg）は、アプリケーション（クライアント）とディスプレイサーバーが自由に入力イベントをやり取りできる柔軟な設計を採用しています。しかし、設計が古いためセキュリティ上の懸念があり、画面キャプチャやグローバルショートカットの制御などに課題を抱えていました。

これに対してWaylandは、現代的なセキュリティ要件を満たすためにゼロから設計されたディスプレイサーバープロトコルです。Waylandコンポジターが直接ウィンドウ管理と入力イベントの制御を行い、他のアプリケーションが無断でキー入力を盗み見ることができない強固なセキュリティモデルを実現しています。

ここで取り違えやすいのが、WaylandはGNOMEやKDE Plasmaと横並びの「選択肢」ではないという点です。GNOMEやKDEは見た目と操作を担当するデスクトップ環境で、その一段下にある描画と入力の土台がX11かWaylandです。同じGNOMEでも、下の土台だけが違うという組み合わせがあり得ます。キーボードテストの結果を解釈するときは、この層の違いを意識すると整理しやすくなります。

比較表：キーボードテストに関わる観点

Linux環境でのキーボードテストにおける影響と違い

キーボードテストツールやWebブラウザ（Google ChromeやFirefoxなど）を使ってキー入力を検証する際、WaylandとX11の違いが影響を与えることがあります。従来のX11環境では、システム全体のエントリをツール側で容易にキャッチできました。

一方、純粋なWaylandセッション上では、アプリケーションの独立性が高いため、レガシーな入力監視ツールがそのままでは動作しない場合があります。そのため、多くの環境では「XWayland」という互換レイヤーを介して従来のX11アプリケーションやブラウザを動作させており、ブラウザベースのキーボードテストの多くはこのXWayland上でイベントを受け取っています。自分の環境がどちらで動いているかを把握することで、キー反応のトラブルシューティングをスムーズに行うことができます。

なお、キーボードテストサイトやキーボードテストオンラインの多くはブラウザのJavaScriptでキーイベントを拾う仕組みなので、WaylandでもX11でも基本原理は同じです。違いが出るのは「イベントがアプリまで届くか」「どの経路で届くか」という部分であり、テスト結果がおかしいときの原因の在りかが変わります。

自分のLinux環境（Wayland / X11）の確認方法とテスト手順

キーボードテストの結果を正しく解釈するには、まず自分がWaylandとX11のどちらで動いているかを把握する必要があります。確認は端末で次のコマンドを実行するだけです。

echo $XDG_SESSION_TYPE

出力が wayland ならWaylandセッション、x11 ならX11セッションです。ただし、この環境変数はログインマネージャや端末の種類によっては空になることがあります。空だった場合は、デスクトップ環境の「設定」→「概要」や「About」ページでセッション種別を確認するほうが確実です。また、DISPLAY が設定されていることはX11の証拠にはなりません。WaylandセッションでもXWayland用にDISPLAYが設定されるためです。

Waylandセッション上でもX11向けアプリはXWayland経由で動作します。特定のアプリがWaylandネイティブかXWaylandかを調べるには、xlsclients コマンドでXWayland接続中のアプリ一覧を表示する方法があります。キーボードテストをブラウザで行う場合、ブラウザ自体がWaylandネイティブかXWayland経由かで入力イベントの扱いが変わる可能性があるため、トラブル時にはこの違いも意識しておくと原因を切り分けやすくなります。

テスト手順自体はシンプルです。ブラウザでキーボードテストページを開き、ページ内を一度クリックしてフォーカスを合わせてから、確認したいキーを順に押します。WaylandとX11のどちらでも、ブラウザがキーイベントを拾えていれば画面上のキーが反応します。反応しないキーがある場合は、次のトラブルシューティングに進んでください。

キーボード 動作確認でつまずいたときの切り分け

キーボードテストで一部のキーが反応しない、または特定のキーだけ挙動がおかしい場合、原因はハードウェアではなくセッション側の設定にあることが少なくありません。WaylandとX11では入力処理の仕組みが異なるため、対処法も変わります。

特定のキーがまったく反応しない場合

まず切り分けるべきは、OSがそのキーの物理入力を認識しているかどうかです。X11セッションなら xev コマンドでキーコードを確認できますが、Waylandでは xev は機能しません。Wayland・X11の両方で使えるのは evtest です。端末で sudo evtest を実行し、キーボードのイベント番号を選んでから問題のキーを押すと、カーネルレベルでスキャンコードが届いているかを確認できます。

evtest で反応があるのにキーボードテストで反応しない場合は、キーマップやデスクトップ環境のショートカット設定が原因の可能性が高いです。逆に evtest でも何も出ないなら、ハードウェア側の問題を疑う必要があります。キーボードチェックの基本は、この「カーネル→デスクトップ→アプリ」の順で層を下から確かめることです。

キーマップがWaylandで意図したとおりに動かない

X11では問題なく使えていたキーボードレイアウトが、Waylandセッションに切り替えた途端に別の配列として認識されることがあります。KDE Plasmaでは、X11とWaylandでキーボードレイアウトの設定が正しく引き継がれず、特殊文字の入力結果が変わるという報告があります。この場合、Waylandセッション側でレイアウト設定を開き直すか、一度レイアウトを追加してから元に戻すことで設定が再適用されることがあります。

また、JIS配列とUS配列の違いがテスト結果の誤認につながることもあります。キーボードテスト 日本語配列で確認するときは、記号キーの位置やEnterキーの形状が異なるため、テスト前に自分の物理配列と、OS側で選ばれているレイアウト（例：Japanese (OADG 109A)）が一致しているかを確認しておきましょう。配列はIMEとは別レイヤーで管理されている点も見落としやすいポイントです。

IME（日本語入力）関連でテストがうまくいかない

Waylandセッションでは、IMEの動作がX11とは根本的に異なります。X11では環境変数（GTK_IM_MODULE や QT_IM_MODULE）でIMEを指定するのが一般的でしたが、WaylandネイティブアプリはWaylandの text-input プロトコルを使うため、これらの環境変数は不要です。むしろ、WaylandネイティブアプリにX11向けのIME設定を適用すると、かえって入力が不安定になることがあります。

Chromium系ブラウザで日本語入力ができない場合、Waylandの text-input プロトコルのバージョン不一致が原因のことがあります。Chromiumはデフォルトで text-input-v1 を使いますが、GNOMEやSwayは text-input-v3 のみをサポートしています。この場合、Chromiumの起動フラグに --wayland-text-input-version=3 を追加することで改善する可能性があります。

GNOME WaylandではFcitx5のポップアップが正しく表示されない制限があり、GNOME自体がWaylandの input-method プロトコルをサポートしていないためです。日本語入力のテストをGNOME Waylandで行う場合は、IBusを使うか、Fcitx5を使うならKimpanel拡張を導入する必要があります。

関連ページ: キーボードテストで確認する仮想キーボードと物理キーの違い | キーボードテスト

まとめ：キーボードテストは「土台」を確認してから

WaylandとX11は入力処理の仕組みが異なり、同じキーボードテストでも結果の見え方やトラブルの原因が変わります。まずは echo $XDG_SESSION_TYPE で自分のセッションを確認し、問題がある場合は evtest でカーネルレベルでの認識を切り分けるのが最短ルートです。IME関連の不具合はセッション側のプロトコル制限に起因することが多いため、ブラウザやデスクトップ環境の設定を確認してください。macと比較したい場合は、OSごとに配列と修飾キーの割り当てが独立している点も意識しておくと、結果の読み違いを防げます。

次のアクションとして、今のセッション種別を確認したうえで、当サイトのキーボードテストで全キーの反応を一通りチェックしてみてください。反応しないキーが見つかった場合は、ブラウザでキー入力を確認する仕組みと使い方も参考に、テスト結果の読み方を確認しておくと安心です。