Wayland と Qt
Waylandは、LinuxにおけるX11の代替として開発されました。その主な目的は、アプリケーションのコンテンツが共有画面上でどのように表示されるかを管理すること、およびユーザーが同じ入力デバイスを共有する複数のアプリケーションとどのように対話できるかを管理することです。
オペレーティングシステムにおけるこの役割は、しばしば「ディスプレイサーバー」と呼ばれます。Wayland ディスプレイサーバーは、その役割の一環として行う特定のタスクを指して、「コンポジター」や「ウィンドウマネージャー」と呼ばれることもあります。
以下では、Wayland および Qt におけるその役割について簡単に紹介します。Wayland 自体に関する詳細や背景については、公式ドキュメントを参照してください。
ディスプレイサーバーとは
ディスプレイサーバーとは、画面領域やその他の共有リソースを管理するオペレーティングシステムの一部です。一般的なデスクトップシステムでは、多くの独立したアプリケーションが同時に実行されており、それぞれが画面へのグラフィックの描画や入力の受け取りを期待しています。
ディスプレイサーバーは、アプリケーションと、画面や入力デバイスといった共有リソースとを結びつける役割を果たします。 デスクトップシステムにおける一般的なディスプレイサーバーは、アプリケーションのコンテンツを個別の長方形の「ウィンドウ」に配置し、ユーザーがそれらを移動したりサイズを変更したりできるようにします。ディスプレイサーバーは、アプリケーションのコンテンツが画面上の正しい位置に表示されること、アクティブなウィンドウがキーボードからの入力を受け取ること、重なり合うウィンドウが正しい順序で描画されることなどを確実にします。
他の種類のシステムでは、ディスプレイサーバーの制限がより厳しくなる場合があります。例えば、画面が自動車の計器盤やフォークリフトの操作パネルである場合、ウィンドウの移動やサイズ変更は望ましくないかもしれません。その代わりに、各アプリケーションは画面上のあらかじめ定義された領域に固定され、事前に割り当てられたデバイスからの入力を受け取るようになります。
いずれにせよ、同じリソースを競合する複数の独立したプロセスが存在する限り、ディスプレイサーバーは有用です。
Waylandの役割
「Wayland」という名称は、いくつかの関連する項目を指す場合があります：
- ディスプレイサーバーとそのクライアント間の通信を行うための一連のプロトコル。
- C言語で記述されたライブラリであり、プロセス間通信のための関数を備え、前述のプロトコルを実装するための基盤となるもの。
- プロトコルを拡張するためのXMLベースの言語、およびそのような拡張からC言語のバインディングコードを生成するためのツール。
Qtは、このプロトコルのクライアント側とサーバー側の両方に対する実装を提供しています。
通常のQtアプリケーションは、「wayland」QPAプラグインを選択することで、Waylandディスプレイサーバー上でクライアントとして実行できます（一部のシステムではこれがデフォルト設定です）。これを行うには、-qpa wayland オプションを使用します。さらに、 Qt Wayland Compositor モジュールを使用して、ディスプレイサーバー自体を開発することも可能です。
また、Qtには、Waylandプロトコルを新しいインターフェースで簡単に拡張するための便利な機能も備わっています。
Wayland とその他の技術
Linuxデスクトップにおいて、WaylandはX11および関連する拡張機能に代わる選択肢です。その中核はコンポジティングディスプレイサーバーであり、Waylandサーバーを表す際に「コンポジター」という用語がよく使われます。 つまり、クライアントはコンテンツをオフスクリーンバッファにレンダリングし、それが後で画面上で他のクライアントのコンテンツと「合成」されることで、ドロップシャドウ、透明度、背景のぼかしなどのウィンドウエフェクトが可能になります。
オリジナルのX11プロトコルの重要な設計原則の一つは、ディスプレイサーバーが、画面と入力デバイスしか持たないシンターミナル上で動作できるという点です。その場合、クライアントはより高い処理能力を持つリモートシステム上で動作し、ネットワーク接続を介してサーバーと通信することになります。
対照的に、Waylandは、現代の環境ではクライアントとディスプレイサーバーが通常同じハードウェア上で動作しているという事実を踏まえて設計されています。分散コンピューティング、リモートストレージ、およびリモートデスクトップ機能は、通常、他のメカニズムを通じて処理されます。 この考え方をプロトコルに組み込むことで、クライアントとサーバー間でグラフィックスメモリを共有できるようになります。コンポジターがクライアントのコンテンツを画面に表示する際、グラフィックスメモリ内のある領域から別の領域へ単純にコピーするだけで済むのです。
これを最適に機能させるには、グラフィックスドライバがWaylandをサポートしている必要があります。このサポートは、EGL の拡張機能であるEXT_platform_wayland を通じて提供されます。
注：Qt Waylandは、EXT_platform_wayland がサポートされていないシステムにおいても、XComposite を利用するか、アプリケーションのコンテンツを共有CPUメモリにコピーすることで、コンポジティングをサポートしています。ただし、最適なパフォーマンスを得るためには、ドライバがサポートされているシステムの使用を推奨します。
X11は、コンポジティングやダイレクトレンダリングなどの機能をサポートするように拡張されてきましたが、Waylandはこのユースケースを念頭に置いて一から設計されています。また、長年にわたりX11で蓄積されてきた複雑さとは対照的に、軽量かつ拡張性の高いものとなることを目指しています。
拡張性と組み込みシステム
Waylandはコア部分が最小限で、拡張も容易であるため、組み込みLinuxプラットフォームを構築する際に理想的なツールとなります。
例えば、デスクトップスタイルのウィンドウシステム機能は、コアプロトコルの構成要素ではありません。その代わりに、Waylandには「シェル」と呼ばれる特別なカテゴリのプロトコル拡張があり、クライアントが自身のサーフェスを管理する手段を提供しています。 デスクトップスタイルの機能は、XDG Shell というシェルを通じて提供されます。他の種類のシステムでは、より専門的（そしておそらくより制約の多い）「シェル」を使用することができます。例えば、In-Vehicle Infotainment システムを構築する際には、IVI Shell の方が適しているかもしれません。
Waylandサーバーは、クライアントが接続した際に、サポートしているプロトコル（または「インターフェース」）のリストをブロードキャストし、クライアントは使用したいものにバインドできます。これは標準のインターフェースのいずれでも構いませんが、新しい拡張機能も簡単に追加できます。 Waylandでは、プロトコルを定義するためのわかりやすいXML形式が定義されており、waylandscanner ツールを使用してこれらからCコードを生成することができます。（Qtでは、追加のC++バインディングコードを生成するqtwaylandscanner も用意されています。）
クライアントがインターフェースにバインドすると、サーバーに対して「リクエスト」を送信でき、サーバーはクライアントに「イベント」を送信できます。リクエストやイベント、およびそれらの引数は、プロトコルを記述するXMLファイルで定義されています。
プラットフォームをゼロから構築する場合、サーバーとクライアントの両方のコードを制御できるなら、拡張機能を追加することは、オペレーティングシステムの機能を追加するための簡単かつ管理しやすい方法です。
マルチプロセスかシングルプロセスか
Qt を使用してシンプルな組み込みプラットフォームを構築する場合、UI のすべての部分を単一のプロセスで実行することも十分に現実的な選択肢です。しかし、システムが複雑になるにつれて、代わりにマルチプロセスシステムを検討したくなるかもしれません。そこで登場するのが Wayland です。 Qt を使用すれば、開発プロセスのどの段階でも、シングルプロセスとマルチプロセスの切り替えを選択できます。
マルチプロセスの利点
以下の図は、マルチプロセスシステムとシングルプロセスシステムの違いを示しています。
マルチプロセス・クライアント・アーキテクチャ
シングルプロセス・クライアントアーキテクチャ
この Qt Wayland Compositor モジュールは、組み込みLinux上のマルチプロセスシステムにおいて、ディスプレイサーバーやコンポジターを構築するのに最適です。マルチプロセスを採用することには、次のような利点があります：
| 安定性 | |
|---|---|
| クライアントがハングアップしたりクラッシュしたりした際の復旧が容易 | 複雑なUIを使用している場合、マルチプロセス方式が有用です。なぜなら、UIの一部がクラッシュしても、システム全体に影響が及ばないからです。同様に、1つのクライアントがフリーズしても、表示が固まることはありません。 注： クライアントが法律により安全上重要な情報を表示することが義務付けられている場合は 、 Qt Safe Rendererの使用を検討してください。 |
| メモリリークの可能性に対する保護 | マルチプロセスシステムでは、あるクライアントでメモリリークが発生し、大量のメモリを消費した場合でも、そのクライアントが終了するとメモリは解放されます。これに対し、シングルプロセスでは、システム全体が再起動するまでメモリリークが解消されません。 |
| セキュリティ |
|---|
| シングルプロセスシステムでは、すべてのクライアントが互いのメモリにアクセスできます。たとえば、機密データの転送に対する分離は存在せず、すべてのコード行が等しく信頼できる必要があります。マルチプロセスシステムでは、設計上、この分離が確保されています。 |
| パフォーマンス |
|---|
| マルチコアCPUを使用している場合、マルチプロセスシステムを利用することで、負荷を各コアに均等に分散させ、CPUをより効率的に活用することができます。 |
| 相互運用性 |
|---|
| マルチプロセスシステムでは、クライアントがWaylandまたはX11に対応していれば、Qt以外のクライアントとも連携できます。たとえば、動画再生にgstreamerを使用する場合や、別のUIツールキットで構築されたナビゲーションアプリケーションを使用したい場合でも、これらのクライアントを他のQtベースのクライアントと並行して実行することができます。 |
マルチプロセスのトレードオフ
シングルプロセスからマルチプロセスに移行する際は、以下のトレードオフを認識しておくことが重要です：
| ビデオメモリ消費量の増加 |
|---|
| これは、組み込みデバイスにとっては制約となる可能性があります。マルチプロセス環境では、各クライアントが独自のグラフィックスバッファを持ち、それをコンポジターに送信する必要があります。その結果、すべてが一度に描画され、各パーツを中間バッファに保存する必要がないシングルプロセスの場合と比較して、より多くのビデオメモリを使用することになります。 |
| メインメモリ消費量の増加 |
|---|
| OS レベルでの追加のオーバーヘッドに加え、複数のクライアントを実行すると、一部のコンポーネントがクライアントごとに 1 回ずつ複製される必要があるため、メインメモリの使用量も増加する可能性があります。たとえば、QML を実行する場合、各クライアントには個別の QML エンジンが必要です。したがって、Qt Quick コントロールを使用する単一のクライアントを実行する場合、その読み込みは 1 回で済みます。 このクライアントを複数のクライアントに分割すると、Qt Quick コントロールが複数回読み込まれることになり、クライアントの初期化にかかる起動コストが高くなります。 |
| グラフィックリソースの重複保存 |
|---|
| 単一プロセスシステムでは、同じテクスチャ、背景、またはアイコンを多くの場所で使用する場合、それらの画像は一度だけ保存されます。対照的に、マルチプロセスシステムでこれらの画像を使用する場合、それらを複数回保存する必要があります。この場合、解決策の一つとして、クライアント間でグラフィックリソースを共有することが挙げられます。 Qtでは、Waylandを利用せずに、メインメモリ上の画像リソースをプロセス間で共有することがすでに可能です。一方、GPUテクスチャをプロセス間で共有するには、より複雑な解決策が必要となります。Qtを使用すれば、そのような解決策を、例えばWayland拡張プロトコルやQQuickImageProvider などを用いて開発することができます。 |
| 入力から表示までの遅延 |
|---|
| 単一プロセスシステムでは、アプリケーションはメインフレームバッファに直接アクセスします。つまり、このような構成では、入力イベントから画面への反映までの遅延を最小限に抑えることができます。 マルチプロセスシステムでは、サーバーがバッファを読み取っている最中にクライアントがそこに描画してティアリングが発生しないよう、アプリケーションのコンテンツはトリプルバッファリングする必要があります。つまり、マルチプロセスシステムには暗黙的なレイテンシが存在することになります。 |
X11やカスタムソリューションではなくWaylandを使用する理由
前述の通り、X11は今日の一般的なシステム構成には最適とは言えません。非常に大規模で複雑であり、カスタマイズ性も欠けています。実際、X11ではクライアントをスムーズに実行し、ティアリングなしで60 fpsを達成することは困難です。 対照的に、Waylandは実装が容易で、パフォーマンスも優れており、最新のグラフィックスハードウェア上で効率的に動作するために必要な要素をすべて備えています。Linux上の組み込みマルチプロセスシステムにおいては、Waylandが標準となっています。
ただし、古いハードウェアやレガシーアプリケーションを扱う場合は、Waylandは適切な選択肢ではないかもしれません。 Waylandプロトコルは、セキュリティと分離性を重視して設計されており、クライアントが利用可能な情報や機能については厳格かつ保守的な仕様となっています。これにより、よりクリーンで安全なインターフェースが実現されますが、レガシーアプリケーションが期待する一部の機能は、Waylandでは利用できなくなる可能性があります。
特に、Waylandが最適な選択肢ではないと思われる一般的なユースケースが3つあります：
- ハードウェアやプラットフォームが古く、X11のみをサポートしている場合。この場合は他に選択肢がありません。
- セキュリティと簡潔さを追求したWaylandプロトコルには存在しない機能に依存するレガシーアプリケーションをサポートしなければならない場合。
- Waylandではまったく動作しないUIツールキットを使用するレガシーアプリケーションをサポートしなければならない場合。場合によっては、それらのアプリケーションを代わりにXWayland上で実行することで、この問題を回避できる可能性があります。
X11が広く普及していた当時、開発者たちはX11の問題を回避するために独自のカスタムソリューションを作成していました。古いバージョンのQtには「Qt Windowing System（QWS）」が搭載されていましたが、現在は廃止されています。現在では、こうしたユースケースのほとんどがWaylandによってカバーされており、カスタムソリューションはますます少なくなってきています。
Qt Waylandが提供する機能
クライアント向け
Qtクライアントは、Waylandプロジェクトの一環として開発されたリファレンスコンポジターであるWestonを含め、あらゆるWaylandコンポジター上で実行可能です。
どの Qt プログラムも、Wayland クライアント（マルチプロセスシステムの一部として）またはスタンドアロンクライアント（シングルプロセス）として実行できます。これは起動時に決定され、その際に異なるバックエンドから選択することができます。開発プロセスでは、まずデスクトップ上でクライアントを開発し、その後でターゲットハードウェア上でテストを行うことができます。 クライアントを常に実際のターゲットハードウェア上で実行する必要はありません。
シングルプロセス・クライアントの開発
Linuxマシンで開発を行う場合、開発マシンのウィンドウ内でコンポジターを実行することも可能です。これにより、ターゲットデバイスに非常に近い環境でクライアントを実行できます。クライアントを再ビルドすることなく、-platform wayland を使用してコンポジター内でクライアントを実行することも可能です。-platform xcb （X11用）を使用すれば、デスクトップ上でクライアントを実行できます。つまり、コンポジターが使用可能になる前に、クライアントの開発を開始することができます。
サーバー用
サーバー（コンポジター）はディスプレイに接続し、各クライアントのコンテンツを画面に表示します。コンポジターは入力を処理し、入力イベントを対応するクライアントに送信します。一方、各クライアントはコンポジターに接続し、自身のウィンドウのコンテンツを送信します。以下はコンポジターが決定する事項です：
- コンテンツをどのように、どこに表示するか
- どのコンテンツを表示するか
- 異なるクライアントのグラフィックバッファをどのように扱うか
つまり、マルチプロセスシステムとは何かを決定するのはコンポジター次第となります。例えば、クライアントは、壁面にウィンドウが表示された3Dシーンの一部であったり、VRシステム上であったり、球体にマッピングされていたりするなど、様々な形態が考えられます。
この Qt Wayland Compositor は、独自のコンポジターを構築するためのAPIです。これにより、カスタムコンポジターUIを自由に構築し、さまざまなクライアントのウィンドウを管理することができます。Qt Quick とQMLをQt Wayland Compositor と組み合わせて、印象的で独創的なUIを作成できます。詳細については、 Qt Wayland Compositorを参照してください。
また、Qt には、Wayland 拡張機能を実装し、Qml や C++ からそれらを利用するための、強力で使いやすい API が用意されています。
関連コンテンツ
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
