Loading article…
X Window System コア プロトコル[ 1 ] [ 2 ] [ 3 ]は、 Unix、Unix ライク、およびその他のオペレーティングシステム上でグラフィカル ユーザー インターフェイスを構築するために使用されるビットマップディスプレイ用のネットワークウィンドウ システムである X Window System の基本プロトコルです。X Window System はクライアント サーバー モデルに基づいています。単一のサーバーが、画面、キーボード、マウスなどの入出力ハードウェアを制御します。すべてのアプリケーションプログラムはクライアントとして動作し、サーバーを介してユーザーや他のクライアントとやり取りします。このやり取りは、X Window System コア プロトコルによって制御されます。X Window System に関連する他のプロトコルも存在し、それらは X Window System コア プロトコルの上に構築されたものと、独立したプロトコルの両方があります。
X Window System のコア プロトコルでは、ネットワーク上で非同期的に送信されるパケットは、リクエスト、レスポンス、イベント、エラーの 4 種類のみです。リクエストは、クライアントがサーバーに何らかの操作 (たとえば、新しいウィンドウの作成) を実行し、保持しているデータを返送するように要求するために送信されます。レスポンスは、サーバーがそのようなデータを提供するために送信されます。イベントは、サーバーがクライアントにユーザーのアクティビティや関心のあるその他の事象を通知するために送信されます。エラーは、サーバーがクライアントのリクエストの処理中に発生したエラーを通知するために送信するパケットです。リクエストはレスポンス、イベント、エラーを生成する可能性があります。これ以外に、プロトコルはネットワーク上でパケットが送信される特定の順序を規定していません。コア プロトコルにはいくつかの拡張機能が存在し、それぞれが独自のリクエスト、レスポンス、イベント、エラーを持っています。
Xは1984年にMITで誕生しました（現在のX11 リリースは 1987 年 9 月に登場しました。設計者のBob ScheiflerとJim Gettys は、コア プロトコルの原則として「ポリシーではなくメカニズムを作成する」ことを定めました。その結果、コア プロトコルはクライアント間およびクライアントとユーザー間のインタラクションを規定していません。これらのインタラクションは、ICCCMやfreedesktop.org仕様などの別の仕様[ 4 ]の対象であり、通常は特定のウィジェット セットを使用することで自動的に強制されます。
サーバーとクライアント間の通信は、チャネルを介してパケットを交換することによって行われます。接続はクライアントによって確立されます（クライアントの起動方法はプロトコルでは規定されていません）。クライアントは、使用するバイト順序、プロトコルのバージョン、およびクライアントがサーバーに期待する認証の種類に関する情報を含む最初のパケットも送信します。サーバーは、接続の承認または拒否を示すパケット、あるいは追加の認証を要求するパケットを返信することで応答します。接続が承認された場合、承認パケットには、クライアントがサーバーとのその後のやり取りで使用するデータが含まれます。
接続が確立されると、クライアントとサーバー間でチャネルを介して4種類のパケットが交換されます。
リクエストパケットとレスポンスパケットの長さは様々ですが、イベントパケットとエラーパケットの長さは32バイトに固定されています。
サーバーはリクエストパケットを受信するとすぐに、それらを順番に番号付けします。クライアントからの最初のリクエストは1、2番目は2、といった具合です。リクエストの連番の最下位16ビットは、リクエストによって生成された応答パケットおよびエラーパケット（存在する場合）に含まれます。また、サーバーが現在処理中または処理を完了したリクエストの連番を示すために、イベントパケットにも含まれます。
ほとんどのグラフィカルユーザーインターフェースで一般的に「ウィンドウ」と呼ばれるものは、X Window Systemでは「トップレベルウィンドウ」と呼ばれます。「ウィンドウ」という用語は、別のウィンドウ内に存在するウィンドウ、つまり親ウィンドウのサブウィンドウを指す場合にも使用されます。ボタン、メニュー、アイコンなどのグラフィック要素は、サブウィンドウを使用して実現できます。
クライアントはウィンドウの作成を要求できます。より正確には、既存のウィンドウのサブウィンドウの作成を要求できます。結果として、クライアントによって作成されたウィンドウはツリー構造（階層構造）に配置されます。このツリーのルートはルートウィンドウであり、これはサーバーが起動時に自動的に作成する特別なウィンドウです。他のすべてのウィンドウは、直接的または間接的にルートウィンドウのサブウィンドウです。最上位のウィンドウは、ルートウィンドウの直接のサブウィンドウです。ルートウィンドウは、仮想デスクトップと同じ大きさで、他のすべてのウィンドウの背後に表示されます。
ウィンドウの内容は、常に時間とともに保持されるとは限りません。特に、ウィンドウが移動、サイズ変更、他のウィンドウに覆われたり、一般的に完全にまたは部分的に非表示になったりすると、ウィンドウの内容が失われる可能性があります。特に、X サーバーがウィンドウの内容のバックアップ ストアを保持していない場合、内容は失われます。クライアントはウィンドウのバックアップ ストアの保持を要求できますが、サーバーにはそうする義務はありません。したがって、クライアントはバックアップ ストアが保持されていると想定することはできません。ウィンドウの表示部分に未指定の内容がある場合、ウィンドウの内容を再描画する必要があることをクライアントに通知するイベントが送信されます。
各ウィンドウには、ウィンドウの形状（サイズと位置）、背景画像、バックストレージが要求されているかどうかなど、一連の属性が関連付けられています。プロトコルには、クライアントがウィンドウの属性を検査および変更するための要求が含まれています。
ウィンドウは、InputOutputまたは のいずれかですInputOnly。InputOutputウィンドウは画面に表示され、描画に使用されます。InputOnlyウィンドウは画面には表示されず、入力を受け取るためだけに使用されます。
ウィンドウの周囲によく見られる装飾的なフレームやタイトルバー（ボタンを含む場合もある）は、ウィンドウを作成したクライアントではなく、ウィンドウマネージャによって作成されます。ウィンドウマネージャは、ユーザーがウィンドウフレームをクリックしてドラッグしたときのウィンドウのサイズ変更など、これらの要素に関連する入力も処理します。クライアントは通常、ウィンドウマネージャによって行われた変更を無視して、自身が作成したウィンドウを操作します。クライアントが考慮しなければならない変更点の1つは、ほとんどすべての最新のウィンドウマネージャが採用している親子関係の変更です。この場合、トップレベルウィンドウの親はルートウィンドウではないウィンドウに変更されます。コアプロトコルの観点から見ると、ウィンドウマネージャは他のアプリケーションと何ら変わりないクライアントです。
このプログラムを実行すると、ウィンドウに関するデータを取得できます。コマンドライン引数xwininfoを渡すと、このプログラムはウィンドウのサブウィンドウのツリー構造と、それらの識別子およびジオメトリデータを表示します。-tree
ピクスマップとは、描画に使用できるメモリ領域のことです。ウィンドウとは異なり、ピクスマップは自動的に画面に表示されるわけではありません。しかし、ピクスマップの内容（またはその一部）をウィンドウに転送したり、その逆も可能です。これにより、ダブルバッファリングなどの技術が実現できます。ウィンドウ上で実行できるグラフィック操作のほとんどは、ピクスマップ上でも実行できます。
ウィンドウとピクスマップはまとめてドローアブルと呼ばれ、そのコンテンツデータはサーバー上に保存されます。ただし、クライアントはドローアブルのコンテンツをサーバーからクライアントへ、またはその逆方向に転送するよう要求できます。
クライアントは、領域のクリア、領域のコピー、点、線、長方形、テキストの描画など、さまざまなグラフィック操作を要求できます。クリア以外のすべての操作は、ウィンドウとピクスマップの両方を含むすべての描画対象に対して可能です。
グラフィック操作のリクエストのほとんどは、グラフィックコンテキストと呼ばれる構造体を含みます。この構造体には、グラフィック操作のパラメータが含まれます。グラフィックコンテキストには、前景色、背景色、テキストのフォント、その他のグラフィックパラメータが含まれます。クライアントは、グラフィック操作をリクエストする際に、このグラフィックコンテキストを含めます。グラフィックコンテキストのすべてのパラメータが操作に影響を与えるわけではありません。例えば、フォントは線の描画には影響しません。
コアプロトコルでは、サーバー側フォントの使用が規定されています。これらのフォントはファイルとして保存され、サーバーはローカルファイルシステムを介して直接アクセスするか、フォントサーバーと呼ばれる別のプログラムからネットワーク経由でアクセスします。クライアントは、サーバーで使用可能なフォントのリストを要求したり、サーバーにフォントの読み込み（まだ読み込まれていない場合）またはアンロード（他のクライアントで使用されていない場合）を要求したりできます。クライアントは、フォントに関する一般的な情報（例えば、フォントのアセント）や、特定のフォントで描画された特定の文字列が占めるスペースを要求できます。
xfontselプログラムを使用すると、フォントのグリフを表示できます。フォント名は、X コア プロトコルのレベルでは任意の文字列です。X論理フォント記述規則[ 5 ]は、フォントの属性に応じてフォントに名前を付ける方法を規定しています。これらの規則は、フォントに付加できるオプション プロパティの値も規定しています。
このxlsfontsプログラムは、サーバーに保存されているフォントの一覧を表示します。xfontselまた、フォントのグリフを表示し、ユーザーがフォント名を選択して別のウィンドウに貼り付けることができるようにします。
サーバー側フォントの使用は現在、クライアント側フォントの使用が推奨されているため、非推奨とみなされています。[ 6 ]このようなフォントは、 XftまたはcairoライブラリとXRender拡張機能のサポートにより、サーバーではなくクライアントによってレンダリングされます。コア プロトコルには、クライアント側フォントに関する仕様は記載されていません。
ウィンドウ、ピクスマップ、フォントなどに関するすべてのデータはサーバーに保存されます。クライアントはこれらのオブジェクトの識別子（サーバーとのやり取りで名前として使用する整数）を知っています。たとえば、クライアントがウィンドウを作成したい場合、指定された識別子を持つウィンドウを作成するようにサーバーに要求します。この識別子は、後でクライアントがたとえばウィンドウに文字列を描画するように要求するために使用できます。以下のオブジェクトはサーバーに存在し、クライアントは数値識別子を介して認識します。
WindowPixmapFontColormap（下記に色の一覧表を掲載）Graphic contextこれらのオブジェクトはリソースと呼ばれます。クライアントがこのようなリソースの作成を要求する際には、そのリソースの識別子も指定します。例えば、新しいウィンドウを作成する場合、クライアントはウィンドウの属性（親ウィンドウ、幅、高さなど）と、ウィンドウに関連付ける識別子の両方を指定します。
識別子は、上位3ビットがゼロの32ビット整数です。各クライアントは、新しいリソースを作成するために使用できる独自の識別子セットを持っています。このセットは、サーバーが接続承認パケット（接続が受け入れられたことをクライアントに通知するために送信するパケット）に含まれる2つの整数として指定されます。クライアントは、このセット内の識別子を、競合しないように選択します。つまり、ウィンドウ、ピクスマップ、フォント、カラーマップ、グラフィックコンテキストなどの2つのオブジェクトが同じ識別子を持つことはできません。
リソースが作成されると、クライアントはその識別子を使用して、サーバーに対してリソースに関する操作を要求します。一部の操作は、指定されたリソースに直接影響を与えます（たとえば、ウィンドウの移動要求）。その他の操作は、サーバーに保存されているリソースデータを取得します（たとえば、ウィンドウの属性の要求）。
識別子はクライアントだけでなくサーバーにも固有です。例えば、異なるクライアントによって作成されたウィンドウであっても、同じ識別子を持つウィンドウは存在しません。クライアントは、自身の識別子が与えられれば、あらゆるオブジェクトにアクセスできます。特に、他のクライアントが作成したリソースにもアクセスでき、そのリソースの識別子がクライアントが作成できる識別子の範囲外であってもアクセス可能です。
その結果、同じサーバーに接続された 2 つのクライアントが同じ識別子を使用して同じリソースを参照できるようになります。たとえば、クライアントが識別子のウィンドウを作成し0x1e00021、この番号を0x1e00021別のアプリケーションに渡す場合 (たとえば、この番号を別のアプリケーションからもアクセス可能なファイルに保存するなど、利用可能なあらゆる手段を使用)、この別のアプリケーションはまさに同じウィンドウを操作できます。この機能は、たとえばGhostviewの X バージョンで利用されています。このプログラムはサブウィンドウを作成し、その識別子を環境変数に保存し、Ghostscriptを呼び出します。このプログラムは、 PostScriptファイルの内容を描画してこのウィンドウに表示します。[ 7 ]
リソースは通常、それを作成したクライアントがサーバーとの接続を閉じると破棄されます。ただし、クライアントは接続を閉じる前に、サーバーに対してリソースを破棄しないよう要求することができます。
イベントとは、サーバーがクライアントに送信するパケットであり、クライアントが関心を持つ可能性のある何らかの事象が発生したことを通知するものです。例えば、ユーザーがキーを押したり、マウスボタンをクリックしたりしたときにイベントが送信されます。イベントは入力のためだけに用いられるわけではありません。例えば、特定のウィンドウに新しいサブウィンドウが作成されたことを示すためにもイベントが送信されます。
すべてのイベントはウィンドウを基準としています。例えば、ユーザーがポインターがウィンドウ内にある状態でクリックした場合、イベントはそのウィンドウを基準とします。イベントパケットには、そのウィンドウの識別子が含まれています。
クライアントは、サーバーに対して別のクライアントにイベントを送信するよう要求できます。これは、クライアント間の通信に使用されます。例えば、クライアントが現在選択されているテキストを要求した場合、このようなイベントが生成されます。このイベントは、現在選択されているテキストを保持しているウィンドウを処理しているクライアントに送信されます。
このExposeイベントは、ウィンドウの一部が破棄され、コンテンツが表示されるようになったときに送信されます。ウィンドウのコンテンツは、例えばウィンドウが覆われていて、サーバーがバックアップストアを保持していない場合など、特定の条件下で破棄されることがあります。サーバーは、Exposeウィンドウの一部を描画する必要があることをクライアントに通知するためにイベントを生成します。
ほとんどの種類のイベントは、クライアントが事前に関心を示した場合にのみ送信されます。これは、クライアントが特定の種類のイベントにのみ関心を持つ可能性があるためです。たとえば、クライアントはキーボード関連のイベントには関心があっても、マウス関連のイベントには関心がない場合があります。ただし、一部の種類のイベントは、クライアントが明示的に要求していなくても送信されます。
クライアントは、ウィンドウの属性を設定することで、送信したいイベントの種類を指定します。たとえば、ウィンドウの内容が破棄されたときにウィンドウを再描画するには、Exposeウィンドウを再描画する必要があることをクライアントに通知するイベントを受信する必要があります。ただし、クライアントが事前にこれらのイベントに関心があることを表明している場合にのみ、クライアントにイベントが送信されます。これは、ウィンドウのイベントマスクExpose属性を適切に設定することで行われます。
異なるクライアントが同じウィンドウに対してイベントを要求することができます。さらに、同じウィンドウに対して異なるイベントマスクを設定することも可能です。例えば、あるクライアントはウィンドウ上でキーボードイベントのみを要求し、別のクライアントは同じウィンドウ上でマウスイベントのみを要求するといったことが可能です。これは、サーバーが各ウィンドウごとにクライアントごとに個別のイベントマスクを保持しているためです。ただし、各ウィンドウに対して一度に1つのクライアントしか選択できないイベントもいくつか存在します。具体的には、マウスボタンのクリックやウィンドウ管理に関連する変更を報告するイベントなどがこれに該当します。
このxevプログラムは、指定されたウィンドウに関連するイベントを表示します。具体的には、xev -id WID識別子で指定されたウィンドウに関連するすべての可能なイベントを要求しWID、それらを出力します。
以下は、サーバーと、黒いボックスを含むウィンドウを作成し、キーを押すと終了するプログラムとの間のやり取りの一例です。この例では、クライアントからのリクエストに対して応答が生成されないため、サーバーは応答を送信しません。これらのリクエストはエラーを発生させる可能性があります。
0x0000002b：）やクライアントが作成できる識別子などの他の情報が含まれています。0x00200000（この要求は、この例の他の要求と同様に、サーバーからの応答を生成しません）。0x0000002bクライアントはサーバーに、識別子0x00200001、サイズ 200x200、位置 (10,10) などを持つトップレベルウィンドウ (つまり、親をルートウィンドウとして指定) を作成するように要求します。0x00200001、イベントExposeの受信に関心があることを指定しますKeyPress。0x00200001をマッピング（画面上に表示）するよう要求します。Exposeイベントを送信します。PolyFillRectangleこのイベントに対応して、クライアントはウィンドウ0x00200001とグラフィックコンテキストを含むリクエストを送信してボックスを描画するように要求します。0x00200000ウィンドウが別のウィンドウで覆われ、再び覆われなくなった場合、バックストアが維持されていないと仮定します。
Exposeウィンドウを再描画する必要があることをクライアントに伝えるために、別のイベントを送信します。PolyFillRectangleクライアントはリクエストを送信してウィンドウを再描画しますキーが押された場合：
KeyPressユーザーがキーを押したことをクライアントに通知するイベントを送信します。プロトコルレベルでは、色はピクセル値と呼ばれる32ビット符号なし整数で表されます。色の表現には、以下の要素が影響します。
最も簡単なケースでは、カラーマップは各行にRGBトリプルを含むテーブルです。ピクセル値は、テーブルの 番目の行xに含まれる色を表します。クライアントがカラーマップのエントリを変更できる場合、この表現はビジュアルクラスで識別されます。ビジュアルクラスは似ていますが、クライアントはカラーマップのエントリを変更できません。xPseudoColorStaticColor
視覚クラスは全部で 6 つあり、それぞれが RGB トリプルをピクセル値で表現する異なる方法を識別します。PseudoColorとStaticColorはその 2 つです。他の 2 つはGrayScaleと でStaticGray、これらはグレーの濃淡のみを表示するという点で異なります。
残りの2つの視覚クラスは、ピクセル値を3つの部分に分割し、赤、緑、青の強度にそれぞれ別のテーブルを使用する点で、上記のクラスとは異なります。この色表現によれば、ピクセル値は次のようにRGBトリプルに変換されます。
このメカニズムでは、カラーマップは3つの別々のテーブル（各原色につき1つ）で構成される必要があります。変換結果は依然として強度値の3つ組です。この表現を使用するビジュアルクラスは、とでありDirectColor、TrueColorクライアントがカラーマップを変更できるかどうかで異なります。
色をピクセル値で表現するこれら6つのメカニズムはすべて、動作するためにいくつかの追加パラメータを必要とします。これらのパラメータはビジュアルタイプにまとめられ、ビジュアルクラスと色の表現に関するその他のパラメータが含まれます。各サーバーには固定されたビジュアルタイプのセットがあり、それぞれが数値識別子に関連付けられています。これらの識別子は32ビット符号なし整数ですが、リソースやアトムの識別子と必ずしも異なるとは限りません。
クライアントからの接続が受け入れられると、サーバーから送信される受け入れパケットには、それぞれが単一の画面に関する情報を含む一連のブロックが含まれます。各画面について、対応するブロックには、その画面がサポートする特定の色深度に関連する他のブロックのリストが含まれます。サポートされている各色深度について、このリストにはビジュアルタイプのリストが含まれます。結果として、各画面には複数の色深度が関連付けられ、各画面の各色深度には複数のビジュアルタイプが関連付けられます。特定のビジュアルタイプは、複数の画面や異なる色深度で使用できます。
各ビジュアルタイプについて、受信パケットにはその識別子と実際のパラメータ（ビジュアルクラスなど）の両方が含まれます。クライアントはこの情報を後で要求できないため、保存します。さらに、クライアントはビジュアルタイプを変更したり、新しいビジュアルタイプを作成したりすることはできません。新しいウィンドウの作成要求には、深度と、そのウィンドウの色を表現するために使用するビジュアルタイプの識別子が含まれます。
カラーマップは、画面を制御するハードウェア（グラフィックカードなど）がパレット（色を表すテーブル）を使用しているかどうかに関係なく使用されます。サーバーは、ハードウェアがパレットを使用していない場合でもカラーマップを使用します。ハードウェアがパレットを使用する場合、インストールできるカラーマップの数は限られています。具体的には、ハードウェアがカラーマップに従って色を表示する場合にカラーマップがインストールされます。クライアントはサーバーにカラーマップのインストールを要求できます。ただし、これには別のカラーマップのアンインストールが必要になる場合があります。その結果、アンインストールされたカラーマップを使用しているウィンドウは正しい色で表示されず、この現象はカラーフラッシングまたはテクニカラーと呼ばれます。この問題は、ピクセル値と色の間に予測可能な関連付けがある標準カラーマップを使用することで解決できます。この特性のおかげで、標準カラーマップはさまざまなアプリケーションで使用できます。
カラーマップの作成は、ICCCM規約によって規定されています。標準カラーマップは、ICCCMおよびXlib仕様によって規定されています。
Xカラーシステムの一部に、Xカラーマネジメントシステム（xcms）があります。このシステムは、1991年にX11R6リリース5で導入されました。このシステムは、xlibのXcms*関数シリーズに含まれるいくつかの追加機能で構成されています。このシステムは、デバイス非依存のカラースキームを定義し、これをデバイス依存のRGBシステムに変換できます。このシステムは、xlibのXcms*関数と、さまざまなデバイス非依存のカラーシステムをデバイス依存のRGBカラーシステムに変換する方法を記述したXデバイスカラー特性規約（XDCCC）で構成されています。このシステムは、CIEXYZ、xyY、CIELUV、CIELAB 、およびTekHVCカラーシステムをサポートしています。 Wayback Machineに2011年10月5日にアーカイブされました。
アトムは文字列を表す 32 ビット整数です。プロトコル設計者は、文字列を短く固定されたサイズで表現できるという理由でアトムを導入しました。 [ 8 ]文字列は任意の長さにすることができますが、アトムは常に 32 ビット整数です。アトムの簡潔さは、同じ文字列で何度も送信される可能性のあるパケットでの使用を義務付けることで活用され、ネットワークのより効率的な使用につながりました。アトムの固定サイズは、イベントのサイズを 32 バイトに固定することで活用されました。固定サイズのパケットにはアトムを含めることができますが、長い文字列を含めることはできません。
正確に言うと、アトムとはサーバーに保存される文字列の識別子です。リソース（ウィンドウ、ピクセルマップなど）の識別子と似ていますが、2つの点で異なります。まず、アトムの識別子はクライアントではなくサーバーによって選択されます。つまり、クライアントが新しいアトムの作成を要求する場合、サーバーには保存する文字列のみを送信し、識別子は送信しません。この識別子はサーバーによって選択され、クライアントへの応答として返されます。リソースとアトムの2つ目の重要な違いは、アトムはクライアントに関連付けられていないことです。一度作成されたアトムは、サーバーが終了またはリセットされるまで存続します（これはリソースのデフォルトの動作ではありません）。
アトムは識別子であり、一意です。ただし、アトムとリソース識別子は一致する場合があります。アトムに関連付けられた文字列はアトム名と呼ばれます。アトム名は作成後に変更できず、2つのアトムが同じ名前を持つことはできません。そのため、アトム名は一般的にアトムを示すために使用されます。「アトムABCD」とは、より正確には「関連付けられた文字列がであるアトムABCD」または「名前がであるアトムABCD」を意味します。クライアントは新しいアトムの作成を要求したり、指定された文字列のアトム（識別子）を要求したりできます。一部のアトムは事前に定義されています（指定された識別子と文字列でサーバーによって作成されます）。
アトムは様々な用途に使用されますが、そのほとんどは同一サーバーに接続された複数のクライアント間の通信に関連しています。特に、アトムはウィンドウのプロパティと連携して使用され、そのプロパティについては後述します。
このプログラムを使用すると、サーバーに存在するすべての原子のリストを出力できますxlsatoms。具体的には、このプログラムは各原子（識別子、つまり番号）とその名前（関連付けられた文字列）を出力します。
すべてのウィンドウには、あらかじめ定義された属性セットとプロパティセットがあり、これらはすべてサーバーに保存され、適切なリクエストを介してクライアントからアクセスできます。属性は、ウィンドウのサイズ、位置、背景色など、ウィンドウに関するデータです。プロパティは、ウィンドウに付加される任意のデータです。属性とは異なり、プロパティはXコアプロトコルのレベルでは意味を持ちません。クライアントは、ウィンドウのプロパティに任意のデータを格納できます。
プロパティは、名前、型、値によって特徴付けられます。プロパティは、命令型プログラミング言語の変数に似ており、クライアントは指定された名前と型を持つ新しいプロパティを作成し、そこに値を格納できます。プロパティはウィンドウに関連付けられます。同じ名前のプロパティでも、型と値が異なる場合は、異なるウィンドウ上に存在できます。
プロパティの名前、型、値は文字列です。より正確には、これらはアトム、つまりサーバーに格納され、識別子を介してクライアントからアクセスできる文字列です。クライアントアプリケーションは、プロパティ名を含むアトムの識別子を使用することで、特定のプロパティにアクセスできます。
プロパティは主にクライアント間の通信に使用されます。たとえば、WM_NAME（関連付けられた文字列がであるアトムによって命名された"WM_NAME"）という名前のプロパティは、ウィンドウの名前を格納するために使用されます。ウィンドウマネージャは通常、このプロパティを読み取って、タイトルバーにウィンドウの名前を表示します。
クライアント間の通信の種類によっては、ルートウィンドウのプロパティを使用するものがあります。たとえば、freedesktopウィンドウマネージャの仕様[ 9 ]によれば、ウィンドウマネージャは現在アクティブなウィンドウの識別子を_NET_ACTIVE_WINDOWルートウィンドウのプロパティに格納する必要があります。プログラムのパラメータを含むX リソースもルートウィンドウのプロパティに格納されます。このようにして、異なるコンピュータで実行されている場合でも、すべてのクライアントがそれらにアクセスできます。
このxpropプログラムは、指定されたウィンドウのプロパティを表示します。xprop -rootルートウィンドウの各プロパティの名前、タイプ、および値を出力します。
/、、7およびは3 つの異なるキーシンボル{に関連付けられています。X Window Systemでは、個々の物理キーにはそれぞれ8～255の範囲の数値が割り当てられており、これをキーコードと呼びます。キーコードはキーを識別するだけで、キーに印字されている文字や用語（例：「Page Up」）を識別するものではありません。これらの文字や用語はそれぞれキーシンボルによって識別されます。キーコードは実際に押されたキーのみに依存しますが、キーシンボルは、例えばShiftキーや他の修飾キーが同時に押されたかどうかによっても異なります。
キーが押されたり離されたりすると、サーバーは適切なクライアントにKeyPressまたは型のイベントを送信します。これらのイベントには以下が含まれます。KeyRelease
そのため、サーバーはキーコードと修飾キーの状態を特定の文字に変換しようとせずに送信します。この変換を行うのはクライアントの責任です。たとえば、クライアントはShiftキーを押しながら特定のキーが押されたことを示すイベントを受け取る場合があります。このキーが通常「a」という文字を生成する場合、クライアント（サーバーではなく）はこのイベントを「A」という文字に関連付けます。
キーコードからキーシンボルへの変換はクライアント側で行われますが、この関連付けを表すテーブルはサーバー側で管理されます。このテーブルを中央集約型の場所に保存することで、すべてのクライアントがアクセスできるようになります。一般的なクライアントは、このマッピングを要求し、キーイベントのキーコードと修飾子フィールドをキーシンボルにデコードするためにのみ使用します。ただし、クライアントはこのマッピングを自由に変更することもできます。
修飾キーとは、押すと他のキーの解釈が変わるキーのことです。よく使われる修飾キーの1つはShiftキーです。通常小文字の「a」を入力するキーをShiftキーと一緒に押すと、大文字の「A」が入力されます。その他のよく使われる修飾キーには、「Control」、「Alt」、「Meta」などがあります。
Xサーバーは最大8つの修飾キーに対応しています。ただし、各修飾キーは複数のキーに関連付けることができます。これは、多くのキーボードで一部の修飾キーが重複しているためです。たとえば、多くのキーボードには「Shift」キーが2つ（左側と右側にそれぞれ1つずつ）あります。これらの2つのキーを押すと、それぞれ異なるキーコードが生成されますが、Xサーバーは両方を「Shift」修飾キーに関連付けます。
Xサーバーは、8つの修飾キーそれぞれについて、その修飾キーとみなされるキーコードのリストを保持しています。例えば、最初の修飾キー（「Shift」修飾キー）のリストにキーコードが含まれている場合0x37、そのキーコードを生成するキーは、0x37XサーバーによってShiftキーとみなされます。
修飾キーのマッピングリストはXサーバーによって管理されますが、各クライアントによって変更可能です。例えば、クライアントは「F1キー」を「Shift」修飾キーのリストに追加するように要求できます。この設定以降、F1キーは別のShift修飾キーのように動作します。ただし、F1キーが押されると、F1キーに対応するキーコードが生成されます。結果として、F1キーは以前と同様に動作します（例えば、押すとヘルプウィンドウが開くなど）。同時に、Shiftキーのように動作します（F1キーを押しながらテキストエディタで「a」を押すと、現在のテキストに「A」が追加されます）。
Xサーバーはマウスボタンの修飾キーマッピングを保持し、使用します。ただし、ボタンの配置は入れ替えのみ可能です。これは主に、左利きユーザーのために一番左のボタンと一番右のボタンを入れ替える場合に便利です。
このxmodmapプログラムは、キー、修飾キー、マウスボタンのマッピングを表示および変更します。
グラブとは、キーボードまたはマウスのすべてのイベントが単一のクライアントに送信される状態のことです。クライアントはキーボード、マウス、またはその両方のグラブを要求できます。サーバーがその要求に応じると、グラブが解除されるまで、すべてのキーボード/マウスイベントがグラブしているクライアントに送信されます。他のクライアントはこれらのイベントを受信しません。
グラブを要求する際、クライアントはグラブウィンドウを指定します。すべてのイベントは、グラブウィンドウを基準とした相対イベントとして、グラブを行うクライアントに送信されます。ただし、他のクライアントは、グラブウィンドウ内でイベントを選択していても、イベントを受信しません。グラブには次の2種類があります。
クライアントは、キーボード、ポインタ、またはその両方を占有することができます。占有要求には、キーボードまたはポインタのフリーズ要求を含めることができます。占有とフリーズの違いは、占有はイベントの受信者を変更するのに対し、フリーズはイベントの配信を完全に停止する点です。デバイスがフリーズされると、そのデバイスが生成するイベントはキューに格納され、フリーズが解除されたときに通常どおり配信されます。
ポインタイベントの場合、イベントの配信に影響を与える追加のパラメータとしてイベントマスクがあり、これは配信するイベントの種類と破棄するイベントの種類を指定します。
グラブ要求には、グラブが確立されていなくてもグラブクライアントに送信されるイベントの処理方法を指定するフィールドが含まれています。具体的には、クライアントはイベントを通常どおり送信するか、グラブに応じて送信するかを指定できます。これら2つの条件は、一見同じように見えますが、実際には異なります。例えば、通常は最初のウィンドウでキーボードイベントを受信するクライアントが、キーボードを2番目のウィンドウでグラブするように要求する場合があります。通常最初のウィンドウに送信されるイベントは、グラブ要求のパラメータに応じて、グラブウィンドウにリダイレクトされる場合とされない場合があります。
クライアントはサーバー全体のデータ取得を要求することもできます。この場合、サーバーはデータ取得を要求したクライアントからのリクエスト以外は一切処理しません。
コアプロトコルには、他にも様々なリクエストやイベントが存在します。まず、ウィンドウ間の親子関係に関するリクエストがあります。クライアントはウィンドウの親を変更するよう要求したり、ウィンドウの親子関係に関する情報を要求したりできます。次に、選択に関するリクエストがありますが、これは主に他のプロトコルによって制御されます。さらに、入力フォーカスやポインタの形状に関するリクエストもあります。クライアントは、リソース（ウィンドウ、ピクスマップなど）の所有者に対して強制終了を要求することもできます。これにより、サーバーはリソースとの接続を終了します。最後に、クライアントはサーバーに対して何もしないリクエストを送信することもできます。
Xコアプロトコルは拡張性を考慮して設計されています。コアプロトコルは、利用可能な拡張機能を照会するメカニズム、および拡張要求、イベント、エラーパケットの作成方法を規定しています。
特に、クライアントは特定の拡張機能に関連するデータに対して利用可能なすべての拡張機能のリストを要求できます。拡張機能のパケットは、コアプロトコルのパケットと似ています。コアプロトコルでは、要求、イベント、およびエラーパケットには、そのタイプを示す整数が含まれると規定されています（たとえば、新しいウィンドウを作成する要求には番号1が割り当てられます）。これらの整数の範囲は、拡張機能用に予約されています。
クライアントが最初にサーバーとの接続を確立すると、サーバーは接続を受け入れるか、拒否するか、認証を要求するかのいずれかで応答します。認証要求には、使用する認証方法の名前が含まれます。コアプロトコルは認証プロセスについては規定していません。認証プロセスは使用される認証方法によって異なりますが、サーバーが承認パケットまたは拒否パケットを送信することで終了します。
クライアントとサーバー間の通常のやり取りにおいて、認証に関連する要求はホストベースのアクセス方式に関するもののみです。具体的には、クライアントはこの方式の有効化を要求したり、接続を許可されたホスト（クライアントxhost）のリストの読み取りと変更を要求したりできます。一般的なアプリケーションではこれらの要求は使用されません。これらの要求は、プログラムがユーザーまたはスクリプトにホストアクセスリストへのアクセス権を付与するために使用されます。ホストベースのアクセス方式は安全ではないと考えられています。
ほとんどのクライアントプログラムは、 Xlibクライアントライブラリを介してサーバーと通信します。特に、多くのクライアントはXaw、Motif、GTK+、Qtなどのライブラリを使用しており、これらのライブラリはサーバーとのやり取りにXlibを使用しています。Xlibの使用には、次のような影響があります。
XFlush。XGetWindowAttributes。XNextEvent）、呼び出しはブロックします（例えば、XNextEventキューが空の場合はブロックします）。Xt （ XawやMotifでも使用されている）のような上位レベルのライブラリを使用すると、クライアントプログラムは一部のイベントに関連付けられたコールバック関数を指定できます。ライブラリはイベントキューをポーリングし、必要に応じて適切な関数を呼び出します。ウィンドウの再描画が必要であることを示すイベントなど、一部のイベントはXtによって内部的に処理されます。
XCBなどの下位レベルのライブラリは、プロトコルへの非同期アクセスを提供し、より優れたレイテンシー隠蔽を可能にする。
X Window System コア プロトコルは、クライアント間の通信を義務付けておらず、グラフィカル ユーザー インターフェイスで一般的な視覚要素 (ボタン、メニューなど) を形成するためにウィンドウがどのように使用されるかを規定していません。グラフィカル ユーザー インターフェイスの要素は、ウィジェット ツールキットを実装するクライアント ライブラリによって定義されます。クライアント間の通信は、ICCCMやfreedesktop仕様などの他の標準によってカバーされています。[ 9 ]
クライアント間通信は、ユーザーがウィンドウ間でデータを転送するために使用する方法である選択、カットバッファ、ドラッグアンドドロップに関係します。ウィンドウは異なるプログラムによって制御される可能性があるため、これらのデータを交換するためのプロトコルが必要です。クライアント間通信は、ウィンドウの外観やグラフィカルユーザーインターフェースの全体的なルックアンドフィールを制御するプログラムであるXウィンドウマネージャにも関係します。
クライアント間の通信がある程度関係するもう一つの問題は、セッション管理です。
ユーザーセッションの開始方法は、コアプロトコルでは規定されていない別の問題です。通常、これはXディスプレイマネージャによって自動的に行われます。ただし、ユーザーはxinitまたはstartxプログラムを実行して、手動でセッションを開始することもできます。