Linuxグラフィックススタックがどのように構成されているか（図とともに）説明できる人はいますか？私はX / GTK / GNOME / KDEなどについて聞いていますが、彼らが実際に何をしているのか、そして彼らがお互いやスタックの残りの部分とどのようにやり取りするのかわかりません。 UnityとWaylandはどのように統合されますか？
答え1
X Windowsシステムはクライアント - サーバーアーキテクチャを使用します。 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を実行してみることができます。metacitykwincompizlarswmpawm
私たちが言ったように、ツールキット、例：Xaw、GTK、Qt、FLTK、...
デスクトップ環境は、統合されたユーザーエクスペリエンスを提供するように設計されたプログラムの集まりです。したがって、デスクトップ環境は通常、パネル、アプリケーションランチャー、システムトレイ、コントロールパネル、および構成インフラストラクチャ（設定が保存される場所）を提供します。有名なデスクトップ環境には、KDE（Qtツールキットを使用して構築）、Gnome（GTKを使用）、Enlightenment（独自のツールキットライブラリを使用）などがあります。
いくつかの最新のデスクトップエフェクトは、3Dハードウェアを使用して最もよく実装されています。だから新しいコンポーネントが登場しました。複合マネージャ。 X拡張（XComposite拡張）は、ウィンドウの内容を複合マネージャに送信します。合成マネージャはそれをテクスチャに変換し、OpenGLを介して3Dハードウェアを使用してさまざまな方法（アルファブレンディング、3D投影など）で合成します。
しばらく前に、Xサーバーはハードウェアデバイスと直接通信していました。デバイス処理の大部分がオペレーティングシステムカーネルであるDRI（Xが3Dハードウェアにアクセスできるようにする）に移動されました。そして直接レンダリングクライアント）、evdev（入力デバイス処理用の統合インターフェイス）、KMS（グラフィックモード設定をカーネルに移動）、GEM / TTM（テクスチャメモリ管理）。
したがって、デバイス処理の複雑さがXの外側にあるため、単純化されたウィンドウシステムを実験するのが簡単になりました。ウェイランド複合管理者の概念に基づくウィンドウシステム、つまりウィンドウシステムは複合管理者です。 WaylandはXで移動したデバイス処理を活用し、レンダリングにOpenGLを使用します。
Unityの場合は、ネットブックに優しいユーザーインターフェイスを持つように設計されたデスクトップ環境です。
答え2
既存のスタックは3つの主要コンポーネントで構築されています。
- ディスプレイを処理するXサーバー
- ウィンドウマネージャはウィンドウをフレームに配置し、ウィンドウの最小化などを処理します。これはUnixのメカニズムとポリシーの分離の一部です。
- stackexchange Web サイトの表示などの便利なタスクを実行するクライアントです。 Xプロトコルを直接使用したり（自殺）、xlibまたはxcb（やや簡単）を使用したり、GTK +やQTなどのツールキットを使用したりできます。
Xアーキテクチャはネットワーク接続されているため、クライアントは別々のホストにあり、ホストはサーバー上にあります。
今まではそんなに良くなった。しかし、それは非常に長い前のイメージでした。今グラフィックを処理することはもはやCPUではなくGPUです。これをモデルに統合し、コアがより機能する場所に配置しようとするさまざまな試みがありました。
第一に、グラフィックカードの使用に関していくつかの仮定がなされる。たとえば、画面レンダリングを考えてみましょう。 Wikipediaはこの情報を見つけることができませんが、DRI 1では同時に1つのアプリケーションだけがOpenGLを使用していると仮定しています（ただし引用することはできませんが、WONTFIXの近くでそのバグを掘り下げることができます。）DRI 2に注意してください。
間接レンダリングのためのいくつかの一時的なソリューションが提案されています（複合WMに必要です）。
- XGL - カードと直接通信するアプリケーションをサポートするための最初の提案
- AIGLX - OpenGLプロトコルのネットワーク属性を使用するための承認された提案
- NVidia独自のソリューション
新しいアーキテクチャ（DRI 2）の作業が開始されました。これには以下が含まれます。
- メモリ処理のためのカーネルサポート（GEM/TTM）
- カーネルモード設定（KMS）を使用すると、カーネルの解像度を変更できるため、切り替え時の遅延を防ぎます。
それにもかかわらず、Galliumドライバをカーネルに直交的に転送する作業が始まりました。 MesaライブラリはもともとCPUにOpenGLを実装した後、GPUアクセラレーションを使い始めました。これは常にOpenGLと密接に関連しています。 OpenGL 3.0では、モデルが大幅に変更され、ライブラリの書き換えは避けられません。しかし、彼らはコードを複数のレイヤーに分けて共通のコードを抽出し、さまざまな3D APIを上位に実装するための低レベルAPIを提供する機会を利用しました。たとえば、Wine は Gallium と直接会話する DirectX を提供できました。 OpenGL APIレイヤを介さずに（直接1-1呼び出しがない可能性があります）
Waylandは、上記の内容がやや複雑で「歴史的」と感じるプロジェクトです。 1984年のデザインは（高度に修正され適用されたにもかかわらず）、21世紀初頭とは無関係です。支持者によると。
完全なOpenGLサポート（一部のネットワークサポートにとって重要）など、いくつかの重要な機能はまだ欠けていますが、より柔軟性とパフォーマンスを向上させる必要があります。
デスクトップ環境とウィンドウマネージャに関する追加情報。ウィンドウマネージャは、ウィンドウの動作を担当するアプリケーションです。たとえば、ワークスペースの管理、タイトルバーの描画（ウィンドウのタイトルとウィンドウの上部に最小化/最大化/閉じるボタンがあるもの）を描くことを担当します。画面）など
最初は最小限のWMしか使用されていませんでしたが、後でユーザーはメニューの実行、デスクトップの背景など、より多くの機能を備えたバージョンのデスクトップ環境を望み始めました。ただし、デスクトップ環境のほとんどは統合されていますが、ウィンドウマネージャではありません。
しばらくすると、OpenGLと間接レンダリングを使用してタスクを完了する複合WMが導入されました。グラフィック効果を提供するだけでなく、特定のアクセシビリティ機能（拡大鏡など）も簡単に実装できます。
答え3
まず、Linuxには実際にグラフィックスタックがありません。 Linuxにはグラフィック表示機能はありません。
ただし、Linuxアプリケーションにはグラフィックディスプレイを使用でき、それを実行できるさまざまなシステムがあります。最も一般的なものはXウィンドウに構築されました。
X プロトコル スタックの途中に標準コンポーネントとしてネットワーキングがあるため、X はネットワークプロトコルです。具体的なユースケースを見てみましょう。ベルリンのある物理学者は、スイスCERNの核粒子衝突装置で実験を実行しようとしています。彼はリモートでログインし、CERNのスーパーコンピュータアレイの1つでデータ分析プログラムを実行し、結果を画面に表示しました。
ベルリンの物理学者は、リモートアプリケーションにグラフィック表示機能を提供するためにいくつかのXサーバーソフトウェアを実行するX端末デバイスを持っています。 X-serverソフトウェアには、特定のハードウェア用の特定のデバイスドライバと通信するフレームバッファがあります。 XサーバーソフトウェアはXプロトコルを使用します。したがって、レイヤーは、グラフィックデバイス - >デバイスドライバ - >フレームバッファ - > Xサーバー - > Xプロトコルです。
スイスでは、アプリケーションはXプロトコルを使用してモニターに接続し、「長方形の描画」や「アルファブレンド」などのグラフィック表示コマンドを送信します。アプリケーションは高レベルのグラフィックライブラリを使用することができ、これは再び低レベルのライブラリに基づくことができる。たとえば、コアグラフィック描画コマンドを実行するために、Cairoというライブラリを使用するGTKの上に構築されたWxWidgetツールキットを使用してPythonでアプリケーションを作成できます。カイロにもOPENGLがあるかもしれません。レイヤーは次のとおりです。 WxWidgets->GTK->Cairo->X Toolkit->X Protocol。明らかに、物事を接続するのは中間のプロトコルであり、LinuxもUNIXソケット（完全に内部データ転送）をサポートしているので、必要に応じて両方のタイプを同じシステムで実行できます。
Xは、グラフィックディスプレイ、ポインティングデバイス、キーボードを実行するXサーバーなどの基本的なプロトコルとアーキテクチャを表します。
GTKとQTは、ウィンドウ、ダイアログ、ボタンなどをサポートする2つの汎用GUIライブラリです。
GNOMEとKDEは、グラフィックデスクトップでウィンドウを管理し、便利なアプレットやボタンバーなどの機能を提供する2つのデスクトップ環境です。また、アプリケーションが別のリモートコンピュータで実行されていても、複数のアプリケーションがXサーバー（Xターミナルデバイス）を介して通信できます。たとえば、コピー＆ペーストは、アプリケーション間通信の一形態です。 GNOMEはGTKに基づいて構築されました。 KDEはQTに基づいて作成されました。また、KDE デスクトップで GNOME アプリケーションを実行したり、GNOME デスクトップで KDE アプリケーションを実行したりできます。どちらも同じネイティブXプロトコルを使用するためです。
答え4
デスクトップと一部のサーバーのLinuxはまだXとフレームバッファのグラフィックです。 X Windowでは、GTK+とQtが付属しています。はい、どちらもXシステムを使用し、同様にXディスプレイや対応するシェルなどを使用するGnome、KDEなど、多くのデスクトップ環境があります。
ところで、Linux conf（http://blip.tv/file/4693305/）に最近のビデオがあります。 IntelのKeith PackardがXとGL*について興味深い話をしました。