Clever Geek Handbook

WaylandはX Window Systemを置き換えます

以前の投稿で 、X Window Systemが歴史上最も成功したオープンソースプロジェクトの1つである理由を学びました。今度は、Linuxグラフィカル環境用の新しいソリューションに置き換えます。 同じ記事で、 WaylandがXを置き換える最も有力な候補である方法を学びます。

















用語集ウェイランド



最初にいくつかの定義と用語を扱うことは理にかなっています。







コンポジター -コンポジットウィンドウマネージャーは、 Waylandおよびその周辺の中心概念の1つです。 それが何であるかは実際にはどこでも定義されていませんが、この用語は誰もがすべてを知っているかのように使用されます。 いずれにせよ、ロシア語では定義が見つかりませんでした。 幸いなことに、例はそのポイントを明確にします。 Waylandのコンテキストにおけるそれらのリストは次のとおりです。









ご覧のとおり、これは、実際にはそうではありませんが、私たちが知っているウィンドウマネージャーにすぎません。 これらはディスプレイサーバーですが 、それでもWMとは機能が異なります。 前者は、ハードウェアを使用してユーザー入出力デバイスとやり取りし、クライアントプログラムのデータフローを制御します。 2番目のものは、ウィンドウの表示とウィンドウインターフェイスシステムでの配置を担当します。







ウィキペディアページの図 。

















しかし、これらのサーバー、マネージャーの間に明確なセマンティックおよび用語の境界があると言うこと そして作曲家 いたずらになります。 たとえば、 KWin



はEnlightenment



と同様にディスプレイサーバーとWMの両方です。 この記事では、 複合ウィンドウマネージャー （COMと略記）およびディスプレイサーバーは、用語Compositorと同等です。 







 $ eix -c enlightenment; eix -ce kwin [N] x11-wm/enlightenment (1.0.17): Enlightenment Window Manager (e16) [I] kde-plasma/kwin (5.8.5(5)@01.02.2017): KDE window manager


複合サーバー、ディスプレイサーバーは、 複合ウィンドウマネージャーとも呼ばれます 。 







 $ eix -c mutter [N] x11-wm/mutter (3.20.3): GNOME 3 compositing window manager based on Clutter


Weston -Wayland Protocol Reference Display Server。 最近、 COM の 2番目のバージョンが出ました 。

EGLは、Khronos Groupによって開発されたOpenGL GLX / AGL / WGLと同等の、プラットフォームに依存しないソフトウェアです。 EGLは、迅速なアプリケーションのセットアップとシーンの初期化のためのインフラストラクチャキットを提供します。









EGLは、GLX / AIGLXとは異なり、 直接レンダリングのみを実行できます。DRI2/ DRI3を介したアプリケーションは、Xサーバーをバイパスしてビデオ機器に安全かつ迅速にアクセスできます。







GLES-携帯電話、タブレット、コンピューター、ゲーム機などの組み込みシステム専用に設計されたOpenGLのサブセット。







ウェイランドアーキテクチャ



それでは、 ウェイランドとは何ですか？ X Window Systemと同様に、プロトコルとその実装について話します。 Waylandは、COMとクライアント間のやり取りのプロトコルであり、Cでのライブラリ実装でもあります。 クライアントは、ユーザーアプリケーション、Xサーバー、または別のディスプレイサーバーです。









プロトコルの最下位レベルで、クライアントとCOMはメッセージを同libwayland-client



、IPCライブラリlibwayland-client



とlibwayland-server



を使用して順序付けられたオブジェクトを交換しlibwayland-server



。 このレベルでは、ウィンドウインターフェイスを制御する方法はありません。Unixドメインソケット、オブジェクト、およびイベントを介して送信されるメッセージのみです。 







 +-------------------+ +-------------------+ | | | | | Client | | Compositor | +-------------------+ +-------------------+ | libwayland-client | | libwayland-server | +-------------------+ +--+----------------+ | | | Wayland | User space | protocol | +---------------------------------------------------+ | Kernel space | +---+ | | | +------>|IPC|<----+ | | +---+ | +---------------------------------------------------+


クライアントによって作成されたオブジェクトは、 wl_proxy



構造で表されます。 wl_proxy



構造には、ソケットを介してサーバーに送信されるメッセージの識別子、 void



データポインター、および静的wl_interface



オブジェクトへのポインターがwl_interface



ます。 メッセージはwl_proxy_marshal



構造を使用して送信されます。 







 static inline void wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y) { wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y); }


Waylandは、オブジェクト指向でメッセージの処理を目的とした非同期プロトコルです。 クライアントからサーバーに送信されるメッセージはcallであり、反対の方向ではeventです。 各メッセージは32ビットワードで構成され、値はホストバイトの順に表示されます。







Wayland ホームページのイラスト 。

















これらのブロックはどのように相互作用しますか？







  1. カーネルはイベントを登録し、COMに送信します。
  2. COMはシーングラフで、このイベントの配信先のウィンドウを見つけ、オブジェクトに適用する変換の種類を正確に知っています。 KOMは、逆変換によって特定のウィンドウの画面座標をローカルに変換します。
  3. クライアントは、グラフィカルインターフェイスの領域を更新してイベントを処理し、COMに変更をレンダリングして通知します。
  4. KOMは、依存バッファーの内容が表面領域と異なる地域のすべてのデータをクライアントから収集し、画面を再配置します。 さらに、ディスプレイサーバーは、KMSにアドレス指定されたioctl呼び出しを使用して新しいページを読み込みます。


そして、レンダリングはどうですか？ クライアントは個別にウィンドウを個別のバッファーに描画し、更新に関する情報をディスプレイサーバーに渡します。ディスプレイサーバーは、さまざまなアプリケーションのバッファーの内容を組み合わせて、ウィンドウのオーバーラップや透明度などの微妙なニュアンスを考慮して最終出力を形成します。







ウェイランドvs. X



それでは、 Waylandはどのようにさらに良くなっているのでしょうか？ 主な点に目を通し、なぜすべてが成功したのかを理解しましょう。 個人的には、 xorg.conf



構成ファイルが存在しないという事実で十分です。 ただし、このファイルの編集に対する直接の手による実り多い影響は、前の投稿へのコメントですでに議論されています。







  1. バージョンはプロトコルを上から下に浸透します。 各インターフェイスには特定のバージョンがあり、各プロトコルオブジェクトはインターフェイスの特定のバージョンを実装します。 これにより、バージョン管理は接続ではなくクライアントに関連付けられるため、バージョン Xの絶え間ない競合の状況がなくなります。 アプリケーションが拡張機能の1つのバージョンをサポートし、ツールキットが別のバージョンで、X11が3番目の場合、アプリケーションが最終的に受け取るものを予測することは不可能です。
  2. Waylandでの入力デバイスの操作は、 Xinput 2.2



    から古いコードのヒープと入力デバイス間のマスター/スレーブの順序を差し引いたものに非常に似ています。 グローバルオブジェクトseat



    、つまり場所は 、マウス、キーボード、タッチスクリーンなどの入力デバイスのグループを定義します。 マルチタッチに関する悪夢のような問題はなくなります。
  3. Waylandは、Xとは異なり、レンダリングAPIを持たないため、アートに関与しません。 彼が必要とするのは、クライアントピクセルで満たされたバッファーだけで、その後、アプリケーションAがアプリケーションBの画像を含むバッファー内で何かを台無しにしないようにします。顧客は、どのピクセルがバッファーに表示され、スクリーン！










  1. ウェイランドは最小限です。 誰かがglxgearsの印刷サポートを追加することを考えた後、XはOSのカーネル機能の完全なセットを備えた状態であり、独自のプリントサーバーさえ持っていたことを思い出してください。 したがって、 ウェイランドでのこのすべては、そうではなく、今後もそうではありません。 主な負担は顧客が負担するものであり、30年前はUI要素の互換性の負担に屈したくないため、これはすばらしいことです。
  2. 必須レイアウト（合成）。 これは、3D効果が避けられないという意味ではありません。 レイアウトとは、揺れたりジャンプしたりしないシームレスな画像を意味します。 ウェイランドのモットーは 一休みではない すべてのフレームが美しい 。 クライアントが考えて実装した、その場所の各ピクセル。 比較のために、X Composite拡張機能はどのように機能しますか？ デスクトップエフェクトの場合、GLレイアウトは非常に魅力的ですが、ブラウザでビデオを見るとすぐに問題が始まります。 ブラウザウィンドウとFlash Playerのペインは、どのような方法でも同期されません。 それらの場合、イベントは独立して処理され、2つのスレッドがすぐに実行されないことを期待できます。 このため、アクティブなYoutubeビデオを使用してウィンドウをスクロールしているときに、画像がジャンプして痙攣する場合があります。
  3. サーバーにフォントはありません。クライアント自身が対処します。 すでに対処しています。
  4. Xは無意識に苦しんでいます。そのため、2つ以上のモニター、グラフィックカードの設定を記憶するには悪名高いxfree86.conf/xorg.conf



    が必要です。 ポストXの時代に、これらのキラー機能がなければ退屈することはないでしょうか？


XとWaylandについての誤った判断



この主題については、多くの執persistentに間違った意見があります。









使用済みの資料と便利なリンク



ウェイランドの状況：X対事実 ウェイランド

Waylandで実行されるX11アプリケーションの開発ステータス

Waylandのドキュメント







More articles:


All Articles