トップQs
タイムライン
チャット
視点
Wayland
ディスプレイサーバとクライアント間の通信プロトコル、およびこれを実装したライブラリ ウィキペディアから
Remove ads
Wayland は、ディスプレイサーバとクライアント間の通信方法を記述した通信プロトコルである。 また、そのプロトコルをCで実装したライブラリでもある。 Waylandプロトコルを使用したディスプレイサーバをWaylandコンポジタと呼ぶ。 これは、このディスプレイサーバがコンポジット型ウィンドウマネージャの機能も持つためである。
Waylandは当初、Kristian Høgsberg率いるボランティアによって、自由かつオープンソースコミュニティ主導のプロジェクトとして開発されていた。 このプロジェクトは、Linuxやその他のUnix系OSにおいて、X Window Systemをモダンで安全で[5][6][7][8]よりシンプルなものに置き換えることを目的としている。プロジェクトのソースコードは、パーミッシブ・ライセンスのひとつであるMITライセンスで公開されている[9][4]。
成果の一部として、WaylandプロジェクトはWestonと呼ばれるWaylandコンポジタのリファレンス実装も開発した。
Remove ads
概要
要約
視点
- Linuxカーネルのevdevモジュールは、イベントを受けとり、Waylandコンポジタへ送る。
- Waylandコンポジタはシーングラフを見渡し、どのウィンドウがそのイベントを受け取るべきかを決定する。 シーングラフは画面に表示されているものに対応しており、Waylandコンポジタはイベントが適用されるシーングラフ内の要素との変換が分かる。そのため、Waylandコンポジタは逆変換することで、正しいウィンドウが分かり画面上の座標をウィンドウ内の座標へ変換することができる。ウィンドウに適用できる変換は、コンポジターが適用できることだけに限られ、入力イベントに対して逆変換できることに限られます。
- Xの場合、クライアイントはイベントを受け取ると、反応してUIを更新する。しかし、Waylandの場合、クライアントはEGLを通じてレンダリングし、コンポジタへ更新された範囲を通知するために要求を送るだけである。
- Waylandコンポジタはクライアントから変更箇所のリクエストを集め、スクリーンを再構成する。それからコンポジタは、KMSによる画面の再描画をスケジューリングするため、ioctlを直接発行する。
コンポジット型ウィンドウマネージャがアプリケーションやグラフィクスハードウェアと直接通信できる方法を、Waylandが提供する。具体的には、各アプリケーションは自身のバッファに画像を描画し、ウィンドウマネージャがディスプレイサーバとしてそれらバッファを合成して、ディスプレイ上に各アプリケーションウィンドウを作り出す。これは、コンポジット型ウィンドウマネージャとX Window Systemを一緒に使う従来の方法より効率的かつシンプルである[10]。
Waylandはグラフィクス周りのみに特化しており、入力ハードウェアとの通信には他のライブラリを使用することを想定している。
Waylandディスプレイサーバプロジェクトは、Red Hatの開発者であったKristian Høgsbergによって、2008年に開始された[11]。
2010年頃、Linuxデスクトップのグラフィックスは、「中心にあるXサーバとやり取りするためだけの山積みのレンダリングインタフェース」を持つ状態から、"XやWaylandのようなウィンドウシステムを脇に退けて"、Linuxカーネルやそのコンポーネント (たとえばダイレクト・レンダリング・インフラストラクチャ(DRI)、ダイレクト・レンダリング・マネージャ(DRM)を"間に置く"ように移行した。その結果、"グラフィックシステムはシンプルになり、より柔軟性があり、より良いパフォーマンスを発揮する"ようになった[12]。
Høgsbergは、多くの最近のプロジェクトと同様にXへの拡張を追加することもできたが、"クライアントとハードウェアの間のホットなパスからXを[締め出す]"ことを採用した。 その理由について、プロジェクトのFAQには以下のとおり記載されている[9]。
今や異なるのは、多くのインフラストラクチャがXサーバからカーネル(メモリ管理、コマンドスケジューリング、モードセッティングやライブラリ(cairo, pixman, FreeType, Fontconfig, Pango等)に移行したことだ。そして中央サーバプロセスでしなければならないことは、ほとんど残っていない。一方、[Xサーバ]は、Xプロトコルで会話することをサポートしなければならず、膨大な量の機能がある。それらの機能はもはや誰も使わない...。 それらの機能は、コードテーブル、グリフのラスタライズとキャッシング、XLFD (マジでXLFD!)、コアレンダリングAPI全体がある。コアレンダリングAPIは、点線、ポリゴン、大きな円弧、その他多くの1980年代スタイルの原始的なグラフィックを描くためのものである。
多くのことに対して、我々はXRandR、XRender、COMPOSITといった拡張を追加することでX.orgサーバをモダンにし続けてきた...。Waylandによって、我々はXサーバとすべてのレガシーテクノロジーをオプションへと移行できる。Xサーバがコアなレンダリングシステムから互換性のあるオプションに置き換わるまでは長い時間がかかるが、計画しなければ達成はできないのだ。
Waylandの初期バージョンでは、ネットワーク透過性を提供していなかった。 しかし、Høgsbergは、2010年にネットワーク透過性が可能であることを記した[13]。 それは、2011年のGoogleサマーコードプロジェクトとして挑戦されたが成功しなかった[14]。 Adam Jacksonは、(VNCのような)"ピクセルスクレイピング"や (RDP、SPICE X11のように)ネットワーク越しに"レンダリングコマンドストリーム"を送る方法で、Waylandアプリケーションへのリモートアクセスを目論んだ[15]。 2013年初頭、Høgsbergは、本物のコンポジタへ圧縮画像を送るプロキシWaylandサーバーを使ってネットワーク透過性の実験を行った[16][17]。 2017年8月、GNOMEはWayland下で最初のピクセルスクレイピングVNCサーバの実装を提示した。
Remove ads
ソフトウェア アーキテクチャ
要約
視点
プロトコル アーキテクチャ
Waylandプロトコルはクライアントサーバモデルである。クライアントはピクセルバッファを画面上へ表示するよう要求するグラフィカルアプリケーションであり、サーバ(コンポジタ)はこれらのバッファの表示を制御するサービスプロバイダである。
Waylandリファレンス実装は、2層のプロトコルとして設計された。すなわち[18]、
- 下位レイヤあるいはワイヤプロトコル: 関係する2つのプロセス—クライアントとコンポジタ—の間のプロセス間通信と、それらが内部で変えるデータのマーシャリング (英語版) を扱う。
- その上の高位レイヤ: クライアントとコンポジタがウィンドウシステムの基本機能を実現するために交換する情報を扱う。このレイヤは、"非同期オブジェクト指向プロトコル"として実装された[19]:9。
下位レイヤはCで手作業で書かれたが、高位レイヤはXMLフォーマットで書かれたプロトコルの記述から自動生成された[20]。 このXMLで書かれたプロトコルの記述が変更されたときは、いつでもプロトコルを実装したCのソースコードを再生成できる。これによって、非常にフレキシブルで、拡張性が高く、エラーを防止したプロトコルになる。
Waylandプロトコルのリファレンス実装は、2つのライブラリ、すなわち、Waylandクライアントによって使われるlibwayland-clientライブラリと、Waylandコンポジタによって使われるlibwayland-serverライブラリである[19]:57。
プロトコルの概要
Waylandプロトコルは、"非同期オブジェクト指向プロトコル"として記述されている[19]:9。オブジェクト指向とは、コンポジタによって提供されるサービスが、同じコンポジタ上に存在する一連のオブジェクトとしてもたらされることを意味する。 各オブジェクトはインタフェースを持つ。インタフェースは、名前と、いくつかのメソッド(リクエストと呼ばれる)、いくつかの関連したイベントを持つ。それぞれのリクエストとイベントは0以上の引数を持ち、それぞれに名前とデータ型がある。プロトコルが非同期とは、リクエストが、同期した返信やACKを待つ必要がないことを意味する。これによりラウンドトリップタイムを避け、パフォーマンスが改善する。
Waylandクライアントは、あるオブジェクトがサポートしているリクエストを、そのオブジェクトへリクエストできる(メソッドを呼び出せる)。クライアントは、必要とされるデータをリクエストの引数として提供しなければならない。これが、クライアントがコンポジタからサービスを要求する方法である。次に、コンポジタは、イベントを(おそらく引数付きで)発行するため、オブジェクトによって情報をクライアントへ返す。これらのイベントは、あるリクエストに対する反応や、あるいは非同期の (入力デバイスからのイベントといった)内部イベントや状態変化としてコンポジタによって発行される。エラー状態もコンポジタによってイベントとして通知される[19]:9。
オブジェクトへリクエストを発行できるクライアントのために、最初に、オブジェクトを識別するために使うID番号をサーバに伝える必要がある[19]:9。コンポジタには2種類のオブジェクトがある。グローバルオブジェクトと、非グローバルオブジェクトである。グローバルオジェクトは、生成時(そして廃棄時)にコンポジタによってクライアントへ通知される。一方、非グローバルオブジェクトは、通常、すでに機能の一部として存在している他のオブジェクトによって生成される[21]。
インタフェースとその要求およびイベントは、Waylandプロトコルを定義する中心となる要素である。プロトコルの各バージョンは、どんなWaylandコンポジタにもあると期待されるインタフェースと、その要求およびイベントの集合を含んでいる。オプションとして、Waylandコンポジタは新しいリクエストとイベントをサポートする独自のインタフェースを定義して実装するかもしれない。それによって、コアプロトコル以上の機能へ拡張することができる[19]:10。プロトコルの違いを管理するため、それぞれのインタフェースは名前に加えて"バージョン番号"属性を持っている。この属性により、同じインタフェースの派生版を区別できる。 各Waylandコンポジタは、どのインタフェースが使用可能かだけでなく、それらのインタフェースがサポートしているバージョンも公開する[19]:12。
Waylandコアインタフェース
現在のバージョンのWaylandプロトコルのインタフェースは、Waylandソースコードにあるprotocol/wayland.xmlで定義されている。これはXMLファイルであり、現在のバージョンに存在するインタフェースが、リクエスト、イベント、その他の属性と共にリストアップされている。このインタフェース集合は、どのWaylandコンポジタも最低限必要とされるインタフェースである。
いくつかのWaylandプロトコルでの最も基本的なインタフェースは、以下のとおりである[19]。
- 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オブジェクトを要求する[21]。
Wayland拡張インタフェース
Waylandコンポジタは、自身の追加インタフェースを定義して公開することができる[19]:10。この特徴によって、コアインタフェースによって提供される基本機能を超えてプロトコルを拡張できる。そしてこれは、Waylandプロトコル拡張を実現する標準的な方法になった。コンポジタは、特化したあるいはユニークな特徴を提供するために、カスタムインタフェースを追加できる。WaylandリファレンスコンポジタであるWestonは、新しいコンセプトやアイデアのためのテストベンチとして、あたらしい実験的なインタフェースを実現するためにカスタムインタフェースを使用した。それらのコンセプトやアイデアは、その後にコアプロトコルの一部になった(たとえばwl_subsurfaceインタフェースは、Wayland 1.4で追加された)[22]。
コアプロトコルの拡張プロトコル
XDG-Shellプロトコル
XDG-Shellプロトコル(XDGについてはfreedesktop.orgを見よ)は、Waylandコンポジタ(Westonに限らず)でサーフェイスを管理するための拡張手段である。サーフェイスを操作(最大化、最小化、フルスクリーンなど)するための伝統的な方法は、wl_shell_*()関数を使用することだった。この関数は、Waylandコアプロトコルの一部で、libwayland-clientにある。対して、XDG-Shellプロトコルの実装は、Waylandコンポジタによって提供される。そのためxdg-shell-client-protocol.hヘッダがWestonソースツリーに含まれる。それぞれのWaylandコンポジタは自身の実装を提供することを想定している。
2014年6月現在[update], 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は、常に別のサーフェイスのための一時的なものであり、暗黙的なグラブを持つ[23]。
IVI-Shellプロトコル
IVI-Shellは、Waylandコアプロトコルの拡張で、車内エンターテインメント (IVI) デバイス[24]をターゲットにしている。
レンダリングモデル
Waylandプロトコルは、レンダリングAPIを含んでいない[19]:7[9][25][26]。その代わり、Waylandはダイレクトレンダリングモデルを採用している。ダイレクトレンダリングモデルでは、クライアントはウィンドウコンテンツをコンポジタと共有できるバッファへ描画しなければならない[19]:7。そのため、クライアントはCairoやOpenGLなどのライブラリを使って、自分自身ですべてをレンダリングすることも選択できる。あるいは、QtやGTKといった、Waylandをサポートする高位のウィジェットライブラリのレンダリングエンジンに頼ることもできる。クライアントは、特定のタスクをこなすために、オプションとしてその他の特化したライブラリを使用することもできる。たとえばフォントレンダリング(英語版)のためにFreeTypeを使用できる。
レンダリングされたウィンドウコンテンツの結果(バッファ)は、wl_bufferオブジェクトに格納される。このオブジェクトのデータ型は、実装依存である。コンテンツデータがクライアントとコンポジタとの間で共有可能でなければならないことだけが唯一要求される。もしクライアントがソフトウェア(CPU)レンダラを使用し、その結果がシステムメモリに格納されるなら、クライアントとコンポジタは、バッファ間のやり取りを余分なコピーなしに実現するため、共有メモリを使用できる。Waylandプロトコルはすでにこの種の共有メモリバッファに何も追加することなしに対応している。共有メモリバッファは、wl_shmおよびwl_shm_poolインタフェースによって実現できる[19]:11, 20-21。この方法の欠点は、コンポジタはそれを表示するために追加の作業(通常、共有データのGPUへのコピー)を必要とする可能性があることである。これにより、グラフィックパフォーマンスは低下する。
最も一般的なケースでは、クライアントがOpenGL、OpenGL ES、Vulkanといったハードウェア(GPU)アクセラレーションのためのAPIを使って、ビデオメモリバッファへ直接レンダリングする。クライアントとコンポジタは、このGPU空間のバッファを参照するための特別なハンドラを用いて共有できる[27]。この方法は、コンポジタに余計なデータコピーをしないようにする。結果として、グラフィックパフォーマンスは向上し、よりよい方法である。コンポジタはAPIクライアントとして、同じハードウェアアクセラレーションAPIを使って、ディスプレイへ描画する最終的なシーンのコンポジションをかなり最適化できる。
レンダリングが共有バッファ内で完成したとき、Waylandクライアントはバッファのレンダリングされたコンテンツをディスプレイに表示するため、コンポジタを導くべきである。そのために、クライアントはレンダリングされたコンテンツを格納するバッファオブジェクトをサーフェイスオブジェクトに紐付ける。そして"commit"リクエストをサーフェイスに送り、バッファの制御をコンポジタヘ転送する[18]。それから、クライアントは、もしまた別のフレームをレンダリングするためにバッファを再利用するなら、コンポジタがバッファを開放するのを待つ(イベントによって通知される)あるいは新しいフレームをレンダリングするため別のバッファを使用し、レンダリングが完了した時にこの新しいバッファをサーフェイスに紐付け、そのコンテンツをコミットすることもできる[19]:7。数個の関連するバッファやその運用を含めて、レンダリングに使用される方法は、全体的にクライアントの制御下にある[19]:7。
Remove ads
他のウィンドウシステムとの比較
要約
視点
→「Mirソフトウェアアーキテクチャ(英語版)」および「Mirをめぐる論争(英語版)」も参照
WaylandとXとの違い
WaylandとXとの間には、パフォーマンス、コードの保守性、セキュリティに関して、いくつかの違いがある[28]。
- アーキテクチャ
- Xのディスプレイサーバとコンポジット型ウィンドウマネージャは分離している一方、Waylandはディスプレイサーバとコンポジタを単一の機能として統合している[29][25]。また、Waylandは、ウィンドウマネージャの仕事のいくつかを組み込んでいる。一方、Xは、クライアント側の仕事として分離されている[30]。
- コンポジット
- Xではコンポジットはオプションであるが、Waylandでは必須である。Xではコンポジタはピクセルデータを"能動的"に取り出さなければならないため遅延が生まれる。Waylandでは、コンポジタはピクセルデータを"受動的"にクライアントから直接受け取る[31]。
- レンダリング
- Xサーバは自身でレンダリングができ、さらにクライアントによって送られたレンダリングされたウィンドウを表示するために構築することもできる。対して、WaylandはレンダリングのためのAPIは表に出しておらず、そうした仕事を(フォント、ウィジェット、等のレンダリングを含めて)クライアントに委譲している[29][25]。ウィンドウの装飾は、(たとえば、グラフィカルツールキットを使って)クライアント側でレンダリングできるし、(コンポジタによって)サーバサイドでもできる[32]。
- セキュリティ
- Waylandは、各ウィンドウの入出力から独立しており、入力・出力それぞれの機密性、整合性、および可用性を実現する。オリジナルのXの設計では、これらの重要なセキュリティの特徴が欠けており[6][7][8]、いくつかの拡張が、それを軽減すべく開発されてきた[33][34][35]。また、Waylandは、コードの大部分がクライアント側で実行されており、「root」権限で実行する必要のあるコードが少なくなり、セキュリティが向上する[6]。一方、複数の一般的なLinuxディストリビューションでは、現在はXをroot権限なしに実行できる[36][37][38][39]。
- プロセス間通信
- Xサーバは、Xクライアント同士の基本的な通信方法を提供する。後にICCCMによって拡張された。このXクライアント-クライアント通信は、ウィンドウマネージャによって使われる。また、Xセッション(英語版)、ウィンドウの選択とドラッグアンドドロップ(英語版)、その他の機能を実現する。Waylandコアプロトコルは、Waylandクライアント間の通信をサポートしない。対応する機能は(もし必要であれば)(KDEやGNOMEといった)デスクトップ環境や(たとえばOSのプロセス間通信といった)サードパーティによって実現される。
- ネットワーク
- Xウィンドウシステムは、ネットワーク越しにコア部分が実行されるよう設計されたアーキテクチャである。Waylandは、それ自身ではネットワーク透過性を持たない[9]。しかし、コンポジタは、リモートディスプレイを実現するためにどんなリモートデスクトッププロトコルも実現できる。加えて、Waylandイメージストリーミングとイメージ圧縮の研究がある。この研究は、Virtual Network ComputingVNCのようにリモートフレームバッファアクセスを実現し得る[17]。
Xとの互換性
XWaylandは、Waylandクライアントとして動作するXサーバである。XWaylandによって、Waylandコンポジタ環境でネイティブのX11クライアントアプリケーションを表示させることができる[40]。これは、XQuartzがXアプリケーションをmacOSのネイティブウィンドウシステムで動かす方法に似ている。XWaylandのゴールは、移植されていないアプリケーションを実行する方法を提供することで、XウィンドウシステムからWayland環境への移行を促進することである。XWaylandは、X.Orgサーババージョン1.16に取り込まれた[41]。
Qt5やGTK3といったウィジェット・ツールキットは、ユーザーがアプリケーションをX上あるいはWayland上で実行させるかに関わらず、ユーザがローダを選択することで、グラフィカルバックエンドを実行時に変更できる[42]。Qt5は、この効果のために-platformコマンドラインオプション[43]を提供している。一方、GTK 3は、GDK_BACKEND環境変数を設定することで、ユーザがGDK(英語版)バックエンドを使用するか選択可能にしている[42][44]。
Waylandコンポジタ
要約
視点
.svg)
Waylandディスプレイサーバプロトコルを実装したディスプレイサーバは、Waylandコンポジタとも呼ばれる。なぜなら、それらはコンポジット型ウィンドウマネージャの仕事もこなすからである。
- Weston – Waylandコンポジタのリファレンス実装である。Westonは、クライアントサイド・デコレーションを実現する。
- Lipstick – Waylandコンポジタを実装したモバイルグラフィカルシェルフレームワークである。これは、Sailfish OS(英語版), Nemo Mobile(英語版), AsteroidOSで使われる[45]。
- Enlightenment は、バージョン0.20から、完全にWaylandをサポートしている[46]。しかし、完全なWaylandコンポジタになるための作業は続けられている[47]。
- KWin は、2021年現在、ほとんど完全にWaylandサポートを完了した[48]。
- Mutter は、(2013年9月に)GNOME 3.9にWaylandを統合するためのブランチを切った状態である[49]。
- Clayland(英語版) – Clutterを用いたWaylandコンポジタのシンプルな例である。
- Westeros – Waylandコンポジタライブラリである。Westerosによって、アプリケーションが自身のWayland表示を作ることが可能になる。それによりサードパーティアプリケーションのネストと埋め込みを可能にする[50]。
- wlroots – モジュラWayland実装である。wlrootsは、他のコンポジタ、とくにSwayのためのベースとして関数である[51][52]。
- Sway – タイル型Waylandコンポジタである。また、X11のためのi3ウィンドウマネージャの置き換えである[53]。
- gamescope – SteamOSの一部である。初期のsteamcompmgrの置き換えである[54]。
Weston
Westonは、Waylandコンポジタのリファレンス実装であり[55] Waylandプロジェクトによって開発されている。Cで書かれており、MITライセンスの下で公開されている。Westonは、Linuxカーネルの特定の機能に依存しているため、公式にはLinuxのみサポートしている。Westonが依存している機能は、カーネルモードセッティング(英語版)、Graphics Execution Manager (GEM) 、udevである。これらは、他のUnixライクOSには実装されていない[56]。Linuxで実行するとき、evdev(英語版)によってハードウェアの入力を運用する。一方、バッファの運用は、ジェネリックバッファマネジメント (GBM) (英語版)に依存している。しかし、2013年にWestonのFreeBSD向けのプロトタイプportがアナウンスされた[57]。
Westonは、コンポジタとアプリケーション間のアプリケーションバッファを共有するためにGEMに依存している。ドックやパネルといった共通のデスクトップの機能のための"シェル"のプラグインシステムを含む[17]。クライアントは、自身のウィンドウボーダや装飾の描画に対して責任を負う。Westonは、レンダリングのためOpenGL ES[59]を使ったり、ソフトウェアレンダリング(英語版)のためにpixmanライブラリ[60]を使ったりすることができる。完全なOpenGL実装は使われない。なぜなら、現在のほとんどのシステムでは完全なOpenGLライブラリをインストールしている場合、GLXやその他のXウィンドウシステムサポートライブラリを依存関係のためにインストールしているからである[61]。
Westonのためのリモートアクセスインタフェースは、2013年10月にRealVNC(英語版)の従業員によって提案された[62]。
Maynard
Maynardは、グラフィカルシェルである。Maynardは、GNOME ShellがMutterへのプラグインとして書かれたことと同様に、Westonのプラグインとして書かれた[63]。 ラズベリーパイ財団は、Collabora(英語版)とのコラボレーションの中でMaynardをリリースし、パフォーマンスとメモリ使用量の改善に取り組んでいる[64][65]。
libinput
入力デバイス(キーボード、ポインタ、タッチスクリーン等)を扱うためのWestonコードは、libinputと呼ばれる独立したライブラリとして分けられている。Weston 1.5に初めてマージされた[66][67]。
libinputは、Waylandコンポジタのための入力デバイスを扱う。また、汎用的なX.Orgサーバ入力ドライバを提供する。libinputの狙いは、入力イベントを扱う共通の方法でWaylandコンポジタ用の単一の実装を提供することである。これによりコンポジタ用にインプットコードをカスタムするための量を最小化する。libinputは、(udevを通じて)デバイスの検出[要説明]、デバイスの運用、入力デバイスイベントの処理と抽象化を提供する[68][69]。
libinputのバージョン1.0は、バージョン0.21の次にリリースされ、タブレット、ボタンセット、タッチパッドジェスチャのサポートを含んでいる。このバージョンは、安定したAPI/ABIを維持する(API/ABIが変わらない。)[70]。
GNOME/GTKおよびKDEフレームワーク5[71]が本流にしたことで、Fedora 22は、X.OrgのevdevとSynapticsドライバをlibinputに置き換えた[72]。
バージョン1.16では、X.Orgサーバがxf86-input-libinputと呼ばれるラッパによって、libinputライブラリをサポートした[73][74]。
Waylandセキュリティモジュール
Waylandセキュリティモジュールは、LinuxカーネルにおけるLinuxセキュリティモジュールインタフェースに似た位置づけである[75]。
(とくにアクセシビリティに関連した)いくつかのアプリケーションは、高い権限(特権)を必要とする。これらの権限は、Waylandコンポジタに共通して持たれる。現在[いつ?]、Waylandにおけるアプリケーションは、一般的にスクリーンショットや入力イベントの発行といったセンシティブな処理は、いずれも実行できない。Waylandの開発者達は、特権を付与されたクライアントを安全に処理するための実行可能な方法を積極的に探しており、クライアント用の特権を持たせるインタフェースを設計している。
Wayland Security Moduleは、コンポジタ内でのセキュリティの決定を、一元化されたセキュリティ決定エンジンに移譲する方法である[75]。
Remove ads
採用実績
要約
視点
Waylandプロトコルは、シンプルであるように設計された。そのためウィンドウシステム全体を構築するためには、追加のプロトコルやインタフェースを定義し実装することが必要である。2014年7月現在[update]これらの追加のインタフェースは作成中である。そのため、ツールキットは既にWaylandを完全にサポートしている一方、グラフィカルシェルの開発者達は必要な追加のインタフェースを作るためにWaylandの開発者と協力している。
デスクトップLinuxディストリビューション
2020年現在[update]ほとんどのLinuxディストリビューションは、Waylandをインストール直後からサポートしている。特筆すべき例を挙げると:
- Fedora は、2016年11月22日にリリースしたバージョン25からWaylandをGNOME 3.22のデフォルトのデスクトップセッションとして使用開始した。X.OrgへはグラフィックドライバがWaylandをサポートできない場合のために戻れるようにしている[76]。Fedoraは、2021年4月27日のバージョン34から、KDEデスクトップのデフォルトのセッションとしてWaylandを使い始めた。
- Ubuntu は、Ubuntu 17.0 (Artful Aardvark) にてWaylandをデフォルトにした[77]。しかし、Ubuntu 18.04 LTSにてX.Orgに戻した。Waylandはまだスクリーン共有とリモートデスクトップアプリケーションに問題を抱えており、ウィンドウマネージャのクラッシュから回復できないためであった[78][79]。21.04で、Waylandを再度デフォルトにした[80]。
- Red Hat Enterprise Linux は、2019年5月7日にリリースしたバージョン8で、Waylandをデフォルトセッションにした[81]。
- Debian は、2019年7月6日にリリースしたバージョン10からGNOMEのデフォルトセッションとしてWaylandを使用している[82]。
- Slackware Linux 2020年2月20日に開発用としてWaylandを組み入れた[83]。-現在、最終的にバージョン15.0になる予定である。
- Manjaro は、2020年11月22日にリリースされたManjaro 20.2 (Nibia) のGnomeエディションでWaylandをデフォルトにした[84]。
特筆するアーリーアダプター:
ツールキットサポート
Waylandをサポートするツールキットの一部を以下に列挙する。
- Clutter(英語版) は、完全にWaylandをサポートしている[89][90][91]。
- EFL は、セレクションを除き、完全にWaylandをサポートしている[92]。
- GTK 3.20 は、Waylandを完全にサポートしている[93]。
- Qt 5 は、Waylandを完全にサポートしている。そしてWaylandコンポジタとWaylandクライアントの両方を記述するために使われる。
- SDL はバージョン2.0.2でWaylandのサポートを開始した[94]。そして、バージョン2.0.4からデフォルトで有効である[95]。
- GLFW(英語版) 3.2 は、Waylandをサポートしている[96]。
- FreeGLUT(英語版) は、最初にWaylandをサポートした[97]。
デスクトップ環境
XからWaylandへの置き換えを進めているデスクトップ環境には、GNOME[98]、KDE Plasma 5[99]やEnlightenment[100]がある。
2015年11月、Enlightenment e20は、完全なWaylandサポートをアナウンスした[101][46][102]。
GNOME 3.20は、完全なWaylandセッションを持つ最初のバージョンである[103]。GNOME 3.22は、GTK, Mutter, GNOME Shellを通してWaylandのサポートを改善した[104]。GNOME 3.24は、Wayland下での商用NVidiaドライバをサポートした[105]。
先行してKWin 4.11 が実験的にWaylandをサポートしていた[106]が、KDE PlasmaによるWaylandのサポートは、Plasma 5のリリースまで遅れた[107]。 Plasma バージョン5.4は、Waylandセッションをサポートした最初のバージョンである[108]。2020年の間、KlipperはWaylandへ移行し、次の2020年10月にリリースされる次の5.20ではスクリーンキャスティングとレコーディングを改良することを目標としている[109]。
その他のソフトウェア
Waylandをサポートするその他のソフトウェアは以下である。
- Intelligent Input Bus は、Waylandでの動作をサポートされ、Fedora 22で準備ができた[110]。
- RealVNC(英語版) は、2014年7月にWayland開発者プレビューを公開した[62][111][112]。
- Maliit は、Wayland下で動作するインプットメソッドフレームワークである[113][114][115]。
- kmscon(英語版) は、wltermにてWaylandをサポートしている[116]。
- Mesa は、統合されてWaylandをサポートした[117]。
- Eclipse は、2014年のGSoCプロジェクトにてWayland上で動作するようにされた[118]。
- Vulkan WSI (Window System Interface) は、EGLが、OpenGL ESに対するEGLやOpenGLに対するGLXと類似した目的を提供するAPI呼び出しの集合である。Vulkan WSIは、最初からWaylandサポートを含む。つまり、Vulkanは、WAYLAND KHRプラットフォームを使用する。Vulkanクライアントは何も変更していないWeston, GENEVI LayerManager, Mutter / GNOME Shell, Enlightenment, あるいは他多くのWaylandサーバで動かすことができる。WSIは、システム上の異なるGPUを見つけることを可能にし、GPUレンダリングの結果をウィンドウシステムへ表示する[119]。
- SPURV(英語版), Waylandを使用したLinuxディストリビューションで動くAndroidアプリケーション用の互換レイヤである。
携帯および組込ハードウェア
Waylandをサポートする携帯および組込ハードウェアは、以下である。
- postmarketOS
- GENIVIアライアンス(英語版): GENIVI in-vehicle infotainment (IVI)のための自動車産業コンソーシアムは、Waylandをサポートする[120]。
- Raspberry Pi: ラズベリーパイ財団は、Collabora(英語版)とのコラボレーションによって、Maynardをリリースした。またパフォーマンスとメモリ消費量の改善に取り組んでいる[64][65]。
- Jolla: Jollaから発売されたスマートフォンは、Waylandをサポートしている。Linux Sailfish OS(英語版)が他のベンダのハードウェアで使われる時、またはユーザによってAndroidデバイスにインストールされた時に標準として使われる[121][122][123]。
- Tizen: Tizenは、2.xまではin-vehicle infotainment (IVI) のセットアップでWaylandをサポートした[124]。3.0以降は、Waylandをデフォルトにした[125]。
Remove ads
履歴
要約
視点
作者であるKristian Høgsbergは、LinuxのグラフィックとX.Orgの開発者であり、以前はAIGLXとDRI2で勤務していた。Red Hatで勤務しているとき、2008年の空いた時間のプロジェクトとしてWaylandの開発を始めた[126][127][128][129]。最初の目標は、"すべてのフレームは完璧である、つまり、それによってアプリケーションは、テアリング、ラグ、再描画、ちらつきを二度と目にしないよう十分にレンダリングをコントロールできる"システムであった。根底となるコンセプトが"固まった"とき、Høgsbergはちょうどマサチューセッツ州Wayland(英語版)の街を運転していたため、その名前がつけられた[128][130]。
2010年10月に、Waylandはfreedesktop.orgのプロジェクトになった[131][132]。移行の一環として、プロジェクトの中心となる議論と開発の場がGoogle グループからWayland-develメーリングリストに置き換えられた。
Waylandクライアントとサーバのライブラリは、当初MITライセンスの下でリリースされた[133]一方、コンポジタのリファレンス実装であるWestonといくつかのクライアントの例は、GNU General Public License version 2を使用した[134]。その後、すべてのGPLのコードは、"コードがリファレンス実装と実際のライブラリとの間をより容易に移動できるよう"MITライセンスに再ライセンスされた(英語版)[135]。2015年には、Waylandで使用していたライセンスの文言が、古いバージョンのMITライセンスとわずかに異なっていたことが見つかった。ライセンスの文言はX.Orgプロジェクトで使われてる(MIT Expat Licenseとして知られる)現在のバージョンのものへ更新された[4]。
Waylandは、DRI2サポートによってすべてのMesa 3D互換ドライバで動作し、[117]同様にHybrisプロジェクト(英語版)を通じてAndroidドライバで動作する。[136][137][138]
リリース
Remove ads
参考文献
関連項目
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads