Clever Geek Handbook

Linuxグラフィックススタック

（オリジナル-GNOME Shell開発者、Jasper St. Pierre、 こちらから撮影 ）



これは、Linuxグラフィックススタックのコンポーネントとそれらがどのように連携するかについての概要記事です。 最初は、このスタックについてオーウェンテイラー、レイストラウド、エデンジャクソンと話し合った後、自分で書いた（ オーウェンテイラー -Gnome Shellのメンテナー 、レイストロード-RedHatコミュニティの多数のデスクトップパッケージのメンテナー、 アダムジャクソン -グラフィックスタックGnome Shellの開発者との統合XOrg;翻訳者のコメント） 。



私は常にそれらを引っ張り、あらゆる種類のささいなことについて何度も尋ねました。そして、私はこれらのささいなことを安全に忘れました。 最後に、私は彼らに質問をしました-自分自身を埋めて、面倒な注意から人を救うレビュー文書はありますか？ 肯定的な回答が得られなかったため、この記事を書くことにしました。この記事は最後にEdam JacksonとDavid Airlieによって読まれました。 両方ともこのスタックで動作します。



読者の皆さん、この記事で示したLinuxグラフィックススタックの大部分のデバイスは、オープンドライバーに有効であることを警告したいと思います。 これは、AMDまたはnVidiaの専用ドライバー内では、すべてが少し間違っている可能性があることを意味します。 またはそうでもない。 またはまったくありません。 独自のOpenGL実装と、コピーされたMesa実装を使用できます。 オープンドライバー「radeon」、「noveau」、およびIntelドライバーに実装されているスタックについて説明します。



ご質問がある場合、または一部の詳細が十分に明確でないように思われる場合（まあ、私は非常に、非常に間違っているか、何らかの形で混乱しています）-コメントでそれについて書くことをheしないでください。



まず、ここでスタックのすべてのコンポーネントを簡単にリストします。 さて、あなたが一般的にそれらの詳細な説明の中で方向づけられるために。



一般的に、正確には、選択するレンダリングのタイプに応じて、スタック内のイベントの開発には2つの異なるシナリオがあります。





OpenGLを使用した3Dレンダリング



  1. プログラムはレンダリングにOpenGLの使用を開始します。
  2. mesaライブラリは、このまさにOpenGL APIを提供します。 ビデオカードの特定のドライバーを使用して、OpenGL呼び出しをビデオカードの許容可能な形式に変換します。 Galliumがドライバー内で使用される場合、共有コンポーネントも接続され、OpenGL呼び出しが共通の中間表現であるTGSIに変わります。 Gallium内で呼び出しを変換した後、低レベルドライバーはTGSIをハードウェアに明確なハードウェアコマンドにのみ変換できます。
  3. libdrmは、特別なioctlを使用してLinuxカーネルと通信します。
  4. Linuxカーネルは（そうする権利があるので）ビデオカードに直接およびシステムメモリの両方でビデオカードのメモリ領域を割り当てることができます。
  5. このすべての後、そのレベルのmesaはDRI2を使用してXorgと通信し、バッファーが切り替えられたこと、ウィンドウの位置などを確認します。 -同期。




cairoを使用した2Dレンダリング



  1. プログラムは、レンダリングにcairoの使用を開始します。
  2. いくつかのグラデーション円を描きます。 Cairoは円を四角形に分割し、XRender拡張機能を使用してこれらの四角形とグラデーションをXサーバーに送信します。 XサーバーがXRenderをサポートしていない場合、cairoはlibpixmapを使用してそれ自体を描画し、別の方法を使用してレンダリングされたピクセルマップをXサーバーに送信します。
  3. Xサーバーは、XRenderからの要求を受け入れます。 この場合、Xorgはさまざまな専用ドライバーを使用できます。

    1）ソフトウェアレンダリングにロールバックするか、ドライバーの準備が整っていない場合、Xorgはlibpixmanを使用して、cairoと同様に独自に描画します。

    2）ハードウェアアクセラレーションの場合、Xorgドライバーはlibdrmを介してカーネルと通信し、テクスチャとコマンドをビデオカードに送信します。




さて、画面に描画するために、Xorg自身がKMSとビデオカードドライバーの助けを借りて、フレームバッファーを準備します。



X Window System、X11、Xlib、Xorg



X11はグラフィックスシステムに直接関連していません-メッセージ配信システム、ウィンドウプロパティの説明などが含まれています。 さらに、X11の上に、グラフィックスとはまったく関係のないものが多数実装されています（たとえば、クリップボードとドラッグアンドドロップのサポート）。 ここでは、X Window System内でのX11の位置を一般的に理解するためだけにX11について書いています。 いつか、X Window System、X11、およびそれらの奇妙なアーキテクチャに関する別の投稿を書くことができれば幸いです。





ネーミングはできるだけ正確にしようとしています。 「X-server」と書くと、抽象サーバーXについて話している-Xorgかもしれないし、AppleのサーバーXの実装かもしれないし、Kdriveかもしれない。 違いはありません。 「X11」または「X Window System」と書くと、これはプロトコルとシステム全体のアーキテクチャを意味することを意味します。 「Xorg」と書くと、最も一般的なXサーバーであるXorgの実装の詳細に関するものであり、他のXサーバーの実装の詳細に関するものではありません。 ちょうど「X」に出会った場合-これはタイプミスまたはジャムです。


X11 （プロトコル自体）は、拡張可能であることを目標に開発されました（つまり、根本的に新しいプロトコルを作成せずに、古いクライアントとの後方互換性を失うことなく、新しい機能を追加することができます）。 たとえば、xeyesとoclockは、非四角形ウィンドウの使用を許可するShape Extensionにより、「非標準」になります。 この機能がどこから出てくるのか不明確な場合、答えは「魔法はそれとは何の関係もない」です。 拡張サポートは、クライアントとサーバーの両方で追加する必要があります。 基本的なプロトコル仕様には、クライアントが利用可能な拡張機能に関する情報をクライアントから受信するための特別な機能があります。 この機能により、顧客は使用するものと使用しないものを決定できます。



X11アーキテクチャは、ネットワーク環境に対して透過的になるように設計されました。 簡単に言えば、クライアントとサーバーの部分（XサーバーとXクライアント）が同じマシン上にあるという事実に頼ることはできません。そのため、それらの間の通信はネットワークを介して実装する必要があります。 実際、通常の構成の最新のデスクトップ環境は、X11に加えて、たとえば、すべての種類のDBusがプロセス間通信に参加するため、この方法では機能しません。 ネットワーク接続での作業は非常に激しく、大量のトラフィックを生成します。 X Window Systemのクライアント部分とサーバー部分が同じマシン上にある場合、ネットワーク接続を介して通信する代わりに、UNIXソケットを介して通信するため、カーネルの負荷が大幅に軽減されます。



X Window Systemとその拡張機能のいくつかに少し戻って説明します。



カイロ



Cairoは、通常のアプリケーション（Firefoxなど）とGTK +などのさまざまなツールキットの両方で直接使用されるベクターグラフィックスレンダリングライブラリです。 たとえば、GTK + 3レンダリングモデルは完全にcairoに基づいています。 HTML <canvas>要素を使用した場合、cairoのAPIは類似しているため、cairoをかなり完全に理解できます。 <canvas>は元々Appleによって導入されたという事実にもかかわらず、ベクターグラフィックスははるかに早く生まれました（PDF、Flash、SVG、Direct2D、Quartz 2D、OpenVGなどの標準と技術に反映されたPostScriptレンダリングモデルからも）等々、それらの数千）。



Cairoは、特別なXlibバックエンドを介してX11表面にペイントできます 。



GTK + 2では、バージョン2.8まで、cairoはオプションのコンポーネントとして使用されていました。 現在、GTK + 3 cairoは必須と見なされています。



XRender拡張



アンチエイリアスを使用したプリミティブのレンダリングをサポートするために、X11プロトコルには特別な拡張機能であるXRenderがあります（X11プロトコルの描画の基本操作ではアンチエイリアスを使用しません）。 アンチエイリアスを使用してプリミティブをレンダリングすることに加えて、この拡張機能では、グラデーション、マトリックス変換などを使用できます。



最初、このような拡張機能をプロトコルに入力する理由は、XRenderが使用するこのレンダリングの特別なハードウェアアクセラレーション方式をドライバーが持つことができるという事実に対する魅力でした。



残念ながら、実際には、ソフトウェアのラスタ化（明らかな理由による）はハードウェアの速度よりも劣らないことが示されています。 まあ。



XRenderは、台形が整列している場合に機能します。左右に平行でない可能性のある四角形。 Karl WorthとKate Packardは、これらのプリミティブをレンダリングするためのかなり高速なプログラミング方法を開発しました。 整列した台形にはもう1つのプラスがあります-台形は2つの三角形の形で簡単に表現できます。 これにより、鉄を使用したレンダリングが簡素化されます。 カイロには素晴らしいユーティリティショートラップがあり、台形にレンダリングするために渡されたプリミティブをカットする方法を示しています。







赤い丸の簡単な例。 円は、パス用と塗りつぶし用の2つの台形セットに分割されます。 show-trapsの実装ではこのプロセスが情報に基づいて表示されないため、ユーティリティのソースコードを調整して、各台形が独自の色でペイントされるようにしました。 これは、黒いアウトラインを描画するための台形セットの例です。







サイケデリック。



ピックスマン



Xサーバーとcairoの両方がピクセルで動作する必要があります。 以前は、CairoとXorgは、ラスタライズ、さまざまなバッファ（ARGB32、BGR24、RGB565）へのピクセルごとのアクセス、グラデーション、マトリックス、その他すべてを異なる方法で実装していました。 現在、cairoとXサーバーの両方が、比較的低レベルのpixmanライブラリを介してこれらすべてを実行しています。 pixmanは共有ライブラリであるという事実にもかかわらず、操作をレンダリングするためのパブリックAPIまたは特定のAPIはありません。 厳密に言えば、APIはまったくありません。前述の2つのコンポーネント間で重複排除するためのコードのリポジトリにすぎません。



Opengl、メサ、ガリウム



そして、これは楽しい部分です-最新のハードウェアレンダリングアクセラレーション。 OpenGLが何であるかは誰もがすでに知っていると思います。 これはライブラリではなく、libGL.soをビルドするための特定のソースセットでもありません。 各メーカーは、OpenGL仕様と互換性のある独自のlibGL.soを持っています。



たとえば、nVidiaは独自のOpenGL実装と独自のlibGL.soを提供しますが、これらは同じWindowsまたはOS Xに対して異なる方法で実装されます。



オープンソースドライバを使用する場合、libGL.soの実装はほとんどの場合mesaに基づいています。 Mesaはあらゆるものの大きな束ですが、このヒープの主で最も有名な部分は、オープンソースのOpenGL実装です。 OpenGL APIのメサ内では、さまざまなバックエンドを使用してAPIを経営陣に変換しています。 3つのソフトウェアバックエンドがあります。







ソフトウェアバックエンドに加えて、mesaはハードウェアをサポートしています。







実際、ガリウムは、ドライバーを簡単に構築できるコンポーネントのセットです。 ポイントは、ドライバーが以下で構成されることです。







残念ながら、Intel開発者はガリウムを使用していません。 私の同僚は、これはIntelドライバー開発者がmesaとドライバーの間にレイヤーを置くことに抵抗があるためだと言います。



いくつかのカット



物語の途中で別の大きな段落を取り上げたくない略語については、後で説明します。 したがって、ここにそれらを単純にリストします。 それらの多くは歴史的価値しかありませんが、それにもかかわらず、私はそれらについて書きます。 あなたが知っているように。







ドライバーXorg、DRM、DRI



先ほど、Xorgがハードウェアアクセラレーションレンダリングを作成できることを書きました。 これは、X11描画コマンドをOpenGL API呼び出しに変換しても実現されないことを付け加えます。 次に、ハードウェアドライバーがmesaの腸で動作し、Xorgがmesaに関連付けられていない場合、Xorgはどのようにハードウェアと動作しますか？



答えは簡単です。 どう？ MesaはOpenGLの実装を担当し、XorgはX11コマンドのレンダリングの実装を担当し、両方とも特定のハードウェア固有のコマンドを使用してハードウェア上で描画する必要があります。 かつて、Xorgとmesaのアーキテクチャに別のコンポーネントが導入され、これらのコマンドがカーネルにロードされます。いわゆる「Direct Rendering Manager」または「 DRM」です。



Libdrmは、元の閉じたカーネルioctlのセットを使用して、グラフィックアクセラレータにリソースを割り当て、テクスチャにコマンドを提供します。 これらのioctlの共通インターフェースは、（一般に、予想どおり）2つのタイプになります。







それらの間に大きな違いはありません。 どちらも同じことを行い、実装がわずかに異なります。 GEMは、歴史的にTTMの単純な代替としてIntelによって導入されてきました。 しばらくして、GEMが成長し、「シンプルさ」はTTMのそれと同じになりました。 そのようなこと。



なんでこんなこと？ また、たとえば、glxgearsなどのユーティリティを実行すると、mesaがロードされます。 Mesaはlibdrmをダウンロードします。 Libdrmは、GEM / TTMを使用してカーネルドライバーと通信します。 はい、glxgearsはカーネルと直接連携していくつかの回転ギアを表示するため、これがベンチマークユーティリティであることを思い出させます。

コンソールでコマンドを実行する場合（アーキテクチャーに応じてlib32 / lib64を置き換えます）：



ls /usr/lib32/libdrm_*







ハードウェア依存のドライバーがあることがわかります。 GEM / TTMに組み込まれた機能が十分でない場合、mesaおよびX-serverドライバーは、実際にはこれらのデバイス依存ドライバーにあるカーネルと通信するための、さらにクローズドなioctlのセットを提供します。 Libdrm自体はこれらのドライバーをロードしません。



Xサーバーは、同期を実装するためにグラフィックスサブシステムで何が起こっているかを知る必要があります。 この同期方法（たとえば、実行中のglxgear、カーネル、およびXサーバー間）は、 DRIまたはより正確にはDRI2と呼ばれます。 DRIは「Direct Rendering Infrastructure」の略です。 一般に、DRIは次の2つのことを理解しています。







厳密な用語に準拠しており、DRI1は馬鹿げているように見えるため、プロトコルとライブラリについて説明し、DRI2と呼びます。



KMS



私たちは少し話題から外れており、インフラストラクチャのことについて話し始めたので、質問をします。 新しいXサーバーで作業している、またはXサーバーを使用せずに仮想端末でグラフィックを表示したいとします。 どうやってこれをしますか？



グラフィックを表示できるようにハードウェアを構成する必要があります。



内部では、libdrmとカーネルにはそれを行う特別なKMSサブシステムがあります。 KMSという頭字語は、「カーネルモード設定」の略です。 繰り返しますが、このサブシステムを使用すると、一連のioctl'eyを使用して、グラフィックモードを設定し、フレームバッファーを構成し、TTYでグラフィックを直接表示するために必要なすべてを実行できます。 カーネルにKMSが登場する前は、実際には単一のドキュメント化されたAPIを使用して共有libkmsライブラリを作成するための、さまざまなioctlのセットがありました（そして、まだどこにも行っていません）。



確かに、libkmsの後、突然（Linuxの世界では慣例的です）、文字通り「愚かなioctl」と呼ばれる新しいAPIがカーネルに登場しました。 そのため、現在のところ、libkmsではなく、このioctlのセットを使用することをお勧めします。



これらのioctlは非常に低レベルでシンプルであるという事実にもかかわらず、ほとんど何でも実行できます。 これの例はプリマスであり、ほとんどすべての最新のLinuxディストリビューションでは、Xサーバーを起動せずにブートプロセスをグラフィカルに表示します。



モデルの公開、リダイレクト、TFP、合成、AIGLX



「構成」とは何か、ウィンドウマネージャが何をするのかを理解しない限り、「構成ウィンドウマネージャ」という用語について話すことはできません。



80年代、UNIXウィンドウシステム用にX Window Systemアーキテクチャが開発されたとき、HP、DEC、Sun、SGIなどの企業がX Window Systemに基づいて製品を開発しました。 同時に、X11プロトコルはウィンドウを管理するためのルールを規制せず、その動作に対する責任を「ウィンドウマネージャー」と呼ばれる別のプロセスに委任しました。



たとえば、当時人気のあったウィンドウ環境であるCDEは、「マウスにフォーカスを合わせる」と呼ばれるウィンドウの動作を公言しました。 その本質は、ユーザーがその上にマウスを置いたときに、入力フォーカスがウィンドウに転送されたことです。 これは、クリックによってウィンドウにフォーカスが渡されるWindowsまたはMac OS Xのウィンドウの動作とは異なります。



ウィンドウ環境の人気が高まり、ますます複雑になるにつれて、さまざまなウィンドウ環境の一般的な動作を規制する関連ドキュメントが登場し始めました。 確かに、これらの文書は、フォーカス転送を実装するためのポリシーも規定していませんでした。



繰り返しになりますが、それらの80年代には、多くのシステムにメモリが不足していたため、ウィンドウのすべてのコンテンツをピクセル形式で保存できませんでした。 WindowsとX11の両方がこの問題を同じ方法で解決しました。すべてのX11ウィンドウがピクセル状態を持つべきではありません。 必要に応じて、アプリケーションは、ウィンドウの一部を再描画する必要があるという通知を受け取りました（「露出」、「露出」を生成します）。







このような一連のウィンドウを想像してください。 GIMPウィンドウを移動します。







濃い茶色に塗られた領域が露出しています。 ExposeEventイベントは、ウィンドウを所有するアプリケーションにディスパッチされ、アプリケーションは公開されたものに対応する画面の領域を再描画します。 このモデルのため、WindowsおよびLinuxで中断されたアプリケーションのウィンドウを再描画すると、その上に別のウィンドウをドラッグすると白い領域ができます。 Windowsでは、デスクトップが特別な特権を持たないまったく同じプログラムでレンダリングされ、同じ方法でフリーズする可能性があることを考慮すると、 この楽しいアーティファクトの動作の理由を簡単に理解できます。



今日、コンピューターには多くのメモリがあります。 したがって、ピクセル表現を失わないX11ウィンドウを使用することができます。 これは、「 リダイレクト 」 （「リダイレクト」）と呼ばれるメカニズムを使用して行われます。 ウィンドウをリダイレクトすると、Xサーバーは、オフスクリーンフレームバッファーに直接描画するのではなく、ピクセルバッファーを作成して各ウィンドウを描画します。 これは、ウィンドウの内容が画面に直接表示されないことを意味します。 オフスクリーンフレームバッファーでピクセルをレンダリングするのは、他の何かが原因です。



コンポジションの拡張により、ウィンドウのコンポジションマネージャー（または「 コンポジター 」、「コンポーザー」）は、いわゆるコンポジットオーバーレイウィンドウ（「コンポジションレイヤーのウィンドウ」）またはCOWを作成できます。 その後、作曲家はCOWウィンドウの所有者に任命され、それを描画できます。



CompizまたはGNOME Shellを起動すると、これらのアプリケーションはOpenGLを使用して、リダイレクトされたウィンドウを画面に表示します。 Xサーバーでは、GL拡張機能「 Pixmapのテクスチャ 」 （「ピクセルマップのテクスチャ」）またはTFPを使用して、ウィンドウのコンテンツを使用できます。 この拡張により、OpenGLアプリケーションは、X11ピクセルマップをネイティブOpenGLテクスチャであるかのように使用できます。



コンポジットウィンドウマネージャーは、原則として、TFPまたはOpenGLを使用できません。 TFPとOpenGLだけが最も簡単に作成できます。 ウィンドウマネージャが標準ツールを使用してCOWにピクセルマップウィンドウを描画することを妨げるものは何もありません。 Qt4を直接構成に使用して、kwin4がまさにそれを行うと言われました。



コンポジションウィンドウマネージャーは、TFPを介してXサーバーからピクセルマップを受け取り、適切な場所のOpenGLシーンに描画し、通常のX11ウィンドウで作業しているような錯覚を作成します。 「錯覚」と呼ぶのは馬鹿げているように思えるかもしれませんが、たとえばGNOME Shellを使用すると、コンポジションの「錯覚」を確認できます。 これを行うには、見ているガラスにGJSコードを入力して、アクティブウィンドウのサイズと位置を変更します。



global.get_window_actors().forEach(function(w) { w.scale_x = w.scale_y = 0.5; });







構図の錯覚は、望んでいるウィンドウではなく、別のウィンドウでマウスでつついていることに気づくとすぐに消えます。 すべてを元に戻すには、0.5から1.0に変更して、見えるコードに同じコードを入力します。



これらすべての詳細を理解したので、別の略語-AIGLXについて話すことができます。 AIGLXは「Accelerated Indirect GLX」 （加速トランジット/間接GLX ）の略です。 X11はネットワーク指向のプロトコルであるため、OpenGLはネットワークを介して機能できる必要があります。 OpenGLがこのモードで使用される場合、同じマシンでOpenGLが使用される標準の「直接コンテキスト」モードとは対照的に、モードは「間接コンテキスト」と呼ばれます。 悲しいことに、トランジットコンテキストのネットワークプロトコルは、驚くほど不完全で不安定です。



AIGLXアーキテクチャソリューションの妥協点を理解するには、彼らが解決しようとした問題、Compizのようなコンポジションマネージャーを非常に高速にする必要性を理解する必要があります。 NVidia独自のドライバーには独自のカーネルレベルのメモリ管理インターフェイスがありますが、オープングラフィックスタックにはありません。 したがって、ウィンドウのピクセルマップをテクスチャとしてXサーバーからグラフィックハードウェアに直接転送すると、ウィンドウが更新されるたびにこのピクセルマップがコピーされます。 非常に遅い。 したがって、AIGLXは、ハードウェアアクセラレーションでピクセルマップのコピーを除外するために、OpenGLの高速ソフトウェア実装の一時的な松葉杖として以前は認識されていました。 さて、Compizが描くシーンは通常それほど複雑ではないので、これは完全にうまく機能しました。



多くの賞賛とPhoronixの記事にも関わらず、AIGLXは深刻なことに使用されたことはありません。単にコピーすることなくTFPを実装できる通常のDRIスタックがあるからです。



これで、データを直接コピーしないとOpenGLテクスチャとしてレンダリングに転送できないように、ウィンドウのピクセルマップの内容をコピー（または、より正確には置換）できることを理解する必要があります。 このため、ほとんどのウィンドウマネージャーの設定には、全画面表示に拡大されたウィンドウのリダイレクトを無効にできる機能があります。 結果としてX Window Systemのロジックに従ってウィンドウを取得するため、 「 unredirection 」と呼ぶのは愚かかもしれません。 はい、歴史的にそうです。 しかし、最新のLinuxでは、この状態は通常のウィンドウ状態とはほとんど言えません。 リダイレクトの変更が必要な理由 はい、それから、展開された状態では、どのウィンドウもCOWを完全に覆っているため、複雑な構成を実行する必要はなく、オフにすることができます。 この機能は、ゲームやビデオプレーヤーなどのフルスクリーンアプリケーションを、最大60フレーム/秒の更新パフォーマンスでウィンドウデータを追加コピーせずに動作させるために必要です。



ウェイランド



上記では、Xのモノリシックアーキテクチャからかなり大きなインフラストラクチャを特定しました。 しかし、グラフィックスサブシステムは、時間の経過とともにモノリスから脱落したものすべてではありません。入力デバイスのほとんどすべての処理がevdevを使用してカーネルに移動し、ホットプラグデバイスのサポートがudevに戻りました。



X Window Systemが今も存続している理由は、これまでずっとコミュニティの努力がそれを置き換えることに向けられてきたからです。 この代替はXorgであり、最新のグラフィック環境に必要な機能を提供するさまざまな拡張機能を備えています。 古典的なX Window Systemは廃棄されたゴミだと言えます。



私たちはウェイランドに向かっています。 Waylandは、X Window Systemを置き換えるために作成した非常に大量のインフラストラクチャを再利用しています。 Waylandアーキテクチャに関する唯一の議論の余地があるのは、ネットワークとレンダリングプロトコルの不透明度です。 一方、私たちの時代には、Xの機能の大部分がすでに他のサービス（たとえばDBus）に分散しているため、ネットワークプロトコルの途方もない柔軟性は不要になっています。 実際、Xのネットワーク履歴との互換性のためだけにクリップボードやドラッグアンドドロップサポートなどで作成されたX Window Systemアーキテクチャのハックを見るのは残念です。



既に述べたように、Waylandは上記のスタック全体を使用して、モニター用のフレームバッファーを取得して起動することができます。 Waylandは特定の交換プロトコルを保持していますが、UNIXソケットとローカルリソースのみに基づいています。 WaylandとXorgの最大の違いは、/ usr / bin / waylandで始まっておらず、別のプロセスとしてメモリにハングアップしないことです。 彼は、時代の精神と現代のデスクトップ環境の要件に従って、すべてをウィンドウマネージャーのプロセスに直接接続します。 このようなウィンドウマネージャー、より正確にはWaylandの用語では「作曲家」は、evdevを使用してカーネルからイベントをプルし、KMSまたはDRMを使用してフレームバッファーを調整し、OpenGLを含むグラフィックスタックを使用して画像を描画します。 そのような接着層の言及はすぐに大量のコードとの関連付けを引き起こすという事実にもかかわらず（多くのシステムが相互作用に参加しているため）、実際には、ボリュームの順序は2〜3000行のコードに適合します。 かなりたくさんのようですか？ フォーカス、ウィンドウのスタック、Xサーバーとの同期のメカニズムを説明するつぶやきのほんの一部だけが、すでに4〜5000行のコードであると想像してください。



Waylandにはプロトコルを実装するための参照ライブラリがあり、クライアントと作曲家の両方に使用することを強くお勧めしますが、Waylandの作曲者全体をPythonで書くことを妨げるものは何もありません。 またはRubyで。 また、libwaylandを使用せずに、純粋なPythonでプロトコルを実装します。



Waylandクライアントは作曲家と通信し、バッファーを要求します。 作曲家は、少なくともOpenGLを使用して、少なくとも独自にcairoを使用して描画できるバッファーを提供します。 作曲家は、このバッファーをどうするかを自分で決めます。アプリケーションの永続性のために表示するか、優先させるか、キューブ上で回転させます...キューブ上で回転するLinuxウィンドウでYouTubeに新しいビデオを配置したいので... さて、あなたはポイントを得る。



さらに、作曲家は入力およびイベント処理を担当します。 GNOME Shell用のGJSコードを実行しようとした場合、おそらく「マウスは変換されていないウィンドウで動作するのですか」という質問に戸惑っていたでしょうか？ しかし、X11内のウィンドウ自体ではなく、ウィンドウの表示に基づいて行動したためです。 Xサーバーは独自にウィンドウを監視し、ウィンドウの構成マネージャーがそれに応じてウィンドウを表示することを期待しています。 そうでない場合は、上記の場合のように困惑する必要があります。



Waylandの作曲家はevdevと連携してイベントをウィンドウにディスパッチするため、ウィンドウの場所、表示方法、および必要なすべての変換を個別に実行できることをよく知っています。 したがって、このようなコンポーザーを使用すると、キューブ上のウィンドウを回転できるだけでなく、キューブ上で直接ウィンドウを操作することもできます。



結論



Xorgの実装はモノリシックであるという声をよく耳にします。 もちろん、そのような陳述の真実の共有は存在しますが、時間の経過とともに、そのような陳述の真実はますます少なくなります。 これはXorg開発者の能力不足の結果ではありません。 Xorgだけでなく、長年にわたって蓄積されたすべての荷物も一緒に生きる必要があります-これは、たとえば、ハードウェアアクセラレーションのXRenderプロトコル、または以前に何かを行った場合は、XPolyFillのようなアンチエイリアスなしでコマンドを描画します。 時間の経過とともにXがステージを去り、ウェイランドに取って代わられることは明らかです。 しかし、これはデスクトップ環境とXorgの開発者からの理解と多大な助けを借りて行われたことを明確にしたいと思います。 彼らは頑固ではなく、無能ではありません。 それを気にせず、そのアーキテクチャを壊して再構築せずに30年前のプロトコルを維持することは、彼らにとって素晴らしい仕事です。



また、この記事の内容に取り組んだすべての人に感謝します。 オーウェン・テイラー、レイ・ストラウド、エダム・ジャクソンに、辛抱強く質問してくれてありがとう。 この記事の技術校正に協力してくれたDave AirlieとEdam Jacksonに感謝します。



Linuxグラフィックスタックの主要な部分を簡単に説明したにもかかわらず、興味があればいつでも掘り下げることができます。 たとえば、カイロプリミティブの四角形への分割の根底にある幾何学的アルゴリズムと理論について読むことができます。 または、これらの四角形の高速ソフトウェアラスタライズのアルゴリズムを見て、その高速の理由を理解する必要があります。 DRI2を掘り下げてみてください。 ハードウェア自体とその描画方法に興味があり、データシートを理解して自分でプログラムしようとしたらどうでしょうか？ いずれにせよ、これらの分野のいずれかを掘り下げることに決めた場合、上記のコミュニティとプロジェクトはあなたの意見を喜んで受け入れます。



私はこれについてもっと書くつもりです。 Linuxは多種多様なテクノロジースタックを使用しており、GNOMEコミュニティには、それらを多少なりとも高レベルで説明する正真正銘のレビュードキュメントがまだありません。



RoossoのハブユーザーであるtrollsidとXitsaの校正に感謝します。


More articles:


All Articles