Wayland (プロトコル)

ウェイランド

Waylandサーバーのリファレンス実装であるWeston
原作者	クリスチャン・ホグスバーグ
開発者	freedesktop.org等
初回リリース	2008年9月30日; 16年前[1] ( 2008-09-30 )
安定版リリース	ウェイランド: 1.23、[2]ウェストン: 14.0.1 [3] / 2024年5月30日; 5か月前 ( 2024-05-30 )
リポジトリ	gitlab.freedesktop.org/wayland/wayland
書かれた	Ｃ
オペレーティング·システム	公式: Linux 非公式: NetBSD、FreeBSD、OpenBSD、DragonFly BSD、[4] Haiku（オペレーティングシステム）[5]
タイプ	ウィンドウシステム ディスプレイサーバー
ライセンス	MITライセンス[6] [7] [8]
Webサイト	wayland.freedesktop.org

Waylandは、ディスプレイサーバーとそのクライアント間の通信を規定する通信プロトコルであり、そのプロトコルのCライブラリ実装でもある。 ^{[9] Waylandプロトコルを使用するディスプレイサーバーは、}合成ウィンドウマネージャーのタスクも実行することから、Waylandコンポジターと呼ばれる。

Waylandは、当初Kristian Høgsbergが率いたボランティアのグループによって、フリーでオープンソースのコミュニティ主導のプロジェクトとして開発され、^Linuxやその他のUnix系オペレーティングシステム用の安全でシンプルなウィンドウシステムにX Window Systemを置き換えることを目指しています^。[ 9 ] [ 14 ]プロジェクトのソース^{コードは、寛容}なフリーソフトウェアライセンスであるMITライセンスの条件に基づいて公開されています。^{[14] [6]}

Waylandプロジェクトでは、その取り組みの一環として、Westonと呼ばれるWaylandコンポジターのリファレンス実装も開発しています。^[9]

Wayland Display Serverプロジェクトは、 2008年にRed Hat開発者のKristian Høgsbergによって開始されました。 ^[15]

2010年頃から、Linuxデスクトップグラフィックスは、「宇宙の中心にあるXサーバーと通信するレンダリングインターフェイスの山」から、Linuxカーネルとそのコンポーネント（つまり、 Direct Rendering Infrastructure（DRI）、Direct Rendering Manager（DRM））を「真ん中」に置き、「XやWaylandなどのウィンドウシステム」を「隅」に置く方向に移行しました。これは、「より柔軟性が高く、より優れたパフォーマンスを提供する、大幅に簡素化されたグラフィックスシステム」になります。^[16]

Høgsberg は、最近の多くのプロジェクトと同様にX に拡張機能を追加することもできたが、プロジェクトの FAQ で説明されている理由により、「X をクライアントとハードウェア間のホットパスから押し出す」ことを好んだ。^[14]

これまでと異なるのは、多くのインフラストラクチャがX サーバーからカーネル (メモリ管理、コマンド スケジューリング、モード設定) またはライブラリ ( cairo、pixman、freetype、fontconfig、pangoなど) に移行し、中央のサーバー プロセスで実行する必要があるものがほとんどなくなったことです。... [X サーバーには] X プロトコルを話すと主張するためにサポートしなければならない機能が大量にありますが、これを使用する人は誰もいません。... これには、コード テーブル、グリフのラスタライズとキャッシュ、XLFD (冗談抜きで、XLFD!)、点描線、ポリゴン、幅広の円弧、その他 1980 年代風のグラフィック プリミティブを描画できるコア レンダリング API 全体が含まれます。XRandR、XRender、COMPOSITEなどの拡張機能を追加することで、多くの点で X.org サーバーを最新の状態に保つことができました。Wayland を使用すると、X サーバーとそのすべてのレガシー テクノロジをオプションのコード パスに移動できます。 X サーバーがコア レンダリング システムではなく互換性オプションになる段階に到達するにはしばらく時間がかかりますが、そのための計画を立てなければ、そこに到達することは決してありません。

Wayland は、プロトコルと、Weston というリファレンス実装で構成されています。このプロジェクトでは、X ではなく Wayland にレンダリングするGTKとQtのバージョンも開発されています。ほとんどのアプリケーションは、アプリケーションに変更を加えることなく、これらのライブラリのいずれかを通じて Wayland のサポートを得られると予想されます。

Waylandの初期バージョンではネットワーク透過性が提供されていなかったが、Høgsbergは2010年にネットワーク透過性は可能であると指摘した。^{[17]これは2011年に}Google Summer of Codeプロジェクト として試みられたが、成功しなかった。^[18] Adam Jacksonは、「ピクセルスクレイピング」（VNCなど）またはネットワーク経由で「レンダリングコマンドストリーム」を送信させること（RDP、SPICE、X11など）のいずれかによって、Waylandアプリケーションへのリモートアクセスを提供することを構想した。^[19] 2013年初頭の時点で、Høgsbergは、圧縮された画像を実際のコンポジターに送信するプロキシWaylandサーバーを使用して、ネットワーク透過性の実験を行っていた。 ^{[20] [21]} 2017年8月、GNOMEはWaylandでそのようなピクセルスクレイピングVNCサーバーの実装を初めて目にした。^[22]

多くの Wayland コンポジターには、ネイティブ アプリケーションやFlatpakなどのサンドボックス用のネイティブ ファイル ピッカー(xdg-desktop-portal-gtk はフォールバック ファイル ピッカーとしてよく使用されます)、画面録画、ネットワーク透過性、スクリーンショット、色の選択、およびユーザーの介入が必要でセキュリティ リスクになる可能性があるその他のタスクなどの一般的なタスク用の xdg-desktop-portal 実装も含まれています。xdg-desktop-portal は Flatpak または Wayland 固有のものではなく、代替のパッケージ システムやウィンドウ システムでも使用できることに注意してください。

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

Waylandのリファレンス実装は2層プロトコルとして設計されている: ^[23]

• 2つのプロセス（クライアントとコンポジター）間のプロセス間通信と、それらのプロセス間で交換されるデータのマーシャリングを処理する低レベルレイヤーまたはワイヤプロトコル。このレイヤーはメッセージベースであり、通常はカーネルIPCサービス、特にLinuxやその他のUnix系オペレーティングシステムの場合はUnixドメインソケットを使用して実装されます。 ^[24]
• その上に構築された高レベルレイヤーは、ウィンドウシステムの基本機能を実装するためにクライアントとコンポジターが交換する必要がある情報を処理します。このレイヤーは、「非同期オブジェクト指向プロトコル」として実装されています。^[25]

低レベル層はC言語で手作業で書かれていますが、高レベル層はXML形式で保存されたプロトコルの要素の記述から自動的に生成されます。^[26]このXMLファイルのプロトコル記述が変更されるたびに、そのプロトコルを実装するCソースコードを再生成して新しい変更を組み込むことができるため、非常に柔軟で拡張性があり、エラーのないプロトコルが可能になります。

Waylandプロトコルのリファレンス実装は2つのライブラリに分かれています。1つはWaylandクライアントが使用するライブラリlibwayland-client、もう1つはWaylandコンポジターが使用するライブラリですlibwayland-server。^[27]

Waylandプロトコルは「非同期オブジェクト指向プロトコル」と説明されています。^[25] オブジェクト指向とは、コンポジターによって提供されるサービスが、同じコンポジター上に存在する一連のオブジェクトとして提示されることを意味します。各オブジェクトは、名前、いくつかのメソッド（リクエストと呼ばれる）、およびいくつかの関連イベントを持つインターフェイスを実装します。すべてのリクエストとイベントには0個以上の引数があり、それぞれに名前とデータ型があります。プロトコルは、リクエストが同期された応答またはACKを待つ必要がないという意味で非同期であり、ラウンドトリップの遅延時間を回避してパフォーマンスを向上させます。

Wayland クライアントは、オブジェクトのインターフェースがその要求をサポートしている場合、そのオブジェクトに対して要求 (メソッド呼び出し) を行うことができます。クライアントは、そのような要求の引数に必要なデータも提供する必要があります。これは、クライアントがコンポジターにサービスを要求する方法です。コンポジターは、オブジェクトにイベント (おそらく引数も含む) を発行させることで、クライアントに情報を返します。これらのイベントは、コンポジターによって特定の要求への応答として、または内部イベント (入力デバイスからのものなど) または状態の変化に応じて非同期的に発行されます。エラー状態も、コンポジターによってイベントとして通知されます。^[25]

クライアントがオブジェクトにリクエストを行うには、まずそのオブジェクトを識別するために使用するID番号をサーバーに伝える必要があります。^[25]コンポジターには、グローバルオブジェクトと非グローバルオブジェクトの2種類のオブジェクトがあります。グローバルオブジェクトは、作成時（および破棄時）にコンポジターによってクライアントに通知されますが、非グローバルオブジェクトは通常、機能の一部として既に存在する他のオブジェクトによって作成されます。^[28]

インターフェースとそのリクエストおよびイベントは、Wayland プロトコルを定義するコア要素です。プロトコルの各バージョンには、インターフェースのセットとそのリクエストおよびイベントが含まれており、これらはどの Wayland コンポジターにも含まれることが想定されています。オプションで、Wayland コンポジターは、新しいリクエストとイベントをサポートする独自のインターフェースを定義および実装し、コア プロトコルを超えて機能を拡張することができます。^[29]プロトコルの変更を容易にするために、各インターフェースには名前に加えて「バージョン番号」属性が含まれています。この属性により、同じインターフェースのバリアントを区別できます。各 Wayland コンポジターは、使用可能なインターフェースだけでなく、それらのインターフェースのサポートされるバージョンも公開します。^[30]

Waylandプロトコルの現在のバージョンのインターフェースは、Waylandソースコードのファイルprotocol/wayland.xmlで定義されています。 ^{[26]これは、現在のバージョンの既存のインターフェースとそのリクエスト、イベント、その他の属性をリストした}XMLファイルです。このインターフェースセットは、Waylandコンポジターが実装するために必要な最小限のものです。

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

• 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オブジェクトをバインドし、そこから 1 つ以上のwl_surfaceオブジェクトを要求して、アプリケーションの出力をディスプレイに表示します。^[28]

Waylandコンポジターは、独自の追加インターフェースを定義してエクスポートすることができます。^[29]この機能は、コアインターフェースによって提供される基本機能を超えてプロトコルを拡張するために使用され、Waylandプロトコル拡張を実装する標準的な方法となっています。特定のコンポジターは、特殊な機能や独自の機能を提供するためにカスタムインターフェースを追加することができます。WaylandリファレンスコンポジターであるWestonは、新しい概念やアイデアのテストベッドとして新しい実験的なインターフェースを実装するためにそれらを使用し、その一部は後にコアプロトコルの一部となりました（Wayland 1.4で追加されたwl_subsurfaceインターフェースなど^[31]）。

XDG-Shell プロトコル ( XDG についてはfreedesktop.org を参照) は、Wayland コンポジター (Weston だけではない) でサーフェスを管理するための拡張された方法です。サーフェスを操作 (最大化、最小化、全画面表示など) する従来の方法は、コア Wayland プロトコルの一部であり、libwayland-clientにある wl_shell_*() 関数を使用することです。一方、 xdg-shell プロトコルの実装は、Wayland コンポジターによって提供されることになっています。そのため、Weston ソース ツリーに xdg-shell-client-protocol.hヘッダーがあります。

xdg_shell は、長期的には wl_shell の代替となることを目的としたプロトコルですが、Wayland コア プロトコルの一部にはなりません。最初は開発の場として使用されることを目的とした非安定 API として開始され、いくつかのデスクトップ シェルで必要な機能が定義されると、最終的に安定させることができます。主に 2 つの新しいインターフェイス、xdg_surface と xdg_popup を提供します。xdg_surface インターフェイスは、移動、サイズ変更、最大化などができるデスクトップ スタイルのウィンドウを実装します。子/親関係を作成するための要求を提供します。xdg_popup インターフェイスは、デスクトップ スタイルのポップアップ/メニューを実装します。xdg_popup は常に別のサーフェスに対して一時的であり、暗黙的なグラブも備えています。^[32]

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

WaylandプロトコルにはレンダリングAPIが含まれていません。^{[34] [14] [35] [36] : 2}代わりに、Waylandは直接レンダリングモデルに従います。このモデルでは、クライアントはウィンドウの内容をコンポジターと共有可能なバッファにレンダリングする必要があります。^[37]そのために、クライアントはすべてのレンダリングを自分で行うことも、CairoやOpenGLなどのレンダリングライブラリを使用することもできますし、 QtやGTKなど、Waylandをサポートする高レベルウィジェットライブラリのレンダリングエンジンに依存することもできます。クライアントは、フォントレンダリング用のFreetypeなど、特定のタスクを実行するためにオプションで他の専用ライブラリを使用することもできます。

レンダリングされたウィンドウ コンテンツを含む結果のバッファーは、wl_bufferオブジェクトに格納されます。このオブジェクトの内部タイプは実装に依存します。唯一の要件は、コンテンツ データがクライアントとコンポジターの間で共有可能である必要があることです。クライアントがソフトウェア (CPU) レンダラーを使用し、結果がシステム メモリに格納される場合、クライアントとコンポジターは共有メモリを使用して、余分なコピーなしでバッファー通信を実装できます。Wayland プロトコルは、wl_shm ^[38]およびwl_shm_pool ^[39]インターフェイスを通じて、この種の共有メモリ バッファーをネイティブに提供しています。この方法の欠点は、コンポジターがそれを表示するために追加の作業 (通常は共有データを GPU にコピーする) が必要になる場合があり、グラフィック パフォーマンスが低下することです。

最も一般的なケースは、クライアントがOpenGL、OpenGL ES、Vulkanなどのハードウェア（GPU）アクセラレーションAPIを使用してビデオメモリバッファに直接レンダリングすることです。クライアントとコンポジターは、特別なハンドラを使用してこのGPUスペースバッファを共有できます。^[40]この方法により、コンポジターは、クライアントからコンポジター、そしてGPUへのメインメモリバッファ方式による余分なデータコピーを回避でき、グラフィックスパフォーマンスが向上するため、推奨されます。コンポジターは、APIクライアントと同じハードウェアアクセラレーションAPIを使用して、ディスプレイに表示される最終シーンの合成をさらに最適化できます。

共有バッファでのレンダリングが完了すると、Wayland クライアントは、レンダリングされたバッファの内容をディスプレイに表示するようにコンポジターに指示する必要があります。このために、クライアントは、レンダリングされた内容を格納するバッファ オブジェクトをサーフェス オブジェクトにバインドし、サーフェスに「コミット」要求を送信して、バッファの実効的な制御をコンポジターに渡します。^[23]次に、クライアントは、バッファを再利用して別のフレームをレンダリングする場合、コンポジターがバッファを解放するのを待ちます (イベントによって通知されます)。または、別のバッファを使用して新しいフレームをレンダリングし、レンダリングが完了したら、この新しいバッファをサーフェスにバインドしてその内容をコミットします。^{[41] : 7}レンダリングに使用される手順 (関連するバッファの数とその管理を含む) は、完全にクライアントの制御下にあります。^{[41] : 7}

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

建築

コンポジションマネージャはXでは独立した追加機能ですが、Waylandではディスプレイサーバーとコンポジターを1つの機能として統合しています。^{[43] [35]また、Xでは別のクライアント側プロセスである}ウィンドウマネージャのタスクの一部も組み込まれています。^[44]

合成

合成はXではオプションだが、Waylandでは必須である。Xでの合成は「アクティブ」である。つまり、合成者はすべてのピクセルデータを取得する必要があり、遅延が生じる。Waylandでは、合成は「パッシブ」であり、合成者はクライアントから直接ピクセルデータを受け取る。^{[45] : 8–11}

レンダリング

Xサーバー自体もレンダリングを実行できますが、クライアントから送信されたレンダリングされたウィンドウを表示するように指示することもできます。対照的に、Waylandはレンダリング用のAPIを公開していませんが、そのようなタスク（フォント、ウィジェットなどのレンダリングを含む）をクライアントに委任します。^{[43] [35]}ウィンドウの装飾は、クライアント側（たとえば、グラフィックスツールキットによって）でレンダリングされるか、コンポジターがそのような機能を実装することを選択した場合は、オプトインのxdg-decorationプロトコルを使用してサーバー側（コンポジターによって）でレンダリングされます。^[46]

安全

Waylandは、すべてのウィンドウの入力と出力を分離し、両方の機密性、整合性、可用性を実現します。オリジナルのX設計にはこれらの重要なセキュリティ機能が欠けていましたが、 ^{[11] [12] [13]}、それを軽減しようとする拡張機能がいくつか開発されました。^{[47] [48] [49]}また、コードの大部分がクライアントで実行されるため、ルート権限で実行する必要があるコードが少なくなり、セキュリティが向上しました。^[11]ただし、現在では多くの一般的なLinuxディストリビューションで、Xサーバーをルート権限なしで実行できます。^{[50] [51] [52] [53]}

プロセス間通信

X サーバーは、X クライアント間の基本的な通信方法を提供し、これは後にICCCM規約によって拡張されました。この X クライアント間の通信は、ウィンドウ マネージャーによって使用され、X セッション、選択とドラッグ アンド ドロップ、およびその他の機能を実装するためにも使用されます。Wayland コア プロトコルは、Wayland クライアント間の通信をまったくサポートしていません。これは、対応する機能 (必要な場合) が、Wayland コミュニティによって、デスクトップ環境(KDE や GNOME など) またはサード パーティ (たとえば、基礎となるオペレーティング システムのネイティブIPC を使用する) によって実装されるべきものであると見なされているためです。

ネットワーキング

X Window System は、ネットワーク上で動作するように設計されたアーキテクチャです。Wayland 自体はネットワーク透過性を提供しませんが、^[14]コンポジターは任意のリモートデスクトッププロトコルを実装してリモートディスプレイを実現できます。さらに、 VNCと同様のリモートフレームバッファアクセスを提供する Wayland イメージストリーミングと圧縮の研究が行われています。^[21]

XWaylandはWaylandクライアントとして動作するXサーバーであり、Waylandコンポジター環境でネイティブX11クライアントアプリケーションを表示することができる。^{[54]これは、} XQuartzがmacOSのネイティブウィンドウシステムでXアプリケーションを実行する方法に似ている。XWaylandの目標は、X Window SystemからWayland環境への移行を容易にし、その間に移植されていないアプリケーションを実行する方法を提供することである。XWaylandはX.Org Serverバージョン1.16にメインライン化された。^[55]

Qt 5やGTK 3などのウィジェットツールキットは、実行時にグラフィカルバックエンドを切り替えることができるため、^{[56]ユーザーは}ロード時にアプリケーションをX上で実行するかWayland上で実行するかを選択できます。Qt 5では、そのための-platformコマンドラインオプション^{[57]が提供されていますが、GTK 3では、ユーザーは}Unix環境変数を設定することで、希望するGDKバックエンドを選択できます。^{[56] [58]}GDK_BACKEND

Wayland ディスプレイ サーバー プロトコルを実装するディスプレイ サーバーは、合成ウィンドウ マネージャーのタスクも実行するため、Wayland コンポジターとも呼ばれます。

wlrootsと呼ばれるライブラリは、いくつかのコンポジターのベースとして機能するモジュール式のWayland実装です^[59]

注目すべき Wayland コンポジターは次のとおりです。

• Weston – Waylandコンポジターのリファレンス実装。Westonはクライアント側の装飾を実装します。
• Enlightenmentはバージョン0.20からWaylandを完全にサポートしていると主張している^[60]が、現在、完全なWaylandコンポジターを実現するための作業が進行中である^[61]。
• KWinは2021年現在、Waylandをほぼ完全にサポートしています^[62]
• Mutterは、GNOME 3.9（2013年9月）にWaylandを統合するための別のブランチを維持していました。^[63] 2014年の3.13.1リリースでは、Waylandブランチがメインリポジトリに統合されました。^[64]
• Clayland – Clutter を使用したシンプルな Wayland コンポジターの例
• Sway – wlrootsをベースにしたタイリングWaylandコンポジター。i3 X11ウィンドウマネージャーの代替品です。^{[65] [66] [67]}
• Hyprland – C++で書かれた独立したタイリングWaylandコンポジター。Hyprlandの注目すべき機能には、動的なタイリング、タブ付きウィンドウ、クリーンで読みやすいC++コードベース、ウィンドウアニメーション、丸い角、透明なウィンドウのデュアルカワセブラーを提供するカスタムレンダラーなどがあります。^{[68] [69]}
• Woodland – C で書かれた wlroots ベースのスタッキング Wayland コンポジター。TinyWL に触発され、シンプルさと安定性に重点を置いています。

Westonは、Waylandプロジェクトによって開発されたWaylandコンポジター^[70]のリファレンス実装です。C言語で書かれており、 MITライセンスの下で公開されています。Westonは、カーネルモード設定、グラフィックス実行マネージャー（GEM）、udevなど、他のUnix系オペレーティングシステムでは実装されていないLinuxカーネルの特定の機能に依存しているため、Linuxオペレーティングシステムのみ公式にサポートされています。^[71] Linuxで実行する場合、入力ハードウェアの処理はevdevに依存し、バッファーの処理はGeneric Buffer Management （GBM）に依存します。ただし、2013年にWestonのFreeBSDへのプロトタイプ移植が発表されました。^[72]

ウェストンは高帯域幅デジタルコンテンツ保護（HDCP）をサポートしています。^[73]

Weston は、コンポジターとアプリケーション間でアプリケーション バッファーを共有するために GEM に依存しています。これには、ドックやパネルなどの一般的なデスクトップ機能用の「シェル」のプラグイン システムが含まれています。^[21]クライアントは、ウィンドウの境界と装飾の描画を担当します。レンダリングについては、Weston はOpenGL ES ^[74]または pixman ライブラリを使用してソフトウェア レンダリングを行うことができます。^[75]完全な OpenGL 実装は使用されません。これは、現在のほとんどのシステムでは、完全な OpenGL ライブラリをインストールすると、GLXやその他のX ウィンドウ システムサポート ライブラリも依存関係としてインストールされるためです。^[76]

Westonのリモートアクセスインターフェースは、2013年10月にRealVNCの従業員によって提案されました。^[77]

Maynardはグラフィカルシェルであり、 GNOME ShellがMutterのプラグインとして書かれているのと同様に、Westonのプラグインとして書かれています。 ^[78]

Raspberry Pi FoundationはCollaboraと協力してMaynardをリリースし、パフォーマンスとメモリ消費の改善に取り組んでいます。^{[79] [80]}

入力デバイス（キーボード、ポインタ、タッチスクリーンなど）を処理するためのWestonコードは、 libinputと呼ばれる独自の独立したライブラリに分割され、Weston 1.5で初めてサポートされました。^{[81] [82]}

libinput は、複数の Wayland コンポジターの入力デバイスを処理し、汎用X.Org Server入力ドライバーも提供します。これは、複数の Wayland コンポジターに共通の入力イベント処理方法を提供すると同時に、コンポジターが組み込む必要のあるカスタム入力コードの量を最小限に抑えることを目的としています。libinput は、デバイス検出^{[明確化が必要]} ( udev経由)、デバイス処理、入力デバイスイベント処理、および抽象化を提供します。^{[83] [84]}

libinputのバージョン1.0はバージョン0.21に続き、タブレット、ボタンセット、タッチパッドジェスチャのサポートが追加されました。このバージョンでは安定したAPI/ABIが維持されます。^[85]

GNOME/GTKとKDE Frameworks 5 ^[86]では必要な変更がメインライン化されているため、Fedora 22ではX.OrgのevdevとSynapticsのドライバがlibinputに置き換えられます。^[87]

バージョン1.16では、X.Orgサーバーはxf86-input-libinputと呼ばれるラッパーの形でlibinputライブラリのサポートを獲得しました。^{[88] [89]}

Waylandセキュリティモジュールは、 LinuxカーネルにあるLinuxセキュリティモジュールインターフェースに似た提案である。^[90]

一部のアプリケーション (特にアクセシビリティに関連するもの) には、異なる Wayland コンポジター間で機能する特権機能が必要です。現在、^{[いつ? ]} Wayland のアプリケーションは、通常、xdg-desktop-portal を経由したり、システムへの特権アクセスを取得したりせずに、スクリーンショットを撮ったり、入力イベントを挿入したりするなどの機密性の高いタスクを実行できません。

Waylandセキュリティモジュールは、コンポジター内のセキュリティ決定を集中型セキュリティ決定エンジンに委任する方法です。^[90]

Wayland プロトコルはシンプルに設計されているため、総合的なウィンドウ システムを実現するには、追加のプロトコルとインターフェイスを定義および実装する必要があります。2014 年 7 月の時点で、これらの追加インターフェイスは開発中でした。そのため、ツールキットはすでに Wayland を完全にサポートしていますが、グラフィカル シェル^{[アップデート]}の開発者はWayland 開発者と協力して、必要な追加インターフェイスを作成しています。

2020 年現在、^{[アップデート]}ほとんどの Linux ディストリビューションは Wayland をすぐにサポートしています。注目すべき例をいくつか挙げます。

• Fedoraのバージョン25（2016年11月22日リリース）以降では、デフォルトのGNOME 3.22デスクトップセッションにWaylandが使用され、グラフィックスドライバーがWaylandをサポートできない場合はX.Orgがフォールバックとして使用されます。^[91] Fedoraはバージョン34（2021年4月27日リリース）以降、KDEデスクトップセッションのデフォルトとしてWaylandを使用します。
• UbuntuはUbuntu 17.10（Artful Aardvark）でWaylandをデフォルトで搭載して出荷されました。 ^[92]しかし、Ubuntu 18.04 LTSではいくつかの問題によりデフォルトでX.Orgに戻りました。^{[93] [94]} Ubuntu 21.04以降、Waylandが再びデフォルトになりました。^[95]
• Red Hat Enterprise Linuxは、2019年5月7日にリリースされたバージョン8でWaylandをデフォルトセッションとして出荷しています。^[96]
• Debianは、2019年7月6日にリリースされたバージョン10以降、WaylandをGNOMEのデフォルトセッションとして出荷しています。^[97]
• Slackware Linuxは2020年2月20日に開発バージョンである-currentにWaylandを組み込み、バージョン15.0となった^{[98] 。}
• Manjaro は、Manjaro 20.2 (Nibia) (2020 年 11 月 22 日リリース) の Gnome エディションにデフォルトとして Wayland を同梱しています。^[99]

注目すべき早期導入者:

• RebeccaBlackOSは、ライブUSB Debianベースの^[100] Linuxディストリビューションであり、コンピュータのメインオペレーティングシステムに変更を加えることなく、実際のWaylandデスクトップを簡単に試すことができます。^[101] 2012年からWaylandを紹介するために使用されています。^{[102] [103]}

Wayland をサポートするツールキットには次のものがあります。

• ClutterはWaylandを完全にサポートしています。^{[104] [105] [106]}
• EFLは選択を除いてWaylandを完全にサポートしています。^[107]
• GTK 3.20はWaylandを完全にサポートしています。^[108]
• Qt 5 は Wayland を完全にサポートしており、Wayland コンポジターと Wayland クライアントの両方の作成に使用できます。
• WaylandのSDLサポートは2.0.2リリースでデビューし^[109]、バージョン2.0.4以降ではデフォルトで有効になりました。^[110]
• GLFW 3.2はWaylandをサポートしています。^[111]
• FreeGLUTはWaylandの初期サポートを備えています。^[112]

XからWaylandに移植中のデスクトップ環境としては、GNOME ^[113]、 KDE ​​Plasma 6 ^[114]、Enlightenment ^[115]などがある。

2015年11月、完全なWaylandサポートを備えたEnlightenment e20が発表されました。^{[116] [60] [117]} GNOME 3.20は完全なWaylandセッションを備えた最初のバージョンでした。^[118] GNOME 3.22には、GTK、Mutter、GNOME Shell全体で大幅に改善されたWaylandサポートが含まれていました。^[119] GNOME 3.24は、Waylandでの独自のNvidiaドライバーのサポートを出荷しました。^[120]

KDE PlasmaのWaylandサポートはPlasma 5のリリースまで延期されましたが^[121] 、それ以前にKWin 4.11が実験的なWaylandサポートを取得しました。^[122] Plasmaのバージョン5.4はWaylandセッションを備えた最初のバージョンでした。^[123] 2020年中にKlipperはWaylandに移植され、2020年10月にリリースされたPlasma 5.20では画面キャストと録画が改善されました。^{[124] [125]} Plasma 6では、Waylandを使用するデフォルトのグラフィカルセッションがデフォルトに設定され、X11セッションはセカンダリになりました。^[126]

Wayland をサポートするその他のソフトウェアには次のものがあります。

• Intelligent Input BusはWaylandのサポートに取り組んでおり、Fedora 22に間に合う可能性がある。^[127]
• RealVNCは2014年7月にWayland開発者プレビューを公開した。^{[77] [128] [129]}
• wayvnc は、wlroots ベースの Wayland コンポジター用の VNC サーバーです。
• MaliitはWayland上で動作する入力メソッドフレームワークです。 ^{[130] [131] [132]}
• kmsconはwltermでWaylandをサポートします。^[133]
• MesaにはWaylandのサポートが統合されています。^[134]
• Eclipseは2014年のGSoCプロジェクト中にWayland上で実行できるように作られました。^[135]
• Vulkan WSI (Window System Interface) は、OpenGL および OpenGL ES の EGL や X11 上の OpenGL の GLX と同様の目的を果たす API 呼び出しのセットです。Vulkan WSI には、最初から Wayland のサポートが含まれています: VK_USE_PLATFORM_WAYLAND_KHR。Vulkan クライアントは、Weston、GENIVI LayerManager、Mutter / GNOME Shell、Enlightenment など、変更されていない Wayland サーバーで実行できます。WSI を使用すると、アプリケーションはシステム上のさまざまな GPU を検出し、GPU レンダリングの結果をウィンドウ システムに表示できます。^[136]
• Waydroid (旧称Anbox -Halium) は、Wayland を使用して Linux ディストリビューション上で実行するための Android アプリケーション用のコンテナーです。

Wayland をサポートするモバイルおよび組み込みハードウェアには次のものが含まれます。

• ポストマーケットOS
• GENIVIアライアンス：車載インフォテインメント（IVI）のGENIVIアライアンス（現在はCOVESA）がWaylandをサポートしています。^[137]
• Raspberry Pi : Raspberry Pi FoundationはCollaboraと協力してMaynardをリリースし、パフォーマンスとメモリ消費の改善に取り組んでいます。^{[79] [80]}
• Jolla : JollaのスマートフォンはWaylandを採用している。また、Linux Sailfish OSを他のベンダーのハードウェアで使用する場合や、ユーザーがAndroidデバイスにインストールする場合にも標準として使用されている。 ^{[138] [139] [140]}
• Tizen : Tizen 2.xまでは車載インフォテインメント(IVI)セットアップでWaylandをサポートしており^[141]、3.0以降ではWaylandがデフォルトになっています。^{[142] [143]}

クリスチャン・ホグスバーグは、かつてAIGLXとDRI2に携わっていたLinuxグラフィックスおよびX.Org 開発者で、2008 年にRed Hatで働きながら、余暇プロジェクトとして Wayland を立ち上げました。^{[144] [145] [146] [147]}彼が掲げた目標は、「すべてのフレームが完璧であるシステム、つまり、ティアリング、ラグ、再描画、ちらつきがまったく発生しないよう、アプリケーションがレンダリングを制御できる」というものでした。ホグスバーグがマサチューセッツ州ウェイランドの町を運転していたときに、基礎となる概念が「結晶化」し、それがこの名前の由来となりました (ウェストンとメイナードも同じ地域の近くの町であり、このことからもそれがわかります)。^{[146] [148]}

2010年10月、Waylandはfreedesktop.orgプロジェクトとなった。^{[149] [150]}移行の一環として、以前のGoogleグループはプロジェクトの議論と開発の中心として wayland-develメーリングリストに置き換えられた。

Waylandのクライアントとサーバーのライブラリは当初MITライセンスの下でリリースされたが、^[151]リファレンスコンポジターのWestonといくつかのサンプルクライアントはGNU General Public Licenseバージョン2を使用していた。^[152]その後、すべてのGPLコードは「リファレンス実装と実際のライブラリ間でのコードの移動を容易にするため」にMITライセンスの下で再ライセンスされた。 ^{[153] 2015年に、Waylandで使用されていたライセンステキストがMITライセンスのわずかに異なる古いバージョンであることが判明し、ライセンステキストは}X.Orgプロジェクトで使用されている現在のバージョン（ MIT Expat Licenseとして知られる）に更新された。^[6]

Waylandは、DRI2をサポートするすべてのMesa互換ドライバー^[134]と、Hybrisプロジェクト経由のAndroidドライバーで動作します。^{[154] [155] [156]}

• ミール（ソフトウェア）
• X ウィンドウ システム