Wayland

Waylandとは

Waylandは、ディスプレイサーバとクライアント間の通信を規定するプロトコルであり、そのプロトコルをC言語で実装したライブラリでもあります。Waylandプロトコルを使用するディスプレイサーバは、コンポジット型ウィンドウマネージャの機能も持つため、Waylandコンポジタと呼ばれます。

概要

Waylandは、コンポジット型ウィンドウマネージャがアプリケーションやグラフィックスハードウェアと直接通信する方法を提供します。各アプリケーションは自身のバッファに画像を描画し、ウィンドウマネージャ（ディスプレイサーバ）がそれらのバッファを合成して画面に表示します。この方式は、従来のX Window Systemとコンポジット型ウィンドウマネージャを組み合わせるよりも効率的かつシンプルです。

Waylandはグラフィックス処理に特化しており、入力ハードウェアとの通信には他のライブラリを使用します。このプロジェクトは、Red Hatの開発者であるKristian Høgsbergによって2008年に開始されました。

2010年頃、Linuxデスクトップのグラフィックスは、Xサーバを介してレンダリングインターフェースが積み重なった状態から、XやWaylandのようなウィンドウシステムを介さずに、Linuxカーネルやそのコンポーネント（DRI、DRM）を直接利用する形へと移行しました。これにより、グラフィックシステムはよりシンプルで柔軟になり、パフォーマンスも向上しました。

Høgsbergは、Xへの拡張を追加するのではなく、クライアントとハードウェア間のホットパスからXを排除するアプローチを採用しました。この決定は、プロジェクトのFAQで明確に説明されています。

Waylandの初期バージョンではネットワーク透過性は提供されていませんでしたが、2010年にHøgsbergがネットワーク透過性の可能性を示唆し、2017年にはGNOMEがWayland上で初のピクセルスクレイピングVNCサーバーの実装を提示しました。

ソフトウェアアーキテクチャ

プロトコルアーキテクチャ

Waylandプロトコルは、クライアントサーバモデルに基づいています。クライアントは画面にピクセルバッファを表示するグラフィカルアプリケーションであり、サーバ（コンポジタ）はこれらのバッファの表示を制御するサービスプロバイダです。

Waylandのリファレンス実装は、2層のプロトコルとして設計されています。

下位レイヤ（ワイヤプロトコル）: クライアントとコンポジタ間のプロセス間通信とデータマーシャリングを扱います。
上位レイヤ: クライアントとコンポジタがウィンドウシステムの基本機能を実現するために交換する情報を扱います。このレイヤは、非同期オブジェクト指向プロトコルとして実装されています。

下位レイヤはC言語で手動で記述され、上位レイヤはXML形式で記述されたプロトコルの記述から自動生成されます。このXML記述が変更されると、プロトコルを実装したCのソースコードを再生成できます。これにより、プロトコルは非常に柔軟で拡張性が高く、エラーを防止できます。

Waylandプロトコルのリファレンス実装は、`libwayland-client`ライブラリ（Waylandクライアント用）と`libwayland-server`ライブラリ（Waylandコンポジタ用）の2つのライブラリで構成されています。

プロトコルの概要

Waylandプロトコルは、非同期オブジェクト指向プロトコルとして記述されています。コンポジタによって提供されるサービスは、コンポジタ上に存在するオブジェクトとして表現され、各オブジェクトはインタフェースを持ちます。

インタフェースは、名前、メソッド（リクエスト）、関連イベントを持ちます。リクエストとイベントはそれぞれ0個以上の引数を持ち、各引数には名前とデータ型があります。プロトコルが非同期であるため、リクエストは同期的な返信やACKを待つ必要がなく、ラウンドトリップタイムを回避しパフォーマンスが向上します。

クライアントは、オブジェクトがサポートするリクエストをオブジェクトに送信し、必要なデータを引数として提供します。コンポジタはイベント（引数付き）を発行して、クライアントに情報を返します。これらのイベントは、リクエストへの応答、または非同期の内部イベントや状態変化として発行されます。エラー状態もイベントとしてクライアントに通知されます。

オブジェクトにリクエストを送信するためには、クライアントは最初にサーバにオブジェクトを識別するためのIDを伝える必要があります。コンポジタには、グローバルオブジェクトと非グローバルオブジェクトの2種類があります。グローバルオブジェクトは、生成時（および破棄時）にコンポジタによってクライアントに通知されます。非グローバルオブジェクトは通常、既存のオブジェクトによって生成されます。

インタフェースとそのリクエストとイベントは、Waylandプロトコルの中心的な要素です。プロトコルの各バージョンには、すべてのWaylandコンポジタに存在することが期待されるインタフェース、リクエスト、イベントの集合が含まれています。コンポジタは、コアプロトコルを拡張するために、独自のインタフェースを定義して実装できます。

各インタフェースは、名前とバージョン番号を持ちます。コンポジタは、利用可能なインタフェースとそのバージョンを公開します。

Waylandコアインタフェース

現在のWaylandプロトコルで定義されている基本的なインタフェースは、`protocol/wayland.xml`で確認できます。これには、以下のものが含まれます。

`wl_display`: コアグローバルオブジェクトで、Waylandプロトコル自身をカプセル化します。
`wl_registry`: グローバルレジストリオブジェクトで、コンポジタがすべてのグローバルオブジェクトを格納します。
`wl_compositor`: コンポジタを表すオブジェクトで、異なるサーフェスを1つの出力に結合します。
`wl_surface`: 画面上の四角形の領域を表すオブジェクトで、位置、サイズ、描画内容で定義されます。
`wl_buffer`: `wl_surface`に貼り付けられたときに表示する内容を提供するオブジェクト。
`wl_output`: 画面の表示可能領域を表すオブジェクト。
`wl_pointer`, `wl_keyboard`, `wl_touch`: ポインタ、キーボード、タッチスクリーンなどの入力デバイスを表すオブジェクト。
`wl_seat`: 複数人が同時にコンピュータを使うシステムで、入出力デバイスの集合を表すオブジェクト。

標準的なWaylandクライアントセッションは、`wl_display`オブジェクトを使ってコンポジタに接続することから始まります。クライアントは、`wl_registry`グローバルオブジェクトを要求し、そこから必要なオブジェクト（通常は少なくとも1つの`wl_compositor`オブジェクト）を紐付けます。アプリケーションの出力を表示するために、`wl_compositor`オブジェクトから1つ以上の`wl_surface`オブジェクトを要求します。

Wayland拡張インタフェース

Waylandコンポジタは、独自の拡張インタフェースを定義して公開することができます。これにより、コアインタフェースの基本的な機能を超えてプロトコルを拡張できます。WaylandのリファレンスコンポジタであるWestonは、新しい概念やアイデアのテストベッドとしてカスタムインタフェースを使用しており、その多くが後にコアプロトコルに取り込まれています（例：`wl_subsurface`インタフェース）。

コアプロトコルの拡張プロトコル

XDG-Shellプロトコル

XDG-Shellプロトコルは、Waylandコンポジタでサーフェスを管理するための拡張機能です。従来のサーフェスの操作には`wl_shell_()`関数が使用されていましたが、XDG-Shellプロトコルはコンポジタによって提供されます。XDG-Shellプロトコルは、デスクトップスタイルのウィンドウ（移動、サイズ変更、最大化など）とポップアップおよびメニューを実現します。

IVI-Shellプロトコル

IVI-Shellは、車載インフォテインメント（IVI）デバイスを対象としたWaylandコアプロトコルの拡張です。

レンダリングモデル

Waylandプロトコルは、レンダリングAPIを提供していません。代わりに、ダイレクトレンダリングモデルを採用しています。クライアントは、ウィンドウコンテンツをコンポジタと共有できるバッファに描画する必要があります。

クライアントは、CairoやOpenGLなどのライブラリを使って自身でレンダリングすることも、QtやGTKなどの高位ウィジェットライブラリのレンダリングエンジンを利用することもできます。レンダリング結果のバッファは、`wl_buffer`オブジェクトに格納されます。バッファのデータ型は実装に依存しますが、クライアントとコンポジタ間で共有可能である必要があります。

クライアントがソフトウェアレンダラを使用する場合、共有メモリを使用してバッファをやり取りできます。クライアントがハードウェアアクセラレーションAPI（OpenGL、OpenGL ES、Vulkan）を使用する場合、GPUメモリバッファを共有できます。後者の方法は、コンポジタに余計なデータコピーをさせないため、グラフィックパフォーマンスが向上します。

レンダリングが完了したら、クライアントはバッファをサーフェスオブジェクトに紐付け、`commit`リクエストを送信してバッファの制御をコンポジタに転送します。レンダリングに使用される方法は、全体としてクライアントによって制御されます。

他のウィンドウシステムとの比較

WaylandとXの違い

WaylandとXには、パフォーマンス、コード保守性、セキュリティに関していくつかの違いがあります。

アーキテクチャ: Xではディスプレイサーバとコンポジットウィンドウマネージャが分離されていますが、Waylandではこれらを統合しています。また、Waylandはウィンドウマネージャの仕事を一部組み込み、Xではクライアントの仕事として分離しています。
コンポジット: Xではコンポジットはオプションですが、Waylandでは必須です。Waylandでは、コンポジタはクライアントから直接ピクセルデータを受動的に受け取ります。
レンダリング: Xサーバは自身でレンダリングでき、クライアントの描画済みウィンドウも表示できますが、WaylandはレンダリングAPIを提供せず、その仕事をクライアントに委譲します。ウィンドウ装飾は、クライアント側またはサーバ側（コンポジタ）でレンダリングできます。
セキュリティ: Waylandは、ウィンドウの入出力を独立させて機密性、整合性、可用性を実現します。Xにはこれらの機能が欠けており、拡張機能によって軽減されています。Waylandでは、コードの大部分がクライアント側で実行されるため、root権限で実行する必要のあるコードが少なく、セキュリティが向上します。
プロセス間通信: Xサーバはクライアント間の基本的な通信を提供しますが、Waylandコアプロトコルはクライアント間の通信をサポートしません。対応する機能は、デスクトップ環境やサードパーティによって提供されます。
ネットワーク: Xはネットワーク経由での動作を前提としていますが、Waylandはネットワーク透過性を持ちません。ただし、コンポジタはリモートディスプレイのためにリモートデスクトッププロトコルを実装できます。
Xとの互換性: XWaylandはWaylandクライアントとして動作するXサーバで、Waylandコンポジタ環境でX11クライアントアプリケーションを表示できます。

Waylandコンポジタ

Waylandプロトコルを実装したディスプレイサーバは、Waylandコンポジタと呼ばれます。代表的なコンポジタとして、以下のようなものがあります。

Weston: Waylandのリファレンス実装。
Lipstick: モバイルグラフィカルシェルフレームワーク。
Enlightenment: バージョン0.20からWaylandを完全にサポート。
KWin: ほとんど完全にWaylandをサポート。
Mutter: GNOMEで使用されるコンポジタ。
Clayland: Clutterを用いたシンプルなWaylandコンポジタ。
Westeros: Waylandコンポジタライブラリ。
wlroots: モジュール式Wayland実装。
Sway: タイル型Waylandコンポジタ。
gamescope: SteamOSの一部。

Weston

Westonは、Waylandプロジェクトによって開発されたリファレンス実装です。Linuxカーネルの機能に依存するため、公式にはLinuxのみをサポートします。Westonは、カーネルモードセッティング、GEM、udevを使用し、ハードウェア入力はevdev、バッファ運用はGBMに依存します。

Westonは、OpenGL ESまたはpixmanライブラリを使用してレンダリングを行い、クライアントは自身のウィンドウボーダーと装飾を描画する責任があります。リモートアクセスインタフェースも提案されています。

Maynard

Maynardは、Westonのプラグインとして書かれたグラフィカルシェルで、ラズベリーパイ財団が開発に取り組んでいます。

libinput

入力デバイスを扱うためのWestonコードは、libinputと呼ばれる独立したライブラリとして分けられています。libinputは、Waylandコンポジタのための入力デバイスを扱います。また、X.Orgサーバの入力ドライバも提供します。

Waylandセキュリティモジュール

Waylandセキュリティモジュールは、特権を必要とするアプリケーションを安全に処理するための方法を提供します。セキュリティ決定をセキュリティ決定エンジンに委譲します。

採用実績

Waylandプロトコルはシンプルであるため、ウィンドウシステム全体を構築するためには、追加のプロトコルやインタフェースが必要になります。

デスクトップLinuxディストリビューション

現在、ほとんどのLinuxディストリビューションはWaylandをサポートしています。

Fedora: GNOMEとKDEの両方でWaylandをデフォルトセッションとして使用しています。
Ubuntu: Waylandをデフォルトにした後にX.Orgに戻しましたが、後に再びWaylandをデフォルトにしました。
Red Hat Enterprise Linux: Waylandをデフォルトセッションにしています。
Debian: GNOMEのデフォルトセッションとしてWaylandを使用しています。
Slackware Linux: Waylandを開発版として組み込んでいます。
Manjaro: GnomeエディションでWaylandをデフォルトにしています。

ツールキットサポート

Waylandをサポートするツールキットには、Clutter、EFL、GTK 3.20、Qt 5、SDL、GLFW、FreeGLUTなどがあります。

デスクトップ環境

Waylandへの移行を進めているデスクトップ環境には、GNOME、KDE Plasma 5、Enlightenmentがあります。

その他のソフトウェア

Intelligent Input Bus: Waylandでの動作をサポート。
RealVNC: Wayland開発者プレビューを公開。
Maliit: Wayland下で動作するインプットメソッドフレームワーク。
kmscon: wltermにてWaylandをサポート。
Mesa: Waylandを統合してサポート。
Eclipse: Wayland上で動作するようにされた。
Vulkan WSI: Waylandサポートを最初から含む。
SPURV: Waylandを使用したLinuxディストリビューションで動くAndroidアプリケーション用の互換レイヤ。

携帯および組込ハードウェア

Waylandをサポートする携帯および組込ハードウェアには、postmarketOS、GENIVI、Raspberry Pi、Jolla、Tizenなどがあります。

履歴

Waylandは、Red HatのKristian Høgsbergによって2008年に開発が開始されました。当初の目標は、テアリング、ラグ、再描画、ちらつきのない完璧なシステムを提供することでした。プロジェクト名は、Høgsbergが運転していたマサチューセッツ州ウェイランドの街にちなんで名付けられました。

Waylandは、2010年にfreedesktop.orgのプロジェクトとなり、開発の場がGoogleグループからWayland-develメーリングリストに移行しました。WaylandのライブラリはMITライセンスでリリースされ、後にGPLコードもMITライセンスに再ライセンスされました。

Waylandは、DRI2サポートを通じてすべてのMesa 3D互換ドライバで動作し、Hybrisプロジェクトを通じてAndroidドライバでも動作します。

リリース

[TODO:リリース情報を追加]

参考文献

[TODO:参考文献を追加]