Wayland

Wayland は、ディスプレイサーバとクライアント間の通信方法を記述した通信プロトコルである。
また、そのプロトコルをCで実装したライブラリでもある。
Waylandプロトコルを使用したディスプレイサーバを"Waylandコンポジタ"と呼ぶ。
これは、このディスプレイサーバがコンポジット型ウィンドウマネージャの機能も持つためである。
Waylandは当初、Kristian Høgsberg率いるボランティアによって、フリーかつオープンソースコミュニティ主導のプロジェクトとして開発されていた。
このプロジェクトは、Linuxやその他のUnix系OSにおいて、X Window Systemをモダンで安全でよりシンプルなものに置き換えることを目的としている。プロジェクトのソースコードは、パーミッシブ・ライセンスのひとつであるMITライセンスで公開されている。
成果の一部として、Waylandプロジェクトは"Weston"と呼ばれるWaylandコンポジタのリファレンス実装も開発した。
概要.
Waylandは、コンポジット型ウィンドウマネージャが、アプリケーションやグラフィクスハードウェアと直接通信できるようにするための方法を提供する。Waylandはグラフィクス周りのみに特化しており、入力ハードウェアとの通信には他のライブラリを使用することを想定している。Wayland環境下ではコンポジット型ウィンドウマネージャがディスプレイサーバとなる。各アプリケーションは画像を自身のバッファに描画し、ウィンドウマネージャがディスプレイサーバとなり、各アプリケーションのバッファを合成してディスプレイ上のアプリケーションウィンドウを作り出す。これは、コンポジット型ウィンドウマネージャとX Window Systemを一緒に使う従来の方法より効率的かつシンプルである。
Waylandディスプレイサーバプロジェクトは、Red Hatの開発者であったKristian Høgsbergによって、2008年に開始された。
2010年頃、Linuxデスクトップのグラフィックスは、「中心にあるXサーバとやり取りするためだけの山積みのレンダリングインタフェース」を持つ状態から、"XやWaylandのようなウィンドウシステムを脇に退けて"、Linuxカーネルやそのコンポーネント
(たとえばダイレクト・レンダリング・インフラストラクチャ(DRI)、を"間に置く"ように移行した。その結果、"グラフィックシステムはシンプルになり、より柔軟性があり、より良いパフォーマンスを発揮する"ようになった。
Høgsbergは、多くの最近のプロジェクトと同様にを追加することもできたが、"クライアントとハードウェアの間のホットなパスからXを[締め出す]"ことを採用した。
その理由について、プロジェクトのFAQには以下のとおり記載されている。
Waylandの初期バージョンでは、を提供していなかった。
しかし、Høgsbergは、2010年にネットワーク透過性が可能であることを記した。
それは、2011年のGoogleサマーコードプロジェクトとして挑戦されたが成功しなかった。
Adam Jacksonは、(VNCのような)"ピクセルスクレイピング"や
(RDP、 X11のように)ネットワーク越しに"レンダリングコマンドストリーム"を送る方法で、Waylandアプリケーションへのリモートアクセスを目論んだ。
2013年初頭、Høgsbergは、本物のコンポジタへ圧縮画像を送るプロキシWaylandサーバーを使ってネットワーク透過性の実験を行った。
2017年8月、GNOMEはWayland下で最初のピクセルスクレイピングVNCサーバの実装を提示した。
ソフトウェア アーキテクチャ.
プロトコル アーキテクチャ.
Waylandプロトコルはクライアントサーバモデルである。クライアントはピクセルバッファを画面上へ表示するよう要求するグラフィカルアプリケーションであり、サーバ(コンポジタ)はこれらのバッファの表示を制御するサービスプロバイダである。
Waylandリファレンス実装は、2層のプロトコルとして設計された。すなわち、
下位レイヤはCで手作業で書かれたが、高位レイヤはXMLフォーマットで書かれたプロトコルの記述から自動生成された。
このXMLで書かれたプロトコルの記述が変更されたときは、いつでもプロトコルを実装したCのソースコードを再生成できる。これによって、非常にフレキシブルで、拡張性が高く、エラーを防止したプロトコルになる。
Waylandプロトコルのリファレンス実装は、2つのライブラリ、すなわち、Waylandクライアントによって使われるcodice_1ライブラリと、Waylandコンポジタによって使われるcodice_2ライブラリである。
プロトコルの概要.
Waylandプロトコルは、"非同期オブジェクト指向プロトコル"として記述されている。"オブジェクト指向"とは、コンポジタによって提供されるサービスが、同じコンポジタ上に存在する一連の"オブジェクト"としてもたらされることを意味する。
各オブジェクトは"インタフェース"を持つ。インタフェースは、名前と、いくつかのメソッド("リクエスト"と呼ばれる)、いくつかの関連したイベントを持つ。それぞれのリクエストとイベントは0以上の引数を持ち、それぞれに名前とデータ型がある。プロトコルが"非同期"とは、リクエストが、同期した返信やACKを待つ必要がないことを意味する。これによりラウンドトリップタイムを避け、パフォーマンスが改善する。
Waylandクライアントは、あるオブジェクトがサポートしているリクエストを、そのオブジェクトへリクエストできる(メソッドを呼び出せる)。クライアントは、必要とされるデータをリクエストの引数として提供しなければならない。これが、クライアントがコンポジタからサービスを要求する方法である。次に、コンポジタは、イベントを(おそらく引数付きで)発行するため、オブジェクトによって情報をクライアントへ返す。これらのイベントは、あるリクエストに対する反応や、あるいは非同期の (入力デバイスからのイベントといった)内部イベントや状態変化としてコンポジタによって発行される。エラー状態もコンポジタによってイベントとして通知される。
オブジェクトへリクエストを発行できるクライアントのために、最初に、オブジェクトを識別するために使うID番号をサーバに伝える必要がある。コンポジタには2種類のオブジェクトがある。グローバルオブジェクトと、非グローバルオブジェクトである。グローバルオジェクトは、生成時(そして廃棄時)にコンポジタによってクライアントへ通知される。一方、非グローバルオブジェクトは、通常、すでに機能の一部として存在している他のオブジェクトによって生成される。
インタフェースとその要求およびイベントは、Waylandプロトコルを定義する中心となる要素である。プロトコルの各バージョンは、どんなWaylandコンポジタにもあると期待されるインタフェースと、その要求およびイベントの集合を含んでいる。オプションとして、Waylandコンポジタは新しいリクエストとイベントをサポートする独自のインタフェースを定義して実装するかもしれない。それによって、コアプロトコル以上の機能へ拡張することができる。プロトコルの違いを管理するため、それぞれのインタフェースは名前に加えて"バージョン番号"属性を持っている。この属性により、同じインタフェースの派生版を区別できる。 各Waylandコンポジタは、どのインタフェースが使用可能かだけでなく、それらのインタフェースがサポートしているバージョンも公開する。
Waylandコアインタフェース.
現在のバージョンのWaylandプロトコルのインタフェースは、Waylandソースコードにあるで定義されている。これはXMLファイルであり、現在のバージョンに存在するインタフェースが、リクエスト、イベント、その他の属性と共にリストアップされている。このインタフェース集合は、どのWaylandコンポジタも最低限必要とされるインタフェースである。
いくつかのWaylandプロトコルでの最も基本的なインタフェースは、以下のとおりである。
標準的なWaylandクライアントセッションは、"wl_display"オブジェクトを使ってコンポジタに接続することで開始する。これは接続を表す特別なローカルオブジェクトであり、サーバー内には存在しない。このインタフェースを使うことで、クライアントはコンポジタから"wl_registry"グローバルオブジェクトを要求できる。"wl_registry"オブジェクトには、すべての名前があり存在しているグローバルオブジェクトが格納され、クライアントは望むオブジェクトを紐付ける。通常、クライアントは最低限1つの"wl_compositor"オブジェクトを紐付ける。アプリケーションの出力をディスプレイに表示するため、"wl_compositor"オブジェクトから、1つ以上の"wl_surface"オブジェクトを要求する。
Wayland拡張インタフェース.
Waylandコンポジタは、自身の追加インタフェースを定義して公開することができる。この特徴によって、コアインタフェースによって提供される基本機能を超えてプロトコルを拡張できる。そしてこれは、Waylandプロトコル拡張を実現する標準的な方法になった。コンポジタは、特化したあるいはユニークな特徴を提供するために、カスタムインタフェースを追加できる。WaylandリファレンスコンポジタであるWestonは、新しいコンセプトやアイデアのためのテストベンチとして、あたらしい実験的なインタフェースを実現するためにカスタムインタフェースを使用した。それらのコンセプトやアイデアは、その後にコアプロトコルの一部になった(たとえば"wl_subsurface"インタフェースは、Wayland 1.4で追加された)。
コアプロトコルの拡張プロトコル.
XDG-Shellプロトコル.
XDG-Shellプロトコル(XDGについてはfreedesktop.orgを見よ)は、Waylandコンポジタ(Westonに限らず)でサーフェイスを管理するための拡張手段である。サーフェイスを操作(最大化、最小化、フルスクリーンなど)するための伝統的な方法は、wl_shell_*()関数を使用することだった。この関数は、Waylandコアプロトコルの一部で、にある。対して、XDG-Shellプロトコルの実装は、Waylandコンポジタによって提供される。そのためヘッダがWestonソースツリーに含まれる。それぞれのWaylandコンポジタは自身の実装を提供することを想定している。
, XDG-Shellプロトコルはバージョン管理されておらず、まだ変更する可能性がある。
xdg_shellは、長期的にはwl_shellを置き換えることを目指したプロトコルである。しかし、現状ではxdg_shellは、Waylandコアプロトコルの一部ではない。xdg_shellは、開発版のAPIとして始まり、当初は開発用に使われた。これらの特徴がいくつかのデスクトップシェルによって要求されるとなれば、最終的には安定版へ移行できる。xdg_shellは、主に2つの新しいインタフェース:xdg_surfaceとxdg_popupを提供する。xdg_surfaceインタフェースは、動かせ、サイズ変更ができ、最大化等ができるデスクトップスタイルウィンドウを実現する。xdg_surfaceインタフェースは、親子関係を生成するためのリクエストを提供する。xdg_popupインタフェースは、デスクトップスタイルのポップアップとメニューを実現する。xdg_popupは、常に別のサーフェイスのための一時的なものであり、暗黙的なグラブを持つ。
IVI-Shellプロトコル.
IVI-Shellは、Waylandコアプロトコルの拡張で、車内エンターテインメント (IVI) デバイスをターゲットにしている。
レンダリングモデル.
Waylandプロトコルは、レンダリングAPIを含んでいない。その代わり、Waylandは"ダイレクトレンダリング"モデルを採用している。ダイレクトレンダリングモデルでは、クライアントはウィンドウコンテンツをコンポジタと共有できるバッファへ描画しなければならない。そのため、クライアントはCairoやOpenGLなどのライブラリを使って、自分自身ですべてをレンダリングすることも選択できる。あるいは、QtやGTKといった、Waylandをサポートする高位のウィジェットライブラリのレンダリングエンジンに頼ることもできる。クライアントは、特定のタスクをこなすために、オプションとしてその他の特化したライブラリを使用することもできる。たとえばフォントレンダリングのためにFreeTypeを使用できる。
レンダリングされたウィンドウコンテンツの結果(バッファ)は、"wl_buffer"オブジェクトに格納される。このオブジェクトのデータ型は、実装依存である。コンテンツデータがクライアントとコンポジタとの間で共有可能でなければならないことだけが唯一要求される。もしクライアントがソフトウェア(CPU)レンダラを使用し、その結果がシステムメモリに格納されるなら、クライアントとコンポジタは、バッファ間のやり取りを余分なコピーなしに実現するため、共有メモリを使用できる。Waylandプロトコルはすでにこの種の共有メモリバッファに何も追加することなしに対応している。共有メモリバッファは、"wl_shm"および"wl_shm_pool"インタフェースによって実現できる。この方法の欠点は、コンポジタはそれを表示するために追加の作業(通常、共有データのGPUへのコピー)を必要とする可能性があることである。これにより、グラフィックパフォーマンスは低下する。
最も一般的なケースでは、クライアントがOpenGL、OpenGL ES、Vulkanといったハードウェア(GPU)アクセレレーションのためのAPIを使って、ビデオメモリバッファへ直接レンダリングする。クライアントとコンポジタは、このGPU空間のバッファを参照するための特別なハンドラを用いて共有できる。この方法は、コンポジタに余計なデータコピーをしないようにする。結果として、グラフィックパフォーマンスは向上し、よりよい方法である。コンポジタはAPIクライアントとして、同じハードウェアアクセセレレーションAPIを使って、ディスプレイへ描画する最終的なシーンのコンポジションをかなり最適化できる。
レンダリングが共有バッファ内で完成したとき、Waylandクライアントはバッファのレンダリングされたコンテンツをディスプレイに表示するため、コンポジタを導くべきである。そのために、クライアントはレンダリングされたコンテンツを格納するバッファオブジェクトをサーフェイスオブジェクトに紐付ける。そして"commit"リクエストをサーフェイスに送り、バッファの制御をコンポジタヘ転送する。それから、クライアントは、もしまた別のフレームをレンダリングするためにバッファを再利用するなら、コンポジタがバッファを開放するのを待つ(イベントによって通知される)あるいは新しいフレームをレンダリングするため別のバッファを使用し、レンダリングが完了した時にこの新しいバッファをサーフェイスに紐付け、そのコンテンツをコミットすることもできる。数個の関連するバッファやその運用を含めて、レンダリングに使用される方法は、全体的にクライアントの制御下にある。
他のウィンドウシステムとの比較.
WaylandとXとの違い.
WaylandとXとの間には、パフォーマンス、コードの保守性、セキュリティに関して、いくつかの違いがある。
Xとの互換性.
XWaylandは、Waylandクライアントとして動作するXサーバである。XWaylandによって、Waylandコンポジタ環境でネイティブのX11クライアントアプリケーションを表示させることができる。これは、XQuartzがXアプリケーションをmacOSのネイティブウィンドウシステムで動かす方法に似ている。XWaylandのゴールは、移植されていないアプリケーションを実行する方法を提供することで、XウィンドウシステムからWayland環境への移行を促進することである。XWaylandは、X.Orgサーババージョン1.16に取り込まれた。
Qt5やGTK3といったウィジェット・ツールキットは、ユーザーがアプリケーションをX上あるいはWayland上で実行させるかに関わらず、ユーザがローダを選択することで、グラフィカルバックエンドを実行時に変更できる。Qt5は、この効果のためにコマンドラインオプションを提供している。一方、GTK 3は、環境変数を設定することで、ユーザがGDKバックエンドを使用するか選択可能にしている。
Waylandコンポジタ.
Waylandディスプレイサーバプロトコルを実装したディスプレイサーバは、"Waylandコンポジタ"とも呼ばれる。なぜなら、それらはコンポジット型ウィンドウマネージャの仕事もこなすからである。
Weston.
Westonは、Waylandコンポジタのリファレンス実装であり Waylandプロジェクトによって開発されている。Cで書かれており、MITライセンスの下で公開されている。Westonは、Linuxカーネルの特定の機能に依存しているため、公式にはLinuxのみサポートしている。Westonが依存している機能は、カーネルモードセッティング、Graphics Execution Manager (GEM) 、udevである。これらは、他のUnixライクOSには実装されていない。Linuxで実行するとき、evdevによってハードウェアの入力を運用する。一方、バッファの運用は、ジェネリックバッファマネジメント (GBM) に依存している。しかし、2013年にWestonのFreeBSD向けのプロトタイプportがアナウンスされた。
Westonは、HDCPをサポートしている。
Westonは、コンポジタとアプリケーション間のアプリケーションバッファを共有するためにGEMに依存している。ドックやパネルといった共通のデスクトップの機能のための"シェル"のプラグインシステムを含む。クライアントは、自身のウィンドウボーダや装飾の描画に対して責任を負う。Westonは、レンダリングのためOpenGL ESを使ったり、ソフトウェアレンダリングのためにpixmanライブラリを使ったりすることができる。完全なOpenGL実装は使われない。なぜなら、現在のほとんどのシステムでは完全なOpenGLライブラリをインストールしている場合、GLXやその他のXウィンドウシステムサポートライブラリを依存関係のためにインストールしているからである。
Westonのためのリモートアクセスインタフェースは、2013年10月にRealVNCの従業員によって提案された。
Maynard.
Maynardは、グラフィカルシェルである。Maynardは、GNOME ShellがMutterへのプラグインとして書かれたことと同様に、Westonのプラグインとして書かれた。
ラズベリーパイ財団は、Collaboraとのコラボレーションの中でMaynardをリリースし、パフォーマンスとメモリ使用量の改善に取り組んでいる。
libinput.
入力デバイス(キーボード、ポインタ、タッチスクリーン等)を扱うためのWestonコードは、"libinput"と呼ばれる独立したライブラリとして分けられている。Weston 1.5に始めてマージされた。
libinputは、Waylandコンポジタのための入力デバイスを扱う。また、汎用的なX.Orgサーバ入力ドライバを提供する。libinputの狙いは、入力イベントを扱う共通の方法でWaylandコンポジタ用の単一の実装を提供することである。これによりコンポジタ用にインプットコードをカスタムするための量を最小化する。libinputは、(udevを通じて)デバイスの検出、デバイスの運用、入力デバイスイベントの処理と抽象化を提供する。
libinputのバージョン1.0は、バージョン0.21の次にリリースされ、タブレット、ボタンセット、タッチパッドジェスチャのサポートを含んでいる。このバージョンは、安定したAPI/ABIを維持する(API/ABIが変わらない。)。
GNOME/GTKおよびKDEフレームワーク5が本流にしたことで、Fedora 22は、X.OrgのevdevとSynapticsドライバをlibinputに置き換えた。
バージョン1.16では、X.Orgサーバがと呼ばれるラッパによって、libinputライブラリをサポートした。
Waylandセキュリティモジュール.
Waylandセキュリティモジュールは、LinuxカーネルにおけるLinuxセキュリティモジュールインタフェースに似た位置づけである。
(とくにアクセシビリティに関連した)いくつかのアプリケーションは、高い権限(特権)を必要とする。これらの権限は、Waylandコンポジタに共通して持たれる。現在、Waylanにおけるアプリケーションは、一般的にスクリーンショットや入力イベントの発行といったセンシティブな処理は、いずれも実行できない。Waylandの開発者達は、特権を付与されたクライアントを安全に処理するための実行可能な方法を積極的に探しており、クライアント用の特権を持たせるインタフェースを設計している。
Wayland Security Moduleは、コンポジタ内でのセキュリティの決定を、一元化されたセキュリティ決定エンジンに移譲する方法である。
採用実績.
Waylandプロトコルは、シンプルであるように設計された。そのためウィンドウシステム全体を構築するためには、追加のプロトコルやインタフェースを定義し実装することが必要である。これらの追加のインタフェースは作成中である。そのため、ツールキットは既にWaylandを完全にサポートしている一方、グラフィカルシェルの開発者達は必要な追加のインタフェースを作るためにWaylandの開発者と協力している。
デスクトップLinuxディストリビューション.
ほとんどのLinuxディストリビューションは、Waylandをインストール直後からサポートしている。特筆すべき例を挙げると:
特筆するアーリーアダプター:
ツールキットサポート.
Waylandをサポートするツールキットの一部を以下に列挙する。
デスクトップ環境.
XからWaylandへの置き換えを進めているデスクトップ環境には、GNOME、KDE Plasma 5やEnlightenmentがある。
2015年11月、Enlightenment e20は、完全なWaylandサポートをアナウンスした。
GNOME 3.20は、完全なWaylandセッションを持つ最初のバージョンである。GNOME 3.22は、GTK, Mutter, GNOME Shellを通してWaylandのサポートを改善した。GNOME 3.24は、Wayland下での商用NVidiaドライバをサポートした。
先行してKWin 4.11 が実験的にWaylandをサポートしていたが、KDE PlasmaによるWaylandのサポートは、Plasma 5のリリースまで遅れた。
Plasma バージョン5.4は、Waylandセッションをサポートした最初のバージョンである。2020年の間、KlipperはWaylandへ移行し、次の2020年10月にリリースされる次の5.20ではスクリーンキャスティングとレコーディングを改良することを目標としている。
その他のソフトウェア.
Waylandをサポートするその他のソフトウェアは以下である。
携帯および組込ハードウェア.
Waylandをサポートする携帯および組込ハードウェアは、以下である。
履歴.
作者であるKristian Høgsbergは、LinuxのグラフィックとX.Orgの開発者であり、以前はAIGLXとDRI2で勤務していた。Red Hatで勤務しているとき、2008年の空いた時間のプロジェクトとしてWaylandの開発を始めた。最初の目標は、"すべてのフレームは完璧である、つまり、それによってアプリケーションは、テアリング、ラグ、再描画、ちらつきを二度と目にしないよう十分にレンダリングをコントロールできる"システムであった。根底となるコンセプトが"固まった"とき、Høgsbergはちょうどマサチューセッツ州Waylandの街を運転していたため、その名前がつけられた。
2010年10月に、Waylandはfreedesktop.orgのプロジェクトになった。移行の一環として、プロジェクトの中心となる議論と開発の場がGoogle グループから"Wayland-devel"メーリングリストに置き換えられた。
Waylandクライアントとサーバのライブラリは、当初MITライセンスの下でリリースされた一方、コンポジタのリファレンス実装であるWestonといくつかのクライアントの例は、GNU General Public License version 2を使用した。その後、すべてのGPLのコードは、"コードがリファレンス実装と実際のライブラリとの間をより容易に移動できるよう"MITライセンスに再ライセンスされた。2015年には、Waylandで使用していたラインセスの文言が、古いバージョンのMITライセンスとわずかに異なっていたことが見つかった。ライセンスの文言はX.Orgプロジェクトで使われてる(MIT Expat Licenseとして知られる)現在のバージョンのものへ更新された。
Waylandは、DRI2サポートによってすべてのMesa 3D互換ドライバで動作し、同様にHybrisプロジェクトを通じてAndroidドライバで動作する。