Design Document for the Xinerama Extension to the X Window SystemXinerama API (Proposal)(日本語訳)

翻訳にあたって、オープンソースグループ・ジャパンの MIT ライセンスの訳を参考にした。

Design Document for the Xinerama Extension to the X Window System(日本語訳)

著者：

Paul Anderson、Hewlett Packard
Jay Cotton、Sun Microsystems, Inc
Heather Lanigan、Hewlett Packard
Mark Vojkovich、The XFree86 Project

著作権、許諾：

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the names of Hewlett-Packard, Sun Microsystems, Inc., Compaq Computer Corporation, and The XFree86 Project shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from Hewlett-Packard, Sun Microsystems, Inc., Compaq Computer Corporation, and VA Linux Systems.

(本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可する。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれるが、これらに限定されない。)

(上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとする。)

(ソフトウェアは「現状有姿」で提供され、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われない。ここでいう保証には、商品性、特定目的への適合性、および権利の非侵害性に関する保証も含まれるが、これらに限定されるものではない。THE XFREE86 PROJECT は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負わない。)

(Hewlett-Packard、Sun Microsystems, Inc.、Compaq Computer Corporation、及び The XFree86 Project の名称は、この表示に記載されている場合を除き、Hewlett-Packard、Sun Microsystems, Inc.、Compaq Computer Corporation、及び VA Linux Systems の事前の書面による承認を得ずに、宣伝であろうとその他の形であろうと、ソフトウェアの販売を促進するもの、またはソフトウェアの使用その他の扱いを奨励するものに使用してはならない。)

概要

I. コードの変更で影響を受ける領域
II. X ウィンドウ・システムの他の部品に対する依存関係
III. 設計上の決断に関する論議
IV. 新たな技術がコードの大きさと実行効率とに与える影響を評価する。また、実行効率の数字を得るための使用モデル(usage models)の説明も記述する。

I. コード変更の影響

Xinerama 拡張機能のコードの変更は、X ウィンドウ・システムのライブラリ側とサーバ側の両方に対して影響を与える。ライブラリ側においては、新たな API ライブラリが必要になるであろう。Xinerama API は libXext.so には含まれないことに注意。サーバ側においては、以下のライブラリのコードを変更する必要がある。即ち、libdix、libmi、libos、libcfb*、及び libxkb である。コードの変更は、既存の拡張にも影響を与える。影響を受ける拡張は、Shared Memory 拡張、Multibuffer 拡張、及び Shape 拡張である。新しいライブラリは２つ必要になるであろう。１つは API のために、もう１つはサーバ側で拡張そのもののために使用される。

II. 依存関係

Xinerama 拡張機能を実行するのに必要なものは X ウィンドウ・システムだけである。Xinerama 拡張は、技術的には、現在利用可能な拡張機能のいづれをも必要としない。しかしながら、企業の X ウィンドウ・システムのルック・アンド・フィールの中には変えられたくないものもあるであろうから、拡張機能の一部は、Xinerama が存在し且つ使用されていることを認識できるように修正されなければならない。これについては、「拡張機能が Xinerama を認識できるようにする」(MAKING EXTENSIONS XINERAMA AWARE)と題された文書の中で詳しく論じている。

III. 設計上の決断

どの実装を基にするべきか？

タスク・フォースが最初に下すことになった設計上の決断は、すでに X.Org の見本実装の中にある Xinerama 実装を基にして開発を始めるべきか、それとも XFree86 に含まれている XFree86 版の Xinerama 実装を基にして開発を始めるべきかに関するものであった。我々は、(XFree86 のソースコードに含まれている) XFree86 版の Xinerama を使用することに決めた。主な理由は、Stuart Kreitman と Jay Cotton が計測した実行効率データである。以下の数字は、その右側に示す実装が Xinerama 無しの見本実装と比較してどれくらい速いかを表すものである。

.041 倍の速さ - X.Org の実装(ハッシュ探索)。
.54 倍の速さ - X.Org の実装(二分探索)。(訳註：「w/ binary search」要確認)
.65 倍の速さ - XFree の実装(ハッシュ探索)。

これらの数字は、x11perf から「Map window via parent (200 kids)」を実行した場合のものである。

実行効率の差は、XFree86 版では拡張の内部を書き直していることに起因する。実装の違いの１つは、Panoramix の内部データ構造として使用されていた連結リストを削除したことである。連結リストは全てリソースに変わり、サーバのハッシュ表の恩恵を受けられるようになった。

もう１つ、重要な実装上の違いがある。DIX におけるイベント処理が単一の論理スクリーン空間で行われるようになったことである。かつては、イベントの処理は通常の複数モニターの場合と似た形で行われていて、イベントをクライアントへ送ろうとする最後の段階になってからイベントの座標を単一の論理スクリーンの座標に変換していた。このやり方では、逆方向の探索に大きな演算費用が必要であった。即ち、N 番のスクリーンのウィンドウに対応する 0 番のスクリーンのウィンドウを見つける必要があった。今では、イベントが DDX から DIX へ流れる時点で、ポインタの座標を物理的なスクリーンのものから論理的なスクリーンのものへと翻訳するだけでよくなった。

API 関数として何を使用すべきか？

最初に意見が一致したのは、API の全ての関数の名前に「Xinerama」を使用するということであった。これに対して、現在利用可能な API 関数の名前は「PanoramiX」から始まる。この拡張が標準規格となるので、PanoramiX 拡張(PanoramiX 拡張とは、Xinerama 拡張の古い名前である)に対する参照は全て、この拡張からは取り除かれる。この拡張の古い版との互換性をどのように保つのかは、個々の企業が判断すべきことである。

我々は、ウィンドウを特定の物理スクリーンに結びつけたり、ウィンドウを最大化して特定の物理スクリーンの大きさにしたりする、様々な関数について考えてきた。しかし、結局、そうした事柄はウィンドウ・マネージャの領分であると判断した。

また、PanoramiX の API の関数をそっくりそのまま Xinerama API の関数に転換する必要はないと判断した。１つに纏めると使いやすくなる関数があまりにも多かった。特に、それらの関数がいつも必要になるデータを提供するものであったのが大きい。

また、関数 XineramaGetCenterHint の追加を決めた。「中央へ配置されるウィンドウ」をどこへ配置するべきかという情報は、ウィンドウ・マネージャが最も知りたがる事柄であるからである。中央を表すヒント(center hint)はアトム(で表されるプロパティ)となるので、関数 XineramaSetCenterHint を追加した。これは、ウィンドウ・マネージャがデフォルトの位置とは異なる位置を「中央」として使いたい場合に備えたものである。

また、ウィンドウ・マネージャの開発者との議論に基き、次のことを決定した。即ち、要求があった場合には、個々の物理スクリーンに関するデータをより多く返すよう決定した。

API の引数としてウィンドウとスクリーン番号のどちらを使うべきか？

API の引数を通じて論理的な Xinerama スクリーンを指定する方法としては何が最良のものなのか、それが問題であった。長らく２つの方法が主張されていて、結論が出なかった。１つは引数としてウィンドウ(Window)を使う方法であり、もう１つは引数として論理スクリーンの番号である int を使うものであった。

この問題は、人々は２つ以上の論理的な Xinerama スクリーンを使いたがるかもしれないという考えから来ている。もし実際にそうであったとしたら、プロトコルにおいて、どうすれば最も上手くそうした要望を実現することできるであろうか。参考実装の中にこの機能を書き入れる計画は一切無かったが、我々は実現可能性を残しておきたかった。HP は、同社のこれと似た拡張の実装の中で既にこの機能を実現していると言う。しかし、その API は、スクリーン番号を使うところとウィンドウを使うところとがあって、一貫していない。

どちらかの方法がもう１つの方法より優れていることを明確に示す論拠は無いように思われた。コア API (X プロトコル本体の API)では両方の方法を使っている。XSetWindowBackground、XCreateColormap、及び XCreateWindow のような関数は、引数として Window を使う。一方、XBlackPixel、XListDepths、及び XDefaultGC のような関数は、int 型のスクリーン番号を使う。

我々の API 関数の大部分は、論理的な Xinerama スクリーンに関する情報を要求するリクエストである。これらは、特定のウィンドウに関する情報を要求するものではない。また、これらは XSetWindowBackground よりも XListDepths に似ているものである。そこで、一度は int 型のスクリーン番号を使用することに決めた。

ところが、コードを書いてみたら Mark がすぐに次のことに気づいた。「ウィンドウを見つけ出すためには、スクリーン番号が有効でなければならない。そうでないとディスプレイ中の配列の外側の部分を読み込んでしまう。この問題の影響範囲を調べているが、誰かがスクリーン番号として 348279 を指定した場合に何をするべきかについて、問題が見つかった。理論上は、この値はサーバへ送られるべきであり、サーバは BadValue エラーを報告できるはずであった。しかし、私がこの場合にできることは 0 を返してリクエストを蹉跌させることだけであり、エラーは発生しない。なぜなら、リクエストはそもそもサーバへ行っていないから。」

これによって、一方より他方を選ぶことに明確な理由が生まれた。我々は、API の引数として Window を使用することに決めた。

独立した API ライブラリを作るべきか、それとも libXext の中に入れるべきか？

現在 XFree86 の実装には、API のために独立した libXinerama が存在する。一方、X.Org の見本実装では、Xinerama は libXext の中に含まれている。どちらかの方法がより優れているというわけでもない。

X.Org は現在、X ウィンドウ・システムのライブラリ側の参照実装として XFree86 のソース・ツリーを使用する方向へ向けて作業を進めている。したがって、我々の見本コードも、同ソース・ツリーにおける API ライブラリ・コードの構成に基くことになる。そのため、API のために libXinerama を作ることに決めた。

コマンド・ライン・オプションの変更は必要か？

コマンド・ラインの引数(オプション指定)を変更するかどうか検討したが、結局、そのままにしておくことに決めた。オプション指定を変更することに対する関心は、ほとんど、あるいは全く無かった。現在、ユーザは Xinerama の有効・無効を自由に切り替えることができる。但し、Xinerama はデフォルトでは無効になっている。各企業は、スクリーンの配置を指定するにあたって独自の方法を用いている。我々は、そうした状況をそのまま放置することにした。

ビデオ・カードに関する制約は？

Xinerama 拡張に均質なグラフィクス環境(homogeneous graphics environment)が必要であることについては、皆が同意していた。均質なグラフィクス環境でなければ、アプリケーションは何が表示できるのかわからなくなってしまう可能性がある。というのは、アプリケーションは１つのスクリーンしか存在しないと思っているからである。我々は、均質なグラフィクス環境という言葉の定義がタスク・フォースの各人の間で異なっていることに気づいた。ある人の考えでは、全てのグラフィクス・カードは全く同じヴィジュアルと全く同じ深さに対応していなければならず、つまるところ全てのカードは全く同じでなければならない、という意味になる。別の人の考えでは、共通のヴィジュアル及び共通の深さが少なくとも１つ存在すれば均質な環境であるという。

まもなく我々は制約の少ない定義を採用することで合意した。Xinerama では、グラフィクス・カード間で少なくとも１つのヴィジュアルが共通している必要がある。Xinerama は、利用可能なヴィジュアル及び深さの集合の共通部分をアプリケーションに対して公示することになる。この共通集合は、複数のグラフィクス・カードを合わせて使用することに対して各企業が設ける制約によって、いくらか限定を受ける。

物理的なスクリーン形状(layout)の要件

かつては、スクリーンは各企業が認めるレイアウトで自由に構成できることになっていた。L 字型のスクリーンでも X 字型のスクリーンでもよく、直線状でもよかった。しかしながら、Xinerama の用途を考えると、これでは余りにややこしかった。モニターが存在しない隙間の場所ではウィンドウが消失してしまうし、ポインタを転移させる仕組みも変なものになってしまう。プロトコルでは、スクリーン・サイズの定義の中に幅と高さ以外のものを含めることを認めていない。それゆえに、我々は、Xinerama の用途のためにはスクリーンの構成は矩形の一種であるべきだと判断した。

XineramaSetCenterHint は Status を返すべきか、それとも void を返すべきか

XineramaSetCenterHint は、XChangeProperty から返ってきた戻り値をそのまま自身の戻り値として使用していた。問題は、XChangeProperty の戻り値は常に 1 であり、これは成功も失敗も表さないということである。仕様書の XChangeProperty の部分には、戻り値に関する言及が無い。X11 R6.5 において、XChangeProperty の戻り値の型が void から int へ変更された。この関数は R6.3 より前から既に 1 を返していた。タスク・フォースの幾人かのメンバーには、XChangeProperty に対するこの変更は間違ったものだと思われた。

XineramaSetCenterHint が無意味な Status を返すと、他にも問題が生じる。これは誰かがこの値を使おうとした時に起きる。BadWindow エラーが返ってきたのに、戻り値である Status は正常なので戸惑うことになる。これは混乱の素である。

戻り値を int のままにしておきたいという主張は、対となる２つの考えから来ていた。XineramaGetCenterHint に似た型にしておきたいという考えと、XineramaSetCenterHint は XChangeProperty のラッパー関数に過ぎないから XChangeProperty の戻り値をそのまま使うようにしておきたいという考えである。

Paul がこの問題を上手く纏めてくれた。「一番の問題は、コア・プロトコルの関数の振る舞いに従うのか、それとも、この件を誤った振る舞いを正す機会として利用するべきなのかということだと思う。」

タスク・フォースの大半の人々はどちらの手法も容認できた。幾人かは、振る舞いを正すやり方を強く推した。タスク・フォースは、XineramaSetCenterHint の戻り値として void を使用することに決めた。

IV. 実行効率

３６個のファイルにおいて、おおよそ ??? 行のコードの変更と追加があった。変更・追加のあったファイルの中、１１個は新しいファイルである。これによって、サーバは ??? MB 大きくなる。

(訳註：コード・サイズの記述しかない。実行効率やその計測方法に纏わる記述は無い。)

変更履歴：

0.7.1: 2002年5月17日
XineramaSetCenterHint の討議に関する論評を追加。

0.6.4: 2002年4月8日
「スクリーン番号 vs. ウィンドウ」に関する記述を追加。

0.6.2: 2002年1月8日
X.Org Standards Process の記述に合うように版番号の付け方を変更。

0.2: 2002年1月3日
「API の引数としてウィンドウとスクリーン番号のどちらを使うべきか？」の章に文章を追加。