Linux のディスプレイはどのように機能しますか?

Linux ディスプレイ

Linux のディスプレイシステムは、複数のテクノロジ、プロトコル、拡張機能、アプリケーション、サーバー (デーモン)、ドライバー、および概念を使用して、ウィンドウシステムを実現します。たとえば、Xorg、Wayland、X11、OpenGL、RandR、XrandR、画面解像度、DPI、ディスプレイサーバーです。など。これを完全に理解するのは大変かもしれませんが、それぞれの面は特定の目的のために意図されており、同時にすべて一緒に使用されるわけではありません。

X プロトコル

X ウィンドウシステム、X11 (X バージョン 11) はビットマップディスプレイ用のウィンドウシステムで、Unix ライクなオペレーティングシステムで一般的です。X は、GUI 環境の基本的なフレームワークを提供します。ディスプレイデバイス上でウィンドウを描画および移動し、マウスとキーボードを操作します。 X はユーザーインターフェイスを義務付けていません。これは個々のプログラムによって処理されます。そのため、X ベースの環境のビジュアルスタイルは大きく異なります。異なるプログラムは、根本的に異なるインターフェースを提示する場合があります。 X は、1984 年にマサチューセッツ工科大学 (MIT) の Project Athena で生まれました。X プロトコルは、1987 年 9 月からバージョン 11 (したがって「X11」) になっています。X.Org Foundation は X プロジェクトを主導し、現在のリファレンス実装を使用しています。、X.Org サーバー。MIT ライセンスおよび同様の寛容なライセンスの下で、無料のオープンソースソフトウェアとして利用できます。

X 実装

ほとんどの Linux ディストリビューションは X.Org サーバー を使用しますこれは、X.Org Foundation によって管理されている X Window System (X11) 用のディスプレイサーバーの無料のオープンソース実装です。 Xorg/X だけでは、Xorg のスケーリングやレンダリングなど、提供されている複数の機能をサポートしていません。 拡張機能を使用 XFixes、RandR など (RandR は xrandr によって管理されます) たとえば、パン、解像度、またはスケーリングをセットアップすることができます)、GLX (OpenGL 拡張機能)、ウィンドウ階層のサブツリー全体をオフスクリーンバッファーにレンダリングする Render または Composite が可能で、アプリケーションはそのコンテンツを取得できます。オフスクリーンバッファは自動的に親ウィンドウにマージできます または compositing manager と呼ばれる外部プログラムによってマージされます一部のウィンドウマネージャのように独自に合成を行う行う;例えば。 Compiz、Enlightenment、KWin、Marco、Metacity、Muffin、Mutter、Xfwm。他の「非合成」の場合 " ウィンドウマネージャー。Picom、Xcompmgr、Unagi などのスタンドアロンの複合マネージャーを使用できます。Xorg がサポートする拡張機能 次のようにリストできます:xdpyinfo -display :0 -queryExtensions | awk '/^number of extensions:/,/^default screen number/' .

一方、ウェイランド Xorg/X11 のより単純な代替品として意図されており、開発と保守が容易ですが、2020 年の時点で、Gnome 以外の Wayland に対するデスクトップのサポートはまだ完全には準備されていません (例:KDE Kwin および Wayland のサポート)。ディストリビューション側では、Fedora はデフォルトで Wayland を使用します。 Wayland と Xorg は同時に動作する可能性があることに注意してください。これは、使用する構成によって異なります。 XWayland は、Wayland プロトコルで実行される X サーバーを実装する X.Org サーバーコードベースに対する一連のパッチです。パッチは、Wayland への移行中に X11 アプリケーションとの互換性のために Wayland 開発者によって開発および維持され、2014 年に X.Org サーバーのバージョン 1.16 でメインライン化されました。ユーザーが Weston 内から X アプリケーションを実行すると、 XWayland がリクエストを処理します。

スコープ全体

ディスプレイサーバー またはウィンドウサーバーは、クライアントの入出力をオペレーティングシステムの残りの部分、ハードウェア、および相互に調整することを主なタスクとするプログラム (Xorg や Wayland など) です。ディスプレイサーバーは、ディスプレイサーバープロトコル (通信プロトコル) を介してクライアントと通信します。通信プロトコルは、ネットワーク透過型または単にネットワーク対応型にすることができます。たとえば、X11 と Wayland はディスプレイサーバー通信プロトコルです。

図に示されているように、ウィンドウマネージャー デスクトップ環境のもう 1 つの重要な要素であり、グラフィカルユーザーインターフェイスのウィンドウシステム内でウィンドウの配置と外観を制御するシステムソフトウェアです。ほとんどのウィンドウマネージャーは、デスクトップ環境の提供を支援するように設計されています。それらは、グラフィックスハードウェア、ポインティングデバイス、およびキーボードに必要な機能サポートを提供する基礎となるグラフィカルシステムと連携して動作し、多くの場合、ウィジェットツールキットを使用して記述および作成されます。 KDE はウィンドウマネージャーとして KWin を使用します (2020 年現在、Wayland のサポートは限定的です)。同様に、Gnome 2 は Metacity を使用し、Gnome 3 はウィンドウマネージャーとして Mutter を使用します。

Windows マネージャーのもう 1 つの重要な側面は、コンポジター です。または コンポジットウィンドウマネージャ 、各ウィンドウのオフスクリーンバッファーをアプリケーションに提供するウィンドウマネージャーです。ウィンドウマネージャーは、ウィンドウバッファーを画面を表すイメージに合成し、結果をディスプレイメモリに書き込みます。合成ウィンドウマネージャは、バッファリングされたウィンドウに対して追加の処理を実行し、ブレンド、フェード、スケーリング、回転、複製、曲げとゆがみ、シャッフル、ぼかし、アプリケーションのリダイレクト、複数のディスプレイの 1 つへのウィンドウの変換などの 2D および 3D のアニメーション効果を適用します。および仮想デスクトップ。コンピュータグラフィックステクノロジにより、ドロップシャドウ、ライブプレビュー、複雑なアニメーションなどの視覚効果をリアルタイムでレンダリングできます。画面はダブルバッファリングされているため、更新中にちらつきません。最も一般的に使用される合成ウィンドウマネージャーには、Linux、BSD、Hurd、OpenSolaris-Compiz、KWin、Xfwm、Enlightenment、Mutter などがあります。 KDE の KWin のコンポジター など、それぞれ独自の実装があります。アニメーション速度、テアリング防止 (vsync)、ウィンドウサムネイル、スケーリング方法などの多くの機能/設定があり、OpenGLv2/OpenGLv3 または XRender を使用できます レンダリングバックエンドとして Xorg と一緒に。 (XRender/Render を XRandR/RandR と混同しないようにしてください)。

OpenGL (オープングラフィックライブラリ) 2D および 3D ベクターグラフィックスをレンダリングするためのクロス言語、クロスプラットフォームのアプリケーションプログラミングインターフェイス (API) です。この API は通常、グラフィックスプロセッシングユニット (GPU) とやり取りして、ハードウェアアクセラレーションによるレンダリングを実現するために使用されます。 OpenGL は、Xorg、Wayland、または OpenGL を実装する任意のアプリケーションで使用できるレンダリングライブラリです。 OpenGL のインストールは glxinfo | grep OpenGL で確認できます .

ディスプレイの解像度 または、コンピューターモニターまたはディスプレイデバイスの表示モードは、表示できる各次元の個別のピクセル数です。通常、幅 × 高さとして引用され、単位はピクセルです。たとえば、1024 × 768 は、幅が 1024 ピクセルで高さが 768 ピクセルであることを意味します。 xrandr 新しいディスプレイ解像度を追加またはレンダリング/シミュレートするために使用できます。

DPI ドット/インチの略で、空間印刷/表示の尺度です、特に、1 インチ (2.54 cm) のスパン内で一列に配置できる個々のドットの数です。コンピュータの画面にはドットはありませんが、ピクセルはあります。密接に関連する概念は、1 インチあたりのピクセル数または PPI であるため、DPI は PPI の概念で実装されます。デフォルトの 96 DPI 測定値は、垂直方向と水平方向に 96x96 を意味します。さらに、X DPI (ドット/インチ) 設定はテキストのスケーリングのみを目的としていますか? QA は非常に有益です。

メモ

一部の KDE の GUI ツール: systemsettings5> ディスプレイ、kcmshell5 xserver と kinfocenter .

参考文献

リンクとソース: 1、2、3、4、5、6、7、8、9、10、11、12。

質問は非常に広範であり、この回答がカバーするよりも多くのことを主題について書くことができます. Linux グラフィックスの進化に関する歴史的な視点を提供しようとしました。 Linux のグラフィックス、ウィンドウシステム、およびグラフィカルユーザーインターフェイス (GUI) は、1990 年代初頭に X Window System (X11) が Linux に移植されて以来、多くの変更を経てきました。

X ウィンドウシステム

X Window System は、1980 年代に MIT で開発されました。 X11 という名前は X プロトコルのプロトコルバージョン 11 を指しますが、X10 は MIT 以外でも使用され、1987 年にバージョン 11 に置き換えられました。

X Window System は、1980 年代の最先端のグラフィックシステムで動作するように設計されました。典型的なワークステーションには、フレームバッファの内容をディスプレイモニタに表示する単純な CRT コントローラに接続された単一のフレームバッファがありました。 PC とワークステーションの時代以前のコンピューティングは、コンピュータマシンルームにある中央コンピュータに接続されたシリアルライン (「ダム」) 端末を介して行われていました。この歴史的背景が X11 の設計に影響を与えました。グラフィカルアプリケーションは、リモートコンピューター上で実行でき、ユーザーはグラフィック機能を備えた端末を使用してプログラムと対話することができました。「端末」は、ワークステーションまたは専用の X 端末である可能性があります。

X11 は、サーバー/クライアントシステムとして設計されました。 X サーバーは、グラフィックスハードウェアと直接通信する唯一の部分でした。 X クライアントは、ローカル Unix ドメインソケットまたは TCP/IP 接続のいずれかを使用して、X プロトコルを使用してサーバーと通信するアプリケーションプログラムです。 X プロトコルは、クライアントがサーバーに要求を送信し、サーバーからイベントメッセージを受信するために使用されます。

リクエストには次のメッセージが含まれます:

ウィンドウの作成
ウィンドウのマッピング/マッピング解除:ウィンドウを表示/非表示にする
ウィンドウへの描画:ピクセル、線、円弧、楕円、ピックスマップなどを描画します。
指定されたフォント、サイズ、スタイルを使用してテキストを表示する
ウィンドウの移動とサイズ変更、ウィンドウの重なり順の変更など

クライアントはメッセージを受け取ります (完全なリストではありません):

リクエストへの返信
キープレスおよびマウスクリックイベント
イベントを公開する (ウィンドウの領域を再描画する必要がある)
獲得/喪失イベントに焦点を当てる

ユーザーが画面上のウィンドウを操作できるようにするために、たとえば、ウィンドウの移動、サイズ変更、閉じる、上げ下げなど、ウィンドウマネージャーと呼ばれる特定のアプリケーションが提供されます。ウィンドウマネージャーは、枠線、タイトルバー、グローバルメニューなどのウィンドウ装飾も表示できます。

X11 サーバーは、ウィンドウ、フォント、ピックスマップ、カラーマップ、グラフィックコンテキスト (前景色/背景色、線幅など) など、あらゆる種類のリソースを処理する (または、少なくとも伝統的に処理する) ため、非常に「高レベル」であると言えます。）。これに加えて、サーバーはウィンドウの親子関係やウィンドウの重なり順などを処理します。

X プロトコルは、拡張できるように設計されています。 X サーバーに新しいトリックを実行するように教えることができ、新しいオペコードがプロトコルに追加されて、サーバーにそれらのトリックを実行させます。たとえば、XRender 拡張機能では、透明度 (「アルファブレンディング」) を処理する方法が導入されています。この拡張機能は、主にアンチエイリアスフォントをサポートするために導入されましたが、ウィンドウのドロップシャドウなどのデスクトップ効果にも使用されています。 RandR ("Resize and Rotate") 拡張機能により、ルートウィンドウのサイズ変更、回転、画面への反映が可能になります。これにより、上下逆さまのプロジェクターを使用して画面を投影したり、傾斜したモニターを使用したりできます。

GLX 拡張機能 (OpenGL Extension to the X Window System) により、X サーバーが提供するウィンドウで OpenGL を使用できるようになります。 OpenGL への呼び出しは、X プロトコルリクエストに組み込まれています。

X11 の進化のある時点で、フォント処理はクライアントによって処理されるようになりました。この変更の背後にある理由は、X ウィンドウシステムの新しい進化で説明されています。

ダイレクトレンダリング

2000 年代初頭、ディスプレイハードウェアは、1980 年代に X の開発が始まったときに存在していた単純な白黒のビットマップディスプレイから大きく進歩しました。ローカルソケットを使用している場合でも、プロセス間通信 (IPC) モデルの X11 相対オーバーヘッドが大きくなりすぎていました。これに対する解決策は、X サーバーがハードウェアと直接通信する唯一の部分であるという原則を放棄し、クライアントがグラフィックスカードと直接通信するようにすることでした。 Direct Rendering Infrastructure (DRI) が誕生しました。

DRI を使用すると、X クライアントアプリは X サーバーをバイパスし、グラフィックアダプターで直接レンダリングできます。従来の X サーバーに加えて複数のダイレクトレンダリングアプリケーションを同時にアクティブにできるため、ハードウェアへのアクセスを調停するために、ダイレクトレンダリングマネージャーと呼ばれるカーネルコンポーネントが導入されました。 DRI アーキテクチャには、元の DRI (廃止)、DRI2、および DRI3 の 3 つのバージョンがあります。

ウィンドウマネージャーの合成

Linux グラフィックスシーンに参入する次のイノベーションは、合成ウィンドウマネージャーでした。従来、各 X クライアントアプリケーションは、必要に応じてウィンドウ (ウィンドウの一部または全体) を再描画する役割を担っていました。 X サーバーは、ウィンドウが画面にマップされた結果として再描画が必要になった場合、またはウィンドウが他のウィンドウによって隠されなくなった場合に、アプリケーションに Expose イベントを送信しました。重なっているウィンドウが削除されると、その下のウィンドウが表示されます。この領域の再描画に失敗すると、古いコンテンツが表示されたままになります。 https://en.wikipedia.org/wiki/Visual_artifact

合成ウィンドウマネージャーはこれを変更します。アプリケーションは、独自のオフスクリーンバッファーにレンダリングします。それぞれのバッファーは、バッファーを所有するアプリケーションが排他的にアクセスできる個別の画面のようなものです。これらのバッファーを実際の画面上のウィンドウに表示し、他のウィンドウによって隠されているウィンドウや部分的に画面外にあるウィンドウをクリッピングするのは、合成ウィンドウマネージャーのタスクです。ウィンドウマネージャーは、ウィンドウの「構成」を表示します。

通常、合成マネージャーは、ウィンドウのスケーリング、ワープ、フェード、回転、ぼかしなどのアニメーション効果を表示することもできます。たとえば、ウィンドウを移動すると揺れたり、仮想デスクトップが回転する立方体の側面に表示されたりすることがあります。

カーネルモード設定

X サーバーは従来、解像度やリフレッシュレートなどのグラフィックスアダプターのモードの設定も処理していました。モード設定は、Kernel Mode Setting (KMS) と呼ばれる Linux カーネルコンポーネントに移動されました。これにより、Linux の仮想コンソールの切り替えに関する多くの問題が解決されました。

エヴデフ

X サーバーは入力デバイスの情報も持っており、たとえば、マウスの種類を X 構成で指定する必要がありました。一般的な入力イベントインターフェイスを提供する Linux カーネルの evdev サブシステムの導入により、X サーバーはこのタスクから解放されました。

ウェイランド

これらすべての開発により、X サーバーによって実行される多くのタスクが X サーバーの外に移動しました。ダイレクトレンダリングを使用すると、クライアントは X プロトコルを使用しなくなります。 KMS のおかげで、X サーバーはグラフィックスアダプタの低レベルプログラミングをいじる必要がありません。 evdev を使用すると、X サーバーでの入力デバイスの処理が簡素化されました。合成ウィンドウマネージャを使用してウィンドウを再配置およびワープする場合、X サーバーは画面上で何が起こっているのかわかりません。「ウィンドウマネージャーは新しい X サーバーです」.

Wayland は、X サーバープロセスが行うべきことがほとんどないという認識の結果として生まれました。また、仲介者 (X サーバー) を取り除くことによって、はるかに単純なデスクトップグラフィックシステムを実現できます。下位互換性は、Wayland サーフェスを使用してトップレベルの X ウィンドウを表示する修正された Xorg サーバーである Xwayland によって提供されます。

厳密に言えば、Wayland は、クライアントがディスプレイサーバーと通信する方法を定義する単なるプロトコルです。 Wayland プロトコルは X プロトコルとはまったく異なります。Wayland プロトコルは、グラフィックやテキストを描画するメッセージを定義せず、フォントも処理しません。

Wayland アーキテクチャでは、ウィンドウマネージャーとディスプレイサーバーが、合成ウィンドウマネージャーという 1 つのソフトウェアコンポーネントに統合されます。クライアントは、Wayland プロトコルを使用するソフトウェアライブラリを介して、描画するサーフェスを要求できます。「サーフェスは、位置、サイズ、およびピクセルコンテンツによって定義される、画面上の長方形の領域を表すオブジェクトです」.

クライアントはオフスクリーンバッファーにレンダリングし、それをサーフェスにアタッチして、画面上に出力を生成します。クライアントはさまざまな API を使用してレンダリングを行うことができます:OpenGL、OpenGL ES など (「描画 API とは何ですか? 好きなように」) ダブルバッファリングが使用されます:クライアントは 2 番目のバッファを使用してイメージを更新し、そのバッファにコヒーレントイメージが含まれている場合、次のディスプレイモニタの垂直帰線消去間隔で表示されるように切り替えられます。 Wayland のモットーは次のとおりです。「すべてのフレームは完璧です」。つまり、窓が破れたり、ちらついたり、点滅したりしません。

Wayland での入力処理は、どのウィンドウがマウスカーソルの下にあるかを認識している唯一のコンポーネントであるコンポジターを経由します (コンポジターはウィンドウをワープした可能性があることを思い出してください)。コンポジターは、画面座標を適切なウィンドウのウィンドウローカル座標に変換し、イベントをクライアントに送信します。

Wayland の作成につながったストーリーに興味がある場合は、Daniel Stone の陽気なプレゼンテーション The real story behind Wayland and X をご覧になることをお勧めします。