Loading article…
| X.Orgサーバー | |
|---|---|
 | |
| 開発者 | X.Org財団 |
| リリース | 2004年4月6日 （2004-04-06）[ 1 ] |
| 安定放出 | |
| 執筆 | C |
| オペレーティング·システム | クロスプラットフォーム |
| サイズ | 3.7 MiB [ 3 ] |
| 利用可能 | 英語 |
| タイプ | ディスプレイサーバー |
| ライセンス | MITライセンス |
| Webサイト | x.org |
| リポジトリ |
|
X.Org Serverは、 X.Org Foundationによって管理されている、X Window System（X11）ディスプレイサーバーの無料のオープンソース実装です。
クライアント側のX Window Systemプロトコルの実装は、X サーバーとの通信に役立つ API として機能するX11 ライブラリの形で存在します。 [ 4 ] X11 には、このような主要な X ライブラリが 2 つ存在します。これらのライブラリの最初のものは、オリジナルの C 言語 X11 API であるXlibでしたが、 [ 5 ] 2001 年に別の C 言語 X ライブラリであるXCBが作成されました。 [ 6 ]他の言語のXlibおよびXCBのインターフェースとして、またより小さなスタンドアロンの X ライブラリとして、他の小規模な X ライブラリも存在します。
X.Org FoundationがX Serverをサポートするために提供するサービスには、リリースのパッケージング、認証（有料）、コードの改善点の評価、ウェブサイトの開発、および寄付金の分配処理が含まれます。リリースは、世界中の開発者によってコーディング、ドキュメント作成、パッケージングされています。
xdpyinfoX.Org Server の情報を表示するコマンドX.Orgサーバーは、X Window Systemコアプロトコルバージョン11（X11）のサーバー側と、RandRなどの拡張機能を実装しています。[ 7 ]
バージョン1.16.0では、 systemdベースの起動と管理のサポートが統合され、起動パフォーマンスと信頼性が向上しました。 [ 8 ]
デバイス独立X（DIX）は、クライアントとやり取りし、ソフトウェアレンダリングを実装するX.Orgサーバーの一部です。メインループとイベント配信はDIXの一部です。[ 9 ]
Xサーバーは、Xコアプロトコルをサポートするために実装しなければならない膨大な量の機能を備えています。これには、コードテーブル、グリフのラスタライズとキャッシング、XLFD、そしてグラフィックプリミティブを描画するコアレンダリングAPIなどが含まれます。
デバイス依存X（DDX）は、Xサーバーの中でハードウェアとやり取りする部分です。X.Orgサーバーのソースコードでは、「hw」ディレクトリ配下の各ディレクトリが1つのDDXに対応しています。ハードウェアには、グラフィックカード、マウス、キーボードなどが含まれます。各ドライバはハードウェア固有のものであり、個別のロード可能なモジュールとして実装されています。
歴史的な理由から、X.Org Server には、何らかの 2D レンダリング アクセラレーションをサポートするグラフィックス デバイス ドライバがまだ含まれています。以前は、モード設定は、特定のビデオ コントローラハードウェア ( GPU など)に特化した X サーバーのグラフィックス デバイス ドライバによって行われていました。このモード設定機能に、さまざまな GPU で 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.so215 KiB のサイズでインストールされ、Nvidia GeForce の独自ドライバーは8 MiB サイズのファイルをインストールし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 アクセラレーション ドライバで、X レンダリング プリミティブをOpenGL操作に変換し、既存の 3D 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（デジタルデジタルドライバ）であるxf86-video-qxlが存在します。これは「QXLビデオデバイス」用のドライバです。SPICEはこのドライバを利用しますが、ドライバがなくても動作します。
Debianリポジトリでは、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.OrgサーバーとすべてのXクライアントは、それぞれ独立したプロセスとして実行されます。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 Windowシステム拡張機能が必要です。
マルチシートとは、1台のコンピュータに複数の「シート」を配置した構成を指し、複数のユーザーが同時にコンピュータの前に座ってログインし、独立してコンピュータを使用できることを意味します。コンピュータには複数のキーボード、マウス、モニターが接続されており、各「シート」にはキーボード、マウス、モニターがそれぞれ1つずつ割り当てられています。「シート」とは、特定の作業スペースに割り当てられたすべてのハードウェアデバイスの集合体です。少なくとも1つのグラフィックデバイス（グラフィックカード、または出力デバイスと接続されたモニター）とキーボード、マウスが含まれます。ビデオカメラ、サウンドカードなども含まれる場合があります。
LinuxカーネルのVTシステムとXコアプロトコルの制限（特に、Xがルートウィンドウとグラフィックカードの出力との関係をどのように定義するか）により、マルチシート機能は通常のLinuxディストリビューションではそのままでは動作せず、特別な設定が必要となります。
複数座席構成の構成方法は以下のとおりです。
xorg-serverで使用されるコマンドラインオプションは以下のとおりです。
-isolateDevice bus-idデバイスのリセット（出力）をバスIDで指定されたデバイスに制限します。バス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）というものもあります。
現代の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 ]年末までに 2 つのリリースが実現しました。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への移行を推進した主な目的の一つは、開発者が他のプロジェクトですでに使い慣れていて効率的に活用しているツールを利用することでした。X.Orgを巨大なツリーから200以上の小さなツリーに分割したモジュール化プロジェクトの目的は、変更されていない何メガバイトものソフトウェアやフォントをダウンロードしてビルドすることなく、単一のライブラリやドライバのバグを修正できるようにすることでした。
バージョン7.1では、KDriveフレームワーク（キース・パッカードによって書かれた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 ]
2025年6月、X.Org ServerのフォークであるXLibreがリリースされた。[ 48 ] [ 49 ]
xorg gitソース（xmingやcygwinのxwinなど）をベースにしたWindows Xサーバーですが、Visual C++ 2010でコンパイルされています。
