X Window System のプロトコルとアーキテクチャ

コンピューティングにおいて、X ウィンドウ システム(一般に X11 または X) は、ビットマップ表示用のネットワーク透過的な ウィンドウ システムです。この記事では、X11 のプロトコルと技術構造について詳しく説明します。

Xはクライアント・サーバーモデルを採用しています。Xサーバープログラムはグラフィカルディスプレイを備えたコンピュータ上で動作し、さまざまなクライアントプログラムと通信します。Xサーバーはユーザーとクライアントプログラムの仲介役として機能し、クライアントプログラムからのグラフィカル出力（ウィンドウ）のTCPポート6000プラスディスプレイ番号^[1]での要求を受け付けてユーザー（ディスプレイ）に表示し、ユーザー入力（キーボード、マウス）を受け取ってクライアントプログラムに送信します。

X では、サーバーはユーザーのコンピュータで実行され、クライアントはリモート マシンで実行される場合があります。この用語は、クライアントが通常ユーザーのローカル コンピュータで実行され、サーバーがリモート コンピュータで実行されるという、クライアント サーバー システムの一般的な概念を逆転させます。X ウィンドウの用語では、X ウィンドウ プログラムがすべてのアクティビティの中心にあるという観点が採用されています。つまり、X ウィンドウ プログラムは、アプリケーションからの要求や、ユーザーのマウスとキーボードの入力を受け入れ、応答します。したがって、アプリケーション (リモート コンピュータ上) は、X ウィンドウ サーバー プログラムのクライアントと見なされます。

サーバーとクライアント間の通信プロトコルはネットワーク透過的に実行されます。クライアントとサーバーは同じマシン上で実行することも、異なるアーキテクチャやオペレーティングシステムを搭載した異なるマシン上で実行することもできます。クライアントとサーバーは、暗号化された接続を介して接続をトンネリングすることで、インターネット上で安全に通信できます。 ^[2]

Bob ScheiflerとJim Gettys は、 X の初期の原則を次のように定めました (Scheifler/Gettys 1996 に記載)。

• 実装者がそれなしでは実際のアプリケーションを完了できない場合を除き、新しい機能を追加しないでください。
• システムが何であるかを決めるのと同じくらい、システムが何ではないかを決めることも重要です。世界中のあらゆるニーズに応えるのではなく、上位互換性を保ちながら追加のニーズに対応できるようにシステムを拡張可能にします。
• 1 つの例から一般化することよりも悪いのは、まったく例がない状態で一般化することだけです。
• 問題が完全に理解されていない場合は、解決策をまったく提供しないのが最善でしょう。
• 10 パーセントの作業で 90 パーセントの目的の効果が得られる場合は、よりシンプルなソリューションを使用します。 ( 「Worse is better 」も参照してください。)
• 複雑さを可能な限り分離します。
• ポリシーではなくメカニズムを提供します。特に、ユーザー インターフェイス ポリシーをクライアントに委ねます。

最初の原則は、X11 の設計中に次のように変更されました:実際のアプリケーションで必要なことがわかっている場合を除き、新しい機能を追加しないでください。

X はそれ以来、これらの原則をほぼ守ってきました。X.Org Foundation は、実装の拡張と改善を視野に入れながら、1987 年のオリジナル プロトコルとの互換性をほぼ完全に維持しながら、リファレンス実装を開発しています。

サーバーとクライアント間の通信は、ネットワークチャネルを介してパケットを交換することによって行われます。クライアントは最初のパケットを送信して接続を確立します。サーバーは、接続の承諾または拒否を示すパケット、または追加の認証の要求を返信することで応答します。接続が承諾された場合、承諾パケットには、クライアントがサーバーとのその後のやり取りで使用するデータが含まれます。

接続が確立されると、クライアントとサーバーはチャネルを介して次の 4 種類のパケットを交換します。

1. リクエスト:クライアントはサーバーに情報を要求したり、サーバーにアクションの実行を要求します。
2. 応答:サーバーはリクエストに応答します。すべてのリクエストが応答を生成するわけではありません。
3. イベント:サーバーは、キーボードやマウスの入力、ウィンドウの移動、サイズ変更、表示などのイベントをクライアントに送信します。
4. エラー:リクエストが無効な場合、サーバーはエラー パケットを送信します。リクエストはキューに入れられるため、リクエストによって生成されたエラー パケットはすぐに送信されない場合があります。

X サーバーは一連の基本的なサービスを提供します。クライアント プログラムは、サーバーと対話することで、より複雑な機能を実現します。

他のグラフィカル ユーザー インターフェイスで通常ウィンドウと呼ばれるものは、 X ウィンドウ システムのトップレベル ウィンドウです。ウィンドウという用語は、別のウィンドウ内にあるウィンドウ、つまり親ウィンドウのサブウィンドウにも使用されます。ボタン、メニュー、アイコンなどのグラフィカル要素はすべて、ウィンドウを使用して実現されます。

ウィンドウは、親ウィンドウのサブウィンドウとしてのみ作成できます。これにより、ウィンドウはツリー内に階層的に配置されます。X サーバーは、ルート ウィンドウと呼ばれるツリーのルートを自動的に作成します。最上位のウィンドウは、ルート ウィンドウの直接のサブウィンドウです。見た目上、ルート ウィンドウは画面と同じ大きさで、他のすべてのウィンドウの背後にあります。

X サーバーは、ウィンドウ、フォントなどに関するすべてのデータを保存します。クライアントはこれらのオブジェクトの識別子を知っています。これは、サーバーと対話するときに名前として使用できる整数です。たとえば、クライアントがウィンドウを作成したい場合、サーバーにウィンドウの作成を要求し、(成功した場合) 新しく作成されたウィンドウに関連付けられたサーバー識別子が返されます。この識別子は、後でクライアントがウィンドウに描画する文字列などを要求するために使用できます。

識別子は、クライアントだけでなくサーバーに対しても一意です。たとえば、2 つの異なるクライアントによって作成された場合でも、2 つのウィンドウが同じ識別子を持つことはありません。クライアントは、別のクライアントによって作成されたオブジェクトであっても、識別子が与えられたオブジェクトにアクセスできます。

すべてのウィンドウには、定義済みの属性セットとプロパティ セットがあり、それらはすべて X サーバーに保存され、適切なリクエストを介してクライアントからアクセスできます。属性は、ウィンドウのサイズ、位置、背景色など、ウィンドウに関するデータです。プロパティは、ウィンドウに添付されるデータです。属性とは異なり、プロパティは X ウィンドウ コア プロトコル レベルでは意味を持ちません。クライアントは、ウィンドウのプロパティに任意のデータを保存できます。

プロパティは、名前、タイプ、値によって特徴付けられます。プロパティは、アプリケーションが特定の名前とタイプの新しいプロパティを作成し、そこに値を格納できるという点で、命令型プログラミング言語の変数に似ています。プロパティはウィンドウに関連付けられます。つまり、同じ名前の 2 つのプロパティが、異なるタイプと値を持ちながら、2 つの異なるウィンドウに存在することができます。

プロパティは主にクライアント間の通信に使用されます。たとえば、named プロパティにはWM_NAMEウィンドウの名前が格納されます。ウィンドウ マネージャーは通常、このプロパティを読み取り、ウィンドウの上部にその名前を表示します。

プログラムxpropはウィンドウのプロパティを表示できます。特に、X リソース(プログラムのパラメータ) xprop -rootを含むルート ウィンドウのプロパティを表示します。

イベントは、クライアントにとって興味深い出来事が発生したことを通知するために、サーバーからクライアントに送信されるパケットです。クライアントは、サーバーに別のクライアントにイベントを送信するように要求できます。これは、クライアント間の通信に使用されます。たとえば、クライアントが現在選択されているテキストを要求すると、選択されているウィンドウを現在処理しているクライアントにイベントが送信されます。

ウィンドウのコンテンツは、状況によっては「破棄」されることがあります (たとえば、ウィンドウが覆われている場合)。破棄されたコンテンツの領域が表示されるたびに、サーバーはExposeイベントを生成し、ウィンドウの一部を描画する必要があることをクライアントに通知します。

その他のイベントは、キーボードやマウスの入力、新しいウィンドウの作成などをクライアントに通知するために使用できます。

いくつかの種類のイベントは常にクライアントに送信されますが、ほとんどの種類のイベントは、クライアントが特定の種類のイベントにのみ関心がある可能性があるため、クライアントが以前にそのイベントに関心があることを表明した場合にのみ送信されます。たとえば、クライアントはキーボード関連のイベントには関心があるかもしれませんが、マウス関連のイベントには関心がない可能性があります。

X Window System が色を処理する方法は、ユーザーを混乱させることがあるため、これまで複数の異なるモードがサポートされてきました。最近のアプリケーションのほとんどはフルカラー(24 ビットカラー、赤、緑、青にそれぞれ 8 ビット) を使用していますが、古いアプリケーションや専門的なアプリケーションでは、別のカラーモードが必要になる場合があります。多くの商用の専門的なアプリケーションでは、PseudoColor を使用しています。

X11 プロトコルは、ほとんどのグラフィック操作で単一の色を表すために、ピクセル値と呼ばれる単一の 32 ビット符号なし整数を使用します。原色の強度を転送する場合、各色成分に 16 ビット整数が使用されます。次の色の表現が存在します。特定のデバイスでは、すべてがサポートされるわけではありません。

• DirectColor:ピクセル値は、赤、緑、青のサブフィールドに分解されます。各サブフィールドは、個別のカラーマップをインデックスします。すべてのカラーマップのエントリは変更できます。
  • TrueColor: DirectColor と同じですが、カラーマップ エントリはハードウェアによって事前定義されており、変更できません。通常、赤、緑、青の各カラーマップは、強度の (ほぼ) 線形ランプを提供します。
• GrayScale:ピクセル値は、モノクロの強度を含む単一のカラーマップをインデックスします。カラーマップのエントリは変更できます。
  • StaticGray: GrayScale と同じですが、カラーマップ エントリはハードウェアによって事前定義されており、変更できません。
• PseudoColor ( Chunky ): ピクセル値は、色の強度を含む単一のカラーマップをインデックスします。カラーマップのエントリは変更できます。
  • StaticColor: PseudoColor と同じですが、カラーマップ エントリはハードウェアによって事前定義されており、変更できません。

ほとんどのクライアント プログラムは、 Xlibクライアント ライブラリを介してサーバーと通信します。Xlib のほかに、XCBライブラリは X プロトコルにさらに近い動作をします。特に、ほとんどのクライアントは、サーバーとのやり取りにXlib を使用するXaw、Motif、GTK+、Qtなどのライブラリを使用します。Qtは5.0 リリースでXlib からXCBに切り替わりましたが、クライアント プログラムはこの変更による影響をほとんど受けませんでした。

X ウィンドウ コア プロトコルは、クライアント間の通信メカニズム (ウィンドウ プロパティとイベント、特にクライアント間のメッセージ イベント) を提供します。ただし、このようなやり取りのプロトコルは指定されていません。代わりに、クライアント間の通信規約の別のセットがこれらのプロトコルを管理します。

クライアント間通信規約マニュアルは、選択によるデータ交換とアプリケーションとウィンドウマネージャとの相互作用のためのプロトコルを規定しています。この仕様は難しくてわかりにくいと考える人もいます。^{[3] [4]アプリケーションの}外観と操作感および通信の一貫性は、通常、特定のデスクトップ環境に合わせてプログラミングすることで対処されます。

クライアント間交換プロトコル (ICE) は、クライアント間の対話用プロトコルを構築するためのフレームワークを指定します。これにより、プログラマーは、その上に特定のプロトコルを構築できます。特に、X セッション管理プロトコル (XSMP) は、ICE に基づくプロトコルで、セッション マネージャーを使用したアプリケーション間の対話を制御します。セッション マネージャーは、対話型セッションの終了時にデスクトップの状態を保存し、同じユーザーとの別のセッションが再開されたときにその状態を回復するプログラムです。

freedesktop仕様には、ドラッグ アンド ドロップ規則 Xdnd (データを選択して別のウィンドウにドラッグすることでデータを転送するために使用) や埋め込みアプリケーション規則 Xembed (アプリケーションを別のアプリケーションのサブウィンドウで実行する方法の詳細) などの新しい規則が含まれています 。

X ウィンドウ システムの選択、カット バッファ、およびドラッグ アンド ドロップのメカニズムにより、ユーザーは 1 つのウィンドウから別のウィンドウにデータを転送できます。選択とカット バッファは (通常)、ユーザーがウィンドウ内でテキストまたはその他のデータを選択し、別のウィンドウに貼り付けるときに使用されます。ドラッグ アンド ドロップは、ユーザーがウィンドウ内で何かを選択し、選択部分をクリックして別のウィンドウにドラッグするときに使用されます。

2 つの異なるアプリケーションが 2 つのウィンドウを処理する可能性があるため、データ転送では、同じ X サーバーに接続された異なるクライアントが対話する必要があります。X ウィンドウのコア プロトコルには、選択交換に固有のいくつかの種類の要求とイベントが含まれていますが、転送は主に、選択転送に固有ではない一般的なクライアント間のイベント送信とウィンドウ プロパティを使用して行われます。

ユーザーは、クライアント間でさまざまな種類のデータを転送できます。通常はテキストですが、ピクセルマップ、数値、オブジェクトのリストなども転送できます。

選択とドラッグ アンド ドロップはアクティブなメカニズムです。ユーザーがウィンドウ内のデータを選択すると、ウィンドウを処理するクライアントは、そのデータを要求元のアプリケーションに転送するためのプロトコルをアクティブにサポートする必要があります。対照的に、カット バッファはパッシブなメカニズムを提供します。ユーザーがテキストを選択すると、その内容がカット バッファに転送され、ウィンドウを処理するアプリケーションが終了してウィンドウが破棄されても、その内容はカット バッファに残ります。

ウィンドウ マネージャーは、ウィンドウやグラフィカル ユーザー インターフェイスのその他のグラフィカル要素の全体的な外観を制御するプログラムです。異なるインストールでの X ウィンドウ システムの外観の違いは、主に異なるウィンドウ マネージャーの使用またはウィンドウ マネージャーの異なる構成に起因します。

ウィンドウ マネージャーは、ウィンドウの位置を決定し、ウィンドウの周囲に装飾的な境界線を配置し、アイコンを処理し、ウィンドウの外側 (「背景」) でのマウス クリックを処理し、特定のキーストロークを処理します。

X サーバーの観点から見ると、ウィンドウ マネージャーは他のクライアントと同様にクライアントとして動作します。ウィンドウの初期位置と周囲の装飾的な境界線は、次の要求を使用してウィンドウ マネージャーによって処理されます。

1. アプリケーションは、特定のウィンドウのサブウィンドウをマッピング (表示) する要求を満たさず、代わりにイベントを送信するようにサーバーに要求できます。
2. アプリケーションはウィンドウの親の変更を要求できます。

ウィンドウ マネージャーは、最初の要求を使用して、トップレベル ウィンドウ (ルート ウィンドウの子) のマッピング要求を傍受します。別のアプリケーションがトップレベル ウィンドウのマッピングを要求すると、サーバーはそれを行わず、代わりにウィンドウ マネージャーにイベントを送信します。ほとんどのウィンドウ マネージャーは、ウィンドウの親を再設定します。つまり、より大きなトップレベル ウィンドウ (フレーム ウィンドウと呼ばれる) を作成し、元のウィンドウをその子として親再設定します。グラフィカルに言うと、これは元のウィンドウをフレーム ウィンドウ内に配置することに相当します。元のウィンドウが占有しないフレーム ウィンドウのスペースは、ウィンドウの周囲の装飾フレーム (「境界」と「タイトル バー」) に使用されます。

ウィンドウ マネージャーは、フレーム ウィンドウ内のマウス クリックを管理します。これにより、たとえば、ユーザーは境界またはタイトル バーをクリックしてドラッグすることで、ウィンドウを移動したり、サイズを変更したりできます。

ウィンドウ マネージャーは、アイコンやグラフィカル ユーザー インターフェイスに関連する視覚要素も処理します。アイコンは、X ウィンドウ コア プロトコルのレベルには存在しません。ウィンドウ マネージャーによって実装されます。たとえば、ウィンドウを「アイコン化」する必要がある場合、FVWMウィンドウ マネージャーはウィンドウのマップを解除し、アイコン名用のウィンドウと、場合によってはアイコン イメージ用の別のウィンドウを作成します。したがって、アイコンの意味と処理はウィンドウ マネージャーによって完全に決定されます。wm2などの一部のウィンドウ マネージャーは、アイコンをまったく実装しません。

大まかに言えば、セッションの状態とは、特定の時点における「デスクトップの状態」、つまり現在のコンテンツを含むウィンドウのセットです。より正確には、これらのウィンドウを管理するアプリケーションのセットと、必要に応じてこれらのアプリケーションが管理するウィンドウの状態を復元できるようにする情報です。X セッション マネージャーと呼ばれるプログラムは、セッションの状態を保存および復元します。

最もよく知られているのは、セッション マネージャーを使用すると、ユーザーは対話型セッションからログアウトしても、再度ログインしたときにまったく同じ状態のウィンドウが表示されることです。これを実現するには、セッション マネージャー プログラムはログアウト時に実行中のアプリケーションの名前を保存し、ログイン時にそれらを再度起動します。アプリケーションの状態も復元するには (ウィンドウの内容を復元するために必要)、アプリケーションはセッション マネージャーからの要求に応じて実行状態を保存し、再度起動したときにそれを読み込むことができる必要があります。

X Window System には、 と呼ばれるデフォルトのセッション マネージャーが含まれていますxsm。開発者は、特定のデスクトップ システム用に他のセッション マネージャーも作成しています。主な例としては ksmserver、それぞれKDE、Xfce、 およびGNOME用のxfce4-session、 、 など があります。 gnome-session

X ディスプレイ マネージャと呼ばれるプログラムは、X Window System にグラフィカル ログイン プロンプトを表示します。より一般的には、ディスプレイ マネージャは、ローカル コンピュータで 1 つ以上の X サーバーを実行するか、リモート コンピュータで実行されている X サーバーからの着信接続を受け入れます。ローカル サーバーはディスプレイ マネージャによって起動され、ディスプレイ マネージャはローカル サーバーに接続して、ユーザーにログイン画面を表示します。リモート サーバーはディスプレイ マネージャとは独立して起動され、ディスプレイ マネージャに接続します。この状況では、ディスプレイ マネージャはグラフィカルTelnetサーバーのように動作します。X サーバーはディスプレイ マネージャに接続でき、ディスプレイ マネージャはセッションを開始します。このセッションを使用するアプリケーションは、ディスプレイ マネージャと同じコンピュータで実行されますが、X サーバーが実行されるコンピュータ (ユーザーの目の前のコンピュータまたはリモート コンピュータ) で入力と出力が行われます。

X Window System には、基本的なディスプレイ マネージャーとしてXDMが付属しています。その他のディスプレイ マネージャーには、 GDM ( GNOME )、KDM / SDDM ( KDE )、WDM ( Window Makerで使用される WINGs ウィジェット セットを使用)、entre ( Enlightenment v.17 で使用されるアーキテクチャを使用) などがあります。

X 用の初期のウィジェット ツールキットには、 Xaw ( Athena Widget Set、1983 年)、OLIT ( OPEN LOOK Intrinsics Toolkit、1988 年)、XView (1988 年)、Motif (1980 年代)、Tk などがありました。OLIT と XView は、 SunのレガシーOpenWindowsデスクトップ環境 の基本ツールキットとして機能します。

Motif は、 Solaris、AIX、HP-UXなどの商用Unixシステムで使用されるデスクトップ環境であるCommon Desktop Environment (CDE)の基本ツールキットを提供します。(Solaris 10 には CDE とGNOME の両方が含まれており、2010 年現在、後者が推奨されるデスクトップ環境です。) ^{[アップデート]}

最近開発されたツールキットには、Qt (1991- 、 KDE​​で使用)、GTK+ (1997- 、GNOME で使用)、wxWidgets (1992- )、FLTK (1998- )、FOX (1997- )、fpGUI (2005 年以降) などがあります。

Scheifler と Gettys は、X サーバーをシンプルでありながら拡張可能なものとして設計しました。そのため、現在では多くの機能がプロトコルの拡張機能に含まれています。

プロトコルレベルでは、すべての拡張機能に新しいリクエスト/イベント/エラーパケットタイプを割り当てることができます。拡張機能は、クライアントアプリケーションから拡張機能ライブラリを介してアクセスされます。現在のXサーバーの実装に拡張機能を追加することは、サーバー設計のモジュール性の欠如により困難であると報告されています。^[5] XCBプロジェクトの長期目標は、XMLプロトコル記述からクライアント側とサーバー側の両方の拡張機能を自動化することです。

次の表は、開発された拡張機能の部分的なカタログであり、導入された新しい順に大まかに分類されています。

• Xlib
• 本質的性質(Xt)
• X ウィンドウ システム コア プロトコル
• X論理フォントの説明

1. Manrique, Daniel (2001 年 5 月 23 日)。「X ウィンドウ システム アーキテクチャ: 概要」。Xウィンドウ システム アーキテクチャの概要 HOWTO。Linuxドキュメンテーション プロジェクト。2011年7 月 13 日閲覧。
2. マグオロ、フィリッポ（2005 年 12 月 16 日）。 「X-Window のアーキテクチャ」。Linux のレッスン。マウント・キスコ、ニューヨーク州、米国: ジョン・F・ムーア。2011 年7 月 13 日に取得。
3. Stevens, W. Richard (1994)。「30.5 X Window System」(PDF)。TCP /IP Illustrated (PDF) 。Addison-Wesley プロフェッショナル コンピューティング シリーズ。第 1 巻、TheProtocols (第 1 版)。ボストン、マサチューセッツ州、米国: Addison-Wesley。30.5 X Window System。ISBN 978-0-201-63346-7. OCLC  246049781 . 2011年7月13日閲覧。
4. IBM Corporation、International Technical Support Center (1994 年 7 月)。「1.2 X の概念」(PDF)。TCP/IP for MVS、VM、OS/2、および DOS: X Window System ガイド(PDF)。IBM Redbooks (第 2 版)。米国ノースカロライナ州リサーチ トライアングル パーク: IBM。Xの概念。2011 年7 月 13 日に取得。
5. Quercia, Valerie; O'Reilly, Tim (1993) [1988]. X Window System ユーザーズ ガイド: X11 リリース 5 用。X Window System の決定版ガイド。第 3 巻。セバストポル、カリフォルニア州、米国: O'Reilly & Assoc. ISBN 978-1-56592-014-9. OCLC  682229836. LCC  QA76.76.W56 Q47 . 2011年7月14日閲覧。 archive.org には 1990 年版があります。

• Robert W. Scheifler および James Gettys: X Window System: Core and extension protocols, X version 11, releases 6 and 6.1、Digital Press 1996、ISBN 978-1-55558-148-0 
• 「X11 ユーザー インターフェイスの紹介」。2007 年 1 月 3 日時点のオリジナルからアーカイブ。
• X Windows の紹介
• Gettys, Jim (2003 年 12 月 9 日)。「オープン ソース デスクトップ テクノロジー ロード マップ」。2006 年 1 月 2 日時点のオリジナルよりアーカイブ。

• X.Org Foundation（公式ホームページ）
• X.Org Foundation ウィキ
• X ウィンドウ システムの内部
• Kenton Lee の X Window と Motif に関するページは、2013 年 5 月 20 日にWayback Machineにアーカイブされました。
• X11 拡張機能チュートリアル