X ウィンドウ システム コア プロトコル

Xウィンドウシステムコアプロトコル^{[1] [2] [3]}は、 Unix、Unix系、およびその他のオペレーティングシステム上でグラフィカルユーザーインターフェイスを構築するために使用されるビットマップディスプレイ用のネットワークウィンドウシステムであるXウィンドウシステムの基本プロトコルです。Xウィンドウシステムはクライアントサーバーモデルに基づいています。単一のサーバーが画面、キーボード、マウスなどの入出力ハードウェアを制御し、すべてのアプリケーションプログラムはクライアントとして機能し、サーバーを介してユーザーや他のクライアントと対話します。この対話は、Xウィンドウシステムコアプロトコルによって制御されます。Xウィンドウシステムに関連する他のプロトコルは、Xウィンドウシステムコアプロトコルの上部に構築される場合と、別のプロトコルとして存在する場合があります。

X Window System コア プロトコルでは、ネットワーク経由で非同期に送信されるパケットは、要求、応答、イベント、およびエラーの 4 種類だけです。要求は、クライアントからサーバーに送信され、何らかの操作 (たとえば、新しいウィンドウの作成) の実行と、サーバーが保持しているデータの返送を要求します。応答は、サーバーから送信され、そのようなデータを提供します。イベントは、サーバーから送信され、ユーザーのアクティビティやクライアントが関心のあるその他の出来事をクライアントに通知します。エラーは、サーバーから送信されるパケットで、クライアントの要求の処理中に発生したエラーをクライアントに通知します。要求によって応答、イベント、およびエラーが生成される場合がありますが、それ以外に、プロトコルでは、ネットワーク経由でパケットを送信する特定の順序は規定されていません。コア プロトコルにはいくつかの拡張機能があり、それぞれに独自の要求、応答、イベント、およびエラーがあります。

X は 1984 年にMITで開発されました(現在の^{[アップデート]}リリースである X11 は 1987 年 9 月に登場しました)。X の設計者であるBob ScheiflerとJim Gettys は、そのコア プロトコルは「ポリシーではなくメカニズムを作成する」という原則を初期に設定しました。その結果、コア プロトコルはクライアント間およびクライアントとユーザー間のやり取りを指定しません。これらのやり取りは、ICCCMやfreedesktop.org仕様などの別の仕様^{[4]の対象であり、通常は特定の}ウィジェット セットを使用して自動的に実行されます。

サーバーとクライアント間の通信は、チャネルを介してパケットを交換することによって行われます。接続はクライアントによって確立されます (クライアントの起動方法はプロトコルでは指定されていません)。クライアントは、使用するバイト順序、プロトコルのバージョン、およびクライアントがサーバーで使用すると期待する認証の種類に関する情報を含む最初のパケットも送信します。サーバーは、接続の承諾または拒否を示すパケット、または追加の認証の要求を返信することで応答します。接続が承諾された場合、承諾パケットには、クライアントがサーバーとのその後のやり取りで使用するデータが含まれます。

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

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

要求パケットと応答パケットの長さはさまざまですが、イベント パケットとエラー パケットの長さは 32バイトの固定長です。

リクエスト パケットは、サーバーが受信するとすぐに順番に番号が付けられます。クライアントからの最初のリクエストには 1、2 番目のリクエストには 2 というように番号が付けられます。リクエストの連続番号の最下位 16 ビットは、リクエストによって生成された応答パケットとエラー パケット (存在する場合) に含まれます。また、イベント パケットにも含まれ、サーバーが現在処理中または処理を終了したリクエストの連続番号を示します。

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

クライアントはウィンドウの作成を要求できます。より正確には、既存のウィンドウのサブウィンドウの作成を要求できます。その結果、クライアントによって作成されたウィンドウはツリー(階層) に配置されます。このツリーのルートはルート ウィンドウです。ルート ウィンドウは、起動時にサーバーによって自動的に作成される特別なウィンドウです。他のすべてのウィンドウは、ルート ウィンドウの直接的または間接的なサブウィンドウです。最上位のウィンドウは、ルート ウィンドウの直接のサブウィンドウです。見た目上、ルート ウィンドウは仮想デスクトップと同じ大きさで、他のすべてのウィンドウの背後にあります。

ウィンドウの内容は、時間が経っても常に保持されるとは限りません。特に、ウィンドウが移動、サイズ変更、他のウィンドウに覆われたり、一般的に全体または一部が見えなくなったりすると、ウィンドウの内容が破壊される可能性があります。特に、X サーバーがウィンドウの内容のバッキング ストアを維持していない場合、内容は失われます。クライアントはウィンドウのバッキング ストアを維持するように要求できますが、サーバーにはそれを行う義務はありません。したがって、クライアントはバッキング ストアが維持されていると想定することはできません。ウィンドウの可視部分に未指定の内容がある場合、ウィンドウの内容を再度描画する必要があることをクライアントに通知するイベントが送信されます。

すべてのウィンドウには、ウィンドウの形状 (サイズと位置)、背景イメージ、ウィンドウに対してバッキング ストアが要求されているかどうかなど、一連の属性が関連付けられています。プロトコルには、クライアントがウィンドウの属性を検査および変更するための要求が含まれています。

InputOutputウィンドウはまたは にすることができますInputOnly。InputOutputウィンドウは画面に表示され、描画に使用されます。InputOnlyウィンドウは画面には表示されず、入力を受け取るためだけに使用されます。

通常ウィンドウの周囲に表示される装飾的なフレームとタイトル バー(場合によってはボタンを含む) は、ウィンドウを作成するクライアントではなく、ウィンドウ マネージャーによって作成されます。ウィンドウ マネージャーは、ユーザーがウィンドウ フレームをクリックしてドラッグしたときのウィンドウのサイズ変更など、これらの要素に関連する入力も処理します。クライアントは通常、ウィンドウ マネージャーによって行われた変更を無視して、作成したウィンドウを操作します。考慮する必要がある変更は、ほとんどすべての最新のウィンドウ マネージャーに当てはまる親の変更ウィンドウ マネージャーによって、トップレベル ウィンドウの親がルートではないウィンドウに変更されることです。コア プロトコルの観点からは、ウィンドウ マネージャーはクライアントであり、他のアプリケーションと変わりません。

プログラムを実行すると、ウィンドウに関するデータを取得できます。コマンドライン引数xwininfoを渡すと、このプログラムはウィンドウのサブウィンドウのツリーを、それらの識別子とジオメトリ データとともに表示します。 -tree

ピックスマップは、描画に使用できるメモリ領域です。ウィンドウとは異なり、ピックスマップは画面に自動的に表示されません。ただし、ピックスマップの内容 (またはその一部) をウィンドウに転送することはできます。また、その逆も可能です。これにより、ダブル バッファリングなどの手法が可能になります。ウィンドウで実行できるグラフィック操作のほとんどは、ピックスマップでも実行できます。

ウィンドウとピックスマップは総称してドローアブルと呼ばれ、そのコンテンツ データはサーバー上に存在します。ただし、クライアントはドローアブルのコンテンツをサーバーからクライアントに転送するように要求したり、その逆の要求をすることができます。

クライアントは、領域のクリア、領域を別の領域にコピー、点、線、四角形、テキストの描画など、さまざまなグラフィック操作を要求できます。クリア以外にも、ウィンドウとピクセルマップの両方を含むすべての描画可能オブジェクトに対してすべての操作が可能です。

グラフィック操作のほとんどのリクエストには、グラフィック コンテキストが含まれます。これは、グラフィック操作のパラメータを含む構造体です。グラフィック コンテキストには、前景色、背景色、テキストのフォント、およびその他のグラフィック パラメータが含まれます。グラフィック操作をリクエストする場合、クライアントはグラフィック コンテキストを含めます。グラフィック コンテキストのすべてのパラメータが操作に影響するわけではありません。たとえば、フォントは線の描画に影響しません。

コアプロトコルは、サーバー側フォントの使用を規定しています。^{[5]このようなフォントは}ファイルとして保存され、サーバーはローカルファイルシステムを介して直接アクセスするか、フォントサーバーと呼ばれる別のプログラムからネットワーク経由でアクセスします。クライアントは、サーバーで使用可能なフォントのリストを要求したり、サーバーによるフォントのロード（まだロードされていない場合）またはアンロード（他のクライアントで使用されていない場合）を要求したりできます。クライアントは、フォントに関する一般的な情報（フォントのアセントなど）や、特定のフォントで描画されたときに特定の文字列が占めるスペースを要求できます。

フォント名は、Xウィンドウコアプロトコルのレベルで任意の文字列です。X論理フォント記述規則^[6]は、フォントの属性に応じてフォントに名前を付ける方法を指定します。これらの規則では、フォントに添付できるオプションのプロパティの値も指定します。

このxlsfontsプログラムは、サーバーに保存されているフォントのリストを印刷します。このxfontselプログラムはフォントのグリフを表示し、ユーザーがフォント名を選択して別のウィンドウに貼り付けられるようにします。

サーバーサイドフォントの使用は現在、クライアントサイドフォントの使用に取って代わられ、非推奨とみなされています。^{[7]このようなフォントは、} XftまたはcairoライブラリとXRender拡張機能のサポートにより、サーバーではなくクライアントによってレンダリングされます。コアプロトコルでは、クライアントサイドフォントの仕様は規定されていません。

ウィンドウ、ピクセルマップ、フォントなどに関するすべてのデータは、サーバーに保存されます。クライアントは、これらのオブジェクトの識別子(サーバーと対話するときにオブジェクトの名前として使用する整数) を認識します。たとえば、クライアントがウィンドウを作成したい場合、指定された識別子を持つウィンドウを作成するようにサーバーに要求します。クライアントは後でこの識別子を使用して、たとえばウィンドウに描画する文字列を要求できます。次のオブジェクトはサーバーに存在し、数値識別子を介してクライアントに認識されます。

• Window
• Pixmap
• Font
• Colormap(色の表については下記で説明します)
• Graphic context

これらのオブジェクトはリソースと呼ばれます。クライアントがこのようなリソースの作成を要求する場合、そのリソースの識別子も指定します。たとえば、新しいウィンドウを作成する場合、クライアントはウィンドウの属性 (親、幅、高さなど) とウィンドウに関連付ける識別子の両方を指定します。

識別子は 32 ビットの整数で、上位 3 ビットはゼロです。各クライアントには、新しいリソースの作成に使用できる独自の識別子セットがあります。このセットは、サーバーによって、受け入れパケット (接続が受け入れられたことをクライアントに通知するためにサーバーがクライアントに送信するパケット) に含まれる 2 つの整数として指定されます。クライアントは、このセット内の識別子を衝突しないように選択します。つまり、ウィンドウ、ピクセルマップ、フォント、カラーマップ、グラフィック コンテキストの 2 つのオブジェクトに同じ識別子を割り当てることはできません。

リソースが作成されると、クライアントはその識別子を使用して、サーバーにそのリソースに関する操作を要求します。一部の操作は特定のリソースに影響します (たとえば、ウィンドウを移動する要求)。その他の操作はサーバーから保存されたリソース データを要求します (たとえば、ウィンドウの属性の要求)。

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

その結果、同じサーバーに接続している 2 つのクライアントは、同じ識別子を使用して同じリソースを参照できます。たとえば、クライアントが識別子のウィンドウを作成し0x1e00021、この番号を0x1e00021別のアプリケーションに渡すと (使用可能な任意の手段、たとえば、この番号を他のアプリケーションからもアクセス可能なファイルに保存するなど)、この他のアプリケーションはまったく同じウィンドウで操作できます。この可能性は、たとえば Ghostview の X Window バージョンによって活用されています。このプログラムはサブウィンドウを作成し、その識別子を環境変数に保存して、Ghostscriptを呼び出します。このプログラムは、 PostScriptファイルのコンテンツを描画してこのウィンドウに表示します。^[8]

通常、リソースは、それを作成したクライアントがサーバーとの接続を閉じると破棄されます。ただし、接続を閉じる前に、クライアントはサーバーにリソースを破棄しないように要求できます。

イベントは、クライアントが関心を持つ可能性のある何かが発生したことを通知するために、サーバーからクライアントに送信されるパケットです。たとえば、ユーザーがキーを押したり、マウス ボタンをクリックしたりすると、イベントが送信されます。イベントは入力に使用されるだけではありません。たとえば、特定のウィンドウの新しいサブウィンドウの作成を示すためにイベントが送信されます。

すべてのイベントはウィンドウに相対的です。たとえば、ポインターがウィンドウ内にあるときにユーザーがクリックすると、イベントはそのウィンドウに相対的になります。イベント パケットには、そのウィンドウの識別子が含まれます。

クライアントは、サーバーに別のクライアントにイベントを送信するように要求できます。これは、クライアント間の通信に使用されます。このようなイベントは、たとえば、クライアントが現在選択されているテキストを要求したときに生成されます。このイベントは、選択を保持しているウィンドウを現在処理しているクライアントに送信されます。

このExposeイベントは、ウィンドウの領域が破棄され、コンテンツが表示された時に送信されます。ウィンドウのコンテンツは、ウィンドウが覆われていてサーバーがバッキング ストアを保持していない場合など、状況によっては破棄されることがあります。サーバーは、Exposeウィンドウの一部を描画する必要があることをクライアントに通知するイベントを生成します。

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

クライアントは、ウィンドウの属性を設定することで、送信するイベントの種類を指定します。たとえば、コンテンツが破棄されたときにウィンドウを再描画するには、クライアントはExposeウィンドウを再度描画する必要があることを通知するイベントを受信する必要があります。ただし、クライアントにイベントが送信されるのは、クライアントがこれらのイベントに関心があることを事前に表明している場合のみであり、これはウィンドウの イベントマスクExpose属性を適切に設定することで行われます。

異なるクライアントが同じウィンドウのイベントを要求できます。同じウィンドウに異なるイベント マスクを設定することもできます。たとえば、あるクライアントはウィンドウのキーボード イベントのみを要求し、別のクライアントは同じウィンドウのマウス イベントのみを要求する場合があります。これは、サーバーが各ウィンドウに対して、各クライアントの個別のイベント マスクを維持しているために可能です。ただし、各ウィンドウに対して一度に 1 つのクライアントのみが選択できるイベントの種類があります。特に、これらのイベントは、マウス ボタンのクリックやウィンドウ管理に関連する変更を報告します。

このxevプログラムは、ウィンドウに関連するイベントを表示します。特に、xev -id WID識別子のウィンドウに関連するすべての可能なイベントを要求しWID、それらを出力します。

以下は、黒いボックスを含むウィンドウを作成し、キーを押すと終了するプログラムとサーバー間のやり取りの可能な例です。この例では、クライアント要求が応答を生成しないため、サーバーは応答を送信しません。これらの要求によってエラーが発生する可能性があります。

1. クライアントはサーバーとの接続を開き、使用しているバイト順序を指定する初期パケットを送信します。
2. サーバーは、ルート ウィンドウの識別子 (例: 0x0000002b) やクライアントが作成できる識別子などの他の情報を含む適切なパケットを送信して接続を受け入れます (この例では認証は行われません)。
3. クライアントは、識別子付きのデフォルトのグラフィック コンテキストの作成を要求します0x00200000(この要求は、この例の他の要求と同様に、サーバーからの応答を生成しません)
4. 0x0000002bクライアントは、識別子0x00200001、サイズ 200x200、位置 (10,10) などを持つトップレベル ウィンドウ (つまり、親をルート ウィンドウとして指定する) を作成するようにサーバーに要求します。
5. クライアントは、ウィンドウの属性の変更を要求し、イベントとイベントの0x00200001受信に関心があることを指定します。ExposeKeyPress
6. クライアントはウィンドウ0x00200001のマッピングを要求します（画面に表示されます）
7. ウィンドウが表示され、その内容を描画する必要がある場合、サーバーはクライアントにExposeイベントを送信します。
8. PolyFillRectangleこのイベントに応答して、クライアントはウィンドウ0x00200001とグラフィックコンテキストを含むリクエストを送信してボックスの描画を要求します。0x00200000

ウィンドウが別のウィンドウによって覆われ、再び覆われなくなった場合、バッキング ストアが維持されないと仮定すると、次のようになります。

1. サーバーは、Exposeウィンドウを再度描画する必要があることをクライアントに通知するために別のイベントを送信します。
2. PolyFillRectangleクライアントはリクエストを送信してウィンドウを再描画する

キーが押された場合:

1. サーバーは、KeyPressユーザーがキーを押したことをクライアントに通知するイベントを送信します。
2. クライアントは適切に反応します（この場合は終了します）

プロトコル レベルでは、色はピクセル値と呼ばれる 32 ビットの符号なし整数で表されます。次の要素が色の表現に影響します。

1. 色の深さ
2. カラーマップは、赤、緑、青の強度値を含むテーブルです。
3. 視覚タイプ。これは、テーブルを使用して色を表現する方法を指定します。

最も簡単なケースでは、カラーマップは各行にRGBトリプルを含むテーブルです。ピクセル値は、テーブルの - 番目の行xに含まれる色を表します。クライアントがカラーマップのエントリを変更できる場合、この表現はビジュアル クラスによって識別されます。ビジュアル クラスも同様ですが、クライアントはカラーマップのエントリを変更できません。 xPseudoColor StaticColor

合計 6 つのビジュアル クラスがあり、それぞれがピクセル値を持つ RGB トリプルを表す異なる方法を識別します。PseudoColorと はStaticColor2 つです。他の 2 つはGrayScaleと でStaticGray、グレーの濃淡のみを表示するという点で異なります。

残りの 2 つのビジュアル クラスは、ピクセル値を 3 つの部分に分割し、赤、緑、青の強度に 3 つの個別のテーブルを使用する点で、上記のクラスとは異なります。この色表現に従って、ピクセル値は次のように RGB トリプルに変換されます。

1. ピクセル値はビットのシーケンスとして表示されます
2. このシーケンスは3つの部分に分かれています
3. これら3つのビットの塊はそれぞれ整数として扱われ、3つの別々のテーブルのそれぞれで値を見つけるためのインデックスとして使用されます。

このメカニズムでは、カラーマップが、各原色ごとに 1 つずつ、3 つの別々のテーブルで構成されている必要があります。変換の結果は、依然として 3 つの強度値です。この表現を使用するビジュアル クラスは とDirectColorでTrueColor、クライアントがカラーマップを変更できるかどうかが異なります。

ピクセル値で色を表現するこれら 6 つのメカニズムは、いずれも動作するために追加のパラメータを必要とします。これらのパラメータは、ビジュアル クラスと色の表現のその他のパラメータを含むビジュアル タイプにまとめられます。各サーバーにはビジュアル タイプの固定セットがあり、それぞれが数値識別子に関連付けられています。これらの識別子は 32 ビットの符号なし整数ですが、リソースやアトムの識別子と必ずしも異なるわけではありません。

クライアントからの接続が受け入れられると、サーバーから送信される受け入れパケットには、各ブロックに 1 つの画面に関する情報が含まれる一連のブロックが含まれます。各画面の相対ブロックには、画面でサポートされている特定の色深度に関連する他のブロックのリストが含まれます。サポートされている深度ごとに、このリストにはビジュアル タイプのリストが含まれます。その結果、各画面には可能な深度がいくつか関連付けられ、各画面の各深度には可能なビジュアル タイプがいくつか関連付けられます。特定のビジュアル タイプは、より多くの画面や異なる深度に使用できます。

各ビジュアル タイプについて、受け入れパケットにはその識別子とそれに含まれる実際のパラメータ (ビジュアル クラスなど) の両方が含まれます。クライアントは後でこの情報を要求できないため、この情報を保存します。また、クライアントは新しいビジュアル タイプを変更したり作成したりすることはできません。新しいウィンドウの作成要求には、このウィンドウの色を表すために使用するビジュアル タイプの深度と識別子が含まれます。

カラーマップは、画面を制御するハードウェア (グラフィック カードなど)がパレット(色の表現にも使用されるテーブル) を使用するかどうかに関係なく使用されます。ハードウェアがパレットを使用していない場合でも、サーバーはカラーマップを使用します。ハードウェアがパレットを使用する場合は、限られた数のカラーマップのみをインストールできます。特に、カラーマップは、ハードウェアがそれに従って色を表示する場合にインストールされます。クライアントは、サーバーにカラーマップのインストールを要求できます。ただし、これには別のカラーマップのアンインストールが必要になる場合があります。アンインストールされたカラーマップを使用するウィンドウは正しい色で表示されず、色の点滅またはテクニカラーと呼ばれる効果が発生します。この問題は、ピクセル値と色との関連付けが予測可能なカラーマップである標準カラーマップを使用して解決できます。このプロパティのおかげで、標準カラーマップはさまざまなアプリケーションで使用できます。

カラーマップの作成はICCCM規約によって規制されています。標準カラーマップは ICCCM とXlib仕様によって規制されています。

X カラー システムの一部に、X カラー管理システム (xcms) があります。このシステムは、1991 年に X11R6 Release 5 で導入されました。このシステムは、Xcms* シリーズの関数に含まれる、xlib のいくつかの追加機能で構成されています。このシステムは、デバイスに依存しないカラー スキームを定義し、デバイスに依存する RGB システムに変換できます。このシステムは、xlib Xcms* 関数と、さまざまなデバイスに依存しないカラー システムをデバイスに依存する RGB カラー システムに変換する方法を記述する X デバイス カラー特性化規則 (XDCCC) で構成されています。このシステムは、CIEXYZ、xyY、CIELUV、CIELAB、および TekHVC カラー システムをサポートしています。[1] Archived 2011-10-05 at the Wayback Machine、[2]

アトムは文字列を表す 32 ビットの整数です。プロトコル設計者は、アトムが短く固定サイズの文字列を表すことからアトムを導入しました。 ^[9]文字列は任意の長さにすることができますが、アトムは常に 32 ビットの整数です。アトムの簡潔さは、同じ文字列で何度も送信される可能性のある種類のパケットでアトムの使用を義務付けることによって活用され、その結果、ネットワークをより効率的に使用できるようになりました。アトムの固定サイズは、イベントに固定サイズ、つまり 32 バイトを指定することによって活用されました。固定サイズのパケットにはアトムを含めることができますが、長い文字列を含めることはできません。

正確に言うと、アトムはサーバーに保存されている文字列の識別子です。リソース (Windows、Pixmap など) の識別子に似ていますが、2 つの点で異なります。まず、アトムの識別子はクライアントではなくサーバーによって選択されます。つまり、クライアントが新しいアトムの作成を要求すると、保存する文字列のみがサーバーに送信され、識別子は送信されません。この識別子はサーバーによって選択され、クライアントへの応答として返されます。リソースとアトムの 2 つ目の重要な違いは、アトムがクライアントに関連付けられていないことです。アトムは作成されると、サーバーが終了するかリセットされるまで存続します (これはリソースのデフォルトの動作ではありません)。

アトムは識別子であるため、一意です。ただし、アトムとリソース識別子は重複することがあります。アトムに関連付けられた文字列は、アトム名と呼ばれます。アトムの名前は作成後に変更できず、2 つのアトムが同じ名前を持つことはできません。その結果、アトムの名前は、アトムを示すためによく使用されます。「アトムABCD」は、より正確には、「関連付けられた文字列 を持つアトムABCD。」または「名前 を持つアトム。」を意味します。クライアントは、新しいアトムの作成を要求したり、特定の文字列のアトム (識別子) を要求したりできます。一部のアトムは事前定義されてABCDいます(指定された識別子と文字列を使用してサーバーによって作成されます)。

アトムはさまざまな目的で使用されますが、主に同じサーバーに接続された異なるクライアント間の通信に関連しています。特に、以下で説明するウィンドウのプロパティに関連して使用されます。

サーバーに存在するすべての原子のリストは、プログラムを使用して出力できますxlsatoms。特に、このプログラムは各原子 (識別子、つまり番号) をその名前 (関連付けられた文字列) とともに出力します。

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

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

プロパティの名前、タイプ、値は文字列です。より正確には、これらはアトム、つまりサーバーに格納され、識別子を介してクライアントがアクセスできる文字列です。クライアント アプリケーションは、プロパティ名を含むアトムの識別子を使用して、特定のプロパティにアクセスできます。

プロパティは主にクライアント間の通信に使用されます。たとえば、 という名前のプロパティWM_NAME(関連付けられた文字列が であるアトムによって名前が付けられたプロパティ"WM_NAME") は、ウィンドウの名前を格納するために使用されます。ウィンドウ マネージャーは通常、このプロパティを読み取って、タイトル バーにウィンドウの名前を表示します。

一部のクライアント間通信では、ルートウィンドウのプロパティが使用されます。たとえば、freedesktopウィンドウマネージャ仕様^{[10]によれば、ウィンドウマネージャは現在}アクティブなウィンドウの識別子をルートウィンドウのプロパティに格納する必要があります_NET_ACTIVE_WINDOW。プログラムのパラメータを含むXリソースもルートウィンドウのプロパティに格納されます。これにより、異なるコンピュータで実行されている場合でも、すべてのクライアントがそれらにアクセスできます。

プログラムxpropは、指定されたウィンドウのプロパティを出力します。xprop -rootルート ウィンドウの各プロパティの名前、タイプ、および値を出力します。

X Window System では、すべての物理キーに 8 ～ 255 の範囲の番号が関連付けられています。この番号はキーコードと呼ばれます。キーコードはキーのみを識別し、キーに印刷されている文字や用語 (「Page Up」など) を識別するものではありません。これらの文字や用語はそれぞれ、キーシムによって識別されます。キーコードは実際に押されたキーのみに依存しますが、キーシムは、たとえば、Shift キーまたは別の修飾キーも押されたかどうかに依存する場合があります。

キーが押されたり放されたりすると、サーバーはKeyPressまたはタイプのイベントをKeyRelease適切なクライアントに送信します。これらのイベントには次のものが含まれます。

1. 押されたキーのキーコード
2. 修飾キー（Shift、Controlなど）とマウスボタンの現在の状態

したがって、サーバーはキーコードと修飾子の状態を特定の文字に変換せずに送信します。この変換を行うのはクライアントの責任です。たとえば、Shift キーが押されているときに特定のキーが押されたことを示すイベントをクライアントが受信するとします。このキーが通常文字「a」を生成する場合、(サーバーではなく) クライアントがこのイベントを文字「A」に関連付けます。

キーコードからキーシムへの変換はクライアントによって行われますが、この関連付けを表すテーブルはサーバーによって管理されます。このテーブルを一元的な場所に保存すると、すべてのクライアントがアクセスできるようになります。一般的なクライアントは、このマッピングのみを要求し、キーイベントのキーコードと修飾子フィールドをキーシムにデコードするために使用します。ただし、クライアントは自由にこのマッピングを変更することもできます。

修飾子とは、押すと他のキーの解釈が変わるキーのことです。一般的な修飾子はShift キーです。通常小文字の「a」を生成するキーを Shift キーと一緒に押すと、大文字の「A」が生成されます。その他の一般的な修飾子は、「Control」、「Alt」、「Meta」です。

X サーバーは最大 8 つの修飾子で動作します。ただし、各修飾子は複数のキーに関連付けることができます。これは、多くのキーボードで一部の修飾子のキーが重複しているために必要です。たとえば、多くのキーボードには 2 つの「Shift」キーがあります (1 つは左に、もう 1 つは右にあります)。これらの 2 つのキーを押すと、2 つの異なるキーコードが生成されますが、X サーバーは両方を「Shift」修飾子に関連付けます。

8 つの修飾子それぞれについて、X サーバーはその修飾子であるとみなすキーコードのリストを保持します。たとえば、最初の修飾子 (「Shift」修飾子) のリストにキーコードが含まれている場合0x37、キーコードを生成するキーは0x37X サーバーによってシフト キーとみなされます。

修飾子マッピングのリストは X サーバーによって管理されますが、すべてのクライアントによって変更できます。たとえば、クライアントは「F1 キー」を「Shift」修飾子のリストに追加するように要求できます。この時点から、このキーは別のシフト修飾子のように動作します。ただし、このキーが押されると、F1 に対応するキーコードが引き続き生成されます。その結果、F1 は以前と同じように動作します (たとえば、押すとヘルプ ウィンドウが開きます) が、シフト キーのようにも動作します (F1 を押しながらテキスト エディターで「a」を押すと、現在のテキストに「A」が追加されます)。

X サーバーは、マウス ボタンの修飾子マッピングを維持および使用します。ただし、ボタンは並べ替えることしかできません。これは、左利きのユーザー のために、左端のボタンと右端のボタンを交換する場合に最も便利です。

プログラムxmodmapは、キー、修飾子、およびマウス ボタンのマッピングを表示および変更します。

グラブとは、すべてのキーボードまたはマウス イベントが 1 つのクライアントに送信される状態です。クライアントはキーボード、マウス、またはその両方のグラブを要求できます。サーバーによって要求が満たされると、グラブが解放されるまで、すべてのキーボード/マウス イベントがグラブしているクライアントに送信されます。他のクライアントはこれらのイベントを受信しません。

グラブを要求するとき、クライアントはグラブ ウィンドウを指定します。すべてのイベントは、グラブ ウィンドウに関連しているかのように、グラブしているクライアントに送信されます。ただし、他のクライアントは、グラブ ウィンドウでイベントを選択しても、イベントを受信しません。グラブには 2 種類あります。

• アクティブ:グラブはすぐに実行されます
• パッシブ:グラブは、事前に指定されたキーまたはマウスボタンが押されたときにのみ実行され、放されると終了します。

クライアントは、キーボード、ポインター、またはその両方をグラブできます。グラブの要求には、キーボードまたはポインターをフリーズする要求が含まれる場合があります。グラブとフリーズの違いは、グラブではイベントの受信者が変更されるのに対し、フリーズではイベントの配信が完全に停止されることです。デバイスがフリーズされると、デバイスが生成したイベントはキューに保存され、フリーズが終わると通常どおり配信されます。

ポインター イベントの場合、追加のパラメーターがイベントの配信に影響します。イベント マスクは、配信するイベントの種類と破棄するイベントの種類を指定します。

グラブの要求には、グラブを確立していない場合でもグラブ クライアントに送信されるイベントの処理を指定するフィールドが含まれています。特に、クライアントは、イベントを通常どおりに送信するか、グラブに従って送信するかを要求できます。これらの 2 つの条件は、見た目ほど同じではありません。たとえば、通常は最初のウィンドウでキーボード イベントを受信するクライアントは、2 番目のウィンドウでキーボードをグラブするように要求する場合があります。通常は最初のウィンドウに送信されるイベントは、グラブ要求のパラメータに応じて、グラブ ウィンドウにリダイレクトされる場合とされない場合があります。

クライアントは、サーバー全体の取得を要求することもできます。この場合、取得するクライアントからの要求以外は、サーバーによって処理されません。

コア プロトコルには、他の要求とイベントも存在します。最初の種類の要求は、ウィンドウ間の親関係に関連するものです。クライアントは、ウィンドウの親を変更するように要求したり、ウィンドウの親子関係に関する情報を要求したりできます。他の要求は選択に関連していますが、これは主に他のプロトコルによって制御されます。他の要求は、入力フォーカスとポインターの形状に関するものです。クライアントは、リソース (ウィンドウ、ピクセル マップなど) の所有者を強制終了するように要求することもできます。これにより、サーバーは接続を終了します。最後に、クライアントはサーバーに 無操作要求を送信できます。

X ウィンドウ コア プロトコルは拡張可能になるように設計されています。コア プロトコルは、利用可能な拡張機能を照会するメカニズムと、拡張機能の要求、イベント、およびエラー パケットの作成方法を指定します。

特に、クライアントは、特定の拡張機能に関連するデータに使用可能なすべての拡張機能のリストを要求できます。拡張機能のパケットは、コア プロトコルのパケットに似ています。コア プロトコルでは、要求、イベント、およびエラー パケットにそのタイプを示す整数が含まれるように指定されています (たとえば、新しいウィンドウを作成する要求には 1 という番号が付けられます)。これらの整数の範囲は拡張機能用に予約されています。

クライアントが最初にサーバーとの接続を確立すると、サーバーは接続を受け入れるか、接続を拒否するか、認証を要求するかのいずれかで応答できます。認証要求には、使用する認証方法の名前が含まれます。コア プロトコルでは、サーバーが受け入れパケットまたは拒否パケットを送信することで終了すること以外は、使用される認証の種類によって異なる認証プロセスは指定されません。

クライアントとサーバー間の通常のやり取りでは、認証に関連する要求はホスト ベースのアクセス メソッドに関するものだけです。特に、クライアントはこのメソッドを有効にするように要求したり、接続を許可されているホスト (クライアント) のリストの読み取りと変更を要求したりできます。一般的なアプリケーションではこれらの要求は使用されません。プログラムによって、xhostユーザーまたはスクリプトにホスト アクセス リストへのアクセス権を付与するために使用されます。ホスト ベースのアクセス メソッドは安全ではないと考えられています。

ほとんどのクライアント プログラムは、 Xlibクライアント ライブラリを介してサーバーと通信します。特に、ほとんどのクライアントは、サーバーとのやり取りに Xlib を使用するXaw、Motif、GTK+、Qtなどのライブラリを使用します。Xlib を使用すると、次のような効果があります。

1. Xlib は、応答とイベントに関してクライアントを同期させます。
   1. 要求を送信する Xlib 関数は、適切な応答 (必要な場合) が受信されるまでブロックされます。つまり、Xlib を使用しない X ウィンドウ クライアントはサーバーに要求を送信し、応答を待つ間に他の操作を行うことができますが、Xlib を使用するクライアントは、要求を送信して応答を待つ Xlib 関数を呼び出すことしかできず、応答を待つ間クライアントはブロックされます (クライアントが関数を呼び出す前に新しいスレッドを開始しない限り)。
   2. サーバーは非同期的にイベントを送信しますが、Xlib はクライアントが受信したイベントをキューに格納します。クライアント プログラムは、X11 ライブラリの関数を明示的に呼び出すことによってのみ、それらのイベントにアクセスできます。つまり、クライアントはイベントを期待している場合、ブロックまたはビジー待機を強制されます。
2. Xlib はリクエストをすぐにサーバーに送信せず、出力バッファと呼ばれるキューに保存します。出力バッファ内のリクエストは、次の場合に実際に送信されます。
   1. プログラムは、次のようなライブラリ関数を呼び出して明示的に要求しますXFlush。
   2. プログラムは、次のようなサーバーからの応答を含む結果を結果として返す関数を呼び出しますXGetWindowAttributes。
   3. プログラムはイベント キュー内のイベントを要求し (たとえば、 を呼び出すことによって XNextEvent)、呼び出しはブロックします (たとえば、XNextEventキュ​​ーが空の場合、 はブロックします)。

Xtなどの高レベル ライブラリ( XawおよびMotifによって使用される) を使用すると、クライアント プログラムで一部のイベントに関連付けられたコールバック関数を指定できます。ライブラリはイベント キューをポーリングし、必要に応じて適切な関数を呼び出します。ウィンドウの再描画が必要であることを示すイベントなどの一部のイベントは、Xt によって内部的に処理されます。

XCBなどの下位レベルのライブラリは、プロトコルへの非同期アクセスを提供し、レイテンシをより適切に隠蔽します。

X Window Systemコアプロトコルはクライアント間通信を義務付けておらず、グラフィカルユーザーインターフェースで一般的な視覚要素（ボタン、メニューなど）を形成するためにウィンドウがどのように使用されるかを指定していません。グラフィカルユーザーインターフェース要素は、ウィジェットツールキットを実現するクライアントライブラリによって定義されます。クライアント間通信は、 ICCCMやフリーデスクトップ仕様などの他の標準によってカバーされています。^[10]

クライアント間通信は、選択、カット バッファ、ドラッグ アンド ドロップなど、ユーザーがウィンドウから別のウィンドウにデータを転送するために使用する方法に関係します。ウィンドウはさまざまなプログラムによって制御される可能性があるため、このデータを交換するためのプロトコルが必要です。クライアント間通信は、ウィンドウの外観とグラフィカル ユーザー インターフェイスの 一般的な外観と操作感を制御するプログラムであるX ウィンドウ マネージャーにも関係します。

クライアント間通信がある程度関連するもう 1 つの問題は、セッション管理の問題です。

ユーザー セッションの開始方法は、コア プロトコルではカバーされていない別の問題です。通常、これはX ディスプレイ マネージャーによって自動的に行われます。ただし、ユーザーはxinitまたはstartxプログラムを実行して手動でセッションを開始することもできます。

• X Window System のプロトコルとアーキテクチャ
• Xlib
• 本質的
• XneeはX Window Systemプロトコルをスニッフィングするために使用できます

• X.Org Foundation (公式ホームページ) - ドメイン名「freedesktop.org」のミラー。
• X ウィンドウ システムの内部
• Kenton Lee の X Window と Motif に関するページは、2013 年 5 月 20 日にWayback Machineにアーカイブされました。
• X ウィンドウ システム プロトコル、バージョン 11 (現在のリリース)