Linuxグラフィックススタックはどのように構成されていますか？

誰でも説明できますか（できれば絵で）、Linuxグラフィックススタックはどのように編成されていますか？X / GTK / GNOME / KDEなどについてよく耳にしますが、実際に何をするのか、また相互のやり取りやスタックの他の部分とのやり取りについてはまったくわかりません。UnityとWaylandはどのように適合しますか？

X Window Systemは、クライアントサーバーアーキテクチャを使用します。Xサーバーはディスプレイ（モニター+入力デバイス）があるマシンで実行されますが、Xクライアントは他のマシンで実行でき、Xプロトコルを使用してXサーバーに接続できます（直接ではなく、ライブラリを使用するなど、 Xlib、またはより近代的な非ブロッキングイベント駆動型XCB）。Xプロトコルは拡張可能に設計されており、多くの拡張機能があります（を参照xdpyinfo(1)）。

Xサーバーは、ウィンドウの作成と破棄、描画操作の実行（現在、ほとんどの描画はクライアントで行われ、画像としてサーバーに送信されます）、イベントをウィンドウに送信するなど、低レベルの操作のみを行います。 Xサーバーは、実行X :1 &（別のXサーバーがまだ使用していない任意の番号を使用）またはXephyr :1 &（Xephyrが現在のXサーバーに組み込まれたXサーバーを実行）してから、実行xterm -display :1 &して新しいXサーバーに切り替えます（X認証のセットアップが必要な場合があります）を使用xauth(1)）。

ご覧のとおり、Xサーバーはほとんど動作せず、タイトルバーを描画せず、ウィンドウの最小化/アイコン化を行わず、ウィンドウの配置を管理しません...もちろん、コマンドを手動で実行してウィンドウの配置を制御できますに似てxterm -geometry -0-0いますが、通常は上記のことを行う特別なXクライアントがあります。このクライアントはウィンドウマネージャーと呼ばれます。一度にアクティブにできるウィンドウマネージャは1つだけです。あなたはまだ、前のコマンドの裸のXサーバを開いている場合、あなたはそれにウィンドウマネージャを実行しようとすることができ、のようなtwm、metacity、kwin、compiz、larswm、pawm、...

前述したように、Xは低レベルの操作のみを行い、プッシュボタン、メニュー、ツールバーなどの高レベルの概念を提供しません...これらは、ツールキットと呼ばれるライブラリによって提供されます。例：Xaw、GTK、Qt、FLTK、...

デスクトップ環境は、統一されたユーザーエクスペリエンスを提供するように設計されたプログラムのコレクションです。そのため、デスクトップ環境は通常、パネル、アプリケーションランチャー、システムトレイ、コントロールパネル、構成インフラストラクチャ（設定を保存する場所）を提供します。よく知られているデスクトップ環境には、KDE（Qtツールキットを使用して構築）、Gnome（GTKを使用）、Enlightenment（独自のツールキットライブラリを使用）、...

一部の最新のデスクトップエフェクトは、3Dハードウェアを使用するのが最適です。そのため、新しいコンポーネントである複合マネージャーが表示されます。X拡張機能であるXComposite拡張機能は、ウィンドウの内容を複合マネージャーに送信します。コンポジットマネージャは、これらのコンテンツをテクスチャに変換し、OpenGLを介して3Dハードウェアを使用して多くの方法でそれらを構成します（アルファブレンディング、3D投影など）。

少し前まで、Xサーバーはハードウェアデバイスと直接通信していました。このデバイス処理の大部分はOSカーネルに移行しています：DRI（X およびダイレクトレンダリングクライアントによる3Dハードウェアへのアクセスの許可）、evdev（入力デバイス処理用の統合インターフェイス）、KMS（カーネルへのグラフィックモード設定の移動） 、GEM / TTM（テクスチャメモリ管理）。

そのため、デバイス処理の複雑さのほとんどがXの外部になったため、単純化されたウィンドウシステムで実験することが容易になりました。Waylandは、複合マネージャーの概念に基づいたウィンドウシステムです。つまり、ウィンドウシステムは複合マネージャーです。Waylandは、Xから移動したデバイス処理を利用し、OpenGLを使用してレンダリングします。

Unityに関しては、ネットブックに適したユーザーインターフェイスを持つように設計されたデスクトップ環境です。

従来のスタックは、3つの主要コンポーネントに基づいて構築されています。

• 表示を処理するXサーバー
• ウィンドウをフレームに入れたり、ウィンドウの最小化などを処理するウィンドウマネージャ。これは、Unixのポリシーとメカニズムの分離の一部です。
• stackexchange Webサイトを表示するのに役立つタスクを実行するクライアント。Xプロトコルを直接使用する（自殺）か、xlibまたはxcb（わずかに簡単）を使用するか、GTK +やQTなどのツールキットを使用します。

Xアーキテクチャはネットワーク化されているため、クライアントはサーバーとホストを別々にホストできます。

ここまでは順調ですね。しかし、それは昔からのイメージでした。今日では、グラフィックスを処理するのはCPUではなく、GPUです。モデルにそれを組み込むためのさまざまな試みがありました-そして、カーネルがより大きく拡張する場所に来たとき、場所。

まず、グラフィックカードの使用に関していくつかの前提があります。たとえば、画面上のレンダリングのみが想定されています。私は今ウィキペディアでこの情報を見つけることができませんが、DRI 1は同時に1つのアプリケーションのみがOpenGLを使用すると想定しました（すぐに引用することはできませんが、DRIを待つことに注意してWONTFIXに近いバグを掘り下げることができます2）。

間接レンダリングのためにいくつかの一時的な解決策が提案されています（複合WMに必要）：

• XGL-カードと直接通信するアプリケーションをサポートする初期の提案
• AIGLX-OpenGLプロトコルのネットワークプロパティを使用する提案
• NVidiaの独自のソリューション

新しいアーキテクチャ（DRI 2）の作業が開始されました。それに含まれるもの：

• メモリ処理のカーネル内サポート（GEM / TTM）
• カーネルモード設定（KMS）により、カーネル内で解像度を変更できるため、Xとコンソールと他のいくつかの機能を切り替える際の遅延を回避できます（Xが実行されていてもパニックでメッセージを表示するなど-IIRCの実装予定）。

何らかの形でカーネルに移行するために直交して、Galliumドライバーの作業が開始されました。Mesaライブラリは、CPUでのOpenGLの実装として開始され、GPUアクセラレーションを使用して開始されました。OpenGLに常に厳しくされています。OpenGL 3.0では、モデルが大幅に変更され、ライブラリの書き換えは避けられませんでした。ただし、共通のコードを抽出する複数のレイヤーにコードを分割し、その上にさまざまな3D APIを実装できるようにする低レベルAPIを提供する機会を利用しています-たとえば、OpenGLを経由するのではなく、Galliumと直接通信するDirectX APIレイヤー（直接的な1-1呼び出しがない場合があります）。

ウェイランドは、上記を少し複雑で「歴史的」すぎると考えるプロジェクトです。1984年の設計（高度に修正され、適応されていますが）は、21 cの始まりに対応していません。支持者によると。

OpenGLの完全なサポート（および一部のネットワークサポート）などの重要な機能がまだ不足していますが、柔軟性とパフォーマンスの向上が期待されます。

デスクトップ環境とウィンドウマネージャーについてもう少し。ウィンドウマネージャは、ウィンドウの動作を担当するアプリケーションです。たとえば、ワークスペースの管理、タイトルバーの描画（windoタイトルとminimise / maximise / closeボタンを備えた画面上のもの）などを担当します。

最初は最小限のWMのみが使用されましたが、その後、ユーザーはデスクトップ環境、つまりメニューの開始、デスクトップの背景などを含むより多くの機能を備えたバージョンを求め始めました。

しばらくして、OpenGLと間接レンダリングを使用して作業を行う複合WMが導入されました。これらはグラフィカルな効果を提供するだけでなく、一部のアクセシビリティ機能（拡大鏡など）の実装を容易にします。

まず、Linuxグラフィックススタックはありません。Linuxにはグラフィカルな表示機能はありません。

ただし、Linuxアプリケーションはグラフィカルディスプレイを使用でき、そのためのさまざまなシステムがあります。最も一般的なものはすべて、Xウィンドウの上に構築されています。

Xはネットワークプロトコルです。Xプロトコルスタックの中央では、ネットワークを標準コンポーネントとして使用できるためです。特定のユースケースを見てみましょう。ベルリンの物理学者は、スイスのCERNで核粒子衝突型加速器の1つで実験を行いたいと考えています。彼はリモートでログインし、CERNのスーパーコンピューターアレイの1つでデータ分析プログラムを実行し、画面に結果をグラフ化します。

ベルリンの物理学者は、リモートアプリケーションにグラフィカルな表示機能を提供するXサーバーソフトウェアを実行するX端末デバイスを持っています。Xサーバーソフトウェアには、特定のハードウェアの特定のデバイスドライバーと通信するフレームバッファーがあります。また、XサーバーソフトウェアはXプロトコルを使用します。したがって、レイヤーは、グラフィカルデバイス->デバイスドライバー->フレームバッファー-> Xサーバー-> Xプロトコルになります。

次に、スイスでは、アプリケーションはXプロトコルを使用してディスプレイに接続し、「四角形の描画」や「アルファブレンド」などのグラフィック表示コマンドを送信します。アプリケーションはおそらく高レベルのグラフィカルライブラリを使用しており、そのライブラリは低レベルのライブラリに基づいている可能性があります。たとえば、アプリケーションは、コアグラフィカルな描画コマンドにCairoと呼ばれるライブラリを使用するGTKの上に構築されたWxWidgetツールキットを使用してPythonで記述できます。カイロの上にもOPENGLがあります。レイヤーは次のようになります：WxWidgets-> GTK-> Cairo-> X Toolkit-> X protocol。明らかにそれは物事を接続する中間のプロトコルであり、Linuxはデータの完全な内部トランスポートであるUNIXソケットもサポートしているため、必要に応じてこれら2種類の物事を1台のマシンで実行できます。

Xは、プロトコルと、グラフィックディスプレイ、ポインティングデバイス、キーボードを実行するXサーバーなど、アーキテクチャの基本的な要素を指します。

GTKとQTは、ウィンドウ、ダイアログ、ボタンなどをサポートする2つの汎用GUIライブラリです。

GNOMEとKDEは、グラフィカルデスクトップ上のウィンドウを管理し、便利なアプレットとボタンバーのようなものを提供する2つのデスクトップ環境です。また、アプリが別のリモートコンピューターで実行されている場合でも、複数のアプリケーションがXサーバー（X端末デバイス）を介して通信できるようにします。たとえば、コピーと貼り付けは、アプリケーション間通信の一形態です。GNOMEはGTKの上に構築されています。KDEはQTの上に構築されています。また、KDEデスクトップ上でGNOMEアプリを実行することも、GNOMEデスクトップ上でKDEアプリを実行することも可能です。これらはすべて同じ基盤のXプロトコルで動作するためです。

これが組織です。この写真から、テキストのいくつかのページからより多くを学ぶことができます。

デスクトップおよび一部のサーバー上のLinuxは、まだすべてXおよびフレームバッファーグラフィックです。Xウィンドウの下-GTK +とQtが付属し、YES BOTHはXシステムを使用します。ここでも多くのデスクトップ環境があります-Gnome、KDEはXディスプレイとそのシェルなどを使用します。

ところで、linux conf（http://blip.tv/file/4693305/）から最近のビデオがありました。IntelのKeith PackardがXとGLについて話しました*興味深いものでした。