Wayland
[Wikipedia|▼Menu]
今や異なるのは、多くのインフラストラクチャがXサーバからカーネル(メモリ管理、コマンドスケジューリング、モードセッティング(英語版)やライブラリ(cairo, pixman, FreeType, Fontconfig, Pango等)に移行したことだ。そして中央サーバプロセスでしなければならないことは、ほとんど残っていない。一方、[Xサーバ]は、Xプロトコルで会話することをサポートしなければならず、膨大な量の機能がある。それらの機能はもはや誰も使わない...。それらの機能は、コードテーブル、グリフのラスタライズとキャッシング、XLFD (マジでXLFD!)、コアレンダリングAPI全体がある。コアレンダリングAPIは、点線、ポリゴン、大きな円弧、その他多くの1980年代スタイルの原始的なグラフィックを描くためのものである。多くのことに対して、我々はXRandRXRender、COMPOSIT(英語版)といった拡張を追加することでX.orgサーバをモダンにし続けてきた...。Waylandによって、我々はXサーバとすべてのレガシーテクノロジーをオプションへと移行できる。Xサーバがコアなレンダリングシステムから互換性のあるオプションに置き換わるまでは長い時間がかかるが、計画しなければ達成はできないのだ。

Waylandの初期バージョンでは、ネットワーク透過性(英語版)を提供していなかった。しかし、Hogsbergは、2010年にネットワーク透過性が可能であることを記した[12]。それは、2011年のGoogleサマーコードプロジェクトとして挑戦されたが成功しなかった[13]。Adam Jacksonは、(VNCのような)"ピクセルスクレイピング"や(RDP、SPICE(英語版) X11のように)ネットワーク越しにレンダリングコマンドストリームを送る方法で、Waylandアプリケーションへのリモートアクセスを目論んだ[14]。2013年初頭、Hogsbergは、本物のコンポジタへ圧縮画像を送るプロキシWaylandサーバーを使ってネットワーク透過性の実験を行った[15][16]。2017年8月、GNOMEはWayland下で最初のピクセルスクレイピングVNCサーバの実装を提示した。
ソフトウェア アーキテクチャ
プロトコル アーキテクチャWaylandプロトコルのアーキテクチャでは、クライアントとコンポジタがリファレンス実装ライブラリを使用して、Waylandプロトコルで通信する。

Waylandプロトコルはクライアントサーバモデルである。クライアントはピクセルバッファを画面上へ表示するよう要求するグラフィカルアプリケーションであり、サーバ(コンポジタ)はこれらのバッファの表示を制御するサービスプロバイダである。

Waylandリファレンス実装は、2層のプロトコルとして設計された。すなわち[17]

下位レイヤあるいはワイヤプロトコル: 関係する2つのプロセス?クライアントとコンポジタ?の間のプロセス間通信と、それらが内部で変えるデータのマーシャリング (英語版) を扱う。

その上の高位レイヤ: クライアントとコンポジタがウィンドウシステムの基本機能を実現するために交換する情報を扱う。このレイヤは、非同期オブジェクト指向プロトコルとして実装された[18]:9。

下位レイヤはCで手作業で書かれたが、高位レイヤはXMLフォーマットで書かれたプロトコルの記述から自動生成された[19]。このXMLで書かれたプロトコルの記述が変更されたときは、いつでもプロトコルを実装したCのソースコードを再生成できる。これによって、非常にフレキシブルで、拡張性が高く、エラーを防止したプロトコルになる。

Waylandプロトコルのリファレンス実装は、2つのライブラリ、すなわち、Waylandクライアントによって使われるlibwayland-clientライブラリと、Waylandコンポジタによって使われるlibwayland-serverライブラリである[18]:57。
プロトコルの概要

Waylandプロトコルは、"非同期オブジェクト指向プロトコルとして記述されている[18]:9。オブジェクト指向とは、コンポジタによって提供されるサービスが、同じコンポジタ上に存在する一連のオブジェクトとしてもたらされることを意味する。各オブジェクトはインタフェースを持つ。インタフェースは、名前と、いくつかのメソッド(リクエストと呼ばれる)、いくつかの関連したイベントを持つ。それぞれのリクエストとイベントは0以上の引数を持ち、それぞれに名前とデータ型がある。プロトコルが非同期とは、リクエストが、同期した返信やACKを待つ必要がないことを意味する。これによりラウンドトリップタイムを避け、パフォーマンスが改善する。

Waylandクライアントは、あるオブジェクトがサポートしているリクエストを、そのオブジェクトへリクエストできる(メソッドを呼び出せる)。クライアントは、必要とされるデータをリクエストの引数として提供しなければならない。これが、クライアントがコンポジタからサービスを要求する方法である。次に、コンポジタは、イベントを(おそらく引数付きで)発行するため、オブジェクトによって情報をクライアントへ返す。これらのイベントは、あるリクエストに対する反応や、あるいは非同期の (入力デバイスからのイベントといった)内部イベントや状態変化としてコンポジタによって発行される。エラー状態もコンポジタによってイベントとして通知される[18]:9。

オブジェクトへリクエストを発行できるクライアントのために、最初に、オブジェクトを識別するために使うID番号をサーバに伝える必要がある[18]:9。コンポジタには2種類のオブジェクトがある。グローバルオブジェクトと、非グローバルオブジェクトである。グローバルオジェクトは、生成時(そして廃棄時)にコンポジタによってクライアントへ通知される。一方、非グローバルオブジェクトは、通常、すでに機能の一部として存在している他のオブジェクトによって生成される[20]

インタフェースとその要求およびイベントは、Waylandプロトコルを定義する中心となる要素である。プロトコルの各バージョンは、どんなWaylandコンポジタにもあると期待されるインタフェースと、その要求およびイベントの集合を含んでいる。オプションとして、Waylandコンポジタは新しいリクエストとイベントをサポートする独自のインタフェースを定義して実装するかもしれない。それによって、コアプロトコル以上の機能へ拡張することができる[18]:10。プロトコルの違いを管理するため、それぞれのインタフェースは名前に加えてバージョン番号属性を持っている。この属性により、同じインタフェースの派生版を区別できる。 各Waylandコンポジタは、どのインタフェースが使用可能かだけでなく、それらのインタフェースがサポートしているバージョンも公開する[18]:12。
Waylandコアインタフェース

現在のバージョンのWaylandプロトコルのインタフェースは、Waylandソースコードにある.mw-parser-output .monospaced{font-family:monospace,monospace}protocol/wayland.xmlで定義されている。これはXMLファイルであり、現在のバージョンに存在するインタフェースが、リクエスト、イベント、その他の属性と共にリストアップされている。このインタフェース集合は、どのWaylandコンポジタも最低限必要とされるインタフェースである。

いくつかのWaylandプロトコルでの最も基本的なインタフェースは、以下のとおりである[18]

wl_display – コアグローバルオブジェクト。Waylandプロトコル自身をカプセル化した特別なオブジェクトである。

wl_registry – グローバルレジストリオブジェクト。すべてのクライアントが利用できるよう、コンポジタがすべてのグローバルオブジェクトを格納する。

wl_compositor – コンポジタを表すオブジェクト。異なるサーフェイスを1つの出力へと結合することを担当する。

wl_surface – 画面上の四角形の領域を表すオブジェクト。位置、サイズ、描画内容(ピクセル)によって定義される。

wl_buffer – wl_surfaceに貼り付けたとき、表示する内容を提供するオブジェクト。

wl_output – 画面の表示可能領域を表すオブジェクト。

wl_pointer, wl_keyboard, wl_touch – ポインタキーボードといった入力デバイスを表すオブジェクト。

wl_seat – 1台のコンピュータを複数人で同時に使うシステム(英語版)において、1つのシート(入出力デバイスの集合)を表すオブジェクト。

標準的なWaylandクライアントセッションは、wl_displayオブジェクトを使ってコンポジタに接続することで開始する。これは接続を表す特別なローカルオブジェクトであり、サーバー内には存在しない。このインタフェースを使うことで、クライアントはコンポジタからwl_registryグローバルオブジェクトを要求できる。wl_registryオブジェクトには、すべての名前があり存在しているグローバルオブジェクトが格納され、クライアントは望むオブジェクトを紐付ける。通常、クライアントは最低限1つのwl_compositorオブジェクトを紐付ける。アプリケーションの出力をディスプレイに表示するため、wl_compositorオブジェクトから、1つ以上のwl_surfaceオブジェクトを要求する[20]
Wayland拡張インタフェース

Waylandコンポジタは、自身の追加インタフェースを定義して公開することができる[18]:10。この特徴によって、コアインタフェースによって提供される基本機能を超えてプロトコルを拡張できる。そしてこれは、Waylandプロトコル拡張を実現する標準的な方法になった。コンポジタは、特化したあるいはユニークな特徴を提供するために、カスタムインタフェースを追加できる。WaylandリファレンスコンポジタであるWestonは、新しいコンセプトやアイデアのためのテストベンチとして、あたらしい実験的なインタフェースを実現するためにカスタムインタフェースを使用した。それらのコンセプトやアイデアは、その後にコアプロトコルの一部になった(たとえばwl_subsurfaceインタフェースは、Wayland 1.4で追加された)[21]
コアプロトコルの拡張プロトコル
XDG-Shellプロトコル

XDG-Shellプロトコル(XDGについてはfreedesktop.orgを見よ)は、Waylandコンポジタ(Westonに限らず)でサーフェイスを管理するための拡張手段である。サーフェイスを操作(最大化、最小化、フルスクリーンなど)するための伝統的な方法は、wl_shell_*()関数を使用することだった。この関数は、Waylandコアプロトコルの一部で、libwayland-clientにある。


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:130 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef