X Version 11, Release 7.7
Version 2.0
Copyright © 1993, 1994 X Consortium
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 X CONSORTIUM 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 name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.
X Window System is a trademark of The Open Group.
(訳)
(以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可する。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれる。)
(上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとする。)
(ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供される。ここでいう保証には、商品性、特定の目的への適合性、および権利非侵害についての保証も含まれるが、それに限定されるものではない。X CONSORTIUM は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとする。)
(X Consortium の名称は、この表示に記載されている場合を除き、X Consortium の事前の書面による承認を得ずに、宣伝であろうとその他の形であろうと、ソフトウェアの販売を促進するもの、またはソフトウェアの使用その他の扱いを奨励するものに使用してはならない。)
(X Window System は The Open Group の商標である。)
この拡張は、バイト長が 262140 を超えるようなプロトコル・リクエストの使用を可能にするものである。
X コア・プロトコル(本体のプロトコル)では、プロトコル・リクエストの最大長が 262140 バイトに制限されている。これは、リクエスト内の 4 バイト単位のデータの個数を表すのに 16 ビットの length フィールドを使っているためである。これによって、コア・プロトコルで大量の線や弧を結合する場合(PolyLine や PolyArc)に問題が起きる。なぜかというと、これらのリクエストを小さなリクエストに分割すると、必ず結合点のレンダリングが紊れてしまうからである。また、プロトコルの拡張に対しては一層の問題を引き起こす。例えば、3D グラフィクスのための PEX 拡張や、画像操作のための XIE 拡張(X Image Extensionのこと)などは、出力命令において長いデータのリストを送信する必要がある。
この拡張では、length フィールドを 16 ビット以上に拡張する仕組みを定める。プロトコル・リクエストの通常の 16 ビットの length フィールドの値が 0 である場合、リクエストの中のこの 16 ビットの length フィールドの直後に 32 ビットの追加フィールドが挿入され、ここに実際のデータ長(4 バイト単位)が入る。
たとえば、通常の PolyLine は次のように符号化される。
PolyLine | |||
|---|---|---|---|
| 1 | 65 | opcode(命令コード) | |
| 1 | coordinate-mode | ||
| 0 | Origin | ||
| 1 | Previous | ||
| 2 | 3+n | ||
| 4 | DRAWABLE | drawable | |
| 4 | GCONTEXT | gc | |
| 4n | LISTofPOINT | points | |
一方、拡張された length フィールドを持つ PolyLine は次のように符号化される。
PolyLine | |||
|---|---|---|---|
| 1 | 65 | opcode(命令コード) | |
| 1 | coordinate-mode | ||
| 0 | Origin | ||
| 1 | Previous | ||
| 2 | 0 | 拡張 length フィールドを持つことを表すフラグ | |
| 4 | 4+n | リクエストのデータ長(request length) | |
| 4 | DRAWABLE | drawable | |
| 4 | GCONTEXT | gc | |
| 4n | LISTofPOINT | points | |
拡張 length プロトコル(拡張 length フィールドを用いるプロトコル)の符号化方式は、一度有効化されれば、全てのプロトコル・リクエスト(あらゆる拡張のものを含む)で使用できる。
BigReqEnable
=>
maximum-request-length: CARD32
このリクエストを使用したクライアントは、拡張 length プロトコルのリクエストを使用することができるようになる。また、このリクエストは、拡張 length プロトコルのリクエストで使用できる最大のデータ長(4 バイト単位)を返す。この値は常に、接続設定情報として返ってくる最大リクエスト長よりも大きくなる。
本文書は、X11 プロトコルの符号化に関する文書(X Window System Protocol の附録 B「プロトコルの符号化」 )で定められた規約を用いているため、そちらも参照してほしい。
この拡張の名前は「BIG-REQUESTS」である。
| BigReqEnable | ||
|---|---|---|
| 1 | Card8 | opcode(X11 の命令コード) |
| 1 | 0 | bigreq opcode(BigReqEnable リクエストを表す拡張内命令コード) |
| 2 | 1 | request length |
| => | ||
|---|---|---|
| 1 | 1 | Reply |
| 1 | unused | |
| 2 | CARD16 | sequence number(通し番号) |
| 4 | 0 | length |
| 4 | CARD32 | maximum-request-length |
| 20 | unused | |
Xlib 本体も他の拡張も、この拡張が必要な場合、同拡張を内部で使用するのが望ましい。また、この拡張は、X クライアントに対してできる限り透過的な形で利用されるのが望ましい。たとえば、この拡張が初めて必要になる時まで同拡張の有効化を先延ばしにしていたとしたら、XNextRequest を使ってリクエストの通し番号を知ろうとしていたアプリケーションは、もはや正しい通し番号を得ることはできないであろう。なので、XOpenDisplay によってサーバがこの拡張に対応しているかを判断することにし、もし対応していれば、同関数で拡張 length プロトコルの符号化方式を有効にすることにする。
Xlib 本体の関数の中、XDrawLines、XDrawArcs、XFillPolygon、XChangeProperty、XSetClipRectangles、及び XSetRegion は、サーバが拡張 length プロトコルに対応している場合、必要な場面では、同プロトコルの符号化方式を使用することが求められる。他の Xlib 本体の関数(XDrawPoints、XDrawRectangles、XDrawSegments、XFillArcs、XFillRectangles、及び XPutImage)では、拡張 length の符号化方式の利用は認められているが必須ではない。後者の関数群の Xlib の実装においては、代わりに、データを複数の小さなリクエストに分割することにしてもよい。
拡張 length の符号化方式で使える最大リクエスト長をクライアントから知ることができるように、Xlib に次の関数を追加する。
display で指定されたディスプレイがこの拡張に対応していなかった場合、0 が返る。そうでない場合、拡張 length の符号化方式を使う際にサーバが対応できる最大リクエスト長(4 バイト単位)が返る。