X.Org サーバー

開発者	X.Org財団
初回リリース	2004年4月6日; 20年前[1] (2004-04-06)
安定版リリース	21.1.14 [2]  / 2024年10月29日
リポジトリ	gitlab.freedesktop.org/xorg/xserver
書かれた	Ｃ
オペレーティング·システム	クロスプラットフォーム
サイズ	3.7 MiB [3]
利用可能	英語
タイプ	ディスプレイサーバー
ライセンス	MITライセンス
Webサイト	x.org

X.Org Server は、X.Org Foundationによって管理されているX Window System (X11)ディスプレイ サーバーの無料のオープン ソース実装です。

クライアント側のX Window Systemプロトコルの実装は、X11ライブラリの形で存在し、Xサーバーとの通信に役立つAPIとして機能します。^[4] X11には、そのような主要なXライブラリが2つあります。最初のライブラリは、オリジナルのC言語X11 APIであるXlibでした。 ^[5]しかし、別のC言語XライブラリであるXCBが2001年後半に作成されました。^[6]他の小さなXライブラリは、他の言語のXlibとXCBのインターフェイスとして、およびより小さなスタンドアロンXライブラリとして存在します。^{[引用が必要]}

X.Org Foundation が X Server をサポートするサービスには、リリースのパッケージ化、認証 (有料)、コードの改善の評価、Web サイトの開発、寄付金の分配の処理などがあります。^{[要出典]リリースは、世界中の}開発者によってコード化、文書化、パッケージ化されています。^[要説明]

X.Orgサーバーは、 Xウィンドウシステムコアプロトコルバージョン11（X11）のサーバー側と、RandRなどのその拡張機能を実装しています。^[7]

バージョン1.16.0では、 systemdベースの起動と管理のサポートが統合され、起動パフォーマンスと信頼性が向上しました。^[8]

デバイス独立型X (DIX)は、クライアントと対話し、ソフトウェアレンダリングを実装するX.Orgサーバーの一部です。メインループとイベント配信はDIXの一部です。^[9]

X サーバーには、X コア プロトコルをサポートするために実装する必要がある膨大な機能があります。これには、コード テーブル、グリフのラスタライズとキャッシュ、XLFD、およびグラフィックス プリミティブを描画するコア レンダリング API が含まれます。

デバイス依存 X (DDX) は、ハードウェアと対話する x サーバーの一部です。X.Org Server ソース コードでは、「hw」の下の各ディレクトリが 1 つの DDX に対応します。ハードウェアは、グラフィックス カード、マウス、キーボードで構成されます。各ドライバーはハードウェア固有であり、個別のロード可能なモジュールとして実装されます。

歴史的な理由により、X.Org Server には、何らかの形式の 2D レンダリング アクセラレーションをサポートするグラフィック デバイス ドライバーがまだ含まれています。以前は、モード設定は、一部のビデオ コントローラーハードウェア (例: GPU )に固有の X サーバー グラフィック デバイス ドライバーによって行われていました。このモード設定機能には、さまざまな GPU で 2D アクセラレーションが利用可能になったときに、2D アクセラレーションのサポートが追加されました。モード設定機能はDRMに移動され、DRM モード設定インターフェイスを通じて公開されています。この新しいアプローチは、「カーネル モード設定」(KMS) と呼ばれています。ただし、2D レンダリング アクセラレーションは残っています。

Debianでは、X.Org Serverの2Dグラフィックドライバは個別にパッケージ化されており、xserver-xorg-video-*と呼ばれています。^[10]インストール後、2Dグラフィックドライバファイルはにあります/usr/lib/xorg/modules/drivers/。パッケージxserver-xorg-video-nouveauはnouveau_drv.so215KiBのサイズでインストールされ、プロプライエタリなNvidia GeForceドライバは8MiBサイズのファイルをインストールしnvidia_drv.so、Radeon Softwareはfglrx_drv.so約25MiBのサイズで インストールされます。

利用可能な無料およびオープンソースのグラフィック デバイス ドライバーは、Mesa 3Dプロジェクト内で開発されています。これらは必要に応じて再コンパイルできますが、X.Org サーバーが複数のバージョンにわたって安定した API/ABI を維持することで、独自の DDX 2D グラフィック ドライバーの開発が大幅に容易になります。

バージョン 1.17 では、モード設定の汎用メソッドがメインライン化されました。Debianxf86-video-modesettingパッケージと呼ばれるパッケージはxserver-xorg-video-modesetting廃止され、そこに含まれる汎用モード設定 DDX はサーバー パッケージに移動され、KMS 対応のデフォルト DDX となり、AMD、Intel、NVidia GPU の大部分をサポートするようになりました。

2016年4月7日、AMDの従業員Michel Dänzerはxf86-video-atiバージョン7.7.0 ^[11]とxf86-video-amdgpuバージョン1.1.0 ^[12]をリリースしました。後者にはPolarisマイクロアーキテクチャのサポートが含まれています。

少なくともXAA（XFree86アクセラレーションアーキテクチャ）、^[13] EXA、UXA、SNAがあります。

X Window Systemにおいて、XFree86 Acceleration Architecture ( XAA ) は、ビデオカードの 2DハードウェアアクセラレーションをX サーバーで利用できるようにするドライバーアーキテクチャです。^{[14] [15]}これは 1996 年に Harm Hanemaayer によって書かれ、XFree86バージョン 3.3 で初めてリリースされました。XFree86 4.0 では完全に書き直されました。^[16] X.Org Server 1.13 では再び削除されました。

ほとんどのドライバーは、XAA モジュールを使用してアクセラレーションを実装します。XAA はデフォルトでオンになっていますが、個々の機能のアクセラレーションは、必要に応じてサーバー構成ファイル (XF86Configまたはxorg.conf) でオフにすることができます。

ARK チップセットのドライバーは、XAA の元の開発プラットフォームでした。

X.Org Server リリース 6.9/7.0 では、 XAA が現在のビデオ カードに対して速度面でほとんど利点がないため、XAA の代替としてEXAがリリースされました。EXA は、X サーバー全体をOpenGL を使用するように変換するための中間ステップと見なされています。

Glamorは、Xサーバ用の汎用的でハードウェアに依存しない2Dアクセラレーションドライバであり、既存の3D OpenGLドライバを活用して、 XレンダリングプリミティブをOpenGL操作に変換します。 ^{[17]このように、機能的にはApple} Quartz CompositorのQuartz ExtremeやQuartzGL（2Dパフォーマンスアクセラレーション）に似ています。

GLAMORの最終的な目標は、すべてのDDX 2Dグラフィックスデバイスドライバとアクセラレーションアーキテクチャを廃止して置き換えることです。これにより、サポートされているすべてのグラフィックチップセットに対してX 2D固有のドライバを作成する必要がなくなります。^{[18] [19] [20] Glamorには}シェーダをサポートする3Dドライバが必要です。^[21]

Glamorのパフォーマンスチューニングは、 Google Summer of Code 2014に採用されました。^[22] GlamorはXephyrとDRI3をサポートしており、^[23]一部の操作を700～800%高速化できます。^[24] X.Org Serverのバージョン1.16にメインライン化されて以来、Glamorの開発は継続され、1.17リリースのパッチが公開されました。^[25]

仮想化環境内のゲスト システムで実行される X.Org Server のインスタンスには、独自の特別な DDX があります。これは、「QXL ビデオ デバイス」用のドライバーである xf86-video-qxl です。SPICEはこのドライバーを利用しますが、このドライバーがなくても動作します。

Debian リポジトリでは xserver-xorg-video-qxl と呼ばれています。https://packages.debian.org/buster/xserver-xorg-video-qxl を参照してください。

Debian では、入力に関連するドライバは にあります/usr/lib/xorg/modules/input/。このようなドライバは、たとえばevdev_drv.so、mouse_drv.so、synaptics_drv.soなどの名前が付けられますwacom_drv.so。

バージョン 1.16 では、X.Org サーバーはと呼ばれるラッパーの形でlibinputxf86-input-libinputライブラリのサポートを獲得しました。^[26]トロントで開催された XDC 2015 では、設定可能なマウスをサポートする汎用ライブラリとして libratbag が導入されました。^{[27] [28]} xserver-xorg-input-joystickは、X.Org サーバーが従来のジョイスティックやゲームパッドを処理するための入力モジュールであり、X でゲームをプレイするためのものではなく、ジョイスティックやゲームパッドでカーソルを制御するためのものです。^{[29] [30]}

Xウェイランド

XWaylandは、X.Orgサーバーのコードベースに対する一連のパッチであり、Waylandプロトコル上で動作するXサーバーを実装する。このパッチは、Waylandへの移行中にX11アプリケーションとの互換性を保つためにWayland開発者によって開発および保守されており、^[31] 2014年にX.Orgサーバーのバージョン1.16でメインライン化された。^[8]ユーザーがWeston内からXアプリケーションを実行すると、リクエストを処理するためにXWaylandが呼び出される。^[32]

クォーツ

XQuartz は、XWayland がWayland コンポジターに X11 を統合するのと同様に、Apple 社のQuartz コンポジターに X11 プロトコルのサポートを統合するための一連のパッチです。

エクススパイス

XspiceはX.Org Server用のデバイスドライバです。QXLフレームバッファデバイスをサポートし、SPICEプロトコルを介してディスプレイをエクスポートするX.Org Serverを起動できるようにするラッパースクリプト^{[33]が含まれています。これにより、} KVM仮想化を必要とせずに、リモートデスクトップ環境でSPICEを使用できるようになります。

ゼファー

XephyrはX-on-X実装です。バージョン1.16.0以降、Xephyrは新しい2Dアクセラレーションサブシステム（Glamor）の主な開発環境として機能し、単一のマシン上での迅速な開発とテストを可能にしています。^[8]

ランドR

RandR（サイズ変更と回転）は、X11 ^[34]プロトコルの拡張として書かれた通信プロトコルです。XRandRは、画面のルートウィンドウのサイズ変更、回転、反転の機能を提供します。RandRは画面のリフレッシュレートの設定を担当します。^[35]複数のモニターの制御が可能になります。^[36]

X.Org サーバーと x-client は、それぞれ別個のプロセスとして実行されます。Unix/Linux では、プロセスは他のプロセスについて何も知りません。プロセスが他のプロセスと通信するには、利用可能なプロセス間通信(IPC) メカニズムを介して通信を調整するカーネルに完全に依存します。Unix ドメイン ソケットは、同じマシンで実行されているプロセスと通信するために使用されます。特別なソケット関数呼び出しは、システム コール インターフェイスの一部です。インターネット ドメイン ソケットはローカルで使用できますが、プロトコルオーバーヘッド (チェックサム、バイト オーダーなど) がないため、Unix ドメイン ソケットの方が効率的です。

X.Org Server はD-Bus を使用しません。

ソケットは、X サーバーとそのさまざまな X クライアントのプロセス間で最も一般的なプロセス間通信 (IPC) 方法です。TCP/IP ドメインでの通信、および UNIX ドメイン内でのみローカルに通信するためのアプリケーション プログラミング インターフェイス (API) を提供します。X トランスポート インターフェイスには、TLI (トランスポート層インターフェイス) など、他の API もいくつか記述されています。X クライアント サーバー間の IPC のその他のオプションには、MIT 共有メモリ拡張 (MIT-SHM)な​​どの X ウィンドウ システム拡張が必要です。

マルチシートとは、複数の「シート」を備えた 1 台のコンピュータの集合体を指します。これにより、複数のユーザーがコンピュータの前に座り、ログインして、同時に独立してコンピュータを使用できます。コンピュータには複数のキーボード、マウス、およびモニターが接続されており、各「シート」には 1 つのキーボード、1 つのマウス、および 1 つのモニターが割り当てられています。「シート」は、特定の作業場所に割り当てられたすべてのハードウェア デバイスで構成されます。少なくとも 1 つのグラフィック デバイス (グラフィック カードまたは出力と接続されたモニターのみ) とキーボードとマウスで構成されます。ビデオ カメラ、サウンド カードなどが含まれる場合もあります。

Linux カーネルの VT システムと X コア プロトコル (特に、X がルート ウィンドウとグラフィック カードの出力の関係を定義する方法) の制限により、マルチシートは通常の Linux ディストリビューションではそのままでは動作せず、特別な構成が必要になります。

マルチシート アセンブリを構成するには、次の方法があります。

• ホスト xorg-server 上の複数のXephyrサーバー
• xorg-server の複数のインスタンス
  • 1席につきグラフィックカード1枚
  • すべての座席に1枚のグラフィックカード

xorg-server で使用されるコマンドライン オプションは次のとおりです。

• -isolateDevice bus-idデバイスのリセット (出力) を bus-id のデバイスに制限します。bus-id 文字列の形式は、bustype:bus:device:function (例: 'PCI:1:0:0') です。現在、PCI デバイスの分離のみがサポートされています。つまり、bustype が 'PCI' 以外の場合、このオプションは無視されます。
• vtXXたとえば、Debian 9 Stretch のデフォルトは 7 です。つまり、Ctrl+ +を押すと、ユーザーは xorg-server を実行している VT に切り替えることができます。AltF7

最初のモニターのユーザーのみが vt コンソールを使用でき、+ + x を使用して選択できます。他のユーザーにはGDMログイン画面があり、xorg-server を通常どおり使用できますが、vt はありません。 CtrlAltF

1 人のユーザーが 1 つのグラフィック カードの異なるポートに接続された複数のモニターを利用できる場合でも (RandR を参照)、xorg-server の複数のインスタンスに基づく方法では複数のPCIグラフィック カードが必要になるようです。

1枚のグラフィックカードのみを使用してマルチシートを構成することは可能ですが、Xプロトコルの制限により、Xディスプレイマネージャ制御プロトコルXDMCPを使用する必要があります。^[37]

Xdmx (Distributed Multihead X) もあります。

Unix と Linux

X.Org サーバーは、多くのフリーソフトウェアのUnix 系オペレーティング システムで実行され、ほとんどのLinux ディストリビューションやBSDバリアントで採用されています。また、 Solarisオペレーティング システム用の X サーバーでもあります。X.Org は、 Minix 3のリポジトリでも入手できます。

ウィンドウズ

CygwinのMicrosoft Windows用Xサーバの実装であるCygwin/Xは、 VcXsrv ^[38] ( Visual C++ Xサーバ^[39] )やXmingと同様にX.Orgサーバを使用しています。PuTTYなどのSSHクライアントでは、サーバとクライアントの両方でX11転送が有効になっている場合、 X11転送を介してXアプリケーションを起動できます。

OS X / macOS

Mac OS X Leopard (10.5)より前のバージョンのOS XにはXFree86 ベースのサーバーが同梱されていましたが、10.5 の X サーバーは X.Org コードベースを採用しました。^[40] OS X Mountain Lion (10.8)以降、X11 は OS X にバンドルされておらず、代わりに、たとえばオープンソースのXQuartzプロジェクトからインストールする必要があります。^{[41]バージョン 2.7.4 の時点で、X11.app/XQuartz は高解像度の}Retina ディスプレイのサポートを X11 アプリに公開していません。高解像度ディスプレイではピクセル倍増モードで実行されます。

オープンVMS

OpenVMS用のDECwindows X11サーバーの現在のバージョンはX.orgサーバーをベースにしています。^[42]

現代のX.Org Foundation は、X 標準を監督し、公式リファレンス実装を公開した組織が、以前のXFree86開発者と力を合わせた 2004 年に誕生しました。^[43] X.Org Server の最初のバージョンである X11R6.7.0 は、XFree86 4.4 RC2 から分岐しました。 ^[1]分岐の直接の理由は、XFree86 4.4 の最終リリース バージョンの新しいライセンスに対する意見の不一致でしたが、分裂前に貢献者間でいくつかの意見の不一致が表面化していました。以前の XFree86 開発者の多くが X.Org Server プロジェクトに参加しています。

2005年には、X.Orgサーバーのソースコードのモジュール化に多大な努力が払われ、^[44]年末までにデュアルリリースが実現しました。X11R7.0.0リリースでは、 GNU Autotoolsに基づく新しいモジュール式ビルドシステムが追加されましたが、X11R6.9.0では古いimakeビルドシステムが維持され、両方のリリースは同じコードベースを共有しています。それ以来、X11R6.9ブランチは凍結された状態で維持され、進行中の開発はすべてモジュール式ブランチに対して行われています。新しいビルドシステムでは、プラグインとドライバーをロードするためにdlloader標準のダイナミックリンカーも使用されるようになり、古い独自の方法が非推奨になりました。モジュール化の結果、多くのUnixシステムで、 X11バイナリは独自の/usr/X11R6サブディレクトリツリーからグローバルツリーに移動しました。 /usr

2006年6月には、X.OrgサーバーのソースコードベースをCVSからgitに移行するという別の取り組みが行われました。^[45]どちらの取り組みも、プロジェクトに新しい開発者を呼び込むという長期的な目標がありました。アラン・クーパースミスは次のように述べています。^[46]

ここでの私たちの努力の一部は技術的なものでした。Imake から automake へ、CVS から git への変換を推進した努力の 1 つは、開発者がすでに使い慣れていて生産性が高い他のプロジェクトからのツールを活用することでした。X.Org を 1 つの巨大なツリーから 200 を超える小さなツリーに分割したモジュール化プロジェクトの目標は、変更されていない何メガバイトものソフトウェアとフォントをダウンロードしてビルドすることなく、単一のライブラリまたはドライバーのバグを修正できるようにすることでした。

7.1 リリースでは、KDrive フレームワーク ( Keith Packardによって書かれた X の小さな実装で、X.Org 開発者がEXAなどの新しいアイデアのテスト場として使用したXFree86に基づいていない) が X.Org サーバーのメイン コードベースに統合されました。

2008 年、カーネル モード設定(KMS) ドライバーに基づく新しい DRI2 がDRI に取って代わりました。この変更により、ドライバーがサーバーおよびユーザー スペース(UMS)からカーネル スペースに移動されたため、X.Org サーバー アーキテクチャの大きなマイルストーンも設定されました。

2013年に、DRI3とPresent拡張機能の初期バージョンは、より高速でティアリングのない2Dレンダリングを提供するために、Keith Packardによって書かれ、コード化されました。その年の終わりまでに、 GLXの実装はRed HatのAdam Jacksonによって書き直されました。^[47]

Wikimedia Commons には、X.Org Serverに関連するメディアがあります。

• 公式サイト
• VcXsrv - Windows 用の完全に更新された X サーバー
• VcXsrv - Windows 用の Sourceforge の古いリポジトリ