Wayland

Wayland は、ディスプレイサーバとクライアント間の通信方法を記述した通信プロトコルである。 また、そのプロトコルをCで実装したライブラリでもある。 Waylandプロトコルを使用したディスプレイサーバを//Waylandコンポジタ//と呼ぶ。 これは、このディスプレイサーバがコンポジット型ウィンドウマネージャの機能も持つためである。

Waylandは当初、Kristian Høgsberg率いるボランティアによって、フリーかつオープンソースコミュニティ主導のプロジェクトとして開発されていた。 このプロジェクトは、Linuxやその他のUnix系OSにおいて、X Window Systemをモダンで安全でKerrisk 2012}}Peres 2014}}Graesslin 2015 security}}よりシンプルなものに置き換えることを目的としている。プロジェクトのソースコードは、パーミッシブ・ライセンスのひとつであるMITライセンスで公開されているWayland FAQ}}License}}。

成果の一部として、Waylandプロジェクトは//Weston//と呼ばれるWaylandコンポジタのリファレンス実装も開発した。

1. 概要
-----

Waylandは、コンポジット型ウィンドウマネージャが、アプリケーションやグラフィクスハードウェアと直接通信できるようにするための方法を提供する。Waylandはグラフィクス周りのみに特化しており、入力ハードウェアとの通信には他のライブラリを使用することを想定している。Wayland環境下ではコンポジット型ウィンドウマネージャがディスプレイサーバとなる。各アプリケーションは画像を自身のバッファに描画し、ウィンドウマネージャがディスプレイサーバとなり、各アプリケーションのバッファを合成してディスプレイ上のアプリケーションウィンドウを作り出す。これは、コンポジット型ウィンドウマネージャとX Window Systemを一緒に使う従来の方法より効率的かつシンプルである。

Waylandディスプレイサーバプロジェクトは、Red Hatの開発者であったKristian Høgsbergによって、2008年に開始された。

2010年頃、Linuxデスクトップのグラフィックスは、「中心にあるXサーバとやり取りするためだけの山積みのレンダリングインタフェース」を持つ状態から、"XやWaylandのようなウィンドウシステムを脇に退けて"、Linuxカーネルやそのコンポーネント 、ダイレクト・レンダリング・マネージャを"間に置く"ように移行した。その結果、"グラフィックシステムはシンプルになり、より柔軟性があり、より良いパフォーマンスを発揮する"ようになったCorbet 2010}}。

Høgsbergは、多くの最近のプロジェクトと同様にXdmxを追加することもできたが、"クライアントとハードウェアの間のホットなパスからXを[締め出す]"ことを採用した。 その理由について、プロジェクトのFAQには以下のとおり記載されているWayland FAQ}}。

Waylandの初期バージョンでは、ネットワーク透過性を提供していなかった。 しかし、Høgsbergは、2010年にネットワーク透過性が可能であることを記したHøgsberg remotewl}}。 それは、2011年のGoogleサマーコードプロジェクトとして挑戦されたが成功しなかったLarabel 2011 remote}}。 Adam Jacksonは、"ピクセルスクレイピング"や  X11のように)ネットワーク越しに"レンダリングコマンドストリーム"を送る方法で、Waylandアプリケーションへのリモートアクセスを目論んだJackson remotewl}}。 2013年初頭、Høgsbergは、本物のコンポジタへ圧縮画像を送るプロキシWaylandサーバーを使ってネットワーク透過性の実験を行ったStone 2013 LCA}}Willis 2013}}。 2017年8月、GNOMEはWayland下で最初のピクセルスクレイピングVNCサーバの実装を提示した。

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

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

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

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

下位レイヤあるいは//ワイヤプロトコル//: 関係する2つのプロセス—クライアントとコンポジタ—の間のプロセス間通信と、それらが内部で変えるデータのマーシャリング  を扱う。
その上の高位レイヤ: クライアントとコンポジタがウィンドウシステムの基本機能を実現するために交換する情報を扱う。このレイヤは、"非同期オブジェクト指向プロトコル"として実装されたWayland doc。下位レイヤはCで手作業で書かれたが、高位レイヤはXMLフォーマットで書かれたプロトコルの記述から自動生成されたwlprotoxml}}。 このXMLで書かれたプロトコルの記述が変更されたときは、いつでもプロトコルを実装したCのソースコードを再生成できる。これによって、非常にフレキシブルで、拡張性が高く、エラーを防止したプロトコルになる。

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

2.2. プロトコルの概要
-------------

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

Waylandクライアントは、あるオブジェクトがサポートしているリクエストを、そのオブジェクトへリクエストできる。クライアントは、必要とされるデータをリクエストの引数として提供しなければならない。これが、クライアントがコンポジタからサービスを要求する方法である。次に、コンポジタは、イベントを発行するため、オブジェクトによって情報をクライアントへ返す。これらのイベントは、あるリクエストに対する反応や、あるいは非同期の 内部イベントや状態変化としてコンポジタによって発行される。エラー状態もコンポジタによってイベントとして通知されるWayland doc。

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

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

2.2.1. Waylandコアインタフェース
-----------------------

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

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

//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//オブジェクトを要求するPaalanen 2014}}。

2.2.2. Wayland拡張インタフェース
-----------------------

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

2.3. コアプロトコルの拡張プロトコル
--------------------

2.3.1. XDG-Shellプロトコル
---------------------

XDG-Shellプロトコルは、Waylandコンポジタでサーフェイスを管理するための拡張手段である。サーフェイスを操作するための伝統的な方法は、wl_shell_*関数を使用することだった。この関数は、Waylandコアプロトコルの一部で、libwayland-client}}にある。対して、XDG-Shellプロトコルの実装は、Waylandコンポジタによって提供される。そのためxdg-shell-client-protocol.h}}ヘッダがWestonソースツリーに含まれる。それぞれのWaylandコンポジタは自身の実装を提供することを想定している。

2014, 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は、常に別のサーフェイスのための一時的なものであり、暗黙的なグラブを持つxdg-shell}}。

2.3.2. IVI-Shellプロトコル
---------------------

IVI-Shellは、Waylandコアプロトコルの拡張で、車内エンターテインメント  デバイスをターゲットにしている。

2.4. レンダリングモデル
--------------

Waylandプロトコルは、レンダリングAPIを含んでいないWayland docWayland FAQ}}Vervloesem 2012}}Barnes slides。その代わり、Waylandは//ダイレクトレンダリング//モデルを採用している。ダイレクトレンダリングモデルでは、クライアントはウィンドウコンテンツをコンポジタと共有できるバッファへ描画しなければならないWayland doc。そのため、クライアントはCairoやOpenGLなどのライブラリを使って、自分自身ですべてをレンダリングすることも選択できる。あるいは、QtやGTKといった、Waylandをサポートする高位のウィジェットライブラリのレンダリングエンジンに頼ることもできる。クライアントは、特定のタスクをこなすために、オプションとしてその他の特化したライブラリを使用することもできる。たとえばフォントレンダリングのためにFreeTypeを使用できる。

レンダリングされたウィンドウコンテンツの結果は、//wl_buffer//オブジェクトに格納される。このオブジェクトのデータ型は、実装依存である。コンテンツデータがクライアントとコンポジタとの間で共有可能でなければならないことだけが唯一要求される。もしクライアントがソフトウェアレンダラを使用し、その結果がシステムメモリに格納されるなら、クライアントとコンポジタは、バッファ間のやり取りを余分なコピーなしに実現するため、共有メモリを使用できる。Waylandプロトコルはすでにこの種の共有メモリバッファに何も追加することなしに対応している。共有メモリバッファは、//wl_shm//および//wl_shm_pool//インタフェースによって実現できるWayland doc。この方法の欠点は、コンポジタはそれを表示するために追加の作業を必要とする可能性があることである。これにより、グラフィックパフォーマンスは低下する。

最も一般的なケースでは、クライアントがOpenGL、OpenGL ES、VulkanといったハードウェアアクセレレーションのためのAPIを使って、ビデオメモリバッファへ直接レンダリングする。クライアントとコンポジタは、このGPU空間のバッファを参照するための特別なハンドラを用いて共有できるPaalanen 2012}}。この方法は、コンポジタに余計なデータコピーをしないようにする。結果として、グラフィックパフォーマンスは向上し、よりよい方法である。コンポジタはAPIクライアントとして、同じハードウェアアクセセレレーションAPIを使って、ディスプレイへ描画する最終的なシーンのコンポジションをかなり最適化できる。

レンダリングが共有バッファ内で完成したとき、Waylandクライアントはバッファのレンダリングされたコンテンツをディスプレイに表示するため、コンポジタを導くべきである。そのために、クライアントはレンダリングされたコンテンツを格納するバッファオブジェクトをサーフェイスオブジェクトに紐付ける。そして"commit"リクエストをサーフェイスに送り、バッファの制御をコンポジタヘ転送するhellowl}}。それから、クライアントは、もしまた別のフレームをレンダリングするためにバッファを再利用するなら、コンポジタがバッファを開放するのを待つあるいは新しいフレームをレンダリングするため別のバッファを使用し、レンダリングが完了した時にこの新しいバッファをサーフェイスに紐付け、そのコンテンツをコミットすることもできるWayland doc。数個の関連するバッファやその運用を含めて、レンダリングに使用される方法は、全体的にクライアントの制御下にあるWayland doc。

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

3.1. WaylandとXとの違い
------------------

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

アーキテクチャ : コンポジット型ウィンドウマネージャは、Xとは分離しており、追加機能である。一方、Waylandはディスプレイサーバとコンポジタを単一の機能として統合しているWayland architecture}}Vervloesem 2012}}。また、Waylandは、ウィンドウマネージャの仕事のいくつかを組み込んでいる。一方、Xは、クライアント側の仕事として分離されているEdge 2012}}。 コンポジット : Xでは、コンポジットはオプションであるが、Waylandでは必須である。Xでのコンポジットは"能動的"、つまり、コンポジタはすべてのピクセルデータを自分で取り出さなければならない。これは遅延を生む。Waylandでは、コンポジットは"受動的"である。つまり、コンポジタはピクセルデータをクライアントから直接受け取るWayland Compositor。 レンダリング : Xサーバは自身でレンダリングができ、さらにクライアントによって送られたレンダリングされたウィンドウを表示するために構築することもできる。対して、WaylandはレンダリングのためのAPIは表に出しておらず、そうした仕事をクライアントに委譲しているWayland architecture}}Vervloesem 2012}}。ウィンドウの装飾は、クライアント側でレンダリングできるし、サーバサイドでもできるGraesslin 2013 decorations}}。 セキュリティ : Waylandは、各ウィンドウの入出力から独立しており、入力・出力それぞれの機密性、整合性、および可用性を実現する。オリジナルのXの設計では、これらの重要なセキュリティの特徴が欠けておりKerrisk 2012}}Peres 2014}}Graesslin 2015 security}}、いくつかの拡張が、それを軽減すべく開発されてきたX.Org Security}}X11 Security
extension}}XACE}}。また、Waylandは、コードの大部分がクライアント側で実行されており、「root」権限で実行する必要のあるコードが少なくなり、セキュリティが向上するKerrisk 2012}}。一方、複数の一般的なLinuxディストリビューションでは、現在はXをroot権限なしに実行できる。 プロセス間通信 : Xサーバは、Xクライアント同士の基本的な通信方法を提供する。後にICCCMによって拡張された。このXクライアント-クライアント通信は、ウィンドウマネージャによって使われる。また、Xセッション、ウィンドウの選択とドラッグアンドドロップ、その他の機能を実現する。Waylandコアプロトコルは、Waylandクライアント間の通信をサポートしない。対応する機能はデスクトップ環境やサードパーティによって実現される。 ネットワーク : Xウィンドウシステムは、ネットワーク越しにコア部分が実行されるよう設計されたアーキテクチャである。Waylandは、それ自身ではネットワーク透過性を持たないWayland FAQ}}。しかし、コンポジタは、リモートディスプレイを実現するためにどんなリモートデスクトッププロトコルも実現できる。加えて、Waylandイメージストリーミングとイメージ圧縮の研究がある。この研究は、Virtual Network ComputingVNCのようにリモートフレームバッファアクセスを実現し得るWillis 2013}}。

3.2. Xとの互換性
-----------

XWaylandは、Waylandクライアントとして動作するXサーバである。XWaylandによって、Waylandコンポジタ環境でネイティブのX11クライアントアプリケーションを表示させることができるxwayland}}。これは、XQuartzがXアプリケーションをmacOSのネイティブウィンドウシステムで動かす方法に似ている。XWaylandのゴールは、移植されていないアプリケーションを実行する方法を提供することで、XウィンドウシステムからWayland環境への移行を促進することである。XWaylandは、X.Orgサーババージョン1.16に取り込まれたxorg 1.16}}。

Qt5やGTK3といったウィジェット・ツールキットは、ユーザーがアプリケーションをX上あるいはWayland上で実行させるかに関わらず、ユーザがローダを選択することで、グラフィカルバックエンドを実行時に変更できるHøgsberg 2011 GTK}}。Qt5は、この効果のために-platform}}コマンドラインオプションQtWayland}}を提供している。一方、GTK 3は、GDK_BACKEND}}環境変数を設定することで、ユーザがGDKバックエンドを使用するか選択可能にしているHøgsberg 2011 GTK}}GTK Wayland support}}。

4. Waylandコンポジタ
---------------

Waylandディスプレイサーバプロトコルを実装したディスプレイサーバは、//Waylandコンポジタ//とも呼ばれる。なぜなら、それらはコンポジット型ウィンドウマネージャの仕事もこなすからである。

Weston Waylandコンポジタのリファレンス実装である。Westonは、クライアントサイド・デコレーションを実現する。
Lipstick Waylandコンポジタを実装したモバイルグラフィカルシェルフレームワークである。これは、Sailfish OS, Nemo Mobile, AsteroidOSで使われるEdge 2013 jolla}}。
Enlightenment は、バージョン0.20から、完全にWaylandをサポートしているLarabel 2015 e20}}。しかし、完全なWaylandコンポジタになるための作業は続けられている。
KWin は、2021年現在、ほとんど完全にWaylandサポートを完了した。
Mutter は、GNOME 3.9にWaylandを統合するためのブランチを切った状態であるmutter wayland}}。
Clayland – Clutterを用いたWaylandコンポジタのシンプルな例である。
Westeros – Waylandコンポジタライブラリである。Westerosによって、アプリケーションが自身のWayland表示を作ることを可能になる。それによりサードパーティアプリケーションのネストと埋め込みを可能にする。
wlroots – モジュラWayland実装である。wlrootsは、他のコンポジタ、とくにSwayのためのベースとして関数である。
Sway – タイル型Waylandコンポジタである。また、X11のためのi3ウィンドウマネージャの置き換えである。
gamescope – SteamOSの一部である。初期のsteamcompmgrの置き換えである。

4.1. WESTON}}Weston
-------------------

Westonは、Waylandコンポジタのリファレンス実装であり Waylandプロジェクトによって開発されている。Cで書かれており、MITライセンスの下で公開されている。Westonは、Linuxカーネルの特定の機能に依存しているため、公式にはLinuxのみサポートしている。Westonが依存している機能は、カーネルモードセッティング、Graphics Execution Manager  、udevである。これらは、他のUnixライクOSには実装されていないwayland README}}。Linuxで実行するとき、evdevによってハードウェアの入力を運用する。一方、バッファの運用は、ジェネリックバッファマネジメント  に依存している。しかし、2013年にWestonのFreeBSD向けのプロトタイプportがアナウンスされたLarabel 2013 freebsd}}。

Westonは、HDCPをサポートしている。

Westonは、コンポジタとアプリケーション間のアプリケーションバッファを共有するためにGEMに依存している。ドックやパネルといった共通のデスクトップの機能のための"シェル"のプラグインシステムを含むWillis 2013}}。クライアントは、自身のウィンドウボーダや装飾の描画に対して責任を負う。Westonは、レンダリングのためOpenGL ESPaalanen 2012 EGL}}を使ったり、ソフトウェアレンダリングのためにpixmanライブラリLarabel 2013 pixman}}を使ったりすることができる。完全なOpenGL実装は使われない。なぜなら、現在のほとんどのシステムでは完全なOpenGLライブラリをインストールしている場合、GLXやその他のXウィンドウシステムサポートライブラリを依存関係のためにインストールしているからであるHøgsberg wayland GL}}。

Westonのためのリモートアクセスインタフェースは、2013年10月にRealVNCの従業員によって提案されたRealVNC remote}}。

4.1.1. MAYNARD}}Maynard
-----------------------

//は、グラフィカルシェルである。Maynardは、GNOME ShellがMutterへのプラグインとして書かれたことと同様に、Westonのプラグインとして書かれたmaynard}}。ラズベリーパイ財団は、Collaboraとのコラボレーションの中でMaynardをリリースし、パフォーマンスとメモリ使用量の改善に取り組んでいるCollabora RPi}}RPi wayland}}。

4.2. libinput
-------------

入力デバイスを扱うためのWestonコードは、//libinput//と呼ばれる独立したライブラリとして分けられている。Weston 1.5に始めてマージされたwayland 1.5}}libinput announce}}。

libinputは、Waylandコンポジタのための入力デバイスを扱う。また、汎用的なX.Orgサーバ入力ドライバを提供する。libinputの狙いは、入力イベントを扱う共通の方法でWaylandコンポジタ用の単一の実装を提供することである。これによりコンポジタ用にインプットコードをカスタムするための量を最小化する。libinputは、デバイスの検出reason=入力・出力の両方とも検出できる?、デバイスの運用、入力デバイスイベントの処理と抽象化を提供するlibinput}}XDC2014 libinput}}。

libinputのバージョン1.0は、バージョン0.21の次にリリースされ、タブレット、ボタンセット、タッチパッドジェスチャのサポートを含んでいる。このバージョンは、安定したAPI/ABIを維持するlibinput stable API}}。

GNOME/GTKおよびKDEフレームワーク5autoref0004}}が本流にしたことで、Fedora 22は、X.OrgのevdevとSynapticsドライバをlibinputに置き換えたlibinput fedora 22}}。

バージョン1.16では、X.Orgサーバがxf86-input-libinput}}と呼ばれるラッパによって、libinputライブラリをサポートしたHutterer 2014}}libinputfosdem15}}。

4.3. Waylandセキュリティモジュール
-----------------------

Waylandセキュリティモジュールは、LinuxカーネルにおけるLinuxセキュリティモジュールインタフェースに似た位置づけであるXDC2014 wayland security}}。

いくつかのアプリケーションは、高い権限を必要とする。これらの権限は、Waylandコンポジタに共通して持たれる。現在date=October 2014}}、Waylanにおけるアプリケーションは、一般的にスクリーンショットや入力イベントの発行といったセンシティブな処理は、いずれも実行できない。Waylandの開発者達は、特権を付与されたクライアントを安全に処理するための実行可能な方法を積極的に探しており、クライアント用の特権を持たせるインタフェースを設計している。

Wayland Security Moduleは、コンポジタ内でのセキュリティの決定を、一元化されたセキュリティ決定エンジンに移譲する方法であるXDC2014 wayland security}}。

5. 採用実績
-------

Waylandプロトコルは、シンプルであるように設計された。そのためウィンドウシステム全体を構築するためには、追加のプロトコルやインタフェースを定義し実装することが必要である。2014これらの追加のインタフェースは作成中である。そのため、ツールキットは既にWaylandを完全にサポートしている一方、グラフィカルシェルの開発者達は必要な追加のインタフェースを作るためにWaylandの開発者と協力している。

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

2020}}ほとんどのLinuxディストリビューションは、Waylandをインストール直後からサポートしている。特筆すべき例を挙げると:

Fedora は、2016年11月22日にリリースしたバージョン25からWaylandをGNOME 3.22のデフォルトのデスクトップセッションとして使用開始した。X.OrgへはグラフィックドライバがWaylandをサポートできない場合のために戻れるようにしている。Fedoraは、2021年4月27日のバージョン34から、KDEデスクトップのデフォルトのセッションとしてWaylandを使い始めた。
Ubuntu は、Ubuntu 17.0  にてWaylandをデフォルトにした。しかし、Ubuntu 18.04 LTSにてX.Orgに戻した。Waylandはまだスクリーン共有とリモートデスクトップアプリケーションに問題を抱えており、ウィンドウマネージャのクラッシュから回復できないためであった。21.04で、Waylandを再度デフォルトにした。
Red Hat Enterprise Linux は、2019年5月7日にリリースしたバージョン8で、Waylandをデフォルトセッションにした。
Debian は、2019年7月6日にリリースしたバージョン10からGNOMEのデフォルトセッションとしてWaylandを使用している。
Slackware Linux 2020年2月20日に開発用としてWaylandを組み入れた。-現在、最終的にバージョン15.0になる予定である。
Manjaro は、2020年11月22日にリリースされたManjaro 20.2  のGnomeエディションでWaylandをデフォルトにした。特筆するアーリーアダプター:

RebeccaBlackOSはDebianベースのLive USBである。このLinuxディストリビューションは、コンピュータのメインOSを変更することなしに本物のWaylandデスクトップを試す便利な方法を提供する。これは、2012年ころからWaylandを見せるために使われている。

5.2. ツールキットサポート
---------------

Waylandをサポートするツールキットの一部を以下に列挙する。

Clutter は、完全にWaylandをサポートしているclutter 1.6}}Bradford 2011}}clutter 1.16}}。
EFL は、セレクションを除き、完全にWaylandをサポートしているefl wayland}}。
GTK 3.20 は、Waylandを完全にサポートしているgtk+ wayland}}。
Qt 5 は、Waylandを完全にサポートしている。そしてWaylandコンポジタとWaylandクライアントの両方を記述するために使われる。
SDL はバージョン2.0.2でWaylandのサポートを開始したsdl2 wayland}}。そして、バージョン2.0.4からデフォルトで有効であるLarabel 2016 SDL2}}。
GLFW 3.2 は、Waylandをサポートしているglfw wayland}}。
FreeGLUT は、最初にWaylandをサポートしたfreeglut wayland}}。

5.3. デスクトップ環境
-------------

XからWaylandへの置き換えを進めているデスクトップ環境には、GNOMEGNOME wl}}、KDE Plasma 5KDE wl}}やEnlightenmentenlightenment wl}}がある。

2015年11月、Enlightenment e20は、完全なWaylandサポートをアナウンスしたe20 wl}}Larabel 2015 e20}}FOSDEM2016 wl}}。

GNOME 3.20は、完全なWaylandセッションを持つ最初のバージョンであるGNOME release plan}}。GNOME 3.22は、GTK, Mutter, GNOME Shellを通してWaylandのサポートを改善した。GNOME 3.24は、Wayland下での商用NVidiaドライバをサポートした。

先行してKWin 4.11 が実験的にWaylandをサポートしていたLarabel 2013 kwin}}が、KDE PlasmaによるWaylandのサポートは、Plasma 5のリリースまで遅れたvizzzion}}。 Plasma バージョン5.4は、Waylandセッションをサポートした最初のバージョンであるGraesslin 2015}}。2020年の間、KlipperはWaylandへ移行し、次の2020年10月にリリースされる次の5.20ではスクリーンキャスティングとレコーディングを改良することを目標としている。

5.4. その他のソフトウェア
---------------

Waylandをサポートするその他のソフトウェアは以下である。

Intelligent Input Bus は、Waylandでの動作をサポートされ、Fedora 22で準備ができたSchaller 2014}}。
RealVNC は、2014年7月にWayland開発者プレビューを公開したRealVNC remote}}autoref0005}}autoref0006}}。
Maliit は、Wayland下で動作するインプットメソッドフレームワークであるautoref0007}}autoref0008}}Maliit}}。
kmscon は、wltermにてWaylandをサポートしているkmscon wl}}。
Mesa は、統合されてWaylandをサポートしたHillesley 2012 p3}}。
Eclipse は、2014年のGSoCプロジェクトにてWayland上で動作するようにされたeclipse wl}}。
Vulkan WSI  は、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レンダリングの結果をウィンドウシステムへ表示するCollabora vulkan}}。
SPURV, Waylandを使用したLinuxディストリビューションで動くAndroidアプリケーション用の互換レイヤである。

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

Waylandをサポートする携帯および組込ハードウェアは、以下である。

postmarketOS
GENIVIアライアンス: GENIVI in-vehicle infotainment のための自動車産業コンソーシアムは、Waylandをサポートするgenivi}}。
Raspberry Pi: ラズベリーパイ財団は、Collaboraとのコラボレーションによって、Maynardをリリースした。またパフォーマンスとメモリ消費量の改善に取り組んでいるCollabora RPi}}RPi wayland}}。
Jolla: Jollaから発売されたスマートフォンは、Waylandをサポートしている。Linux Sailfish OSが他のベンダのハードウェアで使われる時、またはユーザによってAndroidデバイスにインストールされた時に標準として使われるauto}}auto1}}auto2}}。
Tizen: Tizenは、2.xまではin-vehicle infotainment  のセットアップでWaylandをサポートしたtizen 2.0}}。3.0以降は、Waylandをデフォルトにした。

6. 履歴
-----

作者であるKristian Høgsbergは、LinuxのグラフィックとX.Orgの開発者であり、以前はAIGLXとDRI2で勤務していた。Red Hatで勤務しているとき、2008年の空いた時間のプロジェクトとしてWaylandの開発を始めたHøgsberg 2008}}FOSDEM2012 interview}}Hillesley 2012}}LPC2009}}。最初の目標は、"すべてのフレームは完璧である、つまり、それによってアプリケーションは、テアリング、ラグ、再描画、ちらつきを二度と目にしないよう十分にレンダリングをコントロールできる"システムであった。根底となるコンセプトが"固まった"とき、Høgsbergはちょうどマサチューセッツ州Waylandの街を運転していたため、その名前がつけられたHillesley 2012}}Jenkins 2011}}。

2010年10月に、Waylandはfreedesktop.orgのプロジェクトになったLarabel 2010 freedesktop}}wayland freedesktop}}。移行の一環として、プロジェクトの中心となる議論と開発の場がGoogle グループから//Wayland-devel//メーリングリストに置き換えられた。

Waylandクライアントとサーバのライブラリは、当初MITライセンスの下でリリースされたoriginal license}}一方、コンポジタのリファレンス実装であるWestonといくつかのクライアントの例は、GNU General Public License version 2を使用したlicense clarification}}。その後、すべてのGPLのコードは、"コードがリファレンス実装と実際のライブラリとの間をより容易に移動できるよう"MITライセンスに再ライセンスされたlicense change GPL}}。2015年には、Waylandで使用していたラインセスの文言が、古いバージョンのMITライセンスとわずかに異なっていたことが見つかった。ライセンスの文言はX.Orgプロジェクトで使われてる現在のバージョンのものへ更新されたLicense}}。

Waylandは、DRI2サポートによってすべてのMesa 3D互換ドライバで動作し、Hillesley 2012 p3}}同様にHybrisプロジェクトを通じてAndroidドライバで動作する。wayland part1}}wayland part2}}

6.1. リリース
---------



7. 参考文献
-------

8. 関連項目
-------

ウィンドウシステム
Mir 
X Window System

9. 外部リンク
--------