Initial revision

author: Kaleb Keithley <kaleb@freedesktop.org> 2003-11-14 16:48:55 +0000
committer: Kaleb Keithley <kaleb@freedesktop.org> 2003-11-14 16:48:55 +0000
commit: 67f7a131c3e3616149d4775546dba04857607f96 (patch)
tree: b065dbbe61c34e5a49f8343a39a99a5bafb397aa
parent: 3e77e75b5a28b1b5a258396f4f15a61c9f3dc87c (diff)
32 files changed, 22981 insertions, 0 deletions
diff --git a/hardcopy/Xv/video b/hardcopy/Xv/video
new file mode 100644
index 0000000..41e7cbd
--- /dev/null
+++ b/hardcopy/Xv/video
@@ -0,0 +1,300 @@
+
+Addendum to the Xv Client library documentation
+===============================================
+
+  The following features are new to version 2.2
+
+1) In addition to XvInputMask and XvOutputMask masks in the type field
+   of the XvAdaptorInfo there are 3 new bits defined - XvVideoMask,
+   XvStillMask and XvImageMask indicating that the adaptor is capable
+   of video, still or image primitives respectively.
+
+2) A new function and structure is defined to allow querying
+   port attributes.
+
+typedef struct {
+  int flags;    
+  int min_value;
+  int max_value;
+  char *name;
+} XvAttribute;
+
+  flags  -   May be XvGettable or XvSettable or both OR'd together
+	     indicating the particular attribute is readable, writeable
+	     or readable and writeable.
+
+  min_value, max_value -  Indicate the minimun and maximum attribute
+	     values which are valid for the driver.
+
+  name -  A string describing the name of the attribute that may be used
+	     to retrieve the Atom for the particular attribute.
+
+
+extern XvAttribute* XvQueryPortAttributes(
+  Display*                /* display */,
+  XvPortID                /* port */,
+  int*                    /* number */
+);
+
+   XvQueryPortAttributes returns the number of attributes and an
+   array of XvAttributes valid for the given port.  The array may
+   be freed with XFree().
+
+
+3)  The X Video Extension (Xv) is extended to support client images in
+alternate colorspaces (XvImages) in the following way.
+
+  Xv Adaptors which are capable of displaying XvImages will have
+  the XvImageMask field set in the type field of the XvAdaptorInfo.
+
+  XvImage formats supported by the port may be queried with 
+  XvListImageFormats().
+
+  XvImages may be created with the help of XvCreateImage() or
+  XvShmCreateImage();
+
+  XvImages may be displayed with XvPutImage() or XvShmPutImage().
+
+  The Port attributes of the port specified in the Xv(Shm)PutImage
+  command will be valid for the image operation when applicable.
+
+  There will be a port encoding with the name "XV_IMAGE".  The
+  width and height of that encoding will indicate the maximum
+  source image size.
+
+typedef struct {
+  int id;                      /* Unique descriptor for the format */
+  int type;                    /* XvRGB, XvYUV */
+  int byte_order;              /* LSBFirst, MSBFirst */
+  char guid[16];               /* Globally Unique IDentifier */
+  int bits_per_pixel;
+  int format;                  /* XvPacked, XvPlanar */
+  int num_planes;
+
+  /* for RGB formats */
+  int depth;
+  unsigned int red_mask;       
+  unsigned int green_mask;   
+  unsigned int blue_mask;   
+
+  /* for YUV formats */
+  unsigned int y_sample_bits;
+  unsigned int u_sample_bits;
+  unsigned int v_sample_bits;   
+  unsigned int horz_y_period;
+  unsigned int horz_u_period;
+  unsigned int horz_v_period;
+  unsigned int vert_y_period;
+  unsigned int vert_u_period;
+  unsigned int vert_v_period;
+  char component_order[32];    /* eg. UYVY */
+  int scanline_order;          /* XvTopToBottom, XvBottomToTop */
+} XvImageFormatValues; 
+
+
+   id -  A unique descriptor for the format.  This is often the FOURCC
+	 for the format, when applicable.  This id is used to describe
+	 the format during XvImage creation.
+
+   type - XvRGB or XvYUV.
+
+   byte_order -  The byte order of the image.  It is either LSBFirst
+	         or MSBFirst.
+	
+   guid -  The Globally Unique IDentifier (also known as Universally Unique
+	   IDentifier).  When not applicable, all characters are NULL.  
+
+   bits_per_pixel - The bits taken up (but not necessarily used) by each
+                    pixel.  Note that for some planar formats which have
+                    fractional bits per pixel (such as IF09) this number
+                    may be rounded _down_.
+
+   format - XvPacked or XvPlanar.
+
+   num_planes - The number of planes in planar formats.
+
+   depth - Significant bits per pixel.
+
+   red_mask, green_mask, blue_mask -  The red, green and blue bitmasks
+				      (RGB formats only).
+
+
+   ?_sample_bits -  The size of each sample in bits (YUV formats only).
+
+   horz_?_period, vert_?_period -  The period (in pixels) on which samples
+                                   occur in the horizontal and vertical 
+                                   directions (YUV formats only).
+
+   component_order -  Upper case ascii characters representing the order
+                      that samples are stored within packed formats.
+                      For planar formats this represents the ordering of
+                      the planes.
+
+   scanline_order - XvTopToBottom or XvBottomToTop.
+
+Note:  Since some formats (particularly some planar YUV formats) may not
+       be completely defined by the parameters above, the guid, when
+       available, should provide the most accurate description of the 
+       format.
+
+
+
+XvImageFormatValues * XvListImageFormats (
+   Display 	*display,
+   XvPortID 	port_id,
+   int 		*count_return
+);
+
+   Returns the XvImageFormatValues supported by the specified port. 
+This list should be freed with XFree().
+   
+
+typedef struct {
+   int id;
+   int width, height;
+   int data_size;
+   int num_planes;
+   int *pitches;
+   int *offsets;
+   char *data;          
+   XPointer obdata;     
+} XvImage;
+
+   id - XvImageFormatValues id.
+   
+   width, height - The width and height of the image in pixels.
+
+   int data_size - The size of the data buffer in bytes.
+
+   num_planes -  The number of image planes.
+
+   pitches -  An array of size num_planes indicating the scanline pitch
+              in bytes.  Each plane may have a different pitch.
+
+   offsets -  An array of size num_planes indicating the byte offset
+              from "data" to the start of each plane.
+
+   data -  A pointer to the start of the data buffer.
+
+   obdata -  A private field for holding SHM info.  This field will be
+             set up by the client libraries so the programmer will 
+             generally need not be concerned with this field.
+
+XvImage * XvCreateImage (
+   Display *display,
+   XvPortID port,
+   int id,
+   char *data,
+   int width, 
+   int height 
+);
+
+   display - Specifies the connection to the Xserver.
+   port    - Specifies the port the XvImage will be used with.
+   id      - Specifies the format of the image to be created by
+	     the XvImageFormatValues id.
+   data    - Specifies the image data.
+   width
+   height  - Specifies the desired width and height of the image.
+
+   This function is similar to XCreateImage.  The library will
+allocate the XvImage structure and fill out all fields except for
+"data".  Width and height may be enlarged in some YUV formats.
+The size of the data buffer that needs to be allocated will be
+give in the "data_size" field in the XvImage.  Image data is 
+not allocated by this function.  The client may pass a pointer
+to the preallocated memory as "data" or may allocate the memory
+and fill in the XvImage structure's data field after the 
+"data_size" field has been filled out by the server.  The XvImage
+structure may be freed by XFree();
+
+
+XvImage * XvShmCreateImage (
+   Display *display,
+   XvPortID port,
+   int id,
+   char* data,
+   int width, 
+   int height,
+   XShmSegmentInfo *shminfo
+);
+
+   This function is similar to XShmCreateImage.  The library will
+allocate the XvImage structure and fill out all fields except for
+"data".  Width and height may be enlarged in some YUV formats.
+The size of the data buffer that needs to be allocated will be
+give in the "data_size" field in the XvImage.  Image data is 
+not allocated by this function.  The client may pass a pointer
+to the preallocated memory as "data" or may allocate the memory
+and fill in the XvImage structure's data field after the 
+"data_size" field has been filled out by the server.  The XvImage
+structure may be freed by XFree();
+
+
+XvPutImage (
+   Display *display,
+   XvPortID id,
+   Drawable d,
+   GC gc,
+   XvImage *image,
+   int src_x,
+   int src_y,
+   unsigned int src_w,
+   unsigned int src_h,
+   int dest_x, 
+   int dest_y,
+   unsigned int dest_w,
+   unsigned int dest_h,
+);
+
+XvShmPutImage (
+   Display *display,
+   XvPortID id,
+   Drawable d,
+   GC gc,
+   XvImage *image,
+   int src_x,
+   int src_y,
+   unsigned int src_w,
+   unsigned int src_h,
+   int dest_x, 
+   int dest_y,
+   unsigned int dest_w,
+   unsigned int dest_h,
+   Bool send_event
+);
+
+   display - The connection to the X-Server.
+
+   id -  The port id of a port on an XvImage capable adaptor.
+
+   d - The target drawable.
+   
+   gc - the graphics context specifying the clip mask to use, if any.
+
+   image - A pointer to the XvImage to be displayed.
+
+   src_? - The portion of the XvImage to be displayed.
+ 
+   dest_? - The portion of the destination drawable to be filled by the image.
+
+   send_event - Indicates whether or not an XShmCompletionEvent should be
+                sent.  If sent, the event's major_code and minor_code
+                fields will indicate the Xv extension's major code and
+                XvShmPutImage's minor code.
+
+Shared memory segments are attached/detached with XShmAttach/Detach.
+
+
+Some of the possible Errors:
+
+   BadDrawable   - The specified drawable does not exist.
+   BadContext    - The specified GC does not exist.
+   BadMatch      - Incompatible arguments such as a port that isn't capable
+                   of displaying XvImages.
+   XvBadPort     - The specified port does not exist.
+   BadAlloc      - The server was unable to allocate resources required 
+                   to complete the operation.
+   BadValue      - Some numeric value falls outside the range of the 
+                   values accepted by the request.
+   BadShmSegCode - An invalid shared memory segment.
diff --git a/hardcopy/Xv/xv-protocol-v2.PS b/hardcopy/Xv/xv-protocol-v2.PS
new file mode 100644
index 0000000..7afd75d
--- /dev/null
+++ b/hardcopy/Xv/xv-protocol-v2.PS
@@ -0,0 +1,8891 @@
+%!PS-Adobe-1.0
+%%Creator: devps (Pipeline Associates, Inc.)
+%%CreationDate: Wed Jul 17 14:26:40 1991
+%%Pages: (atend)
+%%DocumentFonts: (atend)
+
+/X{exch}def
+/r{rmoveto}def
+/m{moveto}def
+/l{lineto}def
+/rl{rlineto}def
+/lc{yc X xc X l st}def
+/mc{yc X xc X m}def
+/el{gs /a X def a div 1 X scale cp np a xc 2 div 0 360 arc st gr}def
+/ar{cp 7 2 roll np xc 5 1 roll atan 3 1 roll atan X arc st}def
+/sp{yc X xc X 6 2 roll yc X xc X 6 2 roll yc X xc X 6 2 roll ct}def
+/st{stroke}def
+/gs{gsave}def
+/gr{grestore}def
+/cp{currentpoint}def
+/np{newpath}def
+/ct{curveto}def
+/m0{0 0 moveto}def
+/BP{/devps-save save def m0}def
+/EP{
+clear devps-save restore
+showpage}def
+/res 10.000000 def
+/V{res neg div 792 add
+currentpoint pop X
+m}def
+/H{res div
+currentpoint X pop
+moveto}def
+/h{res div 0 r}def
+/v{res neg div 0 X r}def
+/xc{res div}def
+/yc{res neg div 792 add}def
+/S{X H show}def
+/psize 10 def
+/height 1 def
+/slant 0 def
+/FF{findfont X dup 12 div setlinewidth /psize X def
+    [psize 0 psize height mul slant sin slant cos div mul psize height mul 0 0]
+    makefont setfont}def
+/shade{gs
+ /dy X def
+ /dx X def
+ np m
+ setgray
+ 0 dy rl
+ dx 0 rl
+ 0 dy neg rl
+ dx neg 0 rl
+ closepath
+ fill
+gr}def
+1 setlinecap
+/R{/Times-Roman FF}def
+/B{/Times-Bold FF}def
+/TB{/Helvetica-Bold FF}def
+/HB{/Helvetica-Bold FF}def
+/I{/Times-Italic FF}def
+/C{/Courier FF}def
+%% Troff special characters not on Symbol font
+%% Copyright (C) 1986 by Pipeline Associates, Inc.
+%% Version 1.1
+/altRTD 20 dict def
+altRTD begin
+/s{setcachedevice}def
+/C{1000 1000 scale}def
+/m{moveto}def
+/c{curveto}def
+/S{stroke}def
+/l{lineto}def
+/a{arcto}def
+/p{pop}def
+/sl{setlinewidth}def
+end
+/F_Troff 17 dict def F_Troff begin
+systemdict /currentpacking known
+{/SavePacking currentpacking def true setpacking}if
+/PaintType 0 def
+/FontType 3 def
+/StrokeWidth 0 def
+/UniqueID 8277003 def
+/FontMatrix [.001000 0 0 .001000 0 0] def
+/FontBBox [-12 -105 942 855 ] def
+/Encoding 256 array def
+/CD 256 1 add dict def
+/FontInfo 3 dict def FontInfo begin
+/UnderlinePosition -133 def /UnderlineThickness 20 def end
+/FontName (Troff) def
+0 1 256 1 sub{Encoding exch /.notdef put}for
+CD /.notdef{500 0 setcharwidth{}}put
+Encoding (1) 0 get /br put
+%% bold vertical rule used by tbl
+CD /br{
+C
+0 0 -.5 -.5 1 1 s
+np
+.05 sl
+0 -.1 m
+0 .9 l
+{S}
+}put
+Encoding (2) 0 get /ul put
+%% underline used by tbl
+CD /ul{
+C
+.5 0 -.5 -.5 1 1 s
+np
+.05 sl
+0 -.1 m
+.5 -.1 l
+{S}
+}put
+Encoding (3) 0 get /ru put
+%% baseline rule
+CD /ru{
+C
+.5 0 -.5 -.5 1 1 s
+np
+.05 sl
+m0
+.5 0 l
+{S}
+}put
+Encoding (4) 0 get /vr put
+%% vertical rule
+CD /vr{
+C
+0 0 -.5 -.5 1 1 s
+np
+.05 sl
+m0
+0 1 l
+{S}
+}put
+Encoding (5) 0 get /sq put
+%% square
+CD /sq{
+C
+.5 0 -.5 -.5 1 1 s
+np
+.05 sl
+0 .25 m
+0 .5 rl
+.5 0 rl
+0 -.5 rl
+-.5 0 rl
+closepath
+{S}
+}put
+Encoding (6) 0 get /bx put
+%% solid box
+CD /bx{
+C
+.5 0 -.5 -.5 1 1 s
+np
+0 .25 m
+0 .5 rl
+.5 0 rl
+0 -.5 rl
+-.5 0 rl
+closepath
+{fill}
+}put
+Encoding (7) 0 get /rn put
+%% radical extender
+CD /rn{
+C
+.5 0 -.5 -.5 1 1 s
+np
+.03 sl
+-.03 .9 m
+.5 0 rl
+{S}
+}put
+Encoding (8) 0 get /GR put
+%% gray mask
+CD /GR{
+C
+.5 0 setcharwidth
+.5 setgray
+np
+0 -.1 m
+0 1 rl
+.5 0 rl
+0 -1 rl
+-.5 0 rl
+closepath
+{fill}
+}put
+Encoding 97 /a put
+CD /a{1000 0 0 66 942 421 s 430 415
+m 578 406 678 349 662 319 c 655 306 614 287 583
+296 c 570 300 466 340 438 332 c 365 309 335 213
+270 209 c 0 310 m 108 310 l 108 114 l 0
+114 l 0 310 l 42 161 m 42 134 l 66 134 l 66
+161 l 42 161 l 47 155 m 47 140 l 62 140 l 62
+155 l 47 155 l 110 133 m 226 113 300 66 410
+80 c 497 91 550 69 634 76 c 645 76 663 92 669
+107 c 677 125 673 141 668 160 c 725 334 m 758
+332 734 253 701 250 c 501 325 m 475 316 476 309
+473 302 c 465 282 482 263 499 257 c 552 236 615
+253 689 253 c 701 253 713 236 713 218 c 712 194
+702 168 678 161 c 671 159 663 160 655 160 c 591
+158 516 156 479 168 c 461 173 453 191 453 210 c 453
+224 456 235 466 244 c 476 253 490 252 503 255 c 459
+84 m 447 96 435 106 435 123 c 435 136 440 145 447
+155 c 453 163 462 168 469 173 c 110 293 m 173
+318 300 421 435 415 c 609 407 852 416 885 411 c 898
+409 924 411 930 380 c 942 316 828 339 742 334 c 731
+334 730 335 725 335 c 701 336 685 336 660 336 c{S}}put
+Encoding 98 /b put
+CD /b{1000 0 -12 66 930 421 s 500
+415 m 352 406 252 349 268 319 c 275 306 316 287
+347 296 c 360 300 464 340 492 332 c 565 309 595
+213 660 209 c 930 310 m 822 310 l 822 114 l 930
+114 l 930 310 l 888 161 m 888 134 l 864 134
+l 864 161 l 888 161 l 883 155 m 883 140 l 868
+140 l 868 155 l 883 155 l 820 133 m 704 113
+630 66 520 80 c 433 91 380 69 296 76 c 285 76
+267 92 261 107 c 253 125 257 141 262 160 c 205
+334 m 172 332 196 253 229 250 c 429 325 m 455
+316 454 309 457 302 c 465 282 448 263 431 257 c 378
+236 315 253 241 253 c 229 253 217 236 217 218 c 218
+194 228 168 252 161 c 259 159 267 160 275 160 c 339
+158 414 156 451 168 c 469 173 477 191 477 210 c 477
+224 474 235 464 244 c 454 253 440 252 427 255 c 471
+84 m 483 96 495 106 495 123 c 495 136 490 145 483
+155 c 477 163 468 168 461 173 c 820 293 m 757
+318 630 421 495 415 c 321 407 78 416 45 411 c 32
+409 6 411 0 380 c -12 316 102 339 188 334 c 199
+334 200 335 205 335 c 229 336 245 336 270 336 c{S}}put
+Encoding 99 /c put
+CD /c{1000 0 184 0 827 627 s 185 315
+m 186 488 332 627 505 625 c 682 623 827 467 815
+290 c 804 124 666 0 500 0 c 327 0 184 142 185
+315 c{S}}put
+Encoding 100 /d put
+CD /d{590 0 134 158 477 500 s 300
+160 m 208 162 134 238 135 330 c 136 423 212 500
+305 500 c 397 500 473 427 475 335 c 477 239 396
+158 300 160 c{fill}}put
+Encoding 101 /e put	% Bell Symbol
+CD /e{1010 0 -100 -210 1010 1010 s 100 sl 0 setlinecap
+420 300 450 0 360 arc
+420 650 m 420 575 l S
+newpath 120 125 m 720 125 l 75 sl S
+420 125 m 420 25 l S
+220 400 m 220 175 120 175 100 a p p p p
+220 400 m 220 550 420 550 80 a p p p p 
+620 400 m 620 175 720 175 100 a p p p p
+620 400 m 620 550 420 550 80 a p p p p
+295 550 m 545 550 l{S}}put
+/BuildChar{altRTD /BuildChar get exec}def end
+altRTD begin /BuildChar{altRTD begin
+/char exch def /fontdict exch def save
+/charname fontdict /Encoding get char get def
+fontdict /StrokeWidth get sl
+fontdict /CD get dup charname known
+{charname}{/.notdef}ifelse get newpath exec
+fontdict /PaintType get 0 eq{exec}{p S}ifelse
+restore end}def end
+systemdict /currentpacking known{F_Troff /SavePacking get setpacking}if
+/Troff F_Troff definefont pop
+/Y1{/Troff FF}def
+/TR{/Helvetica FF}def
+%%EndProlog
+%%Page: 1 1
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 TB
+4966(Xv)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(Xv)S
+1052(---)S
+1181(X)S
+1283(Window)S
+1657(System)S
+1982(video)S
+2234(extension)S
+720 H
+1368 V
+9 B
+720(Description)S
+720 H
+1488 V
+10 R
+900(The)S
+1085(Xv)S
+1237(extension)S
+1650(provides)S
+2024(support)S
+2354(for)S
+2500(video)S
+2752(adaptors)S
+3120(attached)S
+3482(to)S
+3590(an)S
+3714(X)S
+3816(display.)S
+4190(It)S
+4281(takes)S
+4516(the)S
+4668(approach)S
+5063(that)S
+5243(a)S
+720 H
+1608 V
+900(display)S
+1219(may)S
+1421(have)S
+1639(one)S
+1813(or)S
+1926(more)S
+2161(video)S
+2413(adaptors,)S
+2806(each)S
+3018(of)S
+3131(which)S
+3405(has)S
+3568(one)S
+3742(or)S
+3855(more)S
+4090(ports)S
+4320(though)S
+4628(which)S
+4902(independent)S
+720 H
+1728 V
+900(video)S
+1152(streams)S
+1487(pass.)S
+720 H
+1896 V
+900(An)S
+1052(adaptor)S
+1381(may)S
+1583(be)S
+1707(able)S
+1903(to)S
+2011(display)S
+2330(video)S
+2582(in)S
+2690(a)S
+2764(drawable,)S
+3184(capture)S
+3507(video)S
+3759(from)S
+3983(a)S
+4057(drawable,)S
+4477(or)S
+4590(both.)S
+4853(It)S
+4944(translates)S
+720 H
+2016 V
+900(between)S
+1262(video)S
+1514(encoding)S
+1910(\(NTSC,)S
+2254(PAL,)S
+2498(SECAM,)S
+2898(etc...\))S
+3152(and)S
+3326(drawable)S
+3721(format)S
+4017(\(depth)S
+4302(and)S
+4476(visual-id)S
+4856(pair\).)S
+5099(An)S
+720 H
+2136 V
+900(adaptor)S
+1229(may)S
+1431(support)S
+1761(multiple)S
+2125(video)S
+2377(encodings)S
+2812(and/or)S
+3097(multiple)S
+3461(drawable)S
+3856(formats.)S
+720 H
+2304 V
+900(Clients)S
+1214(use)S
+1377(Xv\(3X\))S
+1717(to)S
+1825(gain)S
+2027(access)S
+2311(and)S
+2485(manage)S
+2825(sharing)S
+3149(of)S
+3262(a)S
+3336(display's)S
+3727(video)S
+3979(resources.)S
+4440(Typically,)S
+4878(a)S
+4952(client)S
+5204(will)S
+720 H
+2424 V
+900(use)S
+1063(XvQueryExtension\(3X\))S
+2052(to)S
+2160(determine)S
+2589(the)S
+2741(status)S
+2999(of)S
+3112(the)S
+3264(extension,)S
+3702(XvQueryAdaptors\(3X\))S
+4657(to)S
+4765(get)S
+4917(a)S
+4991(descrip-)S
+720 H
+2544 V
+900(tion)S
+1086(of)S
+1199(what)S
+1423(video)S
+1675(adaptors)S
+2043(exist,)S
+2287(and)S
+2461(XvQueryEncodings\(3X\))S
+3472(to)S
+3580(get)S
+3732(a)S
+3806(description)S
+4280(of)S
+4393(what)S
+4617(video)S
+4869(encodings)S
+5304(an)S
+720 H
+2664 V
+900(adaptor)S
+1229(supports.)S
+720 H
+2832 V
+900(Once)S
+1140(a)S
+1214(client)S
+1466(has)S
+1629(determined)S
+2108(what)S
+2332(video)S
+2584(resources)S
+2990(are)S
+3141(available,)S
+3556(it)S
+3642(is)S
+3739(free)S
+3923(to)S
+4031(put)S
+4189(video)S
+4441(into)S
+4627(a)S
+4701(drawable)S
+5096(or)S
+5209(get)S
+720 H
+2952 V
+900(video)S
+1152(from)S
+1376(a)S
+1450(drawable,)S
+1870(according)S
+2293(the)S
+2445(capabilities)S
+2930(supported.)S
+3409(Clients)S
+3723(can)S
+3891(select)S
+4148(to)S
+4256(receive)S
+4573(events)S
+4858(when)S
+5104(video)S
+720 H
+3072 V
+900(activity)S
+1230(changes)S
+1581(in)S
+1689(a)S
+1763(drawable)S
+2158(and)S
+2332(when)S
+2578(port)S
+2769(attributes)S
+3171(have)S
+3389(changed.)S
+720 H
+3240 V
+9 B
+720(Summary)S
+1142(of)S
+1259(Library)S
+1606(Functions)S
+720 H
+3360 V
+10 R
+900(The)S
+1085(following)S
+1504(is)S
+1601(a)S
+1675(summary)S
+2077(of)S
+2190(Xv)S
+2342(library)S
+2638(functions:)S
+720 H
+3600 V
+900(XvGetPortAttribute\(3X\))S
+1912(\261)S
+1992(return)S
+2260(current)S
+2572(port)S
+2763(attribute)S
+3126(value)S
+720 H
+3840 V
+900(XvGetStill\(3X\))S
+1552(\261)S
+1632(capture)S
+1955(a)S
+2029(single)S
+2298(frame)S
+2560(of)S
+2673(video)S
+2925(from)S
+3149(a)S
+3223(drawable)S
+720 H
+4080 V
+900(XvGetVideo\(3X\))S
+1628(\261)S
+1708(capture)S
+2031(video)S
+2283(from)S
+2507(a)S
+2581(drawable)S
+720 H
+4320 V
+900(XvGrabPort\(3X\))S
+1606(\261)S
+1686(lock)S
+1888(port)S
+2079(for)S
+2225(exclusive)S
+2632(use)S
+2795(by)S
+2925(client)S
+720 H
+4560 V
+900(XvPortNotify\(3X\))S
+1668(\261)S
+1748(event)S
+1994(generated)S
+2411(when)S
+2657(port)S
+2848(attributes)S
+3250(change)S
+720 H
+4800 V
+900(XvPutStill\(3X\))S
+1542(\261)S
+1622(write)S
+1857(a)S
+1931(single)S
+2200(frame)S
+2462(of)S
+2575(video)S
+2827(to)S
+2935(a)S
+3009(drawable)S
+720 H
+5040 V
+900(XvPutVideo\(3X\))S
+1618(\261)S
+1698(write)S
+1933(video)S
+2185(into)S
+2371(a)S
+2445(drawable)S
+720 H
+5280 V
+900(XvQueryAdaptors\(3X\))S
+1855(\261)S
+1935(return)S
+2203(adaptor)S
+2532(information)S
+3034(for)S
+3180(a)S
+3254(screen)S
+720 H
+5520 V
+900(XvQueryBestSize\(3X\))S
+1839(\261)S
+1919(determine)S
+2348(the)S
+2500(optimum)S
+2892(drawable)S
+3287(region)S
+3572(size)S
+720 H
+5760 V
+900(XvQueryEncodings\(3X\))S
+1911(\261)S
+1991(return)S
+2259(list)S
+2412(of)S
+2525(encodings)S
+2960(for)S
+3106(an)S
+3230(adaptor)S
+720 H
+6000 V
+900(XvQueryExtension\(3X\))S
+1889(\261)S
+1969(return)S
+2237(version)S
+2561(and)S
+2735(revision)S
+3087(of)S
+3200(extension)S
+720 H
+6240 V
+900(XvSelectPortNotify\(3X\))S
+1912(\261)S
+1992(enable)S
+2282(or)S
+2395(disable)S
+2708(XvPortNotify)S
+3288(events)S
+720 H
+6480 V
+900(XvSelectVideoNotify\(3X\))S
+1989(\261)S
+2069(enable)S
+2359(or)S
+2472(disable)S
+2785(XvVideoNotify)S
+3442(events)S
+720 H
+6720 V
+900(XvSetPortAttribute\(3X\))S
+1896(\261)S
+1976(set)S
+2117(an)S
+2241(attribute)S
+2604(for)S
+2750(a)S
+2824(port)S
+720 H
+6960 V
+900(XvStopVideo\(3X\))S
+1668(\261)S
+1748(stop)S
+1945(active)S
+2213(video)S
+720 H
+7200 V
+900(XvUngrabPort\(3X\))S
+1706(\261)S
+1786(release)S
+2092(a)S
+2166(grabbed)S
+2517(port)S
+720 H
+7680 V
+5350(1)S
+7920 V
+EP
+%%Page: 2 2
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(Xv)S
+887(\()S
+947(3X)S
+1114(\))S
+720 H
+1080 V
+10 R
+900(XvVideoNotify\(3X\))S
+1745(\261)S
+1825(event)S
+2071(generated)S
+2488(for)S
+2634(video)S
+2886(processing)S
+720 H
+1368 V
+900(Each)S
+1129(of)S
+1242(these)S
+1477(functions)S
+1879(is)S
+1976(described)S
+2388(in)S
+2496(its)S
+2621(own)S
+2823(Xv)S
+2975(man)S
+3177(page.)S
+720 H
+7680 V
+720(2)S
+7920 V
+EP
+%%Page: 3 3
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4033(XvFreeAdaptorInfo)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvFreeAdaptorInfo)S
+1722(\261)S
+1802(free)S
+1986(adaptor)S
+2315(information)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(XvFreeAdaptorInfo\()S
+10 I
+1787(p_adaptor_info)S
+10 R
+2410(\))S
+720 H
+1728 V
+10 B
+900(XvAdaptorInfo)S
+10 I
+1591(*p_adaptor_info)S
+10 R
+2264(;)S
+720 H
+1896 V
+9 B
+720(Arguments)S
+720 H
+2016 V
+10 I
+900(p_adaptor_info)S
+720 H
+2136 V
+10 R
+1300(Pointer)S
+1619(to)S
+1727(where)S
+2000(the)S
+2152(adaptor)S
+2481(information)S
+2983(is)S
+3080(located.)S
+720 H
+2304 V
+9 B
+720(Description)S
+720 H
+2424 V
+10 R
+900(XvFreeAdaptorInfo\(3X\))S
+1910(frees)S
+2133(adaptor)S
+2462(information)S
+2964(that)S
+3144(was)S
+3329(returned)S
+3691(by)S
+3821(XvQueryAdaptors\(3X\).)S
+4831(The)S
+5016(data)S
+720 H
+2544 V
+900(structure)S
+1279(used)S
+1492(for)S
+1638(adaptor)S
+1967(information)S
+2469(is)S
+2566(de\256ned)S
+2890(in)S
+2998(the)S
+3150(reference)S
+3549(page)S
+3767(for)S
+3913(XvQueryAdaptors\(3X\).)S
+720 H
+2712 V
+9 B
+720(Examples)S
+720 H
+2832 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+3060 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3180 V
+10 R
+900(XvQueryAdaptors\(3X\),)S
+1880(XvFreeEncodingInfo\(3X\))S
+720 H
+7680 V
+5350(3)S
+7920 V
+EP
+%%Page: 4 4
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvFreeEncodingInfo)S
+1907(\()S
+1967(3X)S
+2134(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvFreeEncodingInfo)S
+1778(\261)S
+1858(free)S
+2042(encoding)S
+2438(information)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(XvFreeEncodingInfo\()S
+10 I
+1833(p_encoding_info)S
+10 R
+2505(\))S
+720 H
+1728 V
+10 B
+900(XvEncodingInfo)S
+10 I
+1637(*p_encoding_info)S
+10 R
+2359(;)S
+720 H
+1896 V
+9 B
+720(Arguments)S
+720 H
+2016 V
+10 I
+900(p_encoding_info)S
+720 H
+2136 V
+10 R
+1300(Pointer)S
+1619(to)S
+1727(where)S
+2000(the)S
+2152(encoding)S
+2548(information)S
+3050(is)S
+3147(located.)S
+720 H
+2304 V
+9 B
+720(Description)S
+720 H
+2424 V
+10 R
+900(XvFreeEncodingInfo\(3X\))S
+1966(frees)S
+2189(encoding)S
+2585(information)S
+3087(that)S
+3267(was)S
+3452(returned)S
+3814(by)S
+3944(XvQueryEncodings\(3X\).)S
+5010(The)S
+5195(data)S
+720 H
+2544 V
+900(structure)S
+1279(used)S
+1492(for)S
+1638(encoding)S
+2034(information)S
+2536(is)S
+2633(de\256ned)S
+2957(in)S
+3065(the)S
+3217(reference)S
+3616(page)S
+3834(for)S
+3980(XvQueryEncodings\(3X\).)S
+720 H
+2712 V
+9 B
+720(Examples)S
+720 H
+2832 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+3060 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3180 V
+10 R
+900(XvQueryEncodings\(3X\))S
+720 H
+7680 V
+720(4)S
+7920 V
+EP
+%%Page: 5 5
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4025(XvGetPortAttribute)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvGetPortAttribute)S
+1724(\261)S
+1804(return)S
+2072(current)S
+2384(port)S
+2575(attribute)S
+2938(value)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvGetPortAttribute\()S
+10 I
+1797(dpy,)S
+1996(port,)S
+2218(attribute,)S
+2618(p_value)S
+10 R
+2934(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Atom)S
+10 I
+1168(attribute)S
+10 R
+1513(;)S
+720 H
+2328 V
+10 B
+900(int)S
+10 I
+1047(*p_vlaue)S
+10 R
+1413(;)S
+720 H
+2616 V
+9 B
+720(Arguments)S
+720 H
+2736 V
+10 I
+900(dpy)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(display)S
+2162(screen)S
+2446(on)S
+2576(which)S
+2850(the)S
+3002(X)S
+3104(Server)S
+3394(is)S
+3491(to)S
+3599(accept)S
+3883(requests)S
+4240(from)S
+4464(X)S
+4566(clients.)S
+4912(If)S
+5008(the)S
+720 H
+2856 V
+1300(display)S
+1619(option)S
+1905(is)S
+2002(not)S
+2160(speci\256ed,)S
+2570(X)S
+2672(uses)S
+2874(the)S
+3026(display)S
+3345(screen)S
+3629(speci\256ed)S
+4014(by)S
+4144(your)S
+4357(DISPLAY)S
+4809(environment)S
+720 H
+2976 V
+1300(variable.)S
+1706(The)S
+1891(display)S
+2210(option)S
+2496(has)S
+2659(the)S
+2811(format)S
+3107(hostname:number.)S
+3908(Using)S
+4177(two)S
+4357(colons)S
+4648(\(::\))S
+4800(instead)S
+5113(of)S
+5226(one)S
+720 H
+3096 V
+1300(\(:\))S
+1424(indicates)S
+1809(that)S
+1989(DECnet)S
+2341(is)S
+2438(to)S
+2546(be)S
+2670(used)S
+2883(for)S
+3029(transport.)S
+720 H
+3264 V
+10 I
+900(port)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(port,)S
+2059(associated)S
+2499(with)S
+2707(the)S
+2859(given)S
+3111(display,)S
+3455(for)S
+3601(which)S
+3875(the)S
+4027(attribute)S
+4390(values)S
+4675(are)S
+4826(to)S
+4934(be)S
+720 H
+3384 V
+1300(returned.)S
+720 H
+3552 V
+10 I
+900(attribute)S
+10 R
+1300(An)S
+1452(atom)S
+1682(that)S
+1862(identi\256es)S
+2259(the)S
+2411(attribute)S
+2774(to)S
+2882(be)S
+3006(queried)S
+3335(by)S
+3465(this)S
+3640(request.)S
+4013(Control)S
+4349(atoms)S
+4618(are)S
+4769(obtained)S
+5143(using)S
+720 H
+3672 V
+1300(the)S
+1452(XInterAtom)S
+1970(request)S
+2288(with)S
+2496(a)S
+2570(string)S
+2828(from)S
+3052(the)S
+3204(following)S
+3623(table.)S
+720 H
+3840 V
+10 I
+900(p_value)S
+10 R
+1300(Pointer)S
+1619(to)S
+1727(the)S
+1879(location)S
+2231(where)S
+2504(the)S
+2656(attribute)S
+3019(value)S
+3265(is)S
+3362(written)S
+3675(on)S
+3805(return.)S
+720 H
+4008 V
+9 B
+720(Description)S
+720 H
+4128 V
+10 R
+900(XvGetPortAttribute\(3X\))S
+1912(returns)S
+2219(the)S
+2371(current)S
+2683(value)S
+2929(of)S
+3042(the)S
+3194(requested)S
+3606(port)S
+3797(attribute)S
+4160(in)S
+4268(the)S
+4420(integer)S
+4727(pointed)S
+5057(to)S
+5165(by)S
+720 H
+4248 V
+10 I
+900(p_value)S
+10 R
+1216(.)S
+1271(The)S
+1456(attribute)S
+1819(is)S
+1916(identi\256ed)S
+2324(using)S
+2571(an)S
+2695(Atom)S
+2953(that)S
+3133(equates)S
+3462(to)S
+3570(the)S
+3722(attribute)S
+4085(name.)S
+4356(The)S
+4541(XInterAtom)S
+5059(request)S
+720 H
+4368 V
+900(can)S
+1068(be)S
+1192(used)S
+1405(with)S
+1613(one)S
+1787(of)S
+1900(the)S
+2052(strings)S
+2349(below)S
+2623(to)S
+2731(return)S
+2999(a)S
+3073(matching)S
+3475(Atom.)S
+720 H
+7680 V
+5350(5)S
+7920 V
+EP
+%%Page: 6 6
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvGetPortAttribute)S
+1828(\()S
+1888(3X)S
+2055(\))S
+720 H
+980 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+1148 V
+10 HB
+900(Attribute)S
+1344(String)S
+1964(Type)S
+2724(Default)S
+720 H
+1228 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+1408 V
+10 R
+900("XV_ENCODING")S
+1964(XvEncodingID)S
+2724(Server)S
+3014(dependent)S
+720 H
+1528 V
+900("XV_HUE")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1648 V
+900("XV_SATURATION")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1768 V
+900("XV_BRIGHTNESS")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1888 V
+900("XV_CONTRAST")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1968 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+2136 V
+9 B
+720(Examples)S
+720 H
+2256 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+2484 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+2604 V
+10 B
+900([Success])S
+720 H
+2724 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetPortAttribute\(3X\))S
+2799(completed)S
+3245(successfully.)S
+720 H
+2892 V
+10 B
+900([XvBadExtension])S
+720 H
+3012 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+3180 V
+10 B
+900([XvBadAlloc])S
+720 H
+3300 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetPortAttribute\(3X\))S
+2799(failed)S
+3056(to)S
+3164(allocate)S
+3504(memory)S
+3867(to)S
+3975(process)S
+4304(the)S
+4456(request.)S
+720 H
+3468 V
+9 B
+720(Diagnostics)S
+720 H
+3588 V
+10 B
+900([XvBadPort])S
+720 H
+3708 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+3876 V
+10 B
+900([BadMatch])S
+720 H
+3996 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(attribute)S
+2757(atom)S
+2987(does)S
+3200(not)S
+3358(specify)S
+3676(an)S
+3800(attribute)S
+4163(supported)S
+4587(by)S
+4717(the)S
+4869(adaptor.)S
+720 H
+4164 V
+9 B
+720(See)S
+892(Also)S
+720 H
+4284 V
+10 R
+900(XvSetPortAttribute\(3X\),)S
+1921(XvPortNotify\(3X\))S
+720 H
+7680 V
+720(6)S
+7920 V
+EP
+%%Page: 7 7
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4543(XvGetStill)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvGetStill)S
+1364(\261)S
+1444(capture)S
+1767(a)S
+1841(single)S
+2110(frame)S
+2372(of)S
+2485(video)S
+2737(from)S
+2961(a)S
+3035(drawable)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(include)S
+1242(Xvlib.h)S
+720 H
+1728 V
+900(XvGetStill\()S
+10 I
+1383(dpy,)S
+1582(port,)S
+1804(d,)S
+1909(gc,)S
+2058(vx,)S
+2201(vy,)S
+720 H
+1968 V
+10 B
+900(register)S
+10 I
+1256(Display)S
+1597(*dpy;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port;)S
+720 H
+2208 V
+10 B
+900(Drawable)S
+10 I
+1346(d;)S
+720 H
+2328 V
+10 B
+900(GC)S
+10 I
+1080(gc;)S
+720 H
+2448 V
+10 B
+900(int)S
+10 I
+1047(vx,)S
+1190(vy,)S
+1333(dx,)S
+1482(dy;)S
+720 H
+2568 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(vw,)S
+1628(vh;)S
+720 H
+2688 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(dw,)S
+1634(dh;)S
+720 H
+2976 V
+9 B
+720(Arguments)S
+720 H
+3096 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+3216 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+3336 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+3456 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3624 V
+10 I
+900(port)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(port)S
+2328(to)S
+2436(which)S
+2710(the)S
+2862(still)S
+3043(is)S
+3140(outputed.)S
+720 H
+3792 V
+10 I
+900(d)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(drawable)S
+2532(from)S
+2756(which)S
+3030(the)S
+3182(still)S
+3363(is)S
+3460(to)S
+3568(be)S
+3692(captured.)S
+720 H
+3960 V
+10 I
+900(gc)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(graphical)S
+2538(context.)S
+2917(GC)S
+3086(components)S
+3599(are:)S
+10 I
+3778(subwindow-mode,)S
+4533(clip-x-origin,)S
+5093(clip-y-)S
+720 H
+4080 V
+1650(origin,)S
+10 R
+1950(and)S
+10 I
+2124(clip-mask.)S
+720 H
+4248 V
+900(vx,vy,vw,vh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(destination)S
+3543(video)S
+3795(region)S
+4080(into)S
+4266(which)S
+4540(the)S
+4692(still)S
+4873(is)S
+4970(to)S
+5078(be)S
+5202(writ-)S
+720 H
+4368 V
+1650(ten.)S
+10 I
+1857(vx)S
+10 R
+1975(and)S
+10 I
+2149(vy)S
+10 R
+2267(de\256ne)S
+2541(the)S
+10 I
+2693(x)S
+2767(and)S
+2947(y)S
+10 R
+3021(coordinates)S
+3511(of)S
+3624(the)S
+3776(upper-left)S
+4199(corner)S
+4483(of)S
+4596(the)S
+4748(video)S
+5000(region;)S
+720 H
+4488 V
+10 I
+1650(vw)S
+1791(and)S
+1971(vh)S
+10 R
+2095(de\256ne)S
+2369(the)S
+2521(width)S
+2779(and)S
+2953(height,)S
+3258(in)S
+3366(pixels,)S
+3660(of)S
+3773(the)S
+3925(video)S
+4177(region.)S
+720 H
+4656 V
+10 I
+900(dx,dy,dw,dh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(source)S
+3364(drawable)S
+3759(from)S
+3983(which)S
+4257(the)S
+4409(still)S
+4590(image)S
+4864(is)S
+4961(to)S
+5069(be)S
+5193(cap-)S
+720 H
+4776 V
+1650(tured.)S
+10 I
+1910(dx)S
+2034(and)S
+2214(dy)S
+10 R
+2338(de\256ne)S
+2612(the)S
+10 I
+2764(x)S
+2838(and)S
+3018(y)S
+10 R
+3092(coordinates)S
+3582(of)S
+3695(the)S
+3847(upper-left)S
+4270(corner)S
+4554(of)S
+4667(the)S
+4819(drawable)S
+720 H
+4896 V
+1650(region;)S
+10 I
+1963(dw)S
+2110(and)S
+2290(dh)S
+10 R
+2420(de\256ne)S
+2694(the)S
+2846(width)S
+3104(and)S
+3278(height,)S
+3583(in)S
+3691(pixels,)S
+3985(of)S
+4098(the)S
+4250(drawable)S
+4645(region.)S
+720 H
+5064 V
+9 B
+720(Description)S
+720 H
+5184 V
+10 TR
+916(XvGetStill)S
+10 R
+1402(captures)S
+1764(a)S
+1838(single)S
+2107(frame)S
+2369(of)S
+2482(video)S
+2734(from)S
+2958(a)S
+3032(drawable.)S
+3482(The)S
+3667(position)S
+4020(and)S
+4194(size)S
+4379(of)S
+4492(the)S
+4644(destination)S
+720 H
+5304 V
+900(\(video\))S
+1218(rectangle)S
+1613(is)S
+1710(speci\256ed)S
+2095(by)S
+10 I
+2225(vx,)S
+2368(vy,)S
+2511(vw)S
+10 R
+2622(,)S
+2677(and)S
+10 I
+2851(vh)S
+10 R
+2945(.)S
+3030(The)S
+3215(position)S
+3568(and)S
+3742(size)S
+3927(of)S
+4040(the)S
+4192(source)S
+4482(\(drawable\))S
+4943(rectangle)S
+720 H
+5424 V
+900(is)S
+997(speci\256ed)S
+1382(by)S
+10 I
+1512(dx,)S
+1661(dy,)S
+1810(dw)S
+10 R
+1927(,)S
+1982(and)S
+10 I
+2156(dh)S
+10 R
+2256(.)S
+720 H
+5592 V
+900(Drawable)S
+1317(data)S
+1513(is)S
+1610(clipped)S
+1934(to)S
+2042(the)S
+2194(bounds)S
+2513(of)S
+2626(the)S
+2778(drawable,)S
+3198(scaled)S
+3477(to)S
+3585(the)S
+3737(requested)S
+4149(video)S
+4401(region)S
+4686(size)S
+4871(\(or)S
+5017(the)S
+720 H
+5712 V
+900(closest)S
+1202(size)S
+1387(supported\))S
+1844(and)S
+2018(clipped)S
+2342(to)S
+2450(the)S
+2602(bounds)S
+2921(of)S
+3034(the)S
+3186(video)S
+3438(encoding.)S
+3889(The)S
+4074(contents)S
+4437(of)S
+4550(any)S
+4724(region)S
+5009(not)S
+720 H
+5832 V
+900(updated)S
+1246(with)S
+1454(drawable)S
+1849(data)S
+2045(is)S
+2142(unde\256ned.)S
+720 H
+6000 V
+900(If)S
+996(the)S
+1148(still)S
+1329(is)S
+1426(successfully)S
+1944(captured)S
+2317(an)S
+2441(XvVideoNotify)S
+3098(event)S
+3344(with)S
+3552(detail)S
+3804(XvStill)S
+4124(is)S
+4221(generated)S
+4638(for)S
+4784(the)S
+4936(drawable.)S
+720 H
+6120 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(grabbed)S
+1787(by)S
+1917(another)S
+2246(client,)S
+2523(this)S
+2698(request)S
+3016(is)S
+3113(ignored,)S
+3473(and)S
+3647(an)S
+3771(XvVideoNotify)S
+4428(event)S
+4674(with)S
+4882(detail)S
+720 H
+6240 V
+900(XvBusy)S
+1258(is)S
+1355(generated)S
+1772(for)S
+1918(the)S
+2070(drawable.)S
+720 H
+6408 V
+9 B
+720(Examples)S
+720 H
+7680 V
+10 R
+5350(7)S
+7920 V
+EP
+%%Page: 8 8
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 TB
+720(XvGetStill)S
+1310(\()S
+1370(3X)S
+1537(\))S
+720 H
+1080 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+1308 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+1428 V
+10 B
+900([Success])S
+720 H
+1548 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetStill\(3X\))S
+2439(completed)S
+2885(successfully.)S
+720 H
+1716 V
+10 B
+900([XvBadExtension])S
+720 H
+1836 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+2004 V
+10 B
+900([XvBadAlloc])S
+720 H
+2124 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetStill\(3X\))S
+2439(failed)S
+2696(to)S
+2804(allocate)S
+3144(memory)S
+3507(to)S
+3615(process)S
+3944(the)S
+4096(request.)S
+720 H
+2292 V
+9 B
+720(Diagnostics)S
+720 H
+2412 V
+10 B
+900([XvBadPort])S
+720 H
+2532 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+2700 V
+10 B
+900([BadDrawable])S
+720 H
+2820 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+2988 V
+10 B
+900([BadGC])S
+720 H
+3108 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(graphics)S
+2762(context)S
+3086(does)S
+3299(not)S
+3457(exist.)S
+720 H
+3276 V
+10 B
+900([BadAlloc])S
+720 H
+3396 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(there)S
+2059(were)S
+2282(insu)S
+2449 H
+	(f)show 10 -.5 mul h (\256)show
+10 R
+2533(cient)S
+2757(resources)S
+3163(to)S
+3271(process)S
+3600(the)S
+3752(request.)S
+720 H
+3564 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3684 V
+10 R
+900(XvPutStill\(3X\),)S
+1567(XvGetVideo\(3X\),)S
+2320(XvPutVideo\(3X\),)S
+3063(XvVideoNotify\(3X\))S
+720 H
+7680 V
+720(8)S
+7920 V
+EP
+%%Page: 9 9
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4438(XvGetVideo)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvGetVideo)S
+1440(\261)S
+1520(capture)S
+1843(video)S
+2095(from)S
+2319(a)S
+2393(drawable)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(include)S
+1242(Xvlib.h)S
+720 H
+1728 V
+900(XvGetVideo\(dpy,)S
+1677(port,)S
+1915(d,)S
+2026(gc,)S
+2175(vx,)S
+2330(vy,)S
+720 H
+1968 V
+900(register)S
+10 I
+1256(Display)S
+1597(*dpy;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port;)S
+720 H
+2208 V
+10 B
+900(Drawable)S
+10 I
+1346(d;)S
+720 H
+2328 V
+10 B
+900(GC)S
+10 I
+1080(gc;)S
+720 H
+2448 V
+10 B
+900(int)S
+10 I
+1047(vx,)S
+1190(vy,)S
+1333(dx,)S
+1482(dy;)S
+720 H
+2568 V
+10 R
+900(unsigned)S
+1291(int)S
+10 I
+1427(vw,)S
+1593(vh;)S
+720 H
+2688 V
+10 R
+900(unsigned)S
+1291(int)S
+10 I
+1427(dw,)S
+1599(dh;)S
+720 H
+2976 V
+9 B
+720(Arguments)S
+720 H
+3096 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+3216 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+3336 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+3456 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3624 V
+10 I
+900(port)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(port)S
+2328(to)S
+2436(which)S
+2710(video)S
+2962(output)S
+3248(is)S
+3345(sent.)S
+720 H
+3792 V
+10 I
+900(d)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(drawable)S
+2532(from)S
+2756(which)S
+3030(video)S
+3282(output)S
+3568(is)S
+3665(to)S
+3773(be)S
+3897(obtained.)S
+720 H
+3960 V
+10 I
+900(gc)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(graphical)S
+2538(context.)S
+2917(GC)S
+3086(components)S
+3599(are:)S
+10 I
+3778(subwindow-mode,)S
+4533(clip-x-origin,)S
+5093(clip-y-)S
+720 H
+4080 V
+1650(origin,)S
+10 R
+1950(and)S
+10 I
+2124(clip-mask.)S
+720 H
+4248 V
+900(vx,vy,vw,vh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(video)S
+3326(region)S
+3611(is)S
+3708(to)S
+3816(be)S
+3940(written.)S
+10 I
+4308(vx)S
+10 R
+4426(and)S
+10 I
+4600(vy)S
+10 R
+4718(de\256ne)S
+4992(the)S
+10 I
+5144(x)S
+5218(and)S
+720 H
+4368 V
+1650(y)S
+10 R
+1724(coordinates)S
+2214(of)S
+2327(the)S
+2479(upper-left)S
+2902(corner)S
+3186(of)S
+3299(the)S
+3451(video)S
+3703(region;)S
+10 I
+4016(vw)S
+4157(and)S
+4337(vh)S
+10 R
+4461(de\256ne)S
+4735(the)S
+4887(width)S
+5145(and)S
+720 H
+4488 V
+1650(height,)S
+1955(in)S
+2063(pixels,)S
+2357(of)S
+2470(the)S
+2622(video)S
+2874(region.)S
+720 H
+4656 V
+10 I
+900(dx,dy,dw,dh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(of)S
+2563(the)S
+2715(source)S
+3005(drawable)S
+3400(from)S
+3624(which)S
+3898(the)S
+4050(video)S
+4302(image)S
+4576(is)S
+4673(to)S
+4781(be)S
+4905(taken.)S
+10 I
+5176(dx)S
+720 H
+4776 V
+1650(and)S
+1830(dy)S
+10 R
+1954(de\256ne)S
+2228(the)S
+10 I
+2380(x)S
+2454(and)S
+2634(y)S
+10 R
+2708(coordinates)S
+3198(of)S
+3311(the)S
+3463(upper-left)S
+3886(corner)S
+4170(of)S
+4283(the)S
+4435(drawable)S
+4830(region;)S
+10 I
+5143(dw)S
+720 H
+4896 V
+1650(and)S
+1830(dh)S
+10 R
+1960(de\256ne)S
+2234(the)S
+2386(width)S
+2644(and)S
+2818(height,)S
+3123(in)S
+3231(pixels,)S
+3525(of)S
+3638(the)S
+3790(drawable)S
+4185(region.)S
+720 H
+5064 V
+9 B
+720(Description)S
+720 H
+5184 V
+10 TR
+916(XvGetVideo)S
+10 R
+1498(outputs)S
+1823(video)S
+2075(from)S
+2299(a)S
+2373(drawable.)S
+2823(The)S
+3008(position)S
+3361(and)S
+3535(size)S
+3720(of)S
+3833(the)S
+3985(destination)S
+4454(rectangle)S
+4849(is)S
+4946(speci\256ed)S
+720 H
+5304 V
+900(by)S
+10 I
+1030(vx,)S
+1173(vy,)S
+1316(vw,)S
+10 R
+1482(and)S
+10 I
+1656(vh.)S
+10 R
+1805(The)S
+1990(position)S
+2343(and)S
+2517(size)S
+2702(of)S
+2815(the)S
+2967(source)S
+3257(rectangle)S
+3652(is)S
+3749(speci\256ed)S
+4134(by)S
+10 I
+4264(dx,)S
+4413(dy,)S
+4562(dw,)S
+10 R
+4734(and)S
+10 I
+4908(dh.)S
+720 H
+5472 V
+10 R
+900(Drawable)S
+1317(data)S
+1513(is)S
+1610(clipped)S
+1934(to)S
+2042(the)S
+2194(bounds)S
+2513(of)S
+2626(the)S
+2778(drawable,)S
+3198(scaled)S
+3477(to)S
+3585(the)S
+3737(requested)S
+4149(video)S
+4401(region)S
+4686(size)S
+4871(\(or)S
+5017(the)S
+720 H
+5592 V
+900(closest)S
+1202(size)S
+1387(supported\))S
+1844(and)S
+2018(clipped)S
+2342(to)S
+2450(the)S
+2602(bounds)S
+2921(of)S
+3034(the)S
+3186(video)S
+3438(encoding.)S
+3889(The)S
+4074(contents)S
+4437(of)S
+4550(any)S
+4724(region)S
+5009(not)S
+720 H
+5712 V
+900(updated)S
+1246(with)S
+1454(drawable)S
+1849(data)S
+2045(is)S
+2142(unde\256ned.)S
+720 H
+5880 V
+900(If)S
+996(video)S
+1248(is)S
+1345(successfully)S
+1863(initiated,)S
+2246(an)S
+2370(XvVideoNotify)S
+3027(event)S
+3273(with)S
+3481(detail)S
+3733(XvStarted)S
+4168(is)S
+4265(generated)S
+4682(for)S
+4828(the)S
+4980(drawable.)S
+720 H
+6000 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(already)S
+1759(in)S
+1867(use,)S
+2055(its)S
+2180(video)S
+2432(is)S
+2529(preempted,)S
+3005(and)S
+3179(if)S
+3270(the)S
+3422(new)S
+3618(drawable)S
+4013(is)S
+4110(di)S
+4188 H
+	(f)show 10 -.5 mul h (f)show
+10 R
+4249(erent)S
+4478(than)S
+4680(the)S
+4832(old,)S
+5015(an)S
+5139(XvVi-)S
+720 H
+6120 V
+900(deoNotify)S
+1335(event)S
+1581(with)S
+1789(detail)S
+2041(XvPreempted)S
+2620(is)S
+2717(generated)S
+3134(for)S
+3280(the)S
+3432(old)S
+3590(drawable.)S
+4040(If)S
+4136(the)S
+4288(port)S
+4479(is)S
+4576(grabbed)S
+4927(by)S
+5057(another)S
+720 H
+6240 V
+900(client,)S
+1177(this)S
+1352(request)S
+1670(is)S
+1767(ignored,)S
+2127(and)S
+2301(an)S
+2425(XvVideoNotify)S
+3082(event)S
+3328(with)S
+3536(detail)S
+3788(XvBusy)S
+4146(is)S
+4243(generated)S
+4660(for)S
+4806(the)S
+4958(drawable.)S
+720 H
+6408 V
+9 B
+720(Examples)S
+720 H
+7680 V
+10 R
+5350(9)S
+7920 V
+EP
+%%Page: 10 10
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 TB
+720(XvGetVideo)S
+1415(\()S
+1475(3X)S
+1642(\))S
+720 H
+1080 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+1308 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+1428 V
+10 B
+900([Success])S
+720 H
+1548 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetVideo\(3X\))S
+2515(completed)S
+2961(successfully.)S
+720 H
+1716 V
+10 B
+900([XvBadExtension])S
+720 H
+1836 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+2004 V
+10 B
+900([XvBadAlloc])S
+720 H
+2124 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetVideo\(3X\))S
+2515(failed)S
+2772(to)S
+2880(allocate)S
+3220(memory)S
+3583(to)S
+3691(process)S
+4020(the)S
+4172(request.)S
+720 H
+2292 V
+9 B
+720(Diagnostics)S
+720 H
+2412 V
+10 B
+900([XvBadPort])S
+720 H
+2532 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+2700 V
+10 B
+900([BadGC])S
+720 H
+2820 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(graphics)S
+2762(context)S
+3086(does)S
+3299(not)S
+3457(exist.)S
+720 H
+2988 V
+10 B
+900([BadDrawable])S
+720 H
+3108 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+3276 V
+10 B
+900([BadAlloc])S
+720 H
+3396 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(there)S
+2059(were)S
+2282(insu)S
+2449 H
+	(f)show 10 -.5 mul h (\256)show
+10 R
+2533(cient)S
+2757(resources)S
+3163(to)S
+3271(process)S
+3600(the)S
+3752(request.)S
+720 H
+3564 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3684 V
+10 R
+900(XvGetStill\(3X\),)S
+1577(XvPutVideo\(3X\),)S
+2320(XvVideoNotify\(3X\))S
+720 H
+7680 V
+720(10)S
+7920 V
+EP
+%%Page: 11 11
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4445(XvGrabPort)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvGrabPort)S
+1418(\261)S
+1498(lock)S
+1700(port)S
+1891(for)S
+2037(exclusive)S
+2444(use)S
+2607(by)S
+2737(client)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvGrabPort\()S
+10 I
+1471(dpy,)S
+1670(port,)S
+1892(time\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port;)S
+720 H
+2208 V
+10 B
+900(Time)S
+10 I
+1152(time;)S
+720 H
+2376 V
+9 B
+720(Arguments)S
+720 H
+2496 V
+10 I
+900(dpy)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(display)S
+2162(screen)S
+2446(on)S
+2576(which)S
+2850(the)S
+3002(Xv)S
+3154(Server)S
+3444(is)S
+3541(to)S
+3649(accept)S
+3933(requests)S
+4290(from)S
+4514(Xv)S
+4666(clients.)S
+5012(If)S
+5108(the)S
+720 H
+2616 V
+1300(display)S
+1619(option)S
+1905(is)S
+2002(not)S
+2160(speci\256ed,)S
+2570(Xv)S
+2722(uses)S
+2924(the)S
+3076(display)S
+3395(screen)S
+3679(speci\256ed)S
+4064(by)S
+4194(your)S
+4407(DISPLAY)S
+4859(environment)S
+720 H
+2736 V
+1300(variable.)S
+1706(The)S
+1891(display)S
+2210(option)S
+2496(has)S
+2659(the)S
+2811(format)S
+3107(hostname:number.)S
+3908(Using)S
+4177(two)S
+4357(colons)S
+4648(\(::\))S
+4800(instead)S
+5113(of)S
+5226(one)S
+720 H
+2856 V
+1300(\(:\))S
+1424(indicates)S
+1809(that)S
+1989(DECnet)S
+2341(is)S
+2438(to)S
+2546(be)S
+2670(used)S
+2883(for)S
+3029(transport.)S
+720 H
+3024 V
+10 I
+900(port)S
+10 R
+1300(De\256nes)S
+1635(the)S
+1787(port)S
+1978(to)S
+2086(be)S
+2210(grabbed.)S
+720 H
+3192 V
+10 I
+900(time)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(request)S
+2161(timestamp.)S
+720 H
+3360 V
+9 B
+720(Description)S
+720 H
+3480 V
+10 R
+900(XvGrabPort\(3X\))S
+1606(grabs)S
+1852(a)S
+1926(port.)S
+2172(Once)S
+2412(a)S
+2486(client)S
+2738(grabs)S
+2984(a)S
+3058(port,)S
+3274(only)S
+3482(that)S
+3662(client)S
+3914(can)S
+4082(make)S
+4328(video)S
+4580(requests)S
+4937(to)S
+5045(that)S
+720 H
+3600 V
+900(port.)S
+720 H
+3768 V
+900(If)S
+996(the)S
+1148(time)S
+1356(is)S
+1453(before)S
+1737(the)S
+1889(current)S
+2201(port)S
+2392(time,)S
+2625(the)S
+2777(XvGrabPort)S
+3295(request)S
+3613(is)S
+3710(ignored)S
+4045(and)S
+4219(XvInvalidTime)S
+4865(is)S
+4962(returned.)S
+720 H
+3888 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(already)S
+1759(grabbed)S
+2110(by)S
+2240(another)S
+2569(client,)S
+2846(XvAlreadyGrabbed)S
+3662(is)S
+3759(returned.)S
+4146(Otherwise)S
+4586(a)S
+4660(it)S
+4746(returns)S
+5053(a)S
+5127(status)S
+720 H
+4008 V
+900(of)S
+10 I
+1013(Success)S
+10 R
+1323(.)S
+1408(The)S
+1593(port)S
+1784(time)S
+1992(is)S
+2089(updated)S
+2435(when)S
+2681(the)S
+2833(following)S
+3252(requests)S
+3609(are)S
+3760(processed:)S
+4211(XvGrabPort\(3X\),)S
+720 H
+4128 V
+900(XvUngrabPort\(3X\),)S
+1731(XvPutVideo\(3X\),)S
+2474(XvPutStill\(3X\),)S
+3141(XvGetVideo\(3X\),)S
+3894(XvGetStill\(3X\).)S
+720 H
+4296 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(actively)S
+1782(processing)S
+2239(video)S
+2491(for)S
+2637(another)S
+2966(client,)S
+3243(the)S
+3395(video)S
+3647(is)S
+3744(preempted,)S
+4220(and)S
+4394(an)S
+4518(XvVideoNotify)S
+5175(event)S
+720 H
+4416 V
+900(with)S
+1108(detail)S
+1360(XvPreempted)S
+1939(is)S
+2036(generated)S
+2453(for)S
+2599(its)S
+2724(drawable.)S
+720 H
+4584 V
+9 B
+720(Examples)S
+720 H
+4704 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+4932 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+5052 V
+10 B
+900([Success])S
+720 H
+5172 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGrabPort\(3X\))S
+2493(completed)S
+2939(successfully.)S
+720 H
+5340 V
+10 B
+900([XvInvalidTime])S
+720 H
+5460 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(requested)S
+2199(time)S
+2407(is)S
+2504(older)S
+2739(than)S
+2941(the)S
+3093(current)S
+3405(port)S
+3596(time.)S
+720 H
+5628 V
+10 B
+900([XvAlreadyGrabbed])S
+720 H
+5748 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(port)S
+2130(is)S
+2227(already)S
+2550(grabbed)S
+2901(by)S
+3031(another)S
+3360(client.)S
+720 H
+5916 V
+10 B
+900([XvBadExtension])S
+720 H
+6036 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+6204 V
+10 B
+900([XvBadAlloc])S
+720 H
+6324 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGrabPort\(3X\))S
+2493(failed)S
+2750(to)S
+2858(allocate)S
+3198(memory)S
+3561(to)S
+3669(process)S
+3998(the)S
+4150(request.)S
+720 H
+6492 V
+9 B
+720(Diagnostics)S
+720 H
+6612 V
+10 B
+900([XvBadPort])S
+10 R
+1650(Generated)S
+2089(if)S
+2180(the)S
+2332(requested)S
+2744(port)S
+2935(does)S
+3148(not)S
+3306(exist.)S
+720 H
+6780 V
+9 B
+720(See)S
+892(Also)S
+720 H
+6900 V
+10 R
+900(XvUngrabPort\(3X\))S
+1706(XvVideoNotify\(3X\))S
+720 H
+7680 V
+5300(11)S
+7920 V
+EP
+%%Page: 12 12
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvPortNotify)S
+1467(\()S
+1527(3X)S
+1694(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvPortNotify)S
+1480(\261)S
+1560(event)S
+1806(generated)S
+2223(when)S
+2469(port)S
+2660(attributes)S
+3062(change)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1908 V
+10 C
+1450(typedef)S
+1930(union)S
+2290({)S
+720 H
+2028 V
+1570(int)S
+1810(type;)S
+720 H
+2148 V
+1570(XvVideoNotifyEvent)S
+2710(xvvideo;)S
+720 H
+2268 V
+1570(XvPortNotifyEvent)S
+2650(xvport;)S
+720 H
+2388 V
+1450(})S
+1570(XvEvent;)S
+720 H
+2628 V
+1450(typedef)S
+1930(struct)S
+2350({)S
+720 H
+2748 V
+1570(int)S
+1810(type;)S
+720 H
+2868 V
+1570(unsigned)S
+2110(long)S
+2410(serial;)S
+720 H
+2988 V
+1570(Bool)S
+1870(send_event;)S
+720 H
+3108 V
+1570(Display)S
+2050(*display;)S
+720 H
+3228 V
+1570(XvPortID)S
+2110(port_id;)S
+720 H
+3348 V
+1570(Time)S
+1870(time;)S
+720 H
+3468 V
+1570(Atom)S
+1870(attribute;)S
+720 H
+3588 V
+1570(long)S
+1870(value;)S
+720 H
+3708 V
+1450(})S
+1570(XvPortNotifyEvent;)S
+720 H
+4056 V
+10 I
+900(type)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(type)S
+2045(of)S
+2158(event:)S
+2432(XvPortNotify.)S
+720 H
+4224 V
+10 I
+900(serial)S
+10 R
+1300(Number)S
+1657(of)S
+1770(the)S
+1922(last)S
+2091(request)S
+2409(processed)S
+2832(by)S
+2962(the)S
+3114(server.)S
+720 H
+4392 V
+10 I
+900(send_event)S
+720 H
+4512 V
+10 R
+1300(True)S
+1518(if)S
+1609(the)S
+1761(event)S
+2007(was)S
+2192(generated)S
+2609(by)S
+2739(a)S
+2813(SendEvent)S
+3276(request.)S
+720 H
+4680 V
+10 I
+900(display)S
+10 R
+1300(A)S
+1402(pointer)S
+1715(to)S
+1823(the)S
+1975(display)S
+2294(the)S
+2446(event)S
+2692(was)S
+2877(read)S
+3078(from.)S
+720 H
+4848 V
+10 I
+900(port_id)S
+10 R
+1300(The)S
+1485(port)S
+1676(whose)S
+1961(attribute)S
+2324(has)S
+2487(changed.)S
+720 H
+5016 V
+10 I
+900(attribute)S
+10 R
+1300(An)S
+1452(atom)S
+1682(specifying)S
+2128(the)S
+2280(attribute)S
+2643(that)S
+2823(changed.)S
+720 H
+5184 V
+10 I
+900(value)S
+10 R
+1300(The)S
+1485(new)S
+1681(value)S
+1927(of)S
+2040(the)S
+2192(attribute.)S
+720 H
+5352 V
+9 B
+720(Description)S
+720 H
+5472 V
+10 R
+900(XvPortNotify)S
+1480(events)S
+1765(are)S
+1916(generated)S
+2333(when)S
+2579(a)S
+2653(port)S
+2844(attribute)S
+3207(is)S
+3304(set)S
+3445(using)S
+3692(the)S
+3844(XvSetPortAttribute\(3X\))S
+4840(function.)S
+720 H
+5640 V
+9 B
+720(Examples)S
+720 H
+5760 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+5988 V
+9 B
+720(See)S
+892(Also)S
+720 H
+6108 V
+10 R
+900(XvSetPortAttribute\(3X\),)S
+1921(XvGetPortAttribute\(3X\),)S
+2958(XvSelectPortNotify\(3X\))S
+720 H
+7680 V
+720(12)S
+7920 V
+EP
+%%Page: 13 13
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4551(XvPutStill)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvPutStill)S
+1354(\261)S
+1434(write)S
+1669(a)S
+1743(single)S
+2012(frame)S
+2274(of)S
+2387(video)S
+2639(to)S
+2747(a)S
+2821(drawable)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvPutStill\()S
+10 I
+1378(dpy,)S
+1577(port,)S
+1799(d,)S
+1904(gc,)S
+2053(vx,)S
+2196(vy,)S
+2339(vw,)S
+2505(vh,)S
+2654(dx,)S
+2803(dy,)S
+2952(dw,)S
+3124(dh)S
+10 R
+3224(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port;)S
+720 H
+2208 V
+10 B
+900(Drawable)S
+10 I
+1346(d;)S
+720 H
+2328 V
+10 B
+900(GC)S
+10 I
+1080(gc;)S
+720 H
+2448 V
+10 B
+900(int)S
+10 I
+1047(vx,)S
+1190(vy,)S
+1333(dx,)S
+1482(dy;)S
+720 H
+2568 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(vw,)S
+1628(vh;)S
+720 H
+2688 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(dw,)S
+1634(dh;)S
+720 H
+2976 V
+9 B
+720(Arguments)S
+720 H
+3096 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+3216 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+3336 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+3456 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3624 V
+10 I
+900(port)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(port)S
+2328(from)S
+2552(which)S
+2826(to)S
+2934(get)S
+3086(the)S
+3238(still.)S
+720 H
+3792 V
+10 I
+900(d)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(drawable)S
+2532(into)S
+2718(which)S
+2992(the)S
+3144(still)S
+3325(is)S
+3422(to)S
+3530(be)S
+3654(written.)S
+720 H
+3960 V
+10 I
+900(gc)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(graphical)S
+2538(context.)S
+2887(GC)S
+3056(components)S
+3569(are:)S
+10 I
+3748(subwindow-mode,)S
+4503(clip-x-origin,)S
+5063(clip-y-)S
+720 H
+4080 V
+1650(origin,)S
+10 R
+1950(and)S
+10 I
+2124(clip-mask.)S
+720 H
+4248 V
+900(vx,vy,vw,vh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(video)S
+3326(region)S
+3611(to)S
+3719(be)S
+3843(written.)S
+10 I
+4211(vx)S
+10 R
+4329(and)S
+10 I
+4503(vy)S
+10 R
+4621(de\256ne)S
+4895(the)S
+5047(upper-)S
+720 H
+4368 V
+1650(left)S
+1813(pixel)S
+2043(of)S
+2156(the)S
+2308(region.)S
+10 I
+2618(vw)S
+10 R
+2759(and)S
+10 I
+2933(vh)S
+10 R
+3057(de\256ne)S
+3331(the)S
+3483(width)S
+3741(and)S
+3915(height,)S
+4220(in)S
+4328(pixels,)S
+4622(of)S
+4735(the)S
+4887(region.)S
+720 H
+4536 V
+10 I
+900(dx,dy,dw,dh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(destination)S
+3543(region)S
+3828(into)S
+4014(which)S
+4288(the)S
+4440(still)S
+4621(image)S
+4895(is)S
+4992(written.)S
+720 H
+4656 V
+10 I
+1650(dx)S
+10 R
+1774(and)S
+10 I
+1948(dy)S
+10 R
+2072(de\256ne)S
+2346(the)S
+2498(upper-left)S
+2921(corner)S
+3205(of)S
+3318(the)S
+3470(region.)S
+10 I
+3780(dw)S
+10 R
+3927(and)S
+10 I
+4101(dh)S
+10 R
+4231(de\256ne)S
+4505(the)S
+4657(width)S
+4915(and)S
+5089(height,)S
+720 H
+4776 V
+1650(in)S
+1758(pixels,)S
+2052(of)S
+2165(the)S
+2317(region.)S
+720 H
+4944 V
+9 B
+720(Description)S
+720 H
+5064 V
+10 R
+900(XvPutStill\(3X\))S
+1542(writes)S
+1816(a)S
+1890(single)S
+2159(frame)S
+2421(of)S
+2534(video)S
+2786(to)S
+2894(a)S
+2968(drawable.)S
+3388(The)S
+3573(position)S
+3926(and)S
+4100(size)S
+4285(of)S
+4398(the)S
+4550(source)S
+4840(\(video\))S
+5158(rec-)S
+720 H
+5184 V
+900(tangle)S
+1174(is)S
+1271(speci\256ed)S
+1656(by)S
+10 I
+1786(vx,)S
+1929(vy,)S
+2072(vw)S
+10 R
+2183(,)S
+2238(and)S
+10 I
+2412(vh)S
+10 R
+2506(.)S
+2591(The)S
+2776(position)S
+3129(and)S
+3303(size)S
+3488(of)S
+3601(the)S
+3753(destination)S
+4222(\(drawable\))S
+4683(rectangle)S
+5078(is)S
+720 H
+5304 V
+900(speci\256ed)S
+1285(by)S
+10 I
+1415(dx,)S
+1564(dy,)S
+1713(dw)S
+10 R
+1830(,)S
+1885(and)S
+10 I
+2059(dh)S
+10 R
+2159(.)S
+720 H
+5472 V
+900(Video)S
+1174(data)S
+1370(is)S
+1467(clipped)S
+1791(to)S
+1899(the)S
+2051(bounds)S
+2370(of)S
+2483(the)S
+2635(video)S
+2887(encoding,)S
+3308(scaled)S
+3587(to)S
+3695(the)S
+3847(requested)S
+4259(drawable)S
+4654(region)S
+4939(size)S
+5124(\(or)S
+5270(the)S
+720 H
+5592 V
+900(closest)S
+1202(size)S
+1387(supported\))S
+1844(and)S
+2018(clipped)S
+2342(to)S
+2450(the)S
+2602(bounds)S
+2921(of)S
+3034(the)S
+3186(drawable.)S
+720 H
+5760 V
+900(If)S
+996(the)S
+1148(still)S
+1329(is)S
+1426(successfully)S
+1944(rendered)S
+2322(an)S
+2446(XvVideoNotify)S
+3103(event)S
+3349(with)S
+3557(detail)S
+3809(XvStill)S
+4129(is)S
+4226(generated)S
+4643(for)S
+4789(the)S
+4941(drawable.)S
+720 H
+5880 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(grabbed)S
+1787(by)S
+1917(another)S
+2246(client,)S
+2523(this)S
+2698(request)S
+3016(is)S
+3113(ignored,)S
+3473(and)S
+3647(an)S
+3771(XvVideoNotify)S
+4428(event)S
+4674(with)S
+4882(detail)S
+720 H
+6000 V
+900(XvBusy)S
+1258(is)S
+1355(generated)S
+1772(for)S
+1918(the)S
+2070(drawable.)S
+720 H
+6168 V
+9 B
+720(Examples)S
+720 H
+6288 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+6516 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+6636 V
+10 B
+900([Success])S
+720 H
+6756 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvPutStill\(3X\))S
+2429(completed)S
+2875(successfully.)S
+720 H
+6924 V
+10 B
+900([XvBadExtension])S
+720 H
+7044 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+7212 V
+10 B
+900([XvBadAlloc])S
+720 H
+7692 V
+10 R
+5300(13)S
+7920 V
+EP
+%%Page: 14 14
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvPutStill)S
+1302(\()S
+1362(3X)S
+1529(\))S
+720 H
+1080 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvGetStill\(3X\))S
+2439(failed)S
+2696(to)S
+2804(allocate)S
+3144(memory)S
+3507(to)S
+3615(process)S
+3944(the)S
+4096(request.)S
+720 H
+1248 V
+9 B
+720(Diagnostics)S
+720 H
+1368 V
+10 B
+900([XvBadPort])S
+720 H
+1488 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+1656 V
+10 B
+900([BadDrawable])S
+720 H
+1776 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+1944 V
+10 B
+900([BadGC])S
+720 H
+2064 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(graphics)S
+2762(context)S
+3086(does)S
+3299(not)S
+3457(exist.)S
+720 H
+2232 V
+10 B
+900([BadAlloc])S
+720 H
+2352 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(there)S
+2059(were)S
+2282(insu)S
+2449 H
+	(f)show 10 -.5 mul h (\256)show
+10 R
+2533(cient)S
+2757(resources)S
+3163(to)S
+3271(process)S
+3600(the)S
+3752(request.)S
+720 H
+2520 V
+9 B
+720(See)S
+892(Also)S
+720 H
+2640 V
+10 R
+900(XvPutVideo\(3X\),)S
+1643(XvGetStill\(3X\),)S
+2320(XvVideoNotify\(3X\))S
+720 H
+7680 V
+720(14)S
+7920 V
+EP
+%%Page: 15 15
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4446(XvPutVideo)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvPutVideo)S
+1430(\261)S
+1510(write)S
+1745(video)S
+1997(into)S
+2183(a)S
+2257(drawable)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvPutVideo\()S
+10 I
+1455(dpy,)S
+1654(port,)S
+1876(d,)S
+1981(gc,)S
+2130(vx,)S
+2273(vy,)S
+2416(vw,)S
+2582(vh,)S
+2731(dx,)S
+2880(dy,)S
+3029(dw,)S
+3201(dh)S
+10 R
+3301(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port;)S
+720 H
+2208 V
+10 B
+900(Drawable)S
+10 I
+1346(d;)S
+720 H
+2328 V
+10 B
+900(GC)S
+10 I
+1080(gc;)S
+720 H
+2448 V
+10 B
+900(int)S
+10 I
+1047(vx,)S
+1190(vy,)S
+1333(dx,)S
+1482(dy;)S
+720 H
+2568 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(vw,)S
+1628(vh;)S
+720 H
+2688 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(dw,)S
+1634(dh;)S
+720 H
+2976 V
+9 B
+720(Arguments)S
+720 H
+3096 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+3216 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+3336 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+3456 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3624 V
+10 I
+900(port)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(port)S
+2328(from)S
+2552(which)S
+2826(to)S
+2934(get)S
+3086(video.)S
+720 H
+3792 V
+10 I
+900(d)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(drawable)S
+2532(into)S
+2718(which)S
+2992(video)S
+3244(is)S
+3341(to)S
+3449(be)S
+3573(written.)S
+720 H
+3960 V
+10 I
+900(gc)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(graphical)S
+2538(context.)S
+2887(GC)S
+3056(components)S
+3569(are:)S
+10 I
+3748(subwindow-mode,)S
+4503(clip-x-origin,)S
+5063(clip-y-)S
+720 H
+4080 V
+1650(origin,)S
+10 R
+1950(and)S
+10 I
+2124(clip-mask.)S
+720 H
+4248 V
+900(vx,vy,vw,vh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(size)S
+2283(and)S
+2457(location)S
+2809(of)S
+2922(the)S
+3074(source)S
+3364(\(video\))S
+3682(region)S
+3967(to)S
+4075(be)S
+4199(written.)S
+10 I
+4567(vx)S
+10 R
+4685(and)S
+10 I
+4859(vy)S
+10 R
+4977(de\256ne)S
+5251(the)S
+720 H
+4368 V
+1650(upper-left)S
+2073(pixel)S
+2303(of)S
+2416(the)S
+2568(region.)S
+10 I
+2878(vw)S
+10 R
+3019(and)S
+10 I
+3193(vh)S
+10 R
+3317(de\256ne)S
+3591(the)S
+3743(width)S
+4001(and)S
+4175(height,)S
+4480(in)S
+4588(pixels,)S
+4882(of)S
+4995(the)S
+720 H
+4488 V
+1650(region.)S
+720 H
+4656 V
+10 I
+900(dx,dy,dw,dh)S
+10 R
+1650(De\256ne)S
+1946(the)S
+2098(location)S
+2450(and)S
+2624(size)S
+2809(of)S
+2922(the)S
+3074(destination)S
+3543(\(drawable\))S
+4004(region)S
+4289(into)S
+4475(which)S
+4749(the)S
+4901(video)S
+5153(image)S
+720 H
+4776 V
+1650(is)S
+1747(written.)S
+10 I
+2085(dx)S
+10 R
+2209(and)S
+10 I
+2383(dy)S
+10 R
+2507(de\256ne)S
+2781(the)S
+2933(upper-left)S
+3356(pixel)S
+3586(of)S
+3699(the)S
+3851(region.)S
+10 I
+4191(dw)S
+10 R
+4338(and)S
+10 I
+4512(dh)S
+10 R
+4642(de\256ne)S
+4916(the)S
+5068(width)S
+720 H
+4896 V
+1650(and)S
+1824(height,)S
+2129(in)S
+2237(pixels,)S
+2531(of)S
+2644(the)S
+2796(region.)S
+720 H
+5064 V
+9 B
+720(Description)S
+720 H
+5184 V
+10 R
+900(XvPutVideo)S
+1430(writes)S
+1704(video)S
+1956(into)S
+2142(a)S
+2216(drawable.)S
+2666(The)S
+2851(position)S
+3204(and)S
+3378(size)S
+3563(of)S
+3676(the)S
+3828(source)S
+4118(\(video\))S
+4436(rectangle)S
+4831(is)S
+4928(speci\256ed)S
+720 H
+5304 V
+900(by)S
+10 I
+1030(vx,)S
+1173(vy,)S
+1316(vw)S
+10 R
+1427(,)S
+1482(and)S
+10 I
+1656(vh)S
+10 R
+1750(.)S
+1805(The)S
+1990(position)S
+2343(and)S
+2517(size)S
+2702(of)S
+2815(the)S
+2967(destination)S
+3436(\(drawable\))S
+3897(rectangle)S
+4292(is)S
+4389(speci\256ed)S
+4774(by)S
+10 I
+4904(dx,)S
+5053(dy,)S
+5202(dw)S
+10 R
+5319(,)S
+720 H
+5424 V
+900(and)S
+10 I
+1074(dh)S
+10 R
+1174(.)S
+720 H
+5592 V
+900(Video)S
+1174(data)S
+1370(is)S
+1467(clipped)S
+1791(to)S
+1899(the)S
+2051(bounds)S
+2370(of)S
+2483(the)S
+2635(video)S
+2887(encoding,)S
+3308(scaled)S
+3587(to)S
+3695(the)S
+3847(requested)S
+4259(drawable)S
+4654(region)S
+4939(size)S
+5124(\(or)S
+5270(the)S
+720 H
+5712 V
+900(closest)S
+1202(size)S
+1387(supported\))S
+1844(and)S
+2018(clipped)S
+2342(to)S
+2450(the)S
+2602(bounds)S
+2921(of)S
+3034(the)S
+3186(drawable.)S
+720 H
+5880 V
+900(If)S
+996(video)S
+1248(is)S
+1345(successfully)S
+1863(initiated,)S
+2246(an)S
+2370(XvVideoNotify)S
+3027(event)S
+3273(with)S
+3481(detail)S
+3733(XvStarted)S
+4168(is)S
+4265(generated)S
+4682(for)S
+4828(the)S
+4980(drawable.)S
+720 H
+6000 V
+900(If)S
+996(the)S
+1148(port)S
+1339(is)S
+1436(already)S
+1759(in)S
+1867(use,)S
+2055(its)S
+2180(video)S
+2432(is)S
+2529(preempted,)S
+3005(and)S
+3179(if)S
+3270(the)S
+3422(new)S
+3618(drawable)S
+4013(is)S
+4110(di)S
+4188 H
+	(f)show 10 -.5 mul h (f)show
+10 R
+4249(erent)S
+4478(than)S
+4680(the)S
+4832(old,)S
+5015(an)S
+5139(XvVi-)S
+720 H
+6120 V
+900(deoNotify)S
+1335(event)S
+1581(with)S
+1789(detail)S
+2041(XvPreempted)S
+2620(is)S
+2717(generated)S
+3134(for)S
+3280(the)S
+3432(old)S
+3590(drawable.)S
+4040(If)S
+4136(the)S
+4288(port)S
+4479(is)S
+4576(grabbed)S
+4927(by)S
+5057(another)S
+720 H
+6240 V
+900(client,)S
+1177(this)S
+1352(request)S
+1670(is)S
+1767(ignored,)S
+2127(and)S
+2301(an)S
+2425(XvVideoNotify)S
+3082(event)S
+3328(with)S
+3536(detail)S
+3788(XvBusy)S
+4146(is)S
+4243(generated)S
+4660(for)S
+4806(the)S
+4958(drawable.)S
+720 H
+6408 V
+9 B
+720(Examples)S
+720 H
+6528 V
+10 R
+900(Example)S
+1285(between)S
+1647(.EX)S
+1835(and)S
+2009(.EE)S
+2186(will)S
+2372(show)S
+2613(in)S
+2721(monospace)S
+720 H
+6756 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+6876 V
+10 B
+900([Success])S
+720 H
+6996 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvPutVideo\(3X\))S
+2505(completed)S
+2951(successfully.)S
+720 H
+7164 V
+10 B
+900([XvBadExtension])S
+720 H
+7284 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+7764 V
+5300(15)S
+7920 V
+EP
+%%Page: 16 16
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvPutVideo)S
+1407(\()S
+1467(3X)S
+1634(\))S
+720 H
+1080 V
+10 B
+900([XvBadAlloc])S
+720 H
+1200 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(there)S
+2016(were)S
+2239(insu)S
+2406 H
+	(f)show 10 -.5 mul h (\256)show
+10 R
+2490(cient)S
+2714(resources)S
+3120(to)S
+3228(process)S
+3557(the)S
+3709(request.)S
+720 H
+1368 V
+9 B
+720(Diagnostics)S
+720 H
+1488 V
+10 B
+900([XvBadPort])S
+720 H
+1608 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+1776 V
+10 B
+900([BadDrawable])S
+720 H
+1896 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+2064 V
+10 B
+900([BadGC])S
+720 H
+2184 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(graphics)S
+2762(context)S
+3086(does)S
+3299(not)S
+3457(exist.)S
+720 H
+2352 V
+10 B
+900([BadAlloc])S
+720 H
+2472 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(there)S
+2059(were)S
+2282(insu)S
+2449 H
+	(f)show 10 -.5 mul h (\256)show
+10 R
+2533(cient)S
+2757(resources)S
+3163(to)S
+3271(process)S
+3600(the)S
+3752(request.)S
+720 H
+2640 V
+9 B
+720(See)S
+892(Also)S
+720 H
+2760 V
+10 R
+900(XvPutStill\(3X\),)S
+1567(XvGetVideo\(3X\),)S
+2320(XvVideoNotify\(3X\))S
+720 H
+7680 V
+720(16)S
+7920 V
+EP
+%%Page: 17 17
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4092(XvQueryAdaptors)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvQueryAdaptors)S
+1667(\261)S
+1747(return)S
+2015(adaptor)S
+2344(information)S
+2846(for)S
+2992(a)S
+3066(screen)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvQueryAdaptors\()S
+10 I
+1727(dpy,)S
+1926(win,)S
+2126(p_num_adaptors,)S
+2859(pp_adaptor_info)S
+10 R
+3532(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy;)S
+720 H
+2088 V
+10 B
+900(Drawable)S
+10 I
+1376(draw;)S
+720 H
+2208 V
+10 B
+900(int)S
+10 I
+1047(*p_num_adaptors)S
+10 R
+1775(;)S
+720 H
+2328 V
+10 B
+900(XvAdaptorInfo)S
+10 I
+1591(**pp_adaptor_info)S
+10 R
+2364(;)S
+720 H
+2496 V
+9 B
+720(Arguments)S
+720 H
+2616 V
+10 I
+900(dpy)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(display)S
+2162(screen)S
+2446(on)S
+2576(which)S
+2850(the)S
+3002(Xv)S
+3154(Server)S
+3444(is)S
+3541(to)S
+3649(accept)S
+3933(requests)S
+4290(from)S
+4514(Xv)S
+4666(clients.)S
+5012(If)S
+5108(the)S
+720 H
+2736 V
+1300(display)S
+1619(option)S
+1905(is)S
+2002(not)S
+2160(speci\256ed,)S
+2570(Xv)S
+2722(uses)S
+2924(the)S
+3076(display)S
+3395(screen)S
+3679(speci\256ed)S
+4064(by)S
+4194(your)S
+4407(DISPLAY)S
+4859(environment)S
+720 H
+2856 V
+1300(variable.)S
+1706(The)S
+1891(display)S
+2210(option)S
+2496(has)S
+2659(the)S
+2811(format)S
+3107(hostname:number.)S
+3908(Using)S
+4177(two)S
+4357(colons)S
+4648(\(::\))S
+4800(instead)S
+5113(of)S
+5226(one)S
+720 H
+2976 V
+1300(\(:\))S
+1424(indicates)S
+1809(that)S
+1989(DECnet)S
+2341(is)S
+2438(to)S
+2546(be)S
+2670(used)S
+2883(for)S
+3029(transport.)S
+720 H
+3144 V
+10 I
+900(draw)S
+10 R
+1300(Speci\256es)S
+1691(a)S
+1765(drawable)S
+2160(of)S
+2273(the)S
+2425(screen)S
+2709(for)S
+2855(which)S
+3129(the)S
+3281(adaptor)S
+3610(information)S
+4112(is)S
+4209(desired.)S
+720 H
+3312 V
+10 I
+900(p_num_adaptors)S
+720 H
+3432 V
+10 R
+1300(A)S
+1402(pointer)S
+1715(to)S
+1823(where)S
+2096(the)S
+2248(numer)S
+2533(of)S
+2646(adaptors)S
+3014(for)S
+3160(the)S
+3312(speci\256ed)S
+3697(screen)S
+3981(is)S
+4078(returned.)S
+720 H
+3600 V
+10 I
+900(pp_adaptor_info)S
+720 H
+3720 V
+10 R
+1300(A)S
+1402(pointer)S
+1715(to)S
+1823(where)S
+2096(the)S
+2248(list)S
+2401(of)S
+2514(returned)S
+2876(adaptor)S
+3205(information)S
+3707(is)S
+3804(returned.)S
+720 H
+3888 V
+9 B
+720(Description)S
+720 H
+4008 V
+10 R
+900(XvQueryAdaptors\(3X\))S
+1855(returns)S
+2162(an)S
+2286(video)S
+2538(adaptor)S
+2867(information)S
+3369(for)S
+3515(the)S
+3667(screen)S
+3951(of)S
+4064(the)S
+4216(speci\256ed)S
+4601(drawable.)S
+5051(The)S
+720 H
+4128 V
+900(XvAdaptorInfo)S
+1545(structure)S
+1924(has)S
+2087(the)S
+2239(following)S
+2658(organization:)S
+720 H
+4428 V
+10 C
+1450(typedef)S
+1930(struct)S
+2350({)S
+720 H
+4548 V
+1570(XvPortID)S
+2110(base_id;)S
+720 H
+4668 V
+1570(unsigned)S
+2110(long)S
+2410(num_ports;)S
+720 H
+4788 V
+1570(char)S
+1870(type;)S
+720 H
+4908 V
+1570(char)S
+1870(*name;)S
+720 H
+5028 V
+1570(unsigned)S
+2110(long)S
+2410(num_formats;)S
+720 H
+5148 V
+1570(XvFormat)S
+2110(*formats;)S
+720 H
+5268 V
+1450(})S
+1570(XvAdaptorInfo;)S
+720 H
+5616 V
+10 I
+900(base_id)S
+10 R
+1300(The)S
+1485(resource)S
+1852(ID)S
+1987(of)S
+2100(the)S
+2252(\256rst)S
+2438(adaptor)S
+2767(port.)S
+720 H
+5784 V
+10 I
+900(num_ports)S
+720 H
+5904 V
+10 R
+1300(The)S
+1485(number)S
+1820(of)S
+1933(ports)S
+2163(supported)S
+2587(by)S
+2717(the)S
+2869(adaptor.)S
+720 H
+6072 V
+10 I
+900(type)S
+10 R
+1300(A)S
+1402(bit)S
+1538(mask)S
+1779(with)S
+1987(the)S
+2139(value)S
+2385(XvInputMask)S
+2970(asserted)S
+3321(if)S
+3412(the)S
+3564(adaptor)S
+3893(supports)S
+4262(video)S
+4514(input,)S
+4775(and)S
+4949(value)S
+720 H
+6192 V
+1300(XvOutputMask)S
+1952(asserted)S
+2303(if)S
+2394(the)S
+2546(adaptor)S
+2875(supports)S
+3244(video)S
+3496(output.)S
+720 H
+6360 V
+10 I
+900(name)S
+10 R
+1300(A)S
+1402(vendor)S
+1709(speci\256c)S
+2044(name)S
+2290(that)S
+2470(identi\256es)S
+2867(the)S
+3019(adaptor.)S
+720 H
+6528 V
+10 I
+900(num_formats)S
+720 H
+6648 V
+10 R
+1300(The)S
+1485(number)S
+1820(of)S
+1933(depth/visual)S
+2452(id)S
+2560(formats)S
+2895(supported)S
+3319(by)S
+3449(the)S
+3601(adaptor.)S
+720 H
+6816 V
+10 I
+900(formats)S
+10 R
+1300(A)S
+1402(pointer)S
+1715(to)S
+1823(an)S
+1947(array)S
+2181(of)S
+2294(XvFormat)S
+2735(structures.)S
+720 H
+6984 V
+900(The)S
+1085(XvFormat)S
+1526(structure)S
+1905(has)S
+2068(the)S
+2220(following)S
+2639(organization:)S
+720 H
+7680 V
+5300(17)S
+7920 V
+EP
+%%Page: 18 18
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvQueryAdaptors)S
+1761(\()S
+1821(3X)S
+1988(\))S
+720 H
+1080 V
+10 C
+1450(typedef)S
+1930(struct)S
+2350({)S
+720 H
+1200 V
+1570(char)S
+1870(depth;)S
+720 H
+1320 V
+1570(unsigned)S
+2110(long)S
+2410(visual_id;)S
+720 H
+1440 V
+1450(})S
+1570(XvFormat;)S
+720 H
+1788 V
+10 I
+900(depth)S
+10 R
+1300(A)S
+1402(drawable)S
+1797(depth)S
+2049(supported)S
+2473(by)S
+2603(the)S
+2755(adaptor.)S
+720 H
+1956 V
+10 I
+900(visual_id)S
+10 R
+1300(A)S
+1402(visual-id)S
+1782(supported)S
+2206(for)S
+2352(the)S
+2504(given)S
+2756(depth)S
+3008(by)S
+3138(the)S
+3290(adaptor.)S
+720 H
+2124 V
+9 B
+720(Examples)S
+720 H
+2244 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+2472 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+2592 V
+10 B
+900([Success])S
+720 H
+2712 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvQueryAdaptors\(3X\))S
+2905(completed)S
+3351(successfully.)S
+720 H
+2880 V
+10 B
+900([XvBadExtension])S
+720 H
+3000 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+3168 V
+10 B
+900([XvBadAlloc])S
+720 H
+3288 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryAdaptors\(3X\))S
+2742(failed)S
+2999(to)S
+3107(allocate)S
+3447(memory)S
+3810(to)S
+3918(process)S
+4247(the)S
+4399(request.)S
+720 H
+3456 V
+9 B
+720(Diagnostics)S
+720 H
+3576 V
+10 B
+900([Drawable])S
+720 H
+3696 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(requested)S
+2351(drawable)S
+2746(does)S
+2959(not)S
+3117(exist.)S
+720 H
+3864 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3984 V
+10 R
+900(XvFreeAdaptorInfo\(3X\))S
+720 H
+7680 V
+720(18)S
+7920 V
+EP
+%%Page: 19 19
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4117(XvQueryBestSize)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvQueryBestSize)S
+1651(\261)S
+1731(determine)S
+2160(the)S
+2312(optimum)S
+2704(drawable)S
+3099(region)S
+3384(size)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvQueryBestSize)S
+10 R
+1649(\()S
+10 I
+1682(dpy,)S
+1881(port,)S
+2103(motion,)S
+2436(vw,)S
+2602(vh,)S
+2751(dw,)S
+2923(dh,)S
+3078(p_dw,)S
+3350(p_dh)S
+10 R
+3550(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Bool)S
+10 I
+1125(motion)S
+10 R
+1403(;)S
+720 H
+2328 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(vw,)S
+1628(vh)S
+10 R
+1722(;)S
+720 H
+2448 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(dw,)S
+1634(dh;)S
+720 H
+2568 V
+10 B
+900(unsigned)S
+1315(int)S
+10 I
+1462(*p_dw,)S
+1784(*p_dh;)S
+720 H
+2736 V
+9 B
+720(Arguments)S
+720 H
+2856 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2976 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+3096 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+3216 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3384 V
+10 I
+900(port)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(port)S
+2328(associated)S
+2768(with)S
+2976(the)S
+3128(display)S
+3447(and)S
+3621(adaptor)S
+3950(for)S
+4096(which)S
+4370(the)S
+4522(optimum)S
+4914(size)S
+5099(is)S
+5196(to)S
+5304(be)S
+720 H
+3504 V
+1650(calculated.)S
+720 H
+3672 V
+10 I
+900(motion)S
+10 R
+1650(Speci\256es)S
+10 I
+2041(True)S
+10 R
+2260(if)S
+2351(the)S
+2503(destination)S
+2972(size)S
+3157(needs)S
+3414(to)S
+3522(support)S
+3852(full)S
+4021(motion,)S
+4360(and)S
+10 I
+4534(False)S
+10 R
+4786(if)S
+4877(the)S
+5029(destina-)S
+720 H
+3792 V
+1650(tion)S
+1836(size)S
+2021(need)S
+2239(only)S
+2447(support)S
+2777(still)S
+2958(images.)S
+720 H
+3960 V
+10 I
+900(vw,vh)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(size)S
+2378(of)S
+2491(the)S
+2643(source)S
+2933(vide)S
+3135(region)S
+3420(desired.)S
+720 H
+4128 V
+10 I
+900(dw,dh)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(size)S
+2378(of)S
+2491(the)S
+2643(destination)S
+3112(drawable)S
+3507(region)S
+3792(desired.)S
+720 H
+4296 V
+10 I
+900(p_dw,p_dh)S
+10 R
+1650(Pointers)S
+2008(to)S
+2116(where)S
+2389(the)S
+2541(closest)S
+2843(destination)S
+3312(sizes)S
+3536(supported)S
+3960(by)S
+4090(the)S
+4242(server)S
+4515(are)S
+4666(retunred.)S
+720 H
+4464 V
+9 B
+720(Description)S
+720 H
+4584 V
+10 R
+900(Some)S
+1158(ports)S
+1388(may)S
+1590(be)S
+1714(able)S
+1910(to)S
+2018(scale)S
+2247(incoming)S
+2655(or)S
+2768(outgoing)S
+3154(video.)S
+3431(XvQueryBestSize\(3X\))S
+4370(returns)S
+4677(the)S
+4829(size)S
+5014(of)S
+5127(the)S
+720 H
+4704 V
+900(closest)S
+1202(destination)S
+1671(region)S
+1956(that)S
+2136(is)S
+2233(supported)S
+2657(by)S
+2787(the)S
+2939(adaptor.)S
+3323(The)S
+3508(returned)S
+3870(size)S
+4055(is)S
+4152(guaranteed)S
+4619(to)S
+4727(be)S
+4851(smaller)S
+5175(than)S
+720 H
+4824 V
+900(the)S
+1052(requested)S
+1464(size)S
+1649(if)S
+1740(a)S
+1814(smaller)S
+2138(size)S
+2323(is)S
+2420(supported.)S
+720 H
+4992 V
+9 B
+720(Examples)S
+720 H
+5112 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+5340 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+5460 V
+10 B
+900([Success])S
+720 H
+5580 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryBestSize\(3X\))S
+2726(completed)S
+3172(successfully.)S
+720 H
+5748 V
+10 B
+900([XvBadExtension])S
+720 H
+5868 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+6036 V
+10 B
+900([XvBadAlloc])S
+720 H
+6156 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryBestSize\(3X\))S
+2726(failed)S
+2983(to)S
+3091(allocate)S
+3431(memory)S
+3794(to)S
+3902(process)S
+4231(the)S
+4383(request.)S
+720 H
+6324 V
+9 B
+720(Diagnostics)S
+720 H
+6444 V
+10 B
+900([XvBadPort])S
+720 H
+6564 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+7680 V
+5300(19)S
+7920 V
+EP
+%%Page: 20 20
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvQueryEncodings)S
+1848(\()S
+1928(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvQueryEncodings)S
+1723(\261)S
+1803(return)S
+2071(list)S
+2224(of)S
+2337(encodings)S
+2772(for)S
+2918(an)S
+3042(adaptor)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvQueryEncodings\()S
+10 I
+1773(dpy,)S
+1972(port,)S
+2194(p_num_encodings,)S
+2976(pp_encoding_info\))S
+720 H
+1968 V
+10 B
+900(register)S
+1256(Display)S
+10 I
+1609(*dpy)S
+10 R
+1803(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(unsigned)S
+1315(long)S
+10 I
+1529(*p_num_encodings)S
+10 R
+2306(;)S
+720 H
+2328 V
+10 B
+900(XvEncodingInfo)S
+10 I
+1637(**pp_encoding_info)S
+10 R
+2459(;)S
+720 H
+2496 V
+9 B
+720(Arguments)S
+720 H
+2616 V
+10 I
+900(*dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2736 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+2856 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+2976 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3144 V
+10 I
+900(port)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(port)S
+2384(whose)S
+2669(adaptor)S
+2998(is)S
+3095(to)S
+3203(be)S
+3327(queried)S
+3656(for)S
+3802(its)S
+3927(list)S
+4080(of)S
+4193(encodings.)S
+720 H
+3312 V
+10 I
+900(p_num_encodings)S
+720 H
+3432 V
+10 R
+1650(A)S
+1752(pointer)S
+2065(to)S
+2173(where)S
+2446(the)S
+2598(number)S
+2933(of)S
+3046(encodings)S
+3481(supported)S
+3905(by)S
+4035(the)S
+4187(adaptor)S
+4516(is)S
+4613(written.)S
+720 H
+3600 V
+10 I
+900(pp_encoding_info)S
+720 H
+3720 V
+10 R
+1650(A)S
+1752(pointer)S
+2065(to)S
+2173(where)S
+2446(the)S
+2598(list)S
+2751(of)S
+2864(returned)S
+3226(encoding)S
+3622(information)S
+4124(is)S
+4221(returned.)S
+4638(XvEncodingInfo)S
+720 H
+3840 V
+1650(has)S
+1813(the)S
+1965(following)S
+2384(structure:)S
+720 H
+4140 V
+10 C
+2140(typedef)S
+2620(struct)S
+3040({)S
+720 H
+4260 V
+2260(XvEncodingID)S
+3040(encoding_id;)S
+720 H
+4380 V
+2260(char)S
+2560(*name;)S
+720 H
+4500 V
+2260(unsigned)S
+2800(long)S
+3100(width;)S
+720 H
+4620 V
+2260(unsigned)S
+2800(long)S
+3100(height;)S
+720 H
+4740 V
+2260(XvRational)S
+2920(rate;)S
+720 H
+4860 V
+2140(})S
+2260(XvEncodingInfo;)S
+720 H
+5208 V
+10 I
+900(encoding_id)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(encoding-id)S
+2700(of)S
+2813(the)S
+2965(encoding.)S
+3416(The)S
+3601(encoding-id)S
+4108(is)S
+4205(used)S
+4418(to)S
+4526(identify)S
+4867(an)S
+4991(encoding)S
+720 H
+5328 V
+1650(when)S
+1896(a)S
+1970(port's)S
+2233(encoding)S
+2629(attribute)S
+2992(is)S
+3089(changed.)S
+720 H
+5496 V
+10 I
+900(name)S
+10 R
+1650(A)S
+1752(pointer)S
+2065(to)S
+2173(a)S
+2247(formatted)S
+2665(string)S
+2923(that)S
+3103(identi\256es)S
+3500(the)S
+3652(encoding.)S
+4103(The)S
+4288(string)S
+4546(has)S
+4709(the)S
+4861(format)S
+720 H
+5616 V
+1650(")S
+10 I
+1691(timing-signaltype)S
+10 R
+2391(".)S
+2517(For)S
+2686(example)S
+3054("ntsc-composite".)S
+720 H
+5784 V
+10 I
+900(width,height)S
+10 R
+1650(The)S
+1835(width)S
+2093(and)S
+2267(height,)S
+2572(in)S
+2680(pixels,)S
+2974(of)S
+3087(the)S
+3239(decoded)S
+3601(video)S
+3853(image.)S
+720 H
+5952 V
+10 I
+900(rate)S
+10 R
+1650(The)S
+1835(\256eld)S
+2043(rate)S
+2222(of)S
+2335(the)S
+2487(decoded)S
+2849(video.)S
+720 H
+6120 V
+900(The)S
+1085(XvRational)S
+1576(structure)S
+1955(is)S
+2052(used)S
+2265(to)S
+2373(specify)S
+2691(a)S
+2765(fractional)S
+3177(number.)S
+3567(It)S
+3658(has)S
+3821(the)S
+3973(following)S
+4392(structure:)S
+720 H
+6420 V
+10 C
+1390(typedef)S
+1870(struct)S
+2290({)S
+720 H
+6540 V
+1510(int)S
+1750(numerator;)S
+720 H
+6660 V
+1510(int)S
+1750(denominator;)S
+720 H
+6780 V
+1390(})S
+1510(XvRational;)S
+720 H
+7080 V
+10 R
+900(The)S
+10 I
+1085(numerator)S
+10 R
+1537(and)S
+10 I
+1711(denominator)S
+10 R
+2252(\256elds)S
+2499(specify)S
+2817(the)S
+2969(appropriate)S
+3453(parts)S
+3677(of)S
+3790(a)S
+3864(fractional)S
+4276(number.)S
+720 H
+7680 V
+720(20)S
+7920 V
+EP
+%%Page: 21 21
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4152(XvQueryEncodings)S
+5280(\()S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Description)S
+720 H
+1200 V
+10 R
+900(XvQueryEncodings\(3X\))S
+1911(returns)S
+2218(encoding)S
+2614(information)S
+3116(about)S
+3368(an)S
+3492(adaptor.)S
+3876(Each)S
+4105(encoding)S
+4501(is)S
+4598(described)S
+5010(by)S
+5140(the)S
+720 H
+1320 V
+900(XvEncodingInfo)S
+1601(structure)S
+1980(described)S
+2392(above.)S
+2715(The)S
+2900(encodings)S
+3335(are)S
+3486(identi\256ed)S
+3894(by)S
+4024(an)S
+4148(encoding-id,)S
+4680(which)S
+4954(can)S
+5122(be)S
+720 H
+1440 V
+900(used)S
+1113(to)S
+1221(set)S
+1362(or)S
+1475(get)S
+1627(the)S
+1779(encoding)S
+2175(attribute)S
+2538(of)S
+2651(a)S
+2725(port.)S
+720 H
+1608 V
+9 B
+720(Examples)S
+720 H
+1728 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+1956 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+2076 V
+10 B
+900([Success])S
+720 H
+2196 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryEncodings\(3X\))S
+2798(completed)S
+3244(successfully.)S
+720 H
+2364 V
+10 B
+900([XvBadExtension])S
+720 H
+2484 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+2652 V
+10 B
+900([XvBadAlloc])S
+720 H
+2772 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryEncodings\(3X\))S
+2798(failed)S
+3055(to)S
+3163(allocate)S
+3503(memory)S
+3866(to)S
+3974(process)S
+4303(the)S
+4455(request.)S
+720 H
+2940 V
+9 B
+720(Diagnostics)S
+720 H
+3060 V
+10 B
+900([XvBadPort])S
+720 H
+3180 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+3348 V
+9 B
+720(See)S
+892(Also)S
+720 H
+3468 V
+10 R
+900(XvFreeEncodingInfo\(3X\))S
+720 H
+7680 V
+5300(21)S
+7920 V
+EP
+%%Page: 22 22
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvQueryExtension)S
+1809(\()S
+1869(3X)S
+2036(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvQueryExtension)S
+1701(\261)S
+1781(return)S
+2049(version)S
+2373(and)S
+2547(release)S
+2853(of)S
+2966(extension)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvQueryExtension\()S
+10 I
+1750(p_version,)S
+2199(p_release,)S
+720 H
+1848 V
+1260(p_request_base,)S
+1942(p_event_base,)S
+2540(p_error_base)S
+10 R
+3084(\))S
+720 H
+2088 V
+10 B
+900(unsigned)S
+1315(int)S
+1462(*p_version,)S
+1984(*p_release;)S
+2496(unsigned)S
+2911(int)S
+3058(*p_request_base,)S
+3824(*p_event_base,)S
+4501(*p_error_base;)S
+720 H
+2256 V
+9 B
+720(Arguments)S
+720 H
+2376 V
+10 I
+900(p_version)S
+10 R
+1650(Pointer)S
+1969(to)S
+2077(where)S
+2350(the)S
+2502(current)S
+2814(version)S
+3138(number)S
+3473(of)S
+3586(the)S
+10 I
+3738(Xv)S
+10 R
+3873(video)S
+4125(extension)S
+4538(is)S
+4635(written.)S
+720 H
+2544 V
+10 I
+900(p_release)S
+10 R
+1650(Pointer)S
+1969(to)S
+2077(where)S
+2350(the)S
+2502(release)S
+2808(number)S
+3143(of)S
+3256(the)S
+10 I
+3408(Xv)S
+10 R
+3543(video)S
+3795(extension)S
+4208(is)S
+4305(written.)S
+720 H
+2712 V
+10 I
+900(p_request_base)S
+10 R
+1650(Pointer)S
+1969(to)S
+2077(where)S
+2350(the)S
+2502(extension)S
+2915(major)S
+3178(request)S
+3496(number)S
+3831(is)S
+3928(returned)S
+720 H
+2880 V
+10 I
+900(p_event_base)S
+10 R
+1650(Pointer)S
+1969(to)S
+2077(where)S
+2350(the)S
+2502(extension)S
+2915(event)S
+3161(base)S
+3368(is)S
+3465(returned)S
+720 H
+3048 V
+10 I
+900(p_error_base)S
+10 R
+1650(Pointer)S
+1969(to)S
+2077(where)S
+2350(the)S
+2502(extension)S
+2915(error)S
+3138(base)S
+3345(is)S
+3442(returned)S
+720 H
+3216 V
+9 B
+720(Description)S
+720 H
+3336 V
+10 R
+900(XvQueryExtension\(3X\))S
+1889(returns)S
+2196(the)S
+2348(version)S
+2672(and)S
+2846(release)S
+3152(numbers)S
+3526(for)S
+3672(the)S
+3824(Xv)S
+3976(video)S
+4228(extension)S
+4641(currently)S
+5031(loaded)S
+720 H
+3456 V
+900(on)S
+1030(the)S
+1182(system.)S
+1545(The)S
+1730(extension)S
+2143(major)S
+2406(request)S
+2724(number,)S
+3084(event)S
+3330(base,)S
+3562(and)S
+3736(error)S
+3959(base)S
+4166(are)S
+4317(also)S
+4508(returned.)S
+720 H
+3624 V
+9 B
+720(Examples)S
+720 H
+3744 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+3972 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+4092 V
+10 B
+900([Success])S
+720 H
+4212 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvQueryExtension\(3X\))S
+2939(completed)S
+3385(successfully.)S
+720 H
+4380 V
+10 B
+900([XvBadExtension])S
+720 H
+4500 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(video)S
+2343(extension)S
+2756(is)S
+2853(not)S
+3011(available)S
+3401(for)S
+3547(the)S
+3699(named)S
+3995(display.)S
+720 H
+4668 V
+10 B
+900([XvBadAlloc])S
+720 H
+4788 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvQueryExtension\(3X\))S
+2776(failed)S
+3033(to)S
+3141(allocate)S
+3481(memory)S
+3844(to)S
+3952(process)S
+4281(the)S
+4433(request.)S
+720 H
+7680 V
+720(22)S
+7920 V
+EP
+%%Page: 23 23
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4031(XvSelectPortNotify)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvSelectPortNotify)S
+1724(\261)S
+1804(enable)S
+2094(or)S
+2207(disable)S
+2520(XvPortNotify\(3X\))S
+3288(events)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvSelectPortNotify\()S
+10 I
+1758(dpy,)S
+1957(port,)S
+2179(ono)S
+2329 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+2380(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Bool)S
+10 I
+1125(ono)S
+1275 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+1326(;)S
+720 H
+2376 V
+9 B
+720(Arguments)S
+720 H
+2496 V
+10 I
+900(dpy)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(display)S
+2162(screen)S
+2446(on)S
+2576(which)S
+2850(the)S
+3002(X)S
+3104(Server)S
+3394(is)S
+3491(to)S
+3599(accept)S
+3883(requests)S
+4240(from)S
+4464(X)S
+4566(clients.)S
+4912(If)S
+5008(the)S
+720 H
+2616 V
+1300(display)S
+1619(option)S
+1905(is)S
+2002(not)S
+2160(speci\256ed,)S
+2570(X)S
+2672(uses)S
+2874(the)S
+3026(display)S
+3345(screen)S
+3629(speci\256ed)S
+4014(by)S
+4144(your)S
+4357(DISPLAY)S
+4809(environment)S
+720 H
+2736 V
+1300(variable.)S
+1706(The)S
+1891(display)S
+2210(option)S
+2496(has)S
+2659(the)S
+2811(format)S
+3107(hostname:number.)S
+3908(Using)S
+4177(two)S
+4357(colons)S
+4648(\(::\))S
+4800(instead)S
+5113(of)S
+5226(one)S
+720 H
+2856 V
+1300(\(:\))S
+1424(indicates)S
+1809(that)S
+1989(DECnet)S
+2341(is)S
+2438(to)S
+2546(be)S
+2670(used)S
+2883(for)S
+3029(transport.)S
+720 H
+3024 V
+10 I
+900(port)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(port)S
+2034(for)S
+2180(which)S
+2454(PortNotify)S
+2912(events)S
+3197(are)S
+3348(to)S
+3456(be)S
+3580(generated)S
+3997(when)S
+4243(its)S
+4368(attributes)S
+4770(are)S
+4921(changed)S
+720 H
+3144 V
+1300(using)S
+1547(XvSetPortAttribute\(3X\).)S
+720 H
+3312 V
+10 I
+900(ono)S
+1050 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+1300(Speci\256es)S
+1691(whether)S
+2042(noti\256cation)S
+2528(is)S
+2625(to)S
+2733(be)S
+2857(enabled)S
+3197(or)S
+3310(disabled.)S
+720 H
+3480 V
+9 B
+720(Description)S
+720 H
+3600 V
+10 R
+900(XvSelectPortNotify\(3X\))S
+1912(enables)S
+2241(or)S
+2354(disables)S
+2706(PortNotify)S
+3164(event)S
+3410(delivery)S
+3767(to)S
+3875(the)S
+4027(requesting)S
+4473(client.)S
+720 H
+3720 V
+900(XvPortNotify\(3X\))S
+1668(events)S
+1953(are)S
+2104(generated)S
+2521(when)S
+2767(port)S
+2958(attributes)S
+3360(are)S
+3511(changed)S
+3873(using)S
+4120(XvSetPortAttribute\(3X\).)S
+720 H
+3888 V
+9 B
+720(Examples)S
+720 H
+4008 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+4236 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+4356 V
+10 B
+900([Success])S
+720 H
+4476 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvSelectPortNotify\(3X\))S
+2962(completed)S
+3408(successfully.)S
+720 H
+4644 V
+10 B
+900([XvBadExtension])S
+720 H
+4764 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+4932 V
+10 B
+900([XvBadAlloc])S
+720 H
+5052 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvSelectPortNotify\(3X\))S
+2799(failed)S
+3056(to)S
+3164(allocate)S
+3504(memory)S
+3867(to)S
+3975(process)S
+4304(the)S
+4456(request.)S
+720 H
+5220 V
+9 B
+720(Diagnostics)S
+720 H
+5340 V
+10 B
+900([XvBadPort])S
+720 H
+5460 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+5628 V
+9 B
+720(See)S
+892(Also)S
+720 H
+5748 V
+10 R
+900(XvSetPortNotify\(3X\),)S
+1821(XvSetPortAttribute\(3X\),)S
+2842(XvPortNotify\(3X\))S
+720 H
+7680 V
+5300(23)S
+7920 V
+EP
+%%Page: 24 24
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvSelectVideoNotify)S
+1909(\()S
+1969(3X)S
+2136(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvSelectVideoNotify)S
+1801(\261)S
+1881(enable)S
+2171(or)S
+2284(disable)S
+2597(VideoNotify)S
+3132(events)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+10 I
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+10 B
+900(XvSelectVideoNotify\()S
+10 I
+1820(dpy,)S
+2019(drawable,)S
+2452(ono)S
+2602 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+2653(\))S
+720 H
+1968 V
+10 B
+900(register)S
+1256(Display)S
+10 I
+1609(*dpy)S
+10 R
+1803(;)S
+720 H
+2088 V
+10 B
+900(Drawable)S
+10 I
+1346(drawable)S
+10 R
+1724(;)S
+720 H
+2208 V
+10 B
+900(Bool)S
+10 I
+1125(ono)S
+1275 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+1326(;)S
+720 H
+2376 V
+9 B
+720(Arguments)S
+720 H
+2496 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2616 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+2736 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+2856 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3024 V
+10 I
+900(drawable)S
+10 R
+1650(De\256nes)S
+1985(the)S
+2137(drawable)S
+2532(in)S
+2640(which)S
+2914(video)S
+3166(activity)S
+3496(is)S
+3593(to)S
+3701(be)S
+3825(reported.)S
+720 H
+3192 V
+10 I
+900(ono)S
+1050 H
+	(f)show 10 -.5 mul h (f)show
+10 I
+10 R
+1650(Selects)S
+1963(whether)S
+2314(video)S
+2566(noti\256cation)S
+3052(is)S
+3149(enabled)S
+3489(or)S
+3602(disabled.)S
+720 H
+3360 V
+9 B
+720(Description)S
+720 H
+3480 V
+10 R
+900(XvSelectVideoNotify\(3X\))S
+1989(enables)S
+2318(or)S
+2431(disables)S
+2783(events)S
+3068(to)S
+3176(be)S
+3300(reported)S
+3662(for)S
+3808(video)S
+4060(activity)S
+4390(in)S
+4498(a)S
+4572(drawable.)S
+720 H
+3648 V
+9 B
+720(Examples)S
+720 H
+3768 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+3996 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+4116 V
+10 B
+900([Success])S
+720 H
+4236 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvSelectVideoNotify\(3X\))S
+3039(completed)S
+3485(successfully.)S
+720 H
+4404 V
+10 B
+900([XvBadExtension])S
+720 H
+4524 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+4692 V
+10 B
+900([XvBadAlloc])S
+720 H
+4812 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvSelectVideoNotify\(3X\))S
+2876(failed)S
+3133(to)S
+3241(allocate)S
+3581(memory)S
+3944(to)S
+4052(process)S
+4381(the)S
+4533(request.)S
+720 H
+4980 V
+10 B
+900([BadDrawable])S
+720 H
+5100 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+5268 V
+9 B
+720(See)S
+892(Also)S
+720 H
+5388 V
+10 R
+900(XvVideoNotify)S
+720 H
+7680 V
+720(24)S
+7920 V
+EP
+%%Page: 25 25
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4039(XvSetPortAttribute)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvSetPortAttribute)S
+1708(\261)S
+1788(sets)S
+1968(an)S
+2092(attribute)S
+2455(of)S
+2568(a)S
+2642(video)S
+2894(port)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvSetPortAttribute\()S
+10 I
+1775(dpy,)S
+1974(port,)S
+2196(attribute,)S
+2596(value)S
+10 R
+2812(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Atom)S
+10 I
+1168(attribute)S
+10 R
+1513(;)S
+720 H
+2328 V
+10 B
+900(int)S
+10 I
+1047(value)S
+10 R
+1263(;)S
+720 H
+2496 V
+9 B
+720(Arguments)S
+720 H
+2616 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2736 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+2856 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+2976 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3144 V
+10 I
+900(port)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(port)S
+2384(for)S
+2530(which)S
+2804(the)S
+2956(attribute)S
+3319(is)S
+3416(to)S
+3524(be)S
+3648(used.)S
+720 H
+3312 V
+10 I
+900(attribute)S
+10 R
+1650(Identi\256es)S
+2052(the)S
+2204(port)S
+2395(attribute)S
+2758(to)S
+2866(be)S
+2990(set)S
+3131(by)S
+3261(this)S
+3436(request.)S
+3809(Can)S
+4000(be)S
+4124(one)S
+4298(of)S
+4411(the)S
+4563(table)S
+4787(entries)S
+5083(under)S
+720 H
+3432 V
+1650(the)S
+1802(column)S
+2132("String,")S
+2514(below.)S
+720 H
+3600 V
+10 I
+900(value)S
+10 R
+1650(Identi\256es)S
+2052(the)S
+2204(value)S
+2450(to)S
+2558(which)S
+10 I
+2832(attribute)S
+10 R
+3207(is)S
+3304(to)S
+3412(be)S
+3536(set.)S
+3732(Can)S
+3923(be)S
+4047(one)S
+4221(of)S
+4334(the)S
+4486(table)S
+4710(entries)S
+5006(under)S
+5263(the)S
+720 H
+3720 V
+1650(column)S
+1980("Type,")S
+2322(below.)S
+720 H
+3888 V
+9 B
+720(Description)S
+720 H
+4008 V
+10 R
+900(XvSetPortAttribute\(3X\))S
+1896(permits)S
+2226(a)S
+2300(client)S
+2552(to)S
+2660(set)S
+2801(the)S
+2953(port)S
+3144(attribute)S
+3507(to)S
+3615(speci\256ed)S
+4000(values.)S
+4340(This)S
+4548(request)S
+4866(supports)S
+5235(the)S
+720 H
+4128 V
+900(following)S
+1319(values:)S
+720 H
+7680 V
+5300(25)S
+7920 V
+EP
+%%Page: 26 26
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvSetPortAttribute)S
+1814(\()S
+1874(3X)S
+2041(\))S
+720 H
+980 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+1148 V
+10 HB
+900(Control)S
+1283(String)S
+1964(Type)S
+2724(Default)S
+720 H
+1228 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+1408 V
+10 R
+900("XV_ENCODING")S
+1964(XvEncodingID)S
+2724(Server)S
+3014(dependent)S
+720 H
+1528 V
+900("XV_HUE")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1648 V
+900("XV_SATURATION")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1768 V
+900("XV_BRIGHTNESS")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1888 V
+900("XV_CONTRAST")S
+1964([-1000...1000])S
+2724(0)S
+720 H
+1968 V
+10 Y1
+900(2)S
+924(22222222222222222222222222222222222222222222222222)S
+720 H
+2136 V
+10 R
+900(The)S
+1085(supplied)S
+1454(encoding)S
+1850(must)S
+2075(be)S
+2199(one)S
+2373(of)S
+2486(the)S
+2638(encodings)S
+3073(listed)S
+3320(for)S
+3466(the)S
+3618(adaptor,)S
+3972(otherwise)S
+4390(an)S
+4514(Encoding)S
+4927(error)S
+720 H
+2256 V
+900(results.)S
+720 H
+2424 V
+900(If)S
+996(the)S
+1148(adaptor)S
+1477(does)S
+1690(not)S
+1848(support)S
+2178(the)S
+2330(exact)S
+2570(hue,)S
+2769(saturation,)S
+3218(brightness,)S
+3684(and)S
+3858(contrast)S
+4204(levels)S
+4467(supplied,)S
+4861(the)S
+5013(closest)S
+720 H
+2544 V
+900(levels)S
+1163(supported)S
+1587(are)S
+1738(assumed.)S
+2167(Use)S
+2352(XvGetPortAttribute\(3X\))S
+3364(to)S
+3472(query)S
+3729(the)S
+3881(resulting)S
+4261(levels.)S
+720 H
+2712 V
+900(When)S
+1168(an)S
+1292(XvSetPortAttribute\(3X\))S
+2288(request)S
+2606(is)S
+2703(processed,)S
+3151(a)S
+3225(PortControlNotify\(3X\))S
+4177(event)S
+4423(is)S
+4520(generated)S
+4937(for)S
+5083(all)S
+720 H
+2832 V
+900(clients)S
+1191(that)S
+1371(have)S
+1589(requested)S
+2001(for)S
+2147(port)S
+2338(changes)S
+2689(using)S
+2936(XvSelectPortNotify\(3X\).)S
+720 H
+3000 V
+9 B
+720(Examples)S
+720 H
+3120 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+3348 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+3468 V
+10 B
+900([Success])S
+720 H
+3588 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvSetPortAttribute\(3X\))S
+2946(completed)S
+3392(successfully.)S
+720 H
+3756 V
+10 B
+900([XvBadExtension])S
+720 H
+3876 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+4044 V
+10 B
+900([XvBadAlloc])S
+720 H
+4164 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvSelectVideoNotify\(3X\))S
+2876(failed)S
+3133(to)S
+3241(allocate)S
+3581(memory)S
+3944(to)S
+4052(process)S
+4381(the)S
+4533(request.)S
+720 H
+4332 V
+9 B
+720(Diagnostics)S
+720 H
+4452 V
+10 B
+900([XvBadPort])S
+720 H
+4572 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+4740 V
+10 B
+900([XvBadEncoding])S
+720 H
+4860 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(an)S
+1954(encoding)S
+2350(is)S
+2447(speci\256ed)S
+2832(that)S
+3012(does)S
+3225(not)S
+3383(exist.)S
+720 H
+5028 V
+10 B
+900([BadMatch])S
+720 H
+5148 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(attribute)S
+2757(atom)S
+2987(does)S
+3200(not)S
+3358(specify)S
+3676(an)S
+3800(attribute)S
+4163(supported)S
+4587(by)S
+4717(the)S
+4869(adaptor.)S
+720 H
+5316 V
+9 B
+720(See)S
+892(Also)S
+720 H
+5436 V
+10 R
+900(XvGetPortAttribute\(3X\),)S
+1937(XvSelectPortNotify\(3X\),)S
+2974(XvPortNotify\(3X\))S
+720 H
+7680 V
+720(26)S
+7920 V
+EP
+%%Page: 27 27
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4373(XvStopVideo)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvStopVideo)S
+1480(\261)S
+1560(stop)S
+1757(active)S
+2025(video)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvStopVideo\()S
+10 I
+1500(dpy,)S
+1699(port,)S
+1921(draw)S
+10 R
+2127(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Drawable)S
+10 I
+1346(draw)S
+10 R
+1552(;)S
+720 H
+2376 V
+9 B
+720(Arguments)S
+720 H
+2496 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2616 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+2736 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+2856 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3024 V
+10 I
+900(port)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(port)S
+2384(for)S
+2530(which)S
+2804(video)S
+3056(is)S
+3153(to)S
+3261(be)S
+3385(stopped.)S
+720 H
+3192 V
+10 I
+900(draw)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(drawable)S
+2588(associated)S
+3028(with)S
+3236(the)S
+3388(named)S
+3684(port.)S
+720 H
+3360 V
+9 B
+720(Description)S
+720 H
+3480 V
+10 R
+900(XvStopVideo\(3X\))S
+1668(stops)S
+1904(active)S
+2172(video)S
+2424(for)S
+2570(the)S
+2722(speci\256ed)S
+3107(port)S
+3298(and)S
+3472(drawable.)S
+3922(If)S
+4018(the)S
+4170(port)S
+4361(is)S
+4458(not)S
+4616(processing)S
+5073(video,)S
+720 H
+3600 V
+900(or)S
+1013(if)S
+1104(it)S
+1190(is)S
+1287(processing)S
+1744(video)S
+1996(in)S
+2104(a)S
+2178(di)S
+2256 H
+	(f)show 10 -.5 mul h (f)show
+10 R
+2317(erent)S
+2546(drawable,)S
+2966(the)S
+3118(request)S
+3436(is)S
+3533(ignored.)S
+3923(When)S
+4191(video)S
+4443(is)S
+4540(stopped)S
+4881(a)S
+720 H
+3720 V
+900(XvVideoNotify\(3X\))S
+1745(event)S
+1991(with)S
+2199(detail)S
+2451(XvStopped)S
+2931(is)S
+3028(generated)S
+3445(for)S
+3591(the)S
+3743(associated)S
+4183(drawable.)S
+720 H
+3888 V
+9 B
+720(Examples)S
+720 H
+4008 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+4236 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+4356 V
+10 B
+900([Success])S
+720 H
+4476 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvStopVideo\(3X\))S
+2718(completed)S
+3164(successfully.)S
+720 H
+4644 V
+10 B
+900([XvBadExtension])S
+720 H
+4764 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+4932 V
+10 B
+900([XvBadAlloc])S
+720 H
+5052 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvStopVideo\(3X\))S
+2555(failed)S
+2812(to)S
+2920(allocate)S
+3260(memory)S
+3623(to)S
+3731(process)S
+4060(the)S
+4212(request.)S
+720 H
+5220 V
+9 B
+720(Diagnostics)S
+720 H
+5340 V
+10 B
+900([XvBadPort])S
+720 H
+5460 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+5628 V
+10 B
+900([BadDrawable])S
+720 H
+5748 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(drawable)S
+2789(does)S
+3002(not)S
+3160(exist.)S
+720 H
+5916 V
+9 B
+720(See)S
+892(Also)S
+720 H
+6036 V
+10 R
+900(XvGetVideo\(3X\),)S
+1653(XvPutVideo\(3X\),)S
+2396(XvVideoNotifyEvent\(3X\))S
+720 H
+7680 V
+5300(27)S
+7920 V
+EP
+%%Page: 28 28
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+720(XvUngrabPort)S
+1546(\()S
+1606(3X)S
+1773(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvUngrabPort)S
+1518(\261)S
+1598(release)S
+1904(port)S
+2095(grabbed)S
+2446(for)S
+2592(video)S
+2844(operation)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1728 V
+900(XvUngrabPort\()S
+10 I
+1571(dpy,)S
+1770(port,)S
+1992(time)S
+10 R
+2164(\))S
+720 H
+1968 V
+10 B
+900(Display)S
+10 I
+1253(*dpy)S
+10 R
+1447(;)S
+720 H
+2088 V
+10 B
+900(XvPortID)S
+10 I
+1351(port)S
+10 R
+1518(;)S
+720 H
+2208 V
+10 B
+900(Time)S
+10 I
+1152(time)S
+10 R
+1324(;)S
+720 H
+2376 V
+9 B
+720(Arguments)S
+720 H
+2496 V
+10 I
+900(dpy)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(display)S
+2512(screen)S
+2796(on)S
+2926(which)S
+3200(the)S
+3352(Xv)S
+3504(Server)S
+3794(is)S
+3891(to)S
+3999(accept)S
+4283(requests)S
+4640(from)S
+4864(Xv)S
+5016(clients.)S
+720 H
+2616 V
+1650(If)S
+1746(the)S
+1898(display)S
+2217(option)S
+2503(is)S
+2600(not)S
+2758(speci\256ed,)S
+3168(Xv)S
+3320(uses)S
+3522(the)S
+3674(display)S
+3993(screen)S
+4277(speci\256ed)S
+4662(by)S
+4792(your)S
+720 H
+2736 V
+1650(DISPLAY)S
+2102(environment)S
+2637(variable.)S
+3043(The)S
+3228(display)S
+3547(option)S
+3833(has)S
+3996(the)S
+4148(format)S
+4444(hostname:number.)S
+720 H
+2856 V
+1650(Using)S
+1919(two)S
+2099(colons)S
+2390(\(::\))S
+2542(instead)S
+2855(of)S
+2968(one)S
+3142(\(:\))S
+3266(indicates)S
+3651(that)S
+3831(DECnet)S
+4183(is)S
+4280(to)S
+4388(be)S
+4512(used)S
+4725(for)S
+4871(transport.)S
+720 H
+3024 V
+10 I
+900(port)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(port)S
+2384(to)S
+2492(be)S
+2616(released.)S
+3027(If)S
+3123(the)S
+3275(port)S
+3466(had)S
+3640(not)S
+3798(been)S
+4016(previously)S
+4468(grabbed,)S
+4844(the)S
+4996(request)S
+5314(is)S
+720 H
+3144 V
+1650(ignored.)S
+720 H
+3312 V
+10 I
+900(time)S
+10 R
+1650(Speci\256es)S
+2041(the)S
+2193(request)S
+2511(timestamp.)S
+720 H
+3480 V
+9 B
+720(Description)S
+720 H
+3600 V
+10 R
+900(XvUngrabPort\(3X\))S
+1706(releases)S
+2051(a)S
+2125(grabbed)S
+2476(port.)S
+2722(If)S
+10 I
+2818(time)S
+10 R
+3020(speci\256es)S
+3394(a)S
+3468(time)S
+3676(before)S
+3960(the)S
+4112(last)S
+4281(XvGrabPort\(3X\))S
+4987(was)S
+5172(exe-)S
+720 H
+3720 V
+900(cuted,)S
+1171(the)S
+1323(request)S
+1641(is)S
+1738(ignored.)S
+720 H
+3888 V
+9 B
+720(Examples)S
+720 H
+4008 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+4236 V
+9 B
+720(Returned)S
+1127(Values)S
+720 H
+4356 V
+10 B
+900([Success])S
+720 H
+4476 V
+10 R
+1300(Returns)S
+1641(True)S
+1859(if)S
+1950(XvUngrabPort\(3X\))S
+2756(completed)S
+3202(successfully.)S
+720 H
+4644 V
+10 B
+900([XvBadExtension])S
+720 H
+4764 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(the)S
+1939(Xv)S
+2091(extension)S
+2504(is)S
+2601(unavailable.)S
+720 H
+4932 V
+10 B
+900([XvBadAlloc])S
+720 H
+5052 V
+10 R
+1300(Returned)S
+1696(if)S
+1787(XvUngrabPort\(3X\))S
+2593(failed)S
+2850(to)S
+2958(allocate)S
+3298(memory)S
+3661(to)S
+3769(process)S
+4098(the)S
+4250(request.)S
+720 H
+5220 V
+9 B
+720(Diagnostics)S
+720 H
+5340 V
+10 B
+900([XvBadPort])S
+720 H
+5460 V
+10 R
+1300(Generated)S
+1739(if)S
+1830(the)S
+1982(requested)S
+2394(port)S
+2585(does)S
+2798(not)S
+2956(exist.)S
+720 H
+5628 V
+9 B
+720(See)S
+892(Also)S
+720 H
+5748 V
+10 R
+900(XvGrabPort\(3X\))S
+720 H
+7680 V
+720(28)S
+7920 V
+EP
+%%Page: 29 29
+BP
+/slant 0 def
+/height 1.000000 def
+10 R
+10 R
+72 H
+120 V
+72(|--)S
+720 H
+600 V
+12 HB
+4299(XvVideoNotify)S
+5133(\()S
+5193(3X)S
+5360(\))S
+720 H
+1080 V
+9 B
+720(Name)S
+720 H
+1200 V
+10 R
+900(XvVideoNotify)S
+1557(\261)S
+1637(event)S
+1883(generated)S
+2300(for)S
+2446(video)S
+2698(processing)S
+720 H
+1368 V
+9 B
+720(Syntax)S
+720 H
+1488 V
+10 B
+900(#include)S
+1292(<X11/extensions/Xvlib.h>)S
+720 H
+1908 V
+10 C
+1450(typedef)S
+1930(union)S
+2290({)S
+720 H
+2028 V
+1570(int)S
+1810(type;)S
+720 H
+2148 V
+1570(XvVideoNotifyEvent)S
+2710(xvvideo;)S
+720 H
+2268 V
+1570(XvPortNotifyEvent)S
+2650(xvport;)S
+720 H
+2388 V
+1450(})S
+1570(XvEvent;)S
+720 H
+2628 V
+1450(typedef)S
+1930(struct)S
+2350({)S
+720 H
+2748 V
+1570(int)S
+1810(type;)S
+720 H
+2868 V
+1570(unsigned)S
+2110(long)S
+2410(serial;)S
+720 H
+2988 V
+1570(Bool)S
+1870(send_event;)S
+720 H
+3108 V
+1570(Display)S
+2050(*display;)S
+720 H
+3228 V
+1570(Drawable)S
+2110(drawable;)S
+720 H
+3348 V
+1570(unsigned)S
+2110(long)S
+2410(reason;)S
+720 H
+3468 V
+1570(XvPortID)S
+2110(port_id;)S
+720 H
+3588 V
+1570(Time)S
+1870(time;)S
+720 H
+3708 V
+1450(})S
+1570(XvVideoNotifyEvent;)S
+720 H
+4056 V
+10 I
+900(type)S
+10 R
+1300(Speci\256es)S
+1691(the)S
+1843(type)S
+2045(of)S
+2158(event:)S
+2432(XvVideoNotify\(3X\).)S
+720 H
+4224 V
+10 I
+900(serial)S
+10 R
+1300(Number)S
+1657(of)S
+1770(the)S
+1922(last)S
+2091(request)S
+2409(processed)S
+2832(by)S
+2962(the)S
+3114(server.)S
+720 H
+4392 V
+10 I
+900(send_event)S
+720 H
+4512 V
+10 R
+1300(True)S
+1518(if)S
+1609(the)S
+1761(event)S
+2007(was)S
+2192(generated)S
+2609(by)S
+2739(a)S
+2813(SendEvent)S
+3276(request.)S
+720 H
+4680 V
+10 I
+900(display)S
+10 R
+1300(A)S
+1402(pointer)S
+1715(to)S
+1823(the)S
+1975(display)S
+2294(the)S
+2446(event)S
+2692(was)S
+2877(read)S
+3078(from.)S
+720 H
+4848 V
+10 I
+900(drawable)S
+720 H
+4968 V
+10 R
+1300(The)S
+1485(drawable)S
+1880(for)S
+2026(which)S
+2300(the)S
+2452(event)S
+2698(was)S
+2883(generated.)S
+720 H
+5136 V
+10 I
+900(reason)S
+10 R
+1300(The)S
+1485(reason)S
+1775(the)S
+1927(event)S
+2173(was)S
+2358(generated:)S
+10 B
+2803(XvStarted)S
+10 R
+3241(,)S
+10 B
+3296(XvStopped)S
+10 R
+3769(,)S
+10 B
+3824(XvStill)S
+10 R
+4119(,)S
+10 B
+4174(XvPreempted)S
+10 R
+4761(,)S
+10 B
+4816(XvBusy)S
+10 R
+5150(,)S
+720 H
+5256 V
+10 B
+1300(XvHardError)S
+10 R
+1899(.)S
+720 H
+5424 V
+10 I
+900(port_id)S
+10 R
+1300(The)S
+1485(port)S
+1676(processing)S
+2133(the)S
+2285(video)S
+2537(for)S
+2683(which)S
+2957(the)S
+3109(event)S
+3355(was)S
+3540(generated.)S
+720 H
+5592 V
+9 B
+720(Description)S
+720 H
+5712 V
+10 R
+900(XvVideoNotify\(3X\))S
+1745(events)S
+2030(are)S
+2181(generated)S
+2598(when)S
+2844(video)S
+3096(is)S
+3193(started,)S
+3514(stopped,)S
+3880(displayed)S
+4293(as)S
+4406(a)S
+4480(still)S
+4661(image,)S
+4960(preempted)S
+720 H
+5832 V
+900(by)S
+1030(another)S
+1359(video)S
+1611(request,)S
+1954(ignored)S
+2289(because)S
+2634(the)S
+2786(port)S
+2977(is)S
+3074(grabbed)S
+3425(by)S
+3555(another)S
+3884(client,)S
+4161(or)S
+4274(interruped)S
+4714(because)S
+5059(of)S
+5172(a)S
+720 H
+5952 V
+900(hard)S
+1107(transmission)S
+1643(or)S
+1756(reception)S
+2157(error.)S
+720 H
+6120 V
+9 B
+720(Examples)S
+720 H
+6240 V
+10 C
+1150(Example)S
+1630(between)S
+2110(.EX)S
+2350(and)S
+2590(.EE)S
+2830(will)S
+3130(show)S
+3430(in)S
+3610(monospace)S
+720 H
+6468 V
+9 B
+720(See)S
+892(Also)S
+720 H
+6588 V
+10 R
+900(XvPutVideo\(3X\),)S
+1643(XvPutStill\(3X\),)S
+2310(XvGetVideo\(3X\),)S
+3063(XvGetStill\(3X\),)S
+3740(XvStopVideo\(3X\),)S
+720 H
+6708 V
+900(XvSelectVideoNotify\(3X\))S
+720 H
+7680 V
+5300(29)S
+72 H
+8030 V
+72(|--)S
+8030 V
+EP
+%%Trailer
+%%DocumentFonts: Times-Roman Times-Bold Times-Italic Helvetica Helvetica-Bold Helvetica-Bold Courier Troff
+%%Pages: 29
diff --git a/hardcopy/saver/saver.PS.gz b/hardcopy/saver/saver.PS.gz
new file mode 100644
index 0000000..724c2c1
--- /dev/null
+++ b/hardcopy/saver/saver.PS.gz
diff --git a/man/general/Consortium.man b/man/general/Consortium.man
new file mode 100644
index 0000000..1a433c5
--- /dev/null
+++ b/man/general/Consortium.man
@@ -0,0 +1,238 @@
+.\" $TOG: Consortium.cpp /main/71 1997/10/13 14:55:16 kaleb $
+.\" Copyright (c) 1993, 1994, 1996  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 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 
+.\" dealing in this Software without prior written authorization from the 
+.\" X Consortium.
+.\"
+.\" $XFree86: xc/doc/man/general/Consortium.man,v 1.4 2001/01/27 18:20:38 dawes Exp $
+.\"
+.TH XCONSORTIUM __miscmansuffix__ __xorgversion__
+.SH NAME
+XConsortium \- X Consortium information
+.SH SYNOPSIS
+Release 6.3 of X Version 11 was brought to you by X Consortium, Inc.
+.SH DESCRIPTION
+The X Consortium was an independent, not-for-profit Delaware membership
+corporation.  It was formed in 1993 as the successor to the MIT X Consortium.
+The purpose of the X Consortium was to foster the development, evolution, and
+maintenance of the X Window System, a comprehensive set of vendor-neutral,
+system-architecture neutral, network-transparent windowing and user interface
+standards.
+.PP
+The X Window System was created in the mid-1980s at the Massachusetts
+Institute of Technology.  In 1988, MIT formed a member-funded consortium to
+provide the technical and administrative leadership necessary to support
+further development of the X Window System.  In 1992, MIT and the membership
+decided it was in their best interests to move the consortium out of MIT and
+create an independent, stand-alone organization.  All rights to the
+X Window System were assigned by MIT to X Consortium, Inc. on January 1, 1994.
+X Consortium, Inc. closed its doors on December 31, 1996.  All rights to the
+X Window System have been assigned to the Open Software Foundation.
+.PP
+The X Consortium was financially self-supporting through membership fees.
+There are no license fees associated with the use of X Window System standards
+and code developed by the X Consortium.  Membership in the X Consortium was
+open to any organization willing to execute a membership agreement.
+.PP
+The X Consortium was a highly participative body.  Members were encouraged to
+actively cooperate with the staff and other members in the design and review
+of proposed specifications, and in the design, coding and testing of sample
+implementations of those specifications.
+.PP
+The X Consortium accomplished most of its work using electronic mail over the
+Internet, with individual mailing lists for working groups.  Internet
+electronic mail connectivity was viewed as a requirement for useful
+participation in X Consortium activities.  Meetings were held as necessary,
+often in conjunction with industry conferences and trade shows.
+.SH STAFF
+.nf
+President:
+Bob Scheifler
+
+Office Manager:
+Janet O'Halloran
+
+Director of Marketing:
+Paul Lavallee
+
+Director of Engineering:
+Jim Fournier
+
+Manager, X Window System:
+Matt Landau, emeritus
+
+Technical Director, X Window System:
+Ralph Swick
+
+Technical Staff, X Window System:
+
+Donna Converse, emeritus
+Stephen Gildea, emeritus
+Kaleb Keithley
+Arnaud Le Hors
+Ralph Mor, emeritus
+Ray Tice
+Dave Wiggins, emeritus
+
+Managers, CDE Development:
+Giora Guth
+Peter Bohnert, emeritus
+
+Manager, CDE Quality Engineering:
+David Brooks
+
+CDE Architects:
+Kevin Samborn
+Daniel Dardailler, emeritus
+
+Technical Staff, CDE Development:
+
+Art Barstow
+Pascale Dardailler
+David Kaelbling
+Mitch Greess
+Robert Seacord
+
+Technical Staff, CDE Quality Engineering:
+
+Chris Burleson
+Tom Cavin
+Sami Mohammed
+Mark Schuldenfrei
+
+Manager, Systems Administration:
+Kevin Ethier
+
+Technical Staff, Systems Administration:
+Mike Donati
+Amy Rich, emeritus
+Anne Salemme
+.fi
+
+.SH "BOARD OF DIRECTORS"
+The X Consortium's activities and affairs were managed under the direction and
+oversight of a Board of Directors, elected annually by the Members.  The Board
+was responsible for reviewing the achievements of the Consortium, approving
+planned work, appointing a President and other officers of the Consortium, and
+setting membership dues.  The last Directors were:
+
+.nf
+Robert W. Scheifler, President, X Consortium
+Dr. Forest Baskett, Senior VP of R&D, Silicon Graphics Computer Systems
+Harold D. Blair, Apogee International Corp.
+Roger S. Gourd, Gourd & Associates
+Dr. Robin Hillyard, Chairman and Chief Technical Officer, Novasoft Systems
+Don McGovern, General Operations Manager and Executive Dir., Hewlett Packard
+Peter J. Shaw, Senior VP, NetManage
+Michael Tobias, President, Tech-Source, Inc.
+.fi
+
+.SH "ADDRESS"
+To reach the X Consortium public Wide World Web server, use the URL:
+http://www.x.org/
+.PP
+To reach the X Consortium public ftp machine, use anonymous ftp to:
+ftp.x.org
+
+.SH "FULL MEMBERS"
+
+.nf
+Adobe Systems Inc.
+Cray Research, Inc.
+Digital Equipment Corp.
+Fujitsu Limited
+Hewlett-Packard Company
+Hitachi Ltd.
+IBM Corporation
+Megatek Corp.
+Motorola, Inc.
+NEC Corporation
+Novell, Inc.
+Oki Electric Industry Co., Ltd.
+OMRON Corporation
+SCO, Inc.
+Siemens Nixdorf Informationssysteme AG
+Silicon Graphics, Inc.
+Sony Corporation
+Sun Microsystems, Inc.
+Tektronix, Inc.
+.fi
+
+.SH "ASSOCIATE MEMBERS"
+
+.nf
+Boundless Technologies
+Hummingbird Communications Ltd.
+Insignia Solutions, Ltd.
+Mercury Interactive Corp.
+NetManage, Inc.
+Network Computing Devices
+VisiCom Laboratories, Inc.
+Walker Richer & Quinn, Inc.
+.fi
+
+.SH "END USERS"
+
+.nf
+Hughes Aircraft Company
+.fi
+
+.SH "AFFILIATE MEMBERS"
+
+.nf
+ASTEC, Inc.
+BARCO Chromatics, Inc.
+CenterLine Software, Inc.
+CliniComp, Intl.
+Component Integration Laboratories, Inc.
+Draper Laboratory.
+Electronic Book Technologies, Inc.
+Gallium Software, Inc.
+Georgia Institiute of Technology
+Human Designed Systems, Inc.
+INRIA \- Institut National de Recherche en Informatique et en Automatique
+Integrated Computer Solutions, Inc.
+Investment Management Services, Inc.
+Jupiter Systems
+KL Group Inc.
+Massachusetts Institute of Technology
+Metheus Corporation
+Metro Link, Inc.
+Object Management Group, Inc.
+Open Software Foundation
+Performance Awareness Corp.
+Peritek Corp.
+Petrotechnical Open Software Corp.
+Point Technologies, Inc.
+Shiman Associates, Inc.
+Smithsonian Astrophysical Observatory.
+Software Development Corp.
+SOUM Corporation
+Spectragraphics Corp.
+Tech-Source, Inc.
+TriTeal Corp.
+White Pine Software, Inc.
+World Wide Web Consortium.
+The XFree86 Project, Inc.
+X Inside, Inc.
+.fi
diff --git a/man/general/Standards.man b/man/general/Standards.man
new file mode 100644
index 0000000..a253a34
--- /dev/null
+++ b/man/general/Standards.man
@@ -0,0 +1,483 @@
+.\" $Xorg: Standards.cpp,v 1.3 2000/08/17 19:42:04 cpqbld Exp $
+.\" Copyright (c) 1993, 1994, 1996  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.
+.\"
+.\" $XFree86: xc/doc/man/general/Standards.man,v 1.4 2001/01/27 18:20:38 dawes Exp $
+.\"
+.\"
+.TH XSTANDARDS __miscmansuffix__ __xorgversion__
+.SH NAME
+XStandards \- X Consortium Standards and X Project Team Specifications
+.SH SYNOPSIS
+The major goal of the X Consortium was to promote cooperation within the
+computer industry in the creation of standard software interfaces at
+all layers in the X Window System environment.  
+The X Consortium produced standards - documents which
+defined network protocols, programming interfaces, and
+other aspects of the X environment.  These standards
+continue to exist in The Open Group's X Project Team
+releases.  The X Project Team produces specifications.
+Like X Consortium Standards, these are documents
+which define network protocols, programming interfaces,
+and other aspects of the X environment.  Under the aegis
+of The Open Group, X Consortium standards, X Project
+Team specifications, and other specifications are the
+basis for portions of The Open Group's various CAE
+specifications.
+.PP
+The status of various standards, specifications, and
+the software in the X11R6.4 distribution, is explained below.
+.SH STANDARDS
+The following documents are X Consortium standards:
+.nf
+
+X Window System Protocol
+X Version 11, Release 6.4
+Robert W. Scheifler
+
+Xlib \- C Language X Interface
+X Version 11, Release 6.4
+James Gettys, Robert W. Scheifler, Ron Newman
+
+X Toolkit Intrinsics \- C Language Interface
+X Version 11, Release 6.4
+Joel McCormack, Paul Asente, Ralph R. Swick, Donna Converse
+
+Bitmap Distribution Format
+Version 2.1
+X Version 11, Release 6.4
+
+Inter-Client Communication Conventions Manual
+Version 2.0
+X Version 11, Release 6.4
+David Rosenthal, Stuart W. Marks
+
+Compound Text Encoding
+Version 1.1
+X Version 11, Release 6.4
+Robert W. Scheifler
+
+X Logical Font Description Conventions
+Version 1.5
+X Version 11, Release 6.4
+Jim Flowers, Stephen Gildea
+
+X Display Manager Control Protocol
+Version 1.0
+X Version 11, Release 6.4
+Keith Packard
+
+X11 Nonrectangular Window Shape Extension
+Version 1.0
+X Version 11, Release 6.4
+Keith Packard
+
+X11 Input Extension Protocol Specification
+Version 1.0
+X Version 11, Release 6.4
+George Sachs, Mark Patrick
+
+X11 Input Extension Library Specification
+X Version 11, Release 6.4
+Mark Patrick, George Sachs
+
+The X Font Service Protocol
+Version 2.0
+X Version 11, Release 6.4
+Jim Fulton
+
+PEX Protocol Specification
+Version 5.1
+Cheryl Huntington (architect), Paula Womack (editor)
+
+PEXlib Specification and C Language Binding
+Version 5.1
+Jeff Stevenson
+
+Inter-Client Exchange (ICE) Protocol
+Version 1.0
+X Version 11, Release 6.4
+Robert Scheifler, Jordan Brown
+
+Inter-Client Exchange (ICE) Library
+Version 1.0
+X Version 11, Release 6.4
+Ralph Mor
+
+X Session Management Protocol
+Version 1.0
+X Version 11, Release 6.4
+Mike Wexler
+
+X Session Management Library
+Version 1.0
+X Version 11, Release 6.4
+Ralph Mor
+
+The Input Method Protocol
+Version 1.0
+X Version 11, Release 6.4
+Masahiko Narita, Hideki Hiura
+
+X Synchronization Extension
+Version 3.0
+X Version 11, Release 6.4
+Tim Glauert, Dave Carver, Jim Gettys, David P. Wiggins
+
+X Image Extension, Protocol Reference Manual
+Version 5.0
+X Version 11, Release 6.4
+Bob Shelley
+
+XTEST Extension
+Version 2.2
+Kieron Drake
+
+Big Requests Extension
+Version 2.0
+X Version 11, Release 6.4
+Bob Scheifler
+
+XC-MISC Extension
+Version 1.1
+X Version 11, Release 6.4
+Bob Scheifler, Dave Wiggins
+
+Double Buffer Extension
+Version 1.0
+Ian Elliott, David P. Wiggins
+
+Record Extension Protocol
+Version 1.13
+Martha Zimet, Stephen Gildea
+
+Record Extension Library
+Version 1.13
+Martha Zimet, Stephen Gildea
+
+X Keyboard Extension Protocol
+X Version 11, Release 6.4
+Erik Fortune
+
+X Keyboard Extension Library
+X Version 11, Release 6.4
+Amber J. Benson, Gary Aitken, Erik Fortune, Donna Converse,
+George Sachs, and Will Walker
+
+X Print Extension Protocol
+X Version 11, Release 6.4
+
+X Print Extension Library
+X Version 11, Release 6.4
+
+X Application Group Extension Protocol and Library
+Version 1.0
+X Version 11, Release 6.4
+Kaleb Keithley
+
+X Security Extension Protocol and Library
+Version 4.0
+X Version 11, Release 6.4
+Dave Wiggins
+
+X Proxy Manager Protocol
+X Version 11, Release 6.4
+Ralph Swick
+
+LBX Extension Protocol and Library
+X Version 11, Release 6.4
+Keith Packard, Dave Lemke, Donna Converse, Ralph Mor, Ray Tice
+
+Remote Execution MIME Type
+Version 1.0
+X Version 11, Release 6.4
+Arnaud Le Hors
+.fi
+.SH SPECIFICATIONS
+The following documents are X Project Team specifications:
+.nf
+
+Colormap Utilization Policy and Extension
+Version 1.0
+Kaleb Keithley
+
+Extended Visual Information Extension
+Version 1.0
+Peter Daifuku
+
+X Display Power Management (DPMS) Extension Protocol and Library
+Version 1.0
+Rob Lembree
+
+.SH "DRAFT STANDARDS"
+The following documents are currently draft standards of the X Consortium.
+.nf
+
+X Image Extension Library
+Public Review Draft
+Gary Rogers
+
+PEX Protocol Specification
+Version 5.2
+Jeff Stevenson (architect), Jane Sczechowski (editor)
+
+PEXlib Specification and C Language Binding
+Version 5.2
+Karl Schultz
+.fi
+
+.SH "INCLUDE FILES"
+The following include files are part of the Xlib standard.
+.PP
+.nf
+<X11/cursorfont.h>
+<X11/keysym.h>
+<X11/keysymdef.h>
+<X11/X.h>
+<X11/Xatom.h>
+<X11/Xcms.h>
+<X11/Xlib.h>
+<X11/Xlibint.h>
+<X11/Xproto.h>
+<X11/Xprotostr.h>
+<X11/Xresource.h>
+<X11/Xutil.h>
+<X11/X10.h>
+.fi
+.PP
+The following include files are part of the X Toolkit Intrinsics standard.
+.PP
+.nf
+<X11/Composite.h>
+<X11/CompositeP.h>
+<X11/Constraint.h>
+<X11/ConstrainP.h>
+<X11/Core.h>
+<X11/CoreP.h>
+<X11/Intrinsic.h>
+<X11/IntrinsicP.h>
+<X11/Object.h>
+<X11/ObjectP.h>
+<X11/RectObj.h>
+<X11/RectObjP.h>
+<X11/Shell.h>
+<X11/ShellP.h>
+<X11/StringDefs.h>
+<X11/Vendor.h>
+<X11/VendorP.h>
+.fi
+.PP
+The following include file is part of the
+Nonrectangular Window Shape Extension standard.
+.PP
+.nf
+<X11/extensions/shape.h>
+.fi
+.PP
+The following include files are part of the X Input Extension standard.
+.PP
+.nf
+<X11/extensions/XI.h>
+<X11/extensions/XInput.h>
+<X11/extensions/XIproto.h>
+.fi
+.PP
+The following include files are part of the PEXlib standard.
+.PP
+.nf
+<X11/PEX5/PEX.h>
+<X11/PEX5/PEXlib.h>
+<X11/PEX5/PEXlibint.h>
+<X11/PEX5/PEXproto.h>
+<X11/PEX5/PEXprotost.h>
+.fi
+.PP
+The following include files are part of the ICElib standard.
+.PP
+.nf
+<X11/ICE/ICE.h>
+<X11/ICE/ICEconn.h>
+<X11/ICE/ICElib.h>
+<X11/ICE/ICEmsg.h>
+<X11/ICE/ICEproto.h>
+<X11/ICE/ICEutil.h>
+.fi
+.PP
+The following include files are part of the SMlib standard.
+.PP
+.nf
+<X11/SM/SM.h>
+<X11/SM/SMlib.h>
+<X11/SM/SMproto.h>
+.fi
+.PP
+The following include file is part of the Synchronization standard.
+.PP
+.nf
+<X11/extensions/sync.h>
+.fi
+.PP
+The following include files are part of the XIElib draft standard.
+.PP
+.nf
+<X11/extensions/XIE.h>
+<X11/extensions/XIElib.h>
+<X11/extensions/XIEproto.h>
+<X11/extensions/XIEprotost.h>
+.fi
+.PP
+The following include file is part of the XTEST standard.
+.PP
+.nf
+<X11/extensions/XTest.h>
+.fi
+.PP
+The following include file is part of the Double Buffer Extension standard.
+.PP
+.nf
+<X11/extensions/Xdbe.h>
+.fi
+.PP
+The following include file is part of the Record Library standard.
+.PP
+.nf
+<X11/extensions/record.h>
+.fi
+.PP
+The following include files are part of the X Keyboard Extension Library
+standard.
+.PP
+.nf
+\" some subset of...
+<X11/XKBlib.h>
+<X11/extensions/XKB.h>
+<X11/extensions/XKBproto.h>
+<X11/extensions/XKBstr.h>
+<X11/extensions/XKBgeom.h>
+.fi
+.PP
+The following include files are part of the X Print Extension Library
+standard.
+.PP
+.nf
+<X11/extensions/Print.h>
+<X11/extensions/Printstr.h>
+.fi
+.PP
+The following include files are part of the X Application Group Extension
+Library standard.
+.PP
+.nf
+<X11/extensions/Xag.h>
+<X11/extensions/Xagstr.h>
+.fi
+.PP
+The following include files are part of the X Security Extension Library
+standard.
+.PP
+.nf
+<X11/extensions/security.h>
+<X11/extensions/securstr.h>
+.fi
+.PP
+The following include files are part of the LBX Extension library standard.
+.PP
+.nf
+\" some subset of...
+<X11/extensions/XLbx.h>
+<X11/extensions/lbxbuf.h>
+<X11/extensions/lbxbufstr.h>
+<X11/extensions/lbxdeltastr.h>
+<X11/extensions/lbximage.h>
+<X11/extensions/lbxopts.h>
+<X11/extensions/lbxstr.h>
+<X11/extensions/lbxzlib.h>
+.fi
+.PP
+The following include files are part of the Colormap Utilization 
+Policy and Extention specification.
+.PP
+.nf
+<X11/extensions/Xcup.h>
+<X11/extensions/Xcupstr.h>
+.fi
+.PP
+The following include files are part of the Extended Visual
+Information specification.
+.PP
+.nf
+<X11/extensions/XEVI.h>
+<X11/extensions/XEVIstr.h>
+.fi
+.PP
+The following include files are part of the X Display Management
+Signaling Extension specification.
+.PP
+.nf
+<X11/extensions/dpms.h>
+<X11/extensions/dpmsstr.h>
+.fi
+
+.SH "NON STANDARDS"
+The X11R6.4 distribution contains \fIsample\fP implementations, not
+\fIreference\fP implementations.  Although much of the code is believed
+to be correct, the code should be assumed to be in error wherever it
+conflicts with the specification.
+.PP
+The only X Consortium standards are the ones listed above.
+No other documents, include files, or software in X11R6.4 carry special
+status within the X Consortium.  For example, none of the following
+are standards:
+internal interfaces of the sample server;
+the MIT-SHM extension;
+the Athena Widget Set;
+the Xmu library;
+the Xau library;
+the RGB database;
+the X Locale database;
+the fonts distributed with X11R6.4;
+the applications distributed with X11R6.4;
+the include files <X11/XWDFile.h>, <X11/Xfuncproto.h>, <X11/Xfuncs.h>,
+<X11/Xosdefs.h>, <X11/Xos.h>, <X11/Xos_r.h>, <X11/Xwinsock.h>, and 
+<X11/Xthreads.h>;
+the bitmap files in <X11/bitmaps>.
+.PP
+The Multi-Buffering extension was a draft standard of the
+X Consortium but has been superseded by DBE as a standard.
+
+.SH "X REGISTRY"
+The X Consortium maintained a registry of certain X-related items, to
+aid in avoiding conflicts and to aid in sharing of such items.
+.PP
+The registry is published as part of the X Consortium software
+release.
+The latest version may also be available by sending a message to
+xstuff@x.org.  The message can have a subject line and no body, or a
+single-line body and no subject, in either case the line looking like:
+.nf
+	send docs registry
+.fi
+The X Registry and the names in it are not X Consortium standards.
diff --git a/man/general/X.man b/man/general/X.man
new file mode 100644
index 0000000..ff610b1
--- /dev/null
+++ b/man/general/X.man
@@ -0,0 +1,1320 @@
+.\" $Xorg: X.cpp,v 1.3 2000/08/17 19:42:04 cpqbld Exp $
+.\" Copyright (c) 1994  X Consortium
+.\" Copyright \(co 2000  The XFree86 Project, Inc.
+.\" 
+.\" 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 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 
+.\" dealing in this Software without prior written authorization from the 
+.\" X Consortium.
+.\"
+.\" $XFree86: xc/doc/man/general/X.man,v 1.8 2002/10/12 16:06:41 herrb Exp $
+.\"
+.TH X __miscmansuffix__ __vendorversion__
+.SH NAME
+X \- a portable, network-transparent window system
+.SH SYNOPSIS
+.PP
+The X Window System is a network transparent window system which runs
+on a wide range of computing and graphics machines.  It should be
+relatively straightforward to build the X Consortium software
+distribution on most ANSI C and POSIX compliant systems.  Commercial
+implementations are also available for a wide range of platforms.
+.PP
+The X Consortium requests that the following names be used when
+referring to this software:
+.sp
+.ce 5
+X
+.br
+X Window System
+.br
+X Version 11
+.br
+X Window System, Version 11
+.br
+X11
+.PP
+.I "X Window System"
+is a trademark of X Consortium, Inc.
+.SH DESCRIPTION
+X Window System servers run on computers with bitmap displays.
+The server distributes user input to and accepts output requests from various
+client programs through a variety of different interprocess
+communication channels.  Although the most common case is for the client
+programs to be
+running on the same machine as the server, clients can be run transparently
+from other machines (including machines with different architectures and
+operating systems) as well.
+.PP
+X supports overlapping hierarchical subwindows and text and
+graphics operations, on both monochrome and color
+displays.
+For a full explanation of the functions that are available, see
+the \fIXlib - C Language X Interface\fP manual, 
+the \fIX Window System Protocol\fP specification,
+the \fIX Toolkit Intrinsics - C Language Interface\fP manual,
+and various toolkit documents.
+.PP
+The number of programs that use \fIX\fP is quite large.
+Programs provided in the core X Consortium distribution include:
+a terminal emulator, \fIxterm\fP;
+a window manager, \fItwm\fP; 
+a display manager, \fIxdm\fP;
+a console redirect program, \fIxconsole\fP;
+a mail interface, \fIxmh\fP;
+a bitmap editor, \fIbitmap\fP;
+resource listing/manipulation tools, \fIappres\fP, \fIeditres\fP;
+access control programs, \fIxauth\fP, \fIxhost\fP, and \fIiceauth\fP;
+user preference setting programs, \fIxrdb\fP, \fIxcmsdb\fP,
+\fIxset\fP, \fIxsetroot\fP, \fIxstdcmap\fP, and \fIxmodmap\fP;
+clocks, \fIxclock\fP and \fIoclock\fP;
+a font displayer, (\fIxfd\fP;
+utilities for listing information about fonts, windows, and displays,
+\fIxlsfonts\fP, \fIxwininfo\fP, \fIxlsclients\fP,
+\fIxdpyinfo\fP, \fIxlsatoms\fP, and \fIxprop\fP;
+screen image manipulation utilities, \fIxwd\fP, \fIxwud\fP, and \fIxmag\fP;
+a performance measurement utility, \fIx11perf\fP;
+a font compiler, \fIbdftopcf\fP;
+a font server and related utilities, \fIxfs\fP, \fIfsinfo\fP, \fIfslsfonts\fP, \fIfstobdf\fP;
+an X Image Extension exerciser, \fIxieperf\fP;
+a display server and related utilities, \fIXserver\fP, \fIrgb\fP, \fImkfontdir\fP;
+remote execution utilities, \fIrstart\fP and \fIxon\fP;
+a clipboard manager, \fIxclipboard\fP;
+keyboard description compiler and related utilities, \fIxkbcomp\fP, 
+\fIxkbprint\fP, \fIxkbbell\fP, \fIxkbevd\fP, \fIxkbvleds\fP, and \fIxkbwatch\fP;
+a utility to terminate clients, \fIxkill\fP; 
+an optimized X protocol proxy, \fIlbxproxy\fP;
+a firewall security proxy, \fIxfwp\fP;
+a proxy manager to control them, \fIproxymngr\fP;
+a utility to find proxies, \fIxfindproxy\fP;
+Netscape Navigator Plug-ins, \fIlibxrx.so\fP and \fIlibxrxnest.so\fP;
+an RX MIME-type helper program, \fIxrx\fP;
+and a utility to cause part or all of the screen to be redrawn, \fIxrefresh\fP. 
+.PP
+Many other utilities, window managers, games, toolkits, etc. are included
+as user-contributed software in the X Consortium distribution, or are
+available using anonymous ftp on the Internet.
+See your site administrator for details.
+.SH "STARTING UP"
+.PP 
+There are two main ways of getting the X server and an initial set of
+client applications started.  The particular method used depends on what
+operating system you are running and whether or not you use other window
+systems in addition to X.
+.TP 8
+.B "\fIxdm\fP (the X Display Manager)"
+If you want to always have X running on your display, your site administrator
+can set your machine up to use the X Display Manager \fIxdm\fP.  This program
+is typically started by the system at boot time and takes care of keeping the
+server running and getting users logged in.  If you are running
+\fIxdm\fP, you will see a window on the screen welcoming you to the system and
+asking for your username and password.  Simply type them in as you would at
+a normal terminal, pressing the Return key after each.  If you make a mistake,
+\fIxdm\fP will display an error message and ask you to try again.  After you
+have successfully logged in, \fIxdm\fP will start up your X environment.  By
+default, if you have an executable file named \fI.xsession\fP in your
+home directory,
+\fIxdm\fP will treat it as a program (or shell script) to run to start up 
+your initial clients (such as terminal emulators, clocks, a window manager,
+user settings for things like the background, the speed of the pointer, etc.).
+Your site administrator can provide details.
+.TP 8
+.B "\fIxinit\fP (run manually from the shell)"
+Sites that support more than one window system might choose to use the
+\fIxinit\fP program for starting X manually.  If this is true for your 
+machine, your site administrator will probably have provided a program 
+named "x11", "startx", or "xstart" that will do site-specific initialization
+(such as loading convenient default resources, running a window manager, 
+displaying a clock, and starting several terminal emulators) in a nice
+way.  If not, you can build such a script using the \fIxinit\fP program.
+This utility simply runs one user-specified program to start the server,
+runs another to start up any desired clients, and then waits for either to
+finish.  Since either or both of the user-specified programs may be a shell 
+script, this gives substantial flexibility at the expense of a
+nice interface.  For this reason, \fIxinit\fP is not intended for end users.
+.SH "DISPLAY NAMES"
+.PP
+From the user's perspective, every X server has a \fIdisplay name\fP of the
+form:
+.sp
+.ce 1
+\fIhostname:displaynumber.screennumber\fP
+.sp
+This information is used by the application to determine how it should
+connect to the server and which screen it should use by default
+(on displays with multiple monitors):
+.TP 8
+.I hostname
+The \fIhostname\fP specifies the name of the machine to which the display is
+physically connected.  If the hostname is not given, the most efficient way of 
+communicating to a server on the same machine will be used.
+.TP 8
+.I displaynumber
+The phrase "display" is usually used to refer to collection of monitors that
+share a common keyboard and pointer (mouse, tablet, etc.).  Most workstations
+tend to only have one keyboard, and therefore, only one display.  Larger, 
+multi-user
+systems, however, frequently have several displays so that more than
+one person can be doing graphics work at once.  To avoid confusion, each
+display on a machine is assigned a \fIdisplay number\fP (beginning at 0)
+when the X server for that display is started.  The display number must always
+be given in a display name.
+.TP 8
+.I screennumber
+Some displays share a single keyboard and pointer among two or more monitors.
+Since each monitor has its own set of windows, each screen is assigned a
+\fIscreen number\fP (beginning at 0) when the X server for that display is
+started.  If the screen number is not given, screen 0 will be used.
+.PP
+On POSIX systems, the default display name is stored 
+in your DISPLAY environment variable.  This variable is set automatically
+by the \fIxterm\fP terminal emulator.  However, when you log into another
+machine on a network, you will need to set DISPLAY by hand to point to your
+display.  For example,
+.sp
+.nf
+    % setenv DISPLAY myws:0
+    $ DISPLAY=myws:0; export DISPLAY
+.fi
+The \fIxon\fP script can be used to start an X program on a remote machine;
+it automatically sets the DISPLAY variable correctly.
+.PP
+Finally, most X programs accept a command line option of 
+\fB-display \fIdisplayname\fR to temporarily override the contents of
+DISPLAY.  This is most commonly used to pop windows on another person's
+screen or as part of a "remote shell" command to start an xterm pointing back 
+to your display.  For example,
+.sp
+.nf
+    % xeyes -display joesws:0 -geometry 1000x1000+0+0
+    % rsh big xterm -display myws:0 -ls </dev/null &
+.fi
+.PP
+X servers listen for connections on a variety of different 
+communications channels (network byte streams, shared memory, etc.).
+Since there can be more than one way of contacting a given server,
+The \fIhostname\fP part of the display name is used to determine the
+type of channel 
+(also called a transport layer) to be used.  X servers generally
+support the following types of connections:
+.TP 8
+.I "local"
+.br
+The hostname part of the display name should be the empty string.
+For example:  \fI:0\fP, \fI:1\fP, and \fI:0.1\fP.  The most efficient
+local transport will be chosen.
+.TP 8
+.I TCP\/IP
+.br
+The hostname part of the display name should be the server machine's
+IP address name.  Full Internet names, abbreviated names, and IP addresses
+are all allowed.  For example:  \fIx.org:0\fP, \fIexpo:0\fP,
+\fI198.112.45.11:0\fP, \fIbigmachine:1\fP, and \fIhydra:0.1\fP.
+.TP 8
+.I DECnet
+.br
+The hostname part of the display name should be the server machine's 
+nodename, followed by two colons instead of one.
+For example:  \fImyws::0\fP, \fIbig::1\fP, and \fIhydra::0.1\fP.
+.PP
+.SH "ACCESS CONTROL"
+An X server can use several types of access control.  Mechanisms provided
+in Release 6 are:
+.nf
+.br
+.ta 3.4i
+    Host Access	Simple host-based access control.
+    MIT-MAGIC-COOKIE-1	Shared plain-text "cookies".
+    XDM-AUTHORIZATION-1	Secure DES based private-keys.
+    SUN-DES-1	Based on Sun's secure rpc system.
+    MIT-KERBEROS-5	Kerberos Version 5 user-to-user.
+.fi
+.PP
+\fIXdm\fP initializes access control for the server and also places
+authorization information in a file accessible to the user.
+Normally, the list of hosts from
+which connections are always accepted should be empty, so that only clients
+with are explicitly authorized can connect to the display.  When you add
+entries to the host list (with \fIxhost\fP), the server no longer performs any
+authorization on connections from those machines.  Be careful with this.
+.PP
+The file from which \fIXlib\fP extracts authorization data can be
+specified with the environment variable \fBXAUTHORITY\fP, and defaults to
+the file \fB.Xauthority\fP in the home directory.  \fIXdm\fP uses
+\fB$HOME/.Xauthority\fP and will create it or merge in authorization records
+if it already exists when a user logs in.
+.PP
+If you use several machines and share a common home directory
+across all of the machines by means of a network file system,
+you never really have to worry about authorization files,
+the system should work correctly by default.
+Otherwise, as the authorization files are machine-independent,
+you can simply copy the files to share them.
+To manage authorization files, use \fIxauth\fP.
+This program allows you to extract
+records and insert them into other files.  Using this, you can send
+authorization to remote machines when you login,
+if the remote machine does not share a common home directory with
+your local machine.
+Note that authorization information transmitted
+``in the clear'' through a network file system or
+using \fIftp\fP or \fIrcp\fP can be ``stolen''
+by a network eavesdropper, and as such may enable unauthorized access.
+In many environments, this level of security is not a concern, but if it is,
+you need to know the exact semantics of the particular authorization
+data to know if this is actually a problem.
+.PP
+For more information on access control, see the \fIXsecurity\fP manual page.
+.SH "GEOMETRY SPECIFICATIONS"
+One of the advantages of using window systems instead of
+hardwired terminals is that 
+applications don't have to be restricted to a particular size or location
+on the screen.
+Although the layout of windows on a display is controlled
+by the window manager that the user is running (described below), 
+most X programs accept
+a command line argument of the form \fB-geometry \fIWIDTHxHEIGHT+XOFF+YOFF\fR
+(where \fIWIDTH\fP, \fIHEIGHT\fP, \fIXOFF\fP, and \fIYOFF\fP are numbers)
+for specifying a preferred size and location for this application's main
+window.
+.PP
+The \fIWIDTH\fP and \fIHEIGHT\fP parts of the geometry specification are
+usually measured in either pixels or characters, depending on the application.
+The \fIXOFF\fP and \fIYOFF\fP parts are measured in pixels and are used to
+specify the distance of the window from the left or right and top and bottom
+edges of the screen, respectively.  Both types of offsets are measured from the
+indicated edge of the screen to the corresponding edge of the window.  The X
+offset may be specified in the following ways:
+.TP 8
+.I +XOFF
+The left edge of the window is to be placed \fIXOFF\fP pixels in from the
+left edge of the screen (i.e., the X coordinate of the window's origin will be 
+\fIXOFF\fP).  \fIXOFF\fP may be negative, in which case the window's left edge 
+will be off the screen.
+.TP 8
+.I -XOFF
+The right edge of the window is to be placed \fIXOFF\fP pixels in from the
+right edge of the screen.  \fIXOFF\fP may be negative, in which case the 
+window's right edge will be off the screen.
+.PP
+The Y offset has similar meanings:
+.TP 8
+.I +YOFF
+The top edge of the window is to be \fIYOFF\fP pixels below the
+top edge of the screen (i.e., the Y coordinate of the window's origin will be
+\fIYOFF\fP).  \fIYOFF\fP may be negative, in which case the window's top edge 
+will be off the screen.
+.TP 8
+.I -YOFF
+The bottom edge of the window is to be \fIYOFF\fP pixels above the
+bottom edge of the screen.  \fIYOFF\fP may be negative, in which case 
+the window's bottom edge will be off the screen.
+.PP
+Offsets must be given as pairs; in other words, in order to specify either
+\fIXOFF\fP or \fIYOFF\fP both must be present.  Windows can be placed in the
+four corners of the screen using the following specifications:
+.TP 8
+.I +0+0
+upper left hand corner.
+.TP 8
+.I -0+0
+upper right hand corner.
+.TP 8
+.I -0-0
+lower right hand corner.
+.TP 8
+.I +0-0
+lower left hand corner.
+.PP
+In the following examples, a terminal emulator is placed in roughly
+the center of the screen and
+a load average monitor, mailbox, and clock are placed in the upper right 
+hand corner:
+.sp
+.nf
+    xterm -fn 6x10 -geometry 80x24+30+200 &
+    xclock -geometry 48x48-0+0 &
+    xload -geometry 48x48-96+0 &
+    xbiff -geometry 48x48-48+0 &
+.fi
+.PP
+.SH "WINDOW MANAGERS"
+The layout of windows on the screen is controlled by special programs called
+\fIwindow managers\fP.  Although many window managers will honor geometry
+specifications as given, others may choose to ignore them (requiring the user
+to explicitly draw the window's region on the screen with the pointer, for 
+example).
+.PP
+Since window managers are regular (albeit complex) client programs,
+a variety of different user interfaces can be built.  The X Consortium distribution
+comes with a window manager named \fItwm\fP which supports overlapping windows,
+popup menus, point-and-click or click-to-type input models, title bars, nice
+icons (and an icon manager for those who don't like separate icon windows).
+.PP
+See the user-contributed software in the X Consortium distribution for other
+popular window managers.
+.SH "FONT NAMES"
+Collections of characters for displaying text and symbols in X are known as
+\fIfonts\fP.  A font typically contains images that share a common appearance
+and look nice together (for example, a single size, boldness, slant, and
+character set).  Similarly, collections of fonts that are based on a common
+type face (the variations are usually called roman, bold, italic, bold italic, 
+oblique, and bold oblique) are called \fIfamilies\fP.  
+.PP
+Fonts come in various sizes.  The X server supports \fIscalable\fP fonts,
+meaning it is possible to create a font of arbitrary size from a single
+source for the font.  The server supports scaling from \fIoutline\fP
+fonts and \fIbitmap\fP fonts.  Scaling from outline fonts usually produces
+significantly better results than scaling from bitmap fonts.
+.PP
+An X server can obtain fonts from individual files stored in directories
+in the file system, or from one or more font servers,
+or from a mixtures of directories and font servers.
+The list of places the server looks when trying to find
+a font is controlled by its \fIfont path\fP.  Although most installations
+will choose to have the server start up with all of the commonly used font
+directories in the font path, the font path can be changed at any time
+with the \fIxset\fP program.
+However, it is important to remember that the directory names are
+on the \fBserver\fP's machine, not on the application's.
+.PP
+Bitmap font files are usually created by compiling a textual font description
+into binary form, using \fIbdftopcf\fP.
+Font databases are created by running the \fImkfontdir\fP program in the
+directory containing the source or compiled versions of the fonts.
+Whenever fonts are added to a directory, \fImkfontdir\fP should be rerun
+so that the server can find the new fonts.  To make the server reread the
+font database, reset the font path with the \fIxset\fP program.  For example,
+to add a font to a private directory, the following commands could be used:
+.sp
+.nf
+    % cp newfont.pcf ~/myfonts
+    % mkfontdir ~/myfonts
+    % xset fp rehash 
+.fi
+.PP
+The \fIxfontsel\fP and \fIxlsfonts\fP programs can be used to browse
+through the fonts available on a server.
+Font names tend to be fairly long as they contain all of the information
+needed to uniquely identify individual fonts.  However, the X server
+supports wildcarding of font names, so the full specification
+.sp
+.nf
+    \fI-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1\fP
+.fi
+.sp
+might be abbreviated as:
+.sp
+.nf
+    \fI-*-courier-medium-r-normal--*-100-*-*-*-*-iso8859-1\fP
+.fi
+.PP
+Because the shell also has special meanings for \fI*\fP and \fI?\fP,
+wildcarded font names should be quoted:
+.sp
+.nf
+    % xlsfonts -fn '-*-courier-medium-r-normal--*-100-*-*-*-*-*-*'
+.fi
+.PP
+The \fIxlsfonts\fP program can be used to list all of the fonts that
+match a given pattern.  With no arguments, it lists all available fonts.
+This will usually list the same font at many different sizes.  To see
+just the base scalable font names, try using one of the following patterns:
+.sp
+.nf
+    \fI-*-*-*-*-*-*-0-0-0-0-*-0-*-*\fP
+    \fI-*-*-*-*-*-*-0-0-75-75-*-0-*-*\fP
+    \fI-*-*-*-*-*-*-0-0-100-100-*-0-*-*\fP
+.fi
+.PP
+To convert one of the resulting names into a font at a specific size,
+replace one of the first two zeros with a nonzero value.
+The field containing the first zero is for the pixel size; replace it
+with a specific height in pixels to name a font at that size.
+Alternatively, the field containing the second zero is for the point size;
+replace it with a specific size in decipoints (there are 722.7 decipoints to
+the inch) to name a font at that size.
+The last zero is an average width field, measured in tenths of pixels;
+some servers will anamorphically scale if this value is specified.
+.SH "FONT SERVER NAMES"
+One of the following forms can be used to name a font server that
+accepts TCP connections:
+.sp
+.nf
+    tcp/\fIhostname\fP:\fIport\fP
+    tcp/\fIhostname\fP:\fIport\fP/\fIcataloguelist\fP
+.fi
+.PP
+The \fIhostname\fP specifies the name (or decimal numeric address)
+of the machine on which the font server is running.  The \fIport\fP
+is the decimal TCP port on which the font server is listening for connections.
+The \fIcataloguelist\fP specifies a list of catalogue names,
+with '+' as a separator.
+.PP
+Examples: \fItcp/x.org:7100\fP, \fItcp/198.112.45.11:7100/all\fP.
+.PP
+One of the following forms can be used to name a font server that
+accepts DECnet connections:
+.sp
+.nf
+    decnet/\fInodename\fP::font$\fIobjname\fP
+    decnet/\fInodename\fP::font$\fIobjname\fP/\fIcataloguelist\fP
+.fi
+.PP
+The \fInodename\fP specifies the name (or decimal numeric address)
+of the machine on which the font server is running.
+The \fIobjname\fP is a normal, case-insensitive DECnet object name.
+The \fIcataloguelist\fP specifies a list of catalogue names,
+with '+' as a separator.
+.PP
+Examples: \fIDECnet/SRVNOD::FONT$DEFAULT\fP, \fIdecnet/44.70::font$special/symbols\fP.
+.SH "COLOR NAMES"
+Most applications provide ways of tailoring (usually through resources or
+command line arguments) the colors of various elements
+in the text and graphics they display.
+A color can be specified either by an abstract color name,
+or by a numerical color specification.
+The numerical specification can identify a color in either
+device-dependent (RGB) or device-independent terms.
+Color strings are case-insensitive.
+.PP
+X supports the use of abstract color names, for example, "red", "blue".
+A value for this abstract name is obtained by searching one or more color
+name databases.
+\fIXlib\fP first searches zero or more client-side databases;
+the number, location, and content of these databases is
+implementation dependent.
+If the name is not found, the color is looked up in the
+X server's database.
+The text form of this database is commonly stored in the file
+\fI__projectroot__/lib/X11/rgb.txt\fP.
+.PP
+A numerical color specification
+consists of a color space name and a set of values in the following syntax:
+.sp
+.nf
+    \fI<color_space_name>\fP:\fI<value>/.../<value>\fP
+.fi
+.PP
+An RGB Device specification is identified by
+the prefix "rgb:" and has the following syntax:
+.sp
+.nf
+    rgb:\fI<red>/<green>/<blue>\fP
+
+        \fI<red>\fP, \fI<green>\fP, \fI<blue>\fP := \fIh\fP | \fIhh\fP | \fIhhh\fP | \fIhhhh\fP
+        \fIh\fP := single hexadecimal digits
+.fi
+Note that \fIh\fP indicates the value scaled in 4 bits, 
+\fIhh\fP the value scaled in 8 bits,
+\fIhhh\fP the value scaled in 12 bits,
+and \fIhhhh\fP the value scaled in 16 bits, respectively.
+These values are passed directly to the X server,
+and are assumed to be gamma corrected.
+.PP
+The eight primary colors can be represented as:
+.sp
+.ta 2.5i
+.nf
+    black	rgb:0/0/0
+    red	rgb:ffff/0/0
+    green	rgb:0/ffff/0
+    blue	rgb:0/0/ffff
+    yellow	rgb:ffff/ffff/0
+    magenta	rgb:ffff/0/ffff
+    cyan	rgb:0/ffff/ffff
+    white	rgb:ffff/ffff/ffff
+.fi
+.PP
+For backward compatibility, an older syntax for RGB Device is
+supported, but its continued use is not encouraged.
+The syntax is an initial sharp sign character followed by
+a numeric specification, in one of the following formats:
+.sp
+.ta 3i
+.nf
+\&    #RGB	(4 bits each)
+\&    #RRGGBB	(8 bits each)
+\&    #RRRGGGBBB	(12 bits each)
+\&    #RRRRGGGGBBBB	(16 bits each)
+.fi
+.PP
+The R, G, and B represent single hexadecimal digits.
+When fewer than 16 bits each are specified, 
+they represent the most-significant bits of the value
+(unlike the "rgb:" syntax, in which values are scaled).
+For example, #3a7 is the same as #3000a0007000.
+.PP
+An RGB intensity specification is identified
+by the prefix "rgbi:" and has the following syntax:
+.sp
+.nf
+    rgbi:\fI<red>/<green>/<blue>\fP
+.fi
+.PP
+The red, green, and blue are floating point values
+between 0.0 and 1.0, inclusive.
+They represent linear intensity values, with
+1.0 indicating full intensity, 0.5 half intensity, and so on.
+These values will be gamma corrected by \fIXlib\fP
+before being sent to the X server.
+The input format for these values is an optional sign,
+a string of numbers possibly containing a decimal point,
+and an optional exponent field containing an E or e 
+followed by a possibly signed integer string.
+.PP
+The standard device-independent string specifications have
+the following syntax:
+.sp
+.ta 3.5i
+.nf
+    CIEXYZ:\fI<X>/<Y>/<Z>\fP	(\fInone\fP, 1, \fInone\fP)
+    CIEuvY:\fI<u>/<v>/<Y>\fP	(~.6, ~.6, 1)
+    CIExyY:\fI<x>/<y>/<Y>\fP	(~.75, ~.85, 1)
+    CIELab:\fI<L>/<a>/<b>\fP	(100, \fInone\fP, \fInone\fP)
+    CIELuv:\fI<L>/<u>/<v>\fP	(100, \fInone\fP, \fInone\fP)
+    TekHVC:\fI<H>/<V>/<C>\fP	(360, 100, 100)
+.fi
+.PP
+All of the values (C, H, V, X, Y, Z, a, b, u, v, y, x) are
+floating point values.  Some of the values are constrained to
+be between zero and some upper bound; the upper bounds are
+given in parentheses above.
+The syntax for these values is an optional '+' or '-' sign,
+a string of digits possibly containing a decimal point,
+and an optional exponent field consisting of an 'E' or 'e'
+followed by an optional '+' or '-' followed by a string of digits.
+.PP
+For more information on device independent color,
+see the \fIXlib\fP reference manual.
+.SH KEYBOARDS
+.PP
+The X keyboard model is broken into two layers:  server-specific codes
+(called \fIkeycodes\fP) which represent the physical keys, and 
+server-independent symbols (called \fIkeysyms\fP) which
+represent the letters or words that appear on the keys.  
+Two tables are kept in the server for converting keycodes to keysyms:
+.TP 8
+.I "modifier list"
+Some keys (such as Shift, Control, and Caps Lock) are known as \fImodifier\fP
+and are used to select different symbols that are attached to a single key
+(such as Shift-a generates a capital A, and Control-l generates a control
+character ^L).  The server keeps a list of keycodes corresponding to the
+various modifier keys.  Whenever a key is pressed or released, the server 
+generates an \fIevent\fP that contains the keycode of the indicated key as 
+well as a mask that specifies which of the modifier keys are currently pressed.
+Most servers set up this list to initially contain
+the various shift, control, and shift lock keys on the keyboard.  
+.TP 8
+.I "keymap table"
+Applications translate event keycodes and modifier masks into keysyms
+using a \fIkeysym table\fP which contains one row for each keycode and one
+column for various modifier states.  This table is initialized by the server
+to correspond to normal typewriter conventions.  The exact semantics of
+how the table is interpreted to produce keysyms depends on the particular
+program, libraries, and language input method used, but the following
+conventions for the first four keysyms in each row are generally adhered to:
+.PP
+The first four elements of the list are split into two groups of keysyms.
+Group 1 contains the first and second keysyms;
+Group 2 contains the third and fourth keysyms.
+Within each group,
+if the first element is alphabetic and the
+the second element is the special keysym \fINoSymbol\fP,
+then the group is treated as equivalent to a group in which
+the first element is the lowercase letter and the second element
+is the uppercase letter.
+.PP
+Switching between groups is controlled by the keysym named MODE SWITCH,
+by attaching that keysym to some key and attaching
+that key to any one of the modifiers Mod1 through Mod5.
+This modifier is called the ``group modifier.''
+Group 1 is used when the group modifier is off,
+and Group 2 is used when the group modifier is on.
+.PP
+Within a group,
+the modifier state determines which keysym to use.
+The first keysym is used when the Shift and Lock modifiers are off.
+The second keysym is used when the Shift modifier is on,
+when the Lock modifier is on and the second keysym is uppercase alphabetic,
+or when the Lock modifier is on and is interpreted as ShiftLock.
+Otherwise, when the Lock modifier is on and is interpreted as CapsLock,
+the state of the Shift modifier is applied first to select a keysym;
+but if that keysym is lowercase alphabetic,
+then the corresponding uppercase keysym is used instead.
+.SH OPTIONS
+Most X programs attempt to use the same names for command line options and
+arguments.  All applications written with the X Toolkit Intrinsics
+automatically accept the following options:
+.TP 8
+.B \-display \fIdisplay\fP
+This option specifies the name of the X server to use.
+.TP 8
+.B \-geometry \fIgeometry\fP
+This option specifies the initial size and location of the window.
+.TP 8
+.B \-bg \fIcolor\fP, \fB\-background \fIcolor\fP
+Either option specifies the color to use for the window background.
+.TP 8
+.B \-bd \fIcolor\fP, \fB\-bordercolor \fIcolor\fP
+Either option specifies the color to use for the window border.
+.TP 8
+.B \-bw \fInumber\fP, \fB\-borderwidth \fInumber\fP
+Either option specifies the width in pixels of the window border.
+.TP 8
+.B \-fg \fIcolor\fP, \fB\-foreground \fIcolor\fP
+Either option specifies the color to use for text or graphics.
+.TP 8
+.B \-fn \fIfont\fP, \fB-font \fIfont\fP
+Either option specifies the font to use for displaying text.
+.TP 8
+.B \-iconic
+.br
+This option indicates that the user would prefer that the application's
+windows initially not be visible as if the windows had be immediately 
+iconified by the user.  Window managers may choose not to honor the
+application's request.  
+.TP 8
+.B \-name
+.br
+This option specifies the name under which resources for the
+application should be found.  This option is useful in shell
+aliases to distinguish between invocations of an application,
+without resorting to creating links to alter the executable file name.
+.TP 8
+.B \-rv\fP, \fB\-reverse\fP
+Either option indicates that the program should simulate reverse video if 
+possible, often by swapping the foreground and background colors.  Not all
+programs honor this or implement it correctly.  It is usually only used on
+monochrome displays.
+.TP 8
+.B \+rv
+.br
+This option indicates that the program should not simulate reverse video.  
+This is used to
+override any defaults since reverse video doesn't always work properly.
+.TP 8
+.B \-selectionTimeout
+This option specifies the timeout in milliseconds within which two
+communicating applications must respond to one another for a selection
+request.
+.TP 8
+.B \-synchronous
+This option indicates that requests to the X server should be sent 
+synchronously, instead of asynchronously.  Since 
+.I Xlib
+normally buffers requests to the server, errors do not necessarily get reported
+immediately after they occur.  This option turns off the buffering so that
+the application can be debugged.  It should never be used with a working 
+program.
+.TP 8
+.B \-title \fIstring\fP
+This option specifies the title to be used for this window.  This information 
+is sometimes
+used by a window manager to provide some sort of header identifying the window.
+.TP 8
+.B \-xnllanguage \fIlanguage[_territory][.codeset]\fP
+This option specifies the language, territory, and codeset for use in
+resolving resource and other filenames.
+.TP 8
+.B \-xrm \fIresourcestring\fP
+This option specifies a resource name and value to override any defaults.  It 
+is also very useful for setting resources that don't have explicit command 
+line arguments.
+.SH RESOURCES
+To make the tailoring of applications to personal preferences easier, X 
+provides a mechanism for storing default values for program resources
+(e.g. background color, window title, etc.)
+Resources are specified as strings
+that are read in from various places when an application is run.
+Program components are named in a hierarchical fashion,
+with each node in the hierarchy identified by a class and an instance name.
+At the top level is the class and instance name of the application itself.
+By convention, the class name of the application is the same as the program
+name, but with  the first letter capitalized (e.g. \fIBitmap\fP or \fIEmacs\fP)
+although some programs that begin with the letter ``x'' also capitalize the
+second letter for historical reasons.
+.PP
+The precise syntax for resources is:
+.PP
+.nf
+.ta 1.8i 2.0i
+ResourceLine	=	Comment | IncludeFile | ResourceSpec | <empty line>
+Comment	=	"!" {<any character except null or newline>}
+IncludeFile	=	"#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
+FileName	=	<valid filename for operating system>
+ResourceSpec	=	WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
+ResourceName	=	[Binding] {Component Binding} ComponentName
+Binding	=	"\&." | "*"
+WhiteSpace	=	{<space> | <horizontal tab>}
+Component	=	"?" | ComponentName
+ComponentName	=	NameChar {NameChar}
+NameChar	=	"a"\-"z" | "A"\-"Z" | "0"\-"9" | "_" | "-"
+Value	=	{<any character except null or unescaped newline>}
+.fi
+.PP
+Elements separated by vertical bar (|) are alternatives.
+Curly braces ({\&.\&.\&.}) indicate zero or more repetitions
+of the enclosed elements.
+Square brackets ([\&.\&.\&.]) indicate that the enclosed element is optional.
+Quotes ("\&.\&.\&.") are used around literal characters.
+.PP
+IncludeFile lines are interpreted by replacing the line with the
+contents of the specified file.  The word "include" must be in lowercase.
+The filename is interpreted relative to the directory of the file in
+which the line occurs (for example, if the filename contains no
+directory or contains a relative directory specification).
+.PP
+If a ResourceName contains a contiguous sequence of two or more Binding
+characters, the sequence will be replaced with single "\&." character
+if the sequence contains only "\&." characters,
+otherwise the sequence will be replaced with a single "*" character.
+.PP
+A resource database never contains more than one entry for a given
+ResourceName.  If a resource file contains multiple lines with the
+same ResourceName, the last line in the file is used.
+.PP
+Any whitespace character before or after the name or colon in a ResourceSpec
+are ignored.
+To allow a Value to begin with whitespace,
+the two-character sequence ``\\\^\fIspace\fP'' (backslash followed by space)
+is recognized and replaced by a space character,
+and the two-character sequence ``\\\^\fItab\fP''
+(backslash followed by horizontal tab)
+is recognized and replaced by a horizontal tab character.
+To allow a Value to contain embedded newline characters,
+the two-character sequence ``\\\^n'' is recognized and replaced by a
+newline character.
+To allow a Value to be broken across multiple lines in a text file,
+the two-character sequence ``\\\^\fInewline\fP''
+(backslash followed by newline) is
+recognized and removed from the value.
+To allow a Value to contain arbitrary character codes,
+the four-character sequence ``\\\^\fInnn\fP'',
+where each \fIn\fP is a digit character in the range of ``0''\-``7'',
+is recognized and replaced with a single byte that contains
+the octal value specified by the sequence.
+Finally, the two-character sequence ``\\\\'' is recognized
+and replaced with a single backslash.
+.PP
+When an application looks for the value of a resource, it specifies
+a complete path in the hierarchy, with both class and instance names.
+However, resource values are usually given with only partially specified
+names and classes, using pattern matching constructs.
+An asterisk (*) is a loose binding and is used to represent any number
+of intervening components, including none.
+A period (.) is a tight binding and is used to separate immediately
+adjacent components.
+A question mark (?) is used to match any single component name or class.
+A database entry cannot end in a loose binding;
+the final component (which cannot be "?") must be specified.
+The lookup algorithm searches the resource database for the entry that most
+closely matches (is most specific for) the full name and class being queried.
+When more than one database entry matches the full name and class,
+precedence rules are used to select just one.
+.LP
+The full name and class are scanned from left to right (from highest
+level in the hierarchy to lowest), one component at a time.
+At each level, the corresponding component and/or binding of each
+matching entry is determined, and these matching components and
+bindings are compared according to precedence rules.
+Each of the rules is applied at each level,
+before moving to the next level,
+until a rule selects a single entry over all others.
+The rules (in order of precedence) are:
+.IP 1. 5
+An entry that contains a matching component (whether name, class, or "?")
+takes precedence over entries that elide the level (that is, entries
+that match the level in a loose binding).
+.IP 2. 5
+An entry with a matching name takes precedence over both
+entries with a matching class and entries that match using "?".
+An entry with a matching class takes precedence over
+entries that match using "?".
+.IP 3. 5
+An entry preceded by a tight binding takes precedence over entries
+preceded by a loose binding.
+.PP
+Programs based on the X Tookit Intrinsics
+obtain resources from the following sources
+(other programs usually support some subset of these sources):
+.TP 8
+.B "RESOURCE_MANAGER root window property"
+Any global resources that should be available to clients on all machines 
+should be stored in the RESOURCE_MANAGER property on the
+root window of the first screen using the \fIxrdb\fP program.
+This is frequently taken care
+of when the user starts up X through the display manager or \fIxinit\fP.
+.TP 8
+.B "SCREEN_RESOURCES root window property"
+Any resources specific to a given screen (e.g. colors)
+that should be available to clients on all machines 
+should be stored in the SCREEN_RESOURCES property on the
+root window of that screen.
+The \fIxrdb\fP program will sort resources automatically and place them
+in RESOURCE_MANAGER or SCREEN_RESOURCES, as appropriate.
+.TP 8
+.B "application-specific files"
+Directories named by the environment variable XUSERFILESEARCHPATH
+or the environment variable XAPPLRESDIR (which names a single
+directory and should end with a '/' on POSIX systems), plus directories in a
+standard place (usually under __projectroot__/lib/X11/,
+but this can be overridden with the XFILESEARCHPATH environment variable)
+are searched for for application-specific resources.
+For example, application default resources are usually kept in
+__projectroot__/lib/X11/app-defaults/.
+See the \fIX Toolkit Intrinsics - C Language Interface\fP manual for
+details.
+.TP 8
+.B XENVIRONMENT
+Any user- and machine-specific resources may be specified by setting
+the XENVIRONMENT environment variable to the name of a resource file
+to be loaded by all applications.  If this variable is not defined,
+a file named \fI$HOME\fP/.Xdefaults-\fIhostname\fP is looked for instead,
+where \fIhostname\fP is the name of the host where the application
+is executing.
+.TP 8
+.B \-xrm \fIresourcestring\fP
+Resources can also be specified from the 
+command line.  The \fIresourcestring\fP is a single resource name and value as
+shown above.  Note that if the string contains characters interpreted by
+the shell (e.g., asterisk), they must be quoted.
+Any number of \fB\-xrm\fP arguments may be given on the
+command line.
+.PP
+Program resources are organized into groups called \fIclasses\fP, so that 
+collections of individual resources (each of which are 
+called \fIinstances\fP)
+can be set all at once.  By convention, the instance name of a resource
+begins with a lowercase letter and class name with an upper case letter.
+Multiple word resources are concatenated with the first letter of the 
+succeeding words capitalized.  Applications written with the X Toolkit
+Intrinsics will have at least the following resources:
+.PP
+.TP 8
+.B background (\fPclass\fB Background)
+This resource specifies the color to use for the window background.
+.PP
+.TP 8
+.B borderWidth (\fPclass\fB BorderWidth)
+This resource specifies the width in pixels of the window border.
+.PP
+.TP 8
+.B borderColor (\fPclass\fB BorderColor)
+This resource specifies the color to use for the window border.
+.PP
+Most applications using the X Toolkit Intrinsics also have the resource
+\fBforeground\fP
+(class \fBForeground\fP), specifying the color to use for text
+and graphics within the window.
+.PP
+By combining class and instance specifications, application preferences 
+can be set quickly and easily.  Users of color displays will frequently
+want to set Background and Foreground classes to particular defaults.
+Specific color instances such as text cursors can then be overridden
+without having to define all of the related resources.  For example,
+.sp
+.nf
+    bitmap*Dashed:  off
+    XTerm*cursorColor:  gold
+    XTerm*multiScroll:  on
+    XTerm*jumpScroll:  on
+    XTerm*reverseWrap:  on
+    XTerm*curses:  on
+    XTerm*Font:  6x10
+    XTerm*scrollBar: on
+    XTerm*scrollbar*thickness: 5
+    XTerm*multiClickTime: 500
+    XTerm*charClass:  33:48,37:48,45-47:48,64:48
+    XTerm*cutNewline: off
+    XTerm*cutToBeginningOfLine: off
+    XTerm*titeInhibit:  on
+    XTerm*ttyModes:  intr ^c erase ^? kill ^u
+    XLoad*Background: gold
+    XLoad*Foreground: red
+    XLoad*highlight: black
+    XLoad*borderWidth: 0
+    emacs*Geometry:  80x65-0-0
+    emacs*Background:  rgb:5b/76/86
+    emacs*Foreground:  white
+    emacs*Cursor:  white
+    emacs*BorderColor:  white
+    emacs*Font:  6x10
+    xmag*geometry: -0-0
+    xmag*borderColor:  white
+.fi
+.PP
+If these resources were stored in a file called \fI.Xresources\fP in your home
+directory, they could be added to any existing resources in the server with
+the following command:
+.sp
+.nf
+    % xrdb -merge $HOME/.Xresources
+.fi
+.sp
+This is frequently how user-friendly startup scripts merge user-specific 
+defaults
+into any site-wide defaults.  All sites are encouraged to set up convenient
+ways of automatically loading resources. See the \fIXlib\fP 
+manual section \fIResource Manager Functions\fP for more information.
+.SH ENVIRONMENT
+.TP
+.SM
+.B DISPLAY
+This is the only mandatory environment variable. It must point to an
+X server. See section "Display Names" above.
+.TP
+.SM
+.B XAUTHORITY
+This must point to a file that contains authorization data. The default
+is \fI$HOME/.Xauthority\fP. See
+.BR Xsecurity (__miscmansuffix__),
+.BR xauth (1),
+.BR xdm (1),
+.BR Xau (3).
+.TP
+.SM
+.B ICEAUTHORITY
+This must point to a file that contains authorization data. The default
+is \fI$HOME/.ICEauthority\fP.
+.TP
+.SM
+.BR LC_ALL ", " LC_CTYPE ", " LANG
+The first non-empty value among these three determines the current
+locale's facet for character handling, and in particular the default
+text encoding. See
+.BR locale (__miscmansuffix__),
+.BR setlocale (3),
+.BR locale (1).
+.TP
+.SM
+.B XMODIFIERS
+This variable can be set to contain additional information important
+for the current locale setting. Typically set to \fI@im=<input-method>\fP
+to enable a particular input method. See
+.BR XSetLocaleModifiers (3).
+.TP
+.SM
+.B XLOCALEDIR
+This must point to a directory containing the locale.alias file and
+Compose and XLC_LOCALE file hierarchies for all locales. The default value
+is \fI__projectroot__/lib/X11/locale\fP.
+.TP
+.SM
+.B XENVIRONMENT
+This must point to a file containing X resources. The default is
+\fI$HOME/.Xdefaults-<hostname>\fP. Unlike \fI__projectroot__/lib/X11/Xresources\fP,
+it is consulted each time an X application starts.
+.TP
+.SM
+.B XFILESEARCHPATH
+This must contain a colon separated list of path templates, where libXt
+will search for resource files. The default value consists of
+.sp
+.nf
+    __projectroot__/lib/X11/%L/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%l/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%T/%N%C%S:\\
+    __projectroot__/lib/X11/%L/%T/%N%S:\\
+    __projectroot__/lib/X11/%l/%T/%N%S:\\
+    __projectroot__/lib/X11/%T/%N%S
+.fi
+.sp
+A path template is transformed to a pathname by substituting:
+.sp
+.nf
+    %N => name (basename) being searched for
+    %T => type (dirname) being searched for
+    %S => suffix being searched for
+    %C => value of the resource "customization"
+          (class "Customization")
+    %L => the locale name
+    %l => the locale's language (part before '_')
+    %t => the locale's territory (part after '_` but before '.')
+    %c => the locale's encoding (part after '.')
+.fi
+.TP
+.SM
+.B XUSERFILESEARCHPATH
+This must contain a colon separated list of path templates,
+where libXt will search for user dependent resource files. The default
+value is:
+.sp
+.nf
+    $XAPPLRESDIR/%L/%N%C:\\
+    $XAPPLRESDIR/%l/%N%C:\\
+    $XAPPLRESDIR/%N%C:\\
+    $HOME/%N%C:\\
+    $XAPPLRESDIR/%L/%N:\\
+    $XAPPLRESDIR/%l/%N:\\
+    $XAPPLRESDIR/%N:\\
+    $HOME/%N
+.fi
+.sp
+$XAPPLRESDIR defaults to \fI$HOME\fP, see below.
+.sp
+A path template is transformed to a pathname by substituting:
+.sp
+.nf
+    %N => name (basename) being searched for
+    %T => type (dirname) being searched for
+    %S => suffix being searched for
+    %C => value of the resource "customization"
+          (class "Customization")
+    %L => the locale name
+    %l => the locale's language (part before '_')
+    %t => the locale's territory (part after '_` but before '.')
+    %c => the locale's encoding (part after '.')
+.fi
+.TP
+.SM
+.B XAPPLRESDIR
+This must point to a base directory where the user stores his application
+dependent resource files. The default value is \fI$HOME\fP. Only used if
+XUSERFILESEARCHPATH is not set.
+.TP
+.SM
+.B XKEYSYMDB
+This must point to a file containing nonstandard keysym definitions.
+The default value is \fI__projectroot__/lib/X11/XKeysymDB\fP.
+.TP
+.SM
+.B XCMSDB
+This must point to a color name database file. The default value is
+\fI__projectroot__/lib/X11/Xcms.txt\fP.
+.TP
+.SM
+.B XFT_CONFIG
+This must point to a configuration file for the Xft library. The default
+value is \fI__projectroot__/lib/X11/XftConfig\fP.
+.TP
+.SM
+.B RESOURCE_NAME
+This serves as main identifier for resources belonging to the program
+being executed. It defaults to the basename of pathname of the program.
+.TP
+.SM
+.B SESSION_MANAGER
+Denotes the session manager the application should connect. See
+.BR xsm (1),
+.BR rstart (1).
+.TP
+.SM
+.B XF86BIGFONT_DISABLE
+Setting this variable to a non-empty value disables the XFree86-Bigfont
+extension. This extension is a mechanism to reduce the memory consumption
+of big fonts by use of shared memory.
+.LP
+.B XKB_FORCE
+.br
+.B XKB_DISABLE
+.br
+.B XKB_DEBUG
+.br
+.B _XKB_CHARSET
+.br
+.B _XKB_LOCALE_CHARSETS
+.br
+.B _XKB_OPTIONS_ENABLE
+.br
+.B _XKB_LATIN1_LOOKUP
+.br
+.B _XKB_CONSUME_LOOKUP_MODS
+.br
+.B _XKB_CONSUME_SHIFT_AND_LOCK
+.br
+.B _XKB_IGNORE_NEW_KEYBOARDS
+.br
+.B _XKB_CONTROL_FALLBACK
+.br
+.B _XKB_COMP_LED
+.B _XKB_COMP_FAIL_BEEP
+.TP
+.SM
+.I ""
+These variables influence the X Keyboard Extension.
+.SH EXAMPLES
+The following is a collection of sample command lines for some of the 
+more frequently used commands.  For more information on a particular command,
+please refer to that command's manual page.
+.sp
+.nf
+    %  xrdb $HOME/.Xresources
+    %  xmodmap -e "keysym BackSpace = Delete"
+    %  mkfontdir /usr/local/lib/X11/otherfonts
+    %  xset fp+ /usr/local/lib/X11/otherfonts
+    %  xmodmap $HOME/.keymap.km
+    %  xsetroot -solid 'rgbi:.8/.8/.8' 
+    %  xset b 100 400 c 50 s 1800 r on
+    %  xset q
+    %  twm
+    %  xmag
+    %  xclock -geometry 48x48-0+0 -bg blue -fg white
+    %  xeyes -geometry 48x48-48+0
+    %  xbiff -update 20 
+    %  xlsfonts '*helvetica*'
+    %  xwininfo -root
+    %  xdpyinfo -display joesworkstation:0
+    %  xhost -joesworkstation
+    %  xrefresh
+    %  xwd | xwud
+    %  bitmap companylogo.bm 32x32
+    %  xcalc -bg blue -fg magenta
+    %  xterm -geometry 80x66-0-0 -name myxterm $*
+    %  xon filesysmachine xload
+.fi
+.SH DIAGNOSTICS
+A wide variety of error messages are generated from various programs.
+The default error handler in \fIXlib\fP (also used by many toolkits) uses
+standard resources to construct diagnostic messages when errors occur.  The
+defaults for these messages are usually stored in
+\fI__projectroot__/lib/X11/XErrorDB\fP.  If this file is not present,
+error messages will be rather terse and cryptic.
+.PP
+When the X Toolkit Intrinsics encounter errors converting resource strings to
+the
+appropriate internal format, no error messages are usually printed.  This is
+convenient when it is desirable to have one set of resources across a variety
+of displays (e.g. color vs. monochrome, lots of fonts vs. very few, etc.),
+although it can pose problems for trying to determine why an application might
+be failing.  This behavior can be overridden by the setting the
+\fIStringConversionsWarning\fP resource.
+.PP
+To force the X Toolkit Intrinsics to always print string conversion error
+messages,
+the following resource should be placed in the file that gets
+loaded onto the RESOURCE_MANAGER property
+using the \fIxrdb\fP program (frequently called \fI.Xresources\fP
+or \fI.Xres\fP in the user's home directory):
+.sp
+.nf
+    *StringConversionWarnings: on
+.fi
+.sp
+To have conversion messages printed for just a particular application,
+the appropriate instance name can be placed before the asterisk:
+.sp
+.nf
+    xterm*StringConversionWarnings: on
+.fi
+.SH "SEE ALSO"
+.PP
+.\" introductions
+.BR XProjectTeam (__miscmansuffix__),
+.BR XStandards (__miscmansuffix__),
+.BR Xsecurity (__miscmansuffix__),
+.\" clients, utilities, and demos
+.BR appres (1),
+.BR bdftopcf (1),
+.BR bitmap (1),
+.BR editres (1),
+.BR fsinfo (1),
+.BR fslsfonts (1),
+.BR fstobdf (1),
+.BR iceauth (1),
+.BR imake (1),
+.BR lbxproxy (1),
+.BR makedepend (1),
+.BR mkfontdir (1),
+.BR oclock (1),
+.BR proxymngr (1),
+.BR rgb (1), 
+.BR resize (1),
+.BR rstart (1),
+.BR smproxy (1),
+.BR twm (1),
+.BR x11perf (1),
+.BR x11perfcomp (1), 
+.BR xauth (1),
+.BR xclipboard (1),
+.BR xclock (1),
+.BR xcmsdb (1),
+.BR xconsole (1),
+.BR xdm (1),
+.BR xdpyinfo (1),
+.BR xfd (1),
+.BR xfindproxy (1),
+.BR xfs (1),
+.BR xfwp (1),
+.BR xhost (1),
+.BR xieperf (1),
+.BR xinit (1),
+.BR xkbbell (1),
+.BR xkbcomp (1),
+.BR xkbevd (1),
+.BR xkbprint (1),
+.BR xkbvleds (1),
+.BR xkbwatch (1),
+.BR xkill (1),
+.BR xlogo (1),
+.BR xlsatoms (1),
+.BR xlsclients (1),
+.BR xlsfonts (1),
+.BR xmag (1),
+.BR xmh (1),
+.BR xmodmap (1),
+.BR xon (1),
+.BR xprop (1),
+.BR xrdb (1),
+.BR xrefresh (1),
+.BR xrx (1),
+.BR xset (1),
+.BR xsetroot (1),
+.BR xsm (1),
+.BR xstdcmap (1),
+.BR xterm (1),
+.BR xwd (1),
+.BR xwininfo (1),
+.BR xwud (1).
+.\" servers
+.BR Xserver (1),
+.BR Xdec (1),
+.BR XmacII (1),
+.BR Xsun (1),
+.BR Xnest (1),
+.BR Xvfb (1),
+.BR XFree86 (1),
+.BR XDarwin (1),
+.BR kbd_mode (1),
+.\" specifications
+.I "Xlib \- C Language X Interface\fR,\fP"
+and
+.I "X Toolkit Intrinsics \- C Language Interface"
+.SH TRADEMARKS
+.PP
+X Window System is a trademark of X Consortium, Inc.
+.SH AUTHORS
+.PP
+A cast of thousands, literally.  The Release 6.3 distribution is 
+brought to you by X Consortium, Inc.  The names of all people who 
+made it a reality will be found in the individual documents and 
+source files.  The staff members at the X Consortium responsible
+for this release are: Donna Converse (emeritus), Stephen Gildea 
+(emeritus), Kaleb Keithley, Matt Landau (emeritus), Ralph Mor 
+(emeritus), Janet O'Halloran, Bob Scheifler, Ralph Swick, Dave 
+Wiggins (emeritus), and Reed Augliere.
+.PP
+The X Window System standard was originally developed at the
+Laboratory for Computer Science at the Massachusetts Institute 
+of Technology, and all rights thereto were assigned to the X Consortium 
+on January 1, 1994.
+X Consortium, Inc. closed its doors on December 31, 1996.  All rights to the
+X Window System have been assigned to the Open Software Foundation.
diff --git a/man/general/XProjectTeam.man b/man/general/XProjectTeam.man
new file mode 100644
index 0000000..0914c53
--- /dev/null
+++ b/man/general/XProjectTeam.man
@@ -0,0 +1,92 @@
+.\" $Xorg: XProjectTeam.cpp,v 1.6 2001/01/29 17:44:41 coskrey Exp $
+.\" Copyright (c) 1993, 1994, 1996  X Consortium
+.\" Copyright (c) 1996, 2000 The Open Group
+.\" 
+.\" 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 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 
+.\" dealing in this Software without prior written authorization from the 
+.\" X Consortium.
+.\"
+.\" $XFree86: xc/doc/man/general/XProjectTeam.man,v 1.3 2001/12/19 21:37:27 dawes Exp $
+.\"
+.TH X.Org __miscmansuffix__ __xorgversion__
+.SH NAME
+X.Org, XProjectTeam \- X.Org Group information
+.SH SYNOPSIS
+Release 6.5 and 6.6 of X Version 11 was brought to you by The X.Org Group.
+Release 6.4 of X Version 11 was brought to you by The X Project Team.
+.SH DESCRIPTION
+The Open Group's X Project Team was created as the successor 
+to the X Consortium, Inc., after the X Consortium was merged into
+The Open Group. 
+The X.Org Group (hereinafter called "X.Org") was created as the successor 
+to The X Project Team after the The Open Group ceased operating
+The X Project Team.
+The purpose of X.Org is to foster development, evolution, and 
+maintenance of the X Window System.  X.Org operates under the corporate
+umbrella of The Open Group.
+.PP
+The X Consortium was an independent, not-for-profit Delaware membership
+corporation.  It was formed in 1993 as the successor to the MIT X 
+Consortium.
+.PP
+The X Window System was created in the mid-1980s at the Massachusetts
+Institute of Technology.  In 1988, MIT formed a member-funded consortium 
+to provide the technical and administrative leadership necessary to 
+support further development of the X Window System.  In 1992, MIT and 
+the membership decided it was in their best interests to move the 
+consortium out of MIT and create an independent, stand-alone organization.  
+All rights to the X Window System were assigned by MIT to X Consortium, 
+Inc. on January 1, 1994.  X Consortium, Inc. closed its doors on December 
+31, 1996.  All rights to the X Window System have been assigned to The 
+Open Group, for the benefit of the members of X.Org.
+.PP
+.SH "ADDRESS"
+To reach The Open Group public World Wide Web server, use
+http://www.opengroup.org/.
+.PP
+To reach The X.Org public World Wide Web server, use
+http://www.x.org/.
+.PP
+To reach The X.Org public ftp machine, use anonymous ftp at
+ftp://ftp.x.org/
+
+.SH "FULL MEMBERS"
+
+.nf
+Attachmate
+Barco
+Compaq
+Hewlett-Packard
+Hummingbird
+IBM
+ICS
+Metro Link
+MITRE
+Shiman Associates
+Silicon Graphics Incorporated
+Starnet Communications
+Sun Microsystems
+The XFree86 Project
+US Navy
+WRQ
+Xi Graphics
+.fi
diff --git a/man/general/security.man b/man/general/security.man
new file mode 100644
index 0000000..0859b02
--- /dev/null
+++ b/man/general/security.man
@@ -0,0 +1,236 @@
+.\" $Xorg: security.cpp,v 1.3 2000/08/17 19:42:05 cpqbld Exp $
+.\" Copyright (c) 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.
+.\"
+.\"
+.\" $XFree86: xc/doc/man/general/security.man,v 1.4 2001/01/27 18:20:38 dawes Exp $
+.\"
+.nr )S 12
+.TH XSECURITY __miscmansuffix__ __xorgversion__
+.SH NAME
+Xsecurity \- X display access control
+.SH SYNOPSIS
+.PP
+X provides mechanism for implementing many access control systems.
+The sample implementation includes five mechanisms:
+.nf
+.br
+.ta 3.4i
+    Host Access	Simple host-based access control.
+    MIT-MAGIC-COOKIE-1	Shared plain-text "cookies".
+    XDM-AUTHORIZATION-1	Secure DES based private-keys.
+    SUN-DES-1	Based on Sun's secure rpc system.
+    MIT-KERBEROS-5	Kerberos Version 5 user-to-user.
+.fi
+.SH "ACCESS SYSTEM DESCRIPTIONS"
+.IP "Host Access"
+Any client on a host in the host access control list is allowed access to
+the X server.  This system can work reasonably well in an environment
+where everyone trusts everyone, or when only a single person can log in
+to a given machine, and is easy to use when the list of hosts used is small.
+This system does not work well when multiple people can log in to a single
+machine and mutual trust does not exist.
+The list of allowed hosts is stored in the X server and can be changed with
+the \fIxhost\fP command.
+When using the more secure mechanisms listed below, the host list is
+normally configured to be the empty list, so that only authorized
+programs can connect to the display.
+.IP "MIT-MAGIC-COOKIE-1"
+When using MIT-MAGIC-COOKIE-1,
+the client sends a 128 bit "cookie"
+along with the connection setup information.
+If the cookie presented by the client matches one
+that the X server has, the connection is allowed access.
+The cookie is chosen so that it is hard to guess;
+\fIxdm\fP generates such cookies automatically when this form of
+access control is used.
+The user's copy of
+the cookie is usually stored in the \fI.Xauthority\fP file in the home
+directory, although the environment variable \fBXAUTHORITY\fP can be used
+to specify an alternate location.
+\fIXdm\fP automatically passes a cookie to the server for each new
+login session, and stores the cookie in the user file at login.
+.IP
+The cookie is transmitted on the network without encryption, so
+there is nothing to prevent a network snooper from obtaining the data
+and using it to gain access to the X server.  This system is useful in an
+environment where many users are running applications on the same machine
+and want to avoid interference from each other, with the caveat that this
+control is only as good as the access control to the physical network.
+In environments where network-level snooping is difficult, this system
+can work reasonably well.
+.IP "XDM-AUTHORIZATION-1"
+Sites in the United States can use a DES-based access control
+mechanism called XDM-AUTHORIZATION-1.
+It is similar in usage to MIT-MAGIC-COOKIE-1 in that a key is
+stored in the \fI.Xauthority\fP file and is shared with the X server.
+However,
+this key consists of two parts - a 56 bit DES encryption key and 64 bits of
+random data used as the authenticator.
+.IP
+When connecting to the X server, the application generates 192 bits of data
+by combining the current time in seconds (since 00:00 1/1/1970 GMT) along
+with 48 bits of "identifier".  For TCP/IP connections, the identifier is
+the address plus port number; for local connections it is the process ID
+and 32 bits to form a unique id (in case multiple connections to the same
+server are made from a single process).  This 192 bit packet is then
+encrypted using the DES key and sent to the X server, which is able to
+verify if the requestor is authorized to connect by decrypting with the
+same DES key and validating the authenticator and additional data.
+This system is useful in many environments where host-based access control
+is inappropriate and where network security cannot be ensured.
+.IP "SUN-DES-1"
+Recent versions of SunOS (and some other systems) have included a
+secure public key remote procedure call system.  This system is based
+on the notion of a network principal; a user name and NIS domain pair.
+Using this system, the X server can securely discover the actual user
+name of the requesting process.  It involves encrypting data with the
+X server's public key, and so the identity of the user who started the
+X server is needed for this; this identity is stored in the \fI.Xauthority\fP
+file.  By extending the semantics of "host address" to include this notion of
+network principal, this form of access control is very easy to use.
+.IP
+To allow access by a new user, use \fIxhost\fP.  For example,
+.nf
+    xhost keith@ ruth@mit.edu
+.fi
+adds "keith" from the NIS domain of the local machine, and "ruth" in
+the "mit.edu" NIS domain.  For keith or ruth to successfully connect
+to the display, they must add the principal who started the server to
+their \fI.Xauthority\fP file.  For example:
+.nf
+    xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
+.fi
+This system only works on machines which support Secure RPC, and only for
+users which have set up the appropriate public/private key pairs on their
+system.  See the Secure RPC documentation for details.
+To access the display from a remote host, you may have to do a
+\fIkeylogin\fP on the remote host first.
+.IP MIT-KERBEROS-5
+Kerberos is a network-based authentication scheme developed by MIT for
+Project Athena.  It allows mutually suspicious principals to
+authenticate each other as long as each trusts a third party,
+Kerberos.  Each principal has a secret key known only to it and
+Kerberos.  Principals includes servers, such as an FTP server or X
+server, and human users, whose key is their password.  Users gain
+access to services by getting Kerberos tickets for those services from
+a Kerberos server.  Since the X server has no place to store a secret
+key, it shares keys with the user who logs in.  X authentication thus
+uses the user-to-user scheme of Kerberos version 5.
+.IP
+When you log in via \fIxdm\fP, \fIxdm\fP will use your password to
+obtain the initial Kerberos tickets.  \fIxdm\fP stores the tickets in
+a credentials cache file and sets the environment variable
+\fIKRB5CCNAME\fP to point to the file.  The credentials cache is
+destroyed when the session ends to reduce the chance of the tickets
+being stolen before they expire.
+.IP
+Since Kerberos is a user-based authorization protocol, like the
+SUN-DES-1 protocol, the owner of a display can enable
+and disable specific users, or Kerberos principals.
+The \fIxhost\fP client is used to enable or disable authorization.
+For example,
+.nf
+    xhost krb5:judy krb5:gildea@x.org
+.fi
+adds "judy" from the Kerberos realm of the local machine, and "gildea"
+from the "x.org" realm.
+.SH "THE AUTHORIZATION FILE"
+.PP
+Except for Host Access control, each of these systems uses data stored in
+the \fI.Xauthority\fP file to generate the correct authorization information
+to pass along to the X server at connection setup.  MIT-MAGIC-COOKIE-1 and
+XDM-AUTHORIZATION-1 store secret data in the file; so anyone who can read
+the file can gain access to the X server.  SUN-DES-1 stores only the
+identity of the principal who started the server
+(unix.\fIhostname\fP@\fIdomain\fP when the server is started by \fIxdm\fP),
+and so it is not useful to anyone not authorized to connect to the server.
+.PP
+Each entry in the \fI.Xauthority\fP file matches a certain connection family
+(TCP/IP, DECnet or local connections) and X display name (hostname plus display
+number).  This allows multiple authorization entries for different displays
+to share the same data file.  A special connection family (FamilyWild, value
+65535) causes an entry to match every display, allowing the entry to be used
+for all connections.  Each entry additionally contains the authorization
+name and whatever private authorization data is needed by that authorization
+type to generate the correct information at connection setup time.
+.PP
+The \fIxauth\fP program manipulates the \fI.Xauthority\fP file format.
+It understands the semantics of the connection families and address formats,
+displaying them in an easy to understand format.  It also understands that
+SUN-DES-1 and MIT-KERBEROS-5 use
+string values for the authorization data, and displays
+them appropriately.
+.PP
+The X server (when running on a workstation) reads authorization
+information from a file name passed on the command line with the \fI\-auth\fP
+option (see the \fIXserver\fP manual page).  The authorization entries in
+the file are used to control access to the server.  In each of the
+authorization schemes listed above, the data needed by the server to initialize
+an authorization scheme is identical to the data needed by the client to
+generate the appropriate authorization information, so the same file can be
+used by both processes.  This is especially useful when \fIxinit\fP is used.
+.IP "MIT-MAGIC-COOKIE-1"
+This system uses 128 bits of data shared between the user and the X server.
+Any collection of bits can be used.  \fIXdm\fP generates these keys using a
+cryptographically secure pseudo random number generator, and so the key to
+the next session cannot be computed from the current session key.
+.IP "XDM-AUTHORIZATION-1"
+This system uses two pieces of information.  First, 64 bits of random data,
+second a 56 bit DES encryption key (again, random data) stored
+in 8 bytes, the last byte of which is ignored.  \fIXdm\fP generates these keys
+using the same random number generator as is used for MIT-MAGIC-COOKIE-1.
+.IP "SUN-DES-1"
+This system needs a string representation of the principal which identifies
+the associated X server.
+This information is used to encrypt the client's authority information
+when it is sent to the X server.
+When \fIxdm\fP starts the X server, it uses the root
+principal for the machine on which it is running
+(unix.\fIhostname\fP@\fIdomain\fP, e.g.,
+"unix.expire.lcs.mit.edu@our.domain.edu").  Putting the correct principal
+name in the \fI.Xauthority\fP file causes Xlib to generate the appropriate
+authorization information using the secure RPC library.
+.IP "MIT-KERBEROS-5"
+Kerberos reads tickets from the cache pointed to by the
+\fIKRB5CCNAME\fP environment variable, so does not use any data from
+the \fI.Xauthority\fP file.  An entry with no data must still exist to tell
+clients that MIT-KERBEROS-5 is available.
+.IP
+Unlike the \fI.Xauthority\fP file for clients, the authority file
+passed by xdm to 
+a local X server (with ``\fB\-auth\fP \fIfilename\fP'', see xdm(1))
+does contain the name of the credentials cache, since 
+the X server will not have the 
+\fIKRB5CCNAME\fP environment variable set.
+The data of the MIT-KERBEROS-5 entry is the credentials cache name and
+has the form ``UU:FILE:\fIfilename\fP'', where \fIfilename\fP is the
+name of the credentials cache file created by xdm.  Note again that
+this form is \fInot\fP used by clients.
+.SH FILES
+\&.Xauthority
+.SH "SEE ALSO"
+X(__miscmansuffix__), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)
diff --git a/sgml/Darwin.sgml b/sgml/Darwin.sgml
new file mode 100644
index 0000000..d92e60e
--- /dev/null
+++ b/sgml/Darwin.sgml
@@ -0,0 +1,246 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+<title>XFree86 on Darwin and Mac OS X
+<author>Torrey T. Lyons, <email>torrey@mrcla.com</email>
+<date>12 December 2001
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Darwin.sgml,v 1.9 2001/12/13 07:09:05 torrey Exp $
+</ident>
+
+<toc>
+
+<sect>Introduction
+<p>
+<htmlurl url="http://www.xfree86.org/" name="XFree86">, a freely
+redistributable open-source implementation of the <htmlurl
+url="http://www.x.org/" name="X Window System">, has been ported to <htmlurl
+url="http://www.opensource.apple.com/projects/darwin/" name="Darwin">
+and <htmlurl url="http://www.apple.com/macosx/" name="Mac OS X">. This
+document is a collection of information for anyone
+running XFree86 on Apple's next generation operating system.
+
+<p>
+Most of the current work on XFree86 for Darwin and Mac OS&nbsp;X is centered
+around the <htmlurl url="http://sourceforge.net/projects/xonx/"
+name="XonX project"> at <htmlurl url="http://sourceforge.net"
+name="SourceForge">. If you are interested in up-to-date status, want to
+report a bug, or are interested in working on XFree86 for Darwin, stop by the
+<htmlurl url="http://sourceforge.net/projects/xonx/" name="XonX project">.
+
+<sect>Hardware Support and Configuration
+<p>
+The X window server for Darwin and Mac OS&nbsp;X provided by the <htmlurl
+url="http://www.XFree86.Org/" name="XFree86 Project, Inc."> is called
+XDarwin. XDarwin can run in three different modes. On Mac OS&nbsp;X,
+XDarwin runs in parallel with Aqua in full screen or rootless modes.
+These modes are called Quartz modes, named after the Quartz 2D compositing
+engine used by Aqua. XDarwin can also be run from the Darwin console in
+IOKit mode.
+
+<p>
+In full screen Quartz mode, when the X Window System is active, it takes
+over the entire screen. You can switch back to the Mac OS&nbsp;X desktop
+by holding down Command-Option-A. This key combination can be changed in
+the user preferences. From the Mac OS&nbsp;X desktop, click on the XDarwin
+icon in the Dock to switch back to the X window system. (You can change
+this behavior in the user preferences so that you must click the XDarwin
+icon in the floating switch window instead.)
+
+<p>In rootless mode, the X window system and Aqua share your display.
+The root window of the X11 display is the size of the screen and contains
+all the other windows. The X11 root window is not displayed in rootless
+mode as Aqua handles the desktop background.
+
+<p>
+From the console, the Darwin port of XFree86 uses the IOKit for device
+driver loading and discovery, rather than the XFree86 module loader.
+Because of this, the XFree86 configuration file is not used on Darwin
+or Mac OS&nbsp;X systems. The descriptions found elsewhere of devices
+supported by XFree86 for other operating systems also do not apply.
+
+<p>
+XFree86 for Darwin or Mac OS&nbsp;X will work with any video card that
+you have an IOKit driver for. If you are running Mac OS&nbsp;X, this
+typically means any card that has been shipped by Apple. If a card works
+for you with the Mac OS&nbsp;X GUI, it will work on the same machine with
+XFree86. If you have a pure Darwin installation, you may need to download
+additional third-party drivers from
+<htmlurl url="http://www.opensource.apple.com/projects/darwin/"
+name="Apple's Darwin site">. IOKit drivers are typically installed in
+<tt>/System/Library/Extensions/</tt> or <tt>/Library/Extensions/</tt>.
+
+<p>
+Multi-button and scroll wheel mouse support works well with all
+USB mice that I have tested. I have done no testing with ADB
+mice, but without a special driver, only a single mouse button
+will work on an ADB mouse.
+
+<sect>Getting Started
+<p>
+Following are instructions for building and running your own copy of
+XFree86. The procedure for getting your X server up and running on
+Darwin and Mac OS&nbsp;X are very similar. Where there are differences
+I have noted them below. Note that to build XFree86 for yourself on
+Mac OS&nbsp;X, you need to install the Developers' Tools.
+
+<p>
+If you don't feel the need to live on the cutting edge, you can save
+some time and effort by using the precompiled binaries available on
+the XFree86 FTP server at <url
+url="ftp://ftp.xfree86.org/pub/XFree86/&relvers;/binaries/">.
+Follow the instructions in the <htmlurl
+url="http://www.xfree86.org/&relvers;/Install.html" name="Install">
+document to install it. This will create two new directory trees,
+<tt>/usr/X11R6</tt> and <tt>/etc/X11</tt> For Mac OS&nbsp;X Quartz
+support, download the optional Xquartz.tgz tarball. With Quartz support,
+the XDarwin application will be installed in <tt>/Applications</tt>.
+
+<p>
+If you get the precompiled binaries you can skip ahead to the section
+on <ref id="running" name="running the X Window System"> On the other hand,
+if you want to build things yourself from scratch, follow the directions
+below.
+
+<sect1> Get the Code 
+
+<p>
+The first thing you need to do is to get the source code from the
+XFree86 project.
+
+<itemize>
+<item> Setup CVS: Both Darwin and Mac OS&nbsp;X include CVS (Concurrent
+Versions System), which is an easy way to download and keep up to date
+with open source code released by XFree86 and others. You do have to
+setup CVS properly, however, to tell it where to look. Follow the
+<htmlurl url="http://www.xfree86.org/cvs/" name="XFree86 instructions"> on
+how to do this either via ssh or via the cvs pserver.
+
+<item> Now make a directory in some convenient place which will serve
+as your top level directory for you open source development efforts. I
+am going to call this directory <tt>sandbox/</tt> in the following discussions
+and you could put this directory, for example, in <tt>~/sandbox/</tt>.
+
+<item>From the command line type:
+<tscreen><verb>
+cd sandbox
+cvs checkout xc
+</verb></tscreen>
+Wait for all the files to complete downloading. 
+
+</itemize>
+
+<sect1> Build XFree86
+<p>
+Once you have everything ready it is easy to build and install
+XFree86. From the command line: 
+
+<tscreen><verb>
+cd sandbox/xc
+make World >& world.log
+
+(wait for several hours)
+
+sudo make install >& install.log
+sudo make install.man >& man.log
+</verb></tscreen>
+
+<sect>Run the X Window System<label id="running">
+<p>
+You need to add the X Window System executables to your path. Your path
+is the list of directories to be searched for executable commands. 
+The X11 commands are located in <tt>/usr/X11R6/bin</tt>, which needs to be
+added to your path. XDarwin does this for you by default and can also add
+additional directories where you have installed command line applications.
+
+<p>
+More experienced users will have already set their path correctly using the
+initialization files for their shell. In this case, you can inform XDarwin
+not to modify your path in the preferences. XDarwin launches the initial
+X11 clients in the user's default login shell. (An alternate shell can also
+be specified in the preferences.) The way to set the path depends on the
+shell you are using. This is described in the man page documentation for
+the shell.
+
+<p>
+In addition you may also want to add the man pages from XFree86 to the list
+of pages to be searched when you are looking for documentation. The X11 man
+pages are located in <tt>/usr/X11R6/man</tt> and the <tt>MANPATH</tt>
+environment variable contains the list of directories to search.
+
+<p>
+On Mac OS&nbsp;X, you can run XFree86 from the Darwin
+text console or in parallel with Aqua. To get to the text
+console in Mac OS&nbsp;X you need to logout and type ``&gt;console'' as
+the user name. This will shutdown Core Graphics and
+bring up the console login prompt. Login again as your user. 
+
+<p>
+From the text console you can start the X Window System by typing
+``exec startx''. After a brief wait at least one terminal window should
+pop up for you. So far it probably isn't very impressive as you might not
+even have a window manager running to allow you to move windows around.
+
+<p>
+When you are ready to quit XFree86 type ``exit'' in the main
+terminal window or quit with the window manager if you have one
+running. Unfortunately the X server does not shutdown correctly and if
+you did not start with ``exec startx'', you 
+will get an apparently frozen screen with only a spinning beachball
+cursor on it. Nothing you type shows up on the screen, but in fact
+your keystrokes are being received by the console. Type
+``logout'' to return to normalcy after a brief delay. With
+Darwin, this should put you back at the text console login prompt. With
+Mac OS&nbsp;X, Core Graphics will restart and you should be given a login
+window.
+
+<p>
+To start XFree86 in Quartz mode you can launch the XDarwin application
+in the <tt>/Applications</tt> folder, or from the command line type
+``startx -- -quartz''. By default this will give you a mode picker to
+choose between full screen or rootless mode. You can change the default
+to always use a particular mode in the preferences, or you can specify
+the ``-fullscreen'' or ``-rootless'' options on the command line instead
+of ``-quartz''.
+
+<p>
+<bf/Customize the X Window System/
+<p>
+
+The X Window System is very customizable and you will certainly want to
+change some things. There is a lot you can do to control how your windows
+look, how the windows are moved, resized, etc. You will likely want to
+get a fancier window manager than twm, which is included with
+XFree86. The <tt>.xinitrc</tt> file in your home directory controls what
+programs are run when you start the X Window System. You can find a sample
+<tt>.xinitrc</tt> file in <tt>/etc/X11/xinit/xinitrc</tt>.  
+
+<p>
+There are many window managers that have been ported to Darwin. The
+following pages contain collections of window managers and other X
+window system clients:
+
+<itemize>
+<item> <htmlurl url="http://fink.sourceforge.net/" name="Fink">: A
+package manager that will easily download, compile, and install lots
+of open source software from the Internet.
+
+<item> <htmlurl url="http://gnu-darwin.sourceforge.net/" name="GNU-Darwin">:
+A source for tons of software ported to Darwin.
+
+<item> <htmlurl url="http://softrak.stepwise.com/Apps/WebObjects/Softrak"
+name="Stepwise's Softrak site">
+
+<item> <htmlurl url="http://www.darwinfo.org/ports/"
+name="Darwinfo's ports page">
+
+</itemize>
+
+<p>
+Good luck!
+
+</article>
+
diff --git a/sgml/Install.sgml b/sgml/Install.sgml
new file mode 100644
index 0000000..fd2cf4b
--- /dev/null
+++ b/sgml/Install.sgml
@@ -0,0 +1,520 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+
+<title>Installation Details for XFree86&trade; &relvers;
+<author>The XFree86 Project, Inc
+<date>24 February 2003
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml,v 1.17 2003/02/24 17:09:16 dawes Exp $
+</ident>
+
+<abstract>
+
+How to install XFree86.
+
+</abstract>
+
+<toc>
+
+<sect>Introduction
+<p>
+This document contains information about installing the XFree86 binaries
+as provided by The XFree86 Project.
+
+<p>
+The XFree86 binaries that we provide for UNIX-like OS's (Linux, the
+BSDs, Solaris, etc) are packaged in a platform-independent gzipped tar
+format (aka "tarballs" identified by the <tt>.tgz</tt> suffix).  Along
+with the binaries we provide a customized version of the GNU tar utility
+called "extract" and an installation script.  We recommend that these
+be used to install the binaries.  (The source for this customized version
+of GNU tar can be found in the XFree86 CVS repository's "utils" module,
+and from our <url name="ftp site"
+url="ftp://ftp.xfree86.org/pub/XFree86/misc/utils-&utilsvers;.tgz">.)
+
+<![ %snapshot [
+<p>
+Note: for snapshot releases like this one, binaries are only available for
+a small number of platforms.
+]]>
+
+
+<sect>Downloading the XFree86 &relvers; binaries
+<p>
+
+<![ %updaterel [
+XFree86 &relvers; is an update release.  The most recent full release
+(&fullrelvers;) needs to be installed before installing this update.
+Information about downloading and installing &fullrelvers; can be found
+in the installation document for that version, which can be found
+on the <url name="XFree86 web site"
+url="http://www.xfree86.org/&fullrelvers/Install.html">.
+]]>
+
+We provide XFree86 &relvers; <![ %updaterel [update ]]>binaries for a range
+of operating systems at our
+<![ %snapshot; [
+<url name="ftp site"
+url="ftp://ftp.xfree86.org/pub/XFree86/snapshots/&relvers/binaries/">
+]]>
+<![ %release; [
+<url name="ftp site"
+url="ftp://ftp.xfree86.org/pub/XFree86/&relvers/binaries/">
+]]>
+and our
+<![ %snapshot; [
+<url name="web site"
+url="http://ftp.xfree86.org/pub/XFree86/snapshots/&relvers/binaries/">.
+]]>
+<![ %release; [
+<url name="web site"
+url="http://ftp.xfree86.org/pub/XFree86/&relvers/binaries/">.
+]]>
+Often during releases our site is heavily loaded.  Instead of downloading
+directly from us we recommend that instead you use one of our mirror
+sites.
+
+<p>
+Our binaries are organized by sub-directories which correspond to each
+of the OS/platforms for which we provide binaries.  First go to the
+sub-directory  that represents your OS platform. In some cases (e.g.,
+Linux) there may be a number of choices depending on the architecture
+or libc version your platform uses.  In all case we recommend that you
+first download the <tt>Xinstall.sh</tt> script, and run it as in the
+following example to find out which binary distribution you should
+download.
+
+<tscreen><verb>
+sh Xinstall.sh -check
+</verb></tscreen>
+
+The output of this utility tells you which is the correct set of binaries
+for you to download.  If you are careful with this step you will save
+yourself a lot time and trouble from NOT downloading an incompatible
+distribution.
+
+<bf>NOTES</bf>:
+
+<itemize>
+  <item>The Xinstall.sh script must be downloaded in binary mode,
+	otherwise it won't run correctly.  If you get lots of "command
+	not found" messages when you try to run it, then it is most
+	likely because the script wasn't downloaded in binary mode.
+	Some web browsers won't do this for files of that name, so we
+	also have a copy of it called "<tt>Xinstall.bin</tt>", and most
+	browsers should download that correctly.  When downloading it
+	under this name, select "save as" on your browser, and save the
+	file under the name "<tt>Xinstall.sh</tt>".
+
+  <item>The Xinstall.sh script requires some system commands and
+	utilities to function correctly.  While most systems will have
+	these, some Linux installations may not.  If you find that the
+	script is failing because of some missing system command, you
+	will need to install it before you can continue.  If you don't
+	know how to do this, then we recommend that you obtain this
+	version of XFree86 from your Operating System distributor.
+
+  <item>Always use the version of the Xinstall.sh script that's provided
+	with the release you're installing.  Older versions of the script
+	may not install newer releases correctly.
+
+  <item>If the binary distribution reported by the Xinstall.sh script
+	isn't present on our site, then there are two possibilities.
+	The first is that it hasn't been prepared and uploaded yet.
+	This is likely if you are looking soon after the release date.
+	The second possibility is that we won't have it available at
+	all for this release.  This is likely if it's still not there
+	about two weeks after the release date.  Check <url name="here"
+	url="http://www.xfree86.org/&relvers;/UPDATES.html"> for
+	information about updates to our binary distributions, and <url
+	name="here" url="http://www.xfree86.org/&relvers;/ERRATA.html">
+	for errata related to this release.
+
+</itemize>
+
+Once you're run the <tt>Xinstall.sh</tt> script and found which binary
+<![ %updaterel; [update ]]>distribution is suitable for your system,
+download the necessary files.  The <![ %fullbinaries [twelve (12)]]><![
+%updaterel [four (4)]]> mandatory files for all installations are listed
+below.  If you have not downloaded all of the files, the installer script
+will complain.
+
+<![ %fullbinaries [
+<quote><verb>
+1.   Xinstall.sh    The installer script
+2.   extract        The utility for extracting tarballs
+3.   Xbin.tgz       X clients/utilities and run-time libraries
+4.   Xlib.tgz       Some data files required at run-time
+5.   Xman.tgz       Manual pages
+6.   Xdoc.tgz       XFree86 documentation
+7.   Xfnts.tgz      Base set of fonts
+8.   Xfenc.tgz      Base set of font encoding data
+9.   Xetc.tgz       Run-time configuration files
+10.  Xvar.tgz       Run-time data
+11.  Xxserv.tgz     XFree86 X server
+12.  Xmod.tgz       XFree86 X server modules
+</verb></quote>
+]]>
+
+<![ %updaterel [
+<quote><verb>
+1.   Xinstall.sh    The installer script
+2.   extract        The utility for extracting tarballs
+3.   Xupdate.tgz    Updated files except X server drivers
+4.   Xdrivers.tgz   Updated X server drivers
+</verb></quote>
+]]>
+
+NOTES:
+<itemize>
+  <item>Some web browsers have a problem downloading the <tt>extract</tt>
+	utility correctly.  If you encounter this problem, download the
+	version called <tt>extract.exe</tt> instead.  This should fix the
+	problem.  (This is not a DOS/Windows executable.)
+
+<![ %fullbinaries [
+  <item>A few distributions don't have or require the <tt>Xvar.tgz</tt>
+	tarball.  If it is present in the <tt>binaries</tt> sub-directory
+	for your platform, then it is required.
+]]>
+
+  <item>The Darwin/Mac OS X distribution doesn't have or require the
+	<![ %fullbinaries [<tt>Xmod.tgz</tt>]]><![ %updaterel
+	[<tt>Xdrivers.tgz</tt>]]> tarball.
+
+  <item>Some distributions may have additional mandatory tarballs.
+	While rare, the installer script will tell you if any are missing.
+
+</itemize>
+
+<![ %fullbinaries [
+The following eleven (11) tarballs are optional.  You should download
+the ones you want to install.
+
+<quote><verb>
+1.   Xfsrv.tgz      Font server
+2.   Xnest.tgz      Nested X server
+3.   Xprog.tgz      X header files, config files and compile-time libs
+4.   Xprt.tgz       X Print server
+5.   Xvfb.tgz       Virtual framebuffer X server
+6.   Xf100.tgz      100dpi fonts
+7.   Xfcyr.tgz      Cyrillic fonts
+8.   Xfscl.tgz      Scalable fonts (Speedo, Type1 and TrueType)
+9.   Xhtml.tgz      HTML version of the documentation
+10.  Xps.tgz        PostScript version of the documentation
+11.  Xjdoc.tgz      Documentation in Japanese
+</verb></quote>
+
+NOTES:
+<itemize>
+  <item>Some distributions may have some additional optional tarballs.
+
+</itemize>
+
+If you miss some and want to install them later, go to the
+<ref id="manual-install" name="Manual Installation"> section.
+]]>
+
+<sect>Installing XFree86 &relvers; using the <tt>Xinstall.sh</tt> script
+<p>
+We strongly recommend that our XFree86 &relvers; binaries be installed
+using the <tt>Xinstall.sh</tt> script that we provide.
+<![ %updaterel [It is also important that the previous full release
+(&fullrelvers;) is installed before installing this update release.
+Make sure that you use the &relvers; version of the <tt>Xinstall.sh</tt>
+script to install this update.  Older versions may not be able to do it
+correctly.]]>
+There are a lot of
+steps in the manual installation process, and those steps can vary
+according to the platform and hardware setup.  <![ %fullbinaries [There is a description of
+the manual installation process for the most common cases <ref
+id="manual-install" name="below">.]]>
+
+You must login as the super user (root) to run the installer script.
+Place all of the downloaded files into a single directory (choose a
+temporary location with enough space).  Use the cd command to change to
+that directory and then run the installer script as follows:
+
+<tscreen><verb>
+sh Xinstall.sh
+</verb></tscreen>
+
+Answer the prompts as they come up.  If you are missing something that
+is required, the installer may tell you to install it before trying
+again.  If the problem is that you did not download all of mandatory
+files aforementioned, then the installer will tell you which ones are
+missing and ask you to download them before proceeding.
+
+<sect1>Questions the installer may ask
+<p>
+The installer asks some questions that may not have obvious answers.  The
+information here should help you answer them.  In most cases, apart from
+the first question, the default answers should be OK.
+
+If you run the installer from within an X session (the installer checks
+if <tt>$DISPLAY</tt> is set), you will be warned that doing so is not
+a good idea.  Unless you have a good reason for knowing that this won't
+be a problem, you should exit your X session, including stopping xdm or
+equivalent if it is running, before continuing.  If you ignore this
+warning and run into problems, well, you were warned!
+
+<![ %fullbinaries [If you have an existing X installation, you]]>
+<![ %updaterel [You ]]>
+will be warned that proceeding
+with this installation will overwrite it.  Only those things that are
+part of our standard distribution will be overwritten.  Other X
+applications that you may have installed will not be removed.  Some
+configuration files may be overwritten though, but the installer should
+prompt you before doing so.  As the opening greeting says, it is
+<bf>strongly</bf> recommended that you backup any existing installation
+before proceeding.  If you want your old applications to still be there
+after you've installed, don't do the "backup" by simply renaming
+your old <tt>/usr/X11R6</tt> directory.  It is better to make a copy of
+it, and then install over the top of the original one.  If you run into
+problems and want to revert to the old installation, you can then
+delete the overwritten one and copy the saved version back.
+
+During the first part of the installation over an existing version, the
+script may remove some old files or directories that would get in the
+way of the new installation.  It will list which files/directories have
+been removed.  If none are listed, then none were removed.
+
+<![ %fullbinaries [
+The next step when installing over an existing version is to check for
+existing configuration files.  As of XFree86 version 3.9.18, the run-time
+configuration files are installed by default under <tt>/etc/X11</tt>
+instead of under <tt>/usr/X11R6/lib/X11</tt>.  The installer will move
+the existing ones for you and create the necessary symbolic links.  If
+you don't want to have these configuration files under <tt>/etc/X11</tt>,
+then you should answer "no" when asked about it.  Answering "no" here
+also means that the new configuration files will be installed in the
+old <tt>/usr/X11R6/lib/X11</tt> location.
+
+Note: for the rare systems that don't have symbolic links, this question
+will not be asked.  The default answer is "yes" because that is best
+for most situations.  It is our new default.  It makes it easier to
+share the <tt>/usr/X11R6</tt> directory between multiple hosts, and
+allows it to be mounted read-only.  If you don't need these features,
+then you can safely answer "no" if you don't want them moved.
+
+When installing over an existing version, you will be prompted before
+each set of configuration files is installed.  If you haven't made any
+Customisations to your existing configuration files, then you can safely
+answer "yes" for each of these.  If you have made customisations, you
+can try answering "no".  If you run into problems later, you may need
+to manually merge your customisations into the the new version of the
+configuration files.  The configuration files can all be found in the
+<tt>Xetc.tgz</tt> tarball.  See the <ref id="manual-install" name="section
+below"> about manual installation for information about extracting them
+separately.
+
+After the configuration files have been dealt with, the other mandatory
+components of the binary distribution will be installed.  This should
+proceed without any user intervention.
+
+If you downloaded any of the optional components, the installer will
+ask you about each one before it is installed.  The default answer is
+"yes".  If there are any that you've since decided that you don't want
+to install, answer "no" when prompted.
+
+After that is done, the main part of the installation is complete.  The
+next steps are to tidy up some aspects of the installation.  The first
+of these is to run "<tt>ldconfig</tt>" on systems that require it, so
+that the newly installed shared libraries are accessible.  Then
+the <tt>fonts.dir</tt> files in some directories are updated so that
+the fonts can be accessed correctly.  Next, the installer checks to
+see if your system has a termcap file or terminfo files.  If it finds
+the former, it tells you how you may update the entries in that file.
+If it finds the latter, it asks you if you want it to update them
+for you.
+
+You may be asked if you want to create links for the GL libraries and
+header files.  The OpenGL standard on some platforms (Linux in particular)
+says that these should be installed in the standard system locations
+(<tt>/usr/lib</tt> and <tt>/usr/include</tt>), so the installer offers
+to create the appropriate links.  If you're running Linux, you should
+probably answer yes.  For other platforms it is your choice.  If you
+already have another version of libGL in /usr/lib, answering "yes" will
+remove it and replace it with a link to the version we supply.  The
+installer will show you a listing of any existing versions before asking
+if they should be replaced.
+
+Finally, the installer asks you if you want a link created for the
+<tt>rstart</tt> utility.  On most modern systems the link isn't essential,
+so the default answer is "no".  Answer "yes" if you know that you need
+it.  If you find later that you need it, you can create it easily by
+running:
+
+<tscreen><verb>
+rm -f /usr/bin/rstartd
+ln -s /usr/X11R6/bin/rstartd /usr/bin/rstartd
+</verb></tscreen>
+
+]]>
+
+<sect1>After the installation is complete
+<p>
+The next step is to configure the X server.  That is covered in detail
+in an as-yet unwritten document :-(.  In the meantime, there are three
+ways to create a basic X server configuration file for XFree86 &relvers;.
+One is to run the <tt>xf86config</tt> utility.  Another is to run the
+<tt>xf86cfg</tt> utility.  The third option is to use the new
+<tt>-configure</tt> X server option:
+
+<tscreen><verb>
+XFree86 -configure
+</verb></tscreen>
+
+Note that if you are running Darwin/Mac OS X, there is no step 3 :-).
+You should skip this step, as configuration is not required or possible.
+The X server configuration file is not used on Darwin/Mac OS X.
+
+The X server config file (<tt>XF86Config</tt>) format has changed
+compared to 3.3.x.  Also, its default location is now <tt>/etc/X11</tt>.
+Finally, there is now only one X server for driving video hardware,
+and it is called "<tt>XFree86</tt>".  Once you're satisfied with the
+operation of the new X server, you can safely remove the old
+<tt>XF86_*</tt> and/or <tt>XF98_*</tt> X server binaries from
+<tt>/usr/X11R6/bin</tt>.
+
+After the X server configuration is done, it may be advisable to reboot,
+especially if you run xdm (or equivalent) or the font server (xfs).
+
+<![ %fullbinaries [
+<sect>Installing XFree86 &relvers; manually<label id="manual-install">
+<p>
+This section contains information about manually installing the XFree86
+&relvers; binary distributions.  You should only use this method if you
+know what you're doing.  The information here covers some common cases,
+but not every possible case.  It also may not be complete or up to date.
+Use at your own risk.
+
+Put all of the downloaded files into a single directory (choose some
+temporary location with enough space).  Become the super user (root).
+All of the following commands should be run as root, and they should be
+run from the directory that has all of the downloaded files.  The
+"<tt>extract</tt>" utility should be used to unpack the tarballs.  This
+is a customised version of GNU tar that has the gzip code built-in, and
+which has a different usage when run under the name "extract".  One
+important thing that <tt>extract</tt> does that most versions of tar do
+not do by default is that it unlinks existing files before writing new
+ones.  This is important when installing over an existing version of X.
+If you choose to use some other utility to extract the tarballs, you're
+on your own.
+
+<sect1>A new installation
+<p>
+The simplest case is when there is no existing X installation.  The
+installation procedure for this case is as follows:
+
+<tscreen><verb>
+chmod +x extract
+mkdir /usr/X11R6
+mkdir /etc/X11
+./extract -C /usr/X11R6 X[a-df-uw-z]*.tgz
+./extract -C /usr/X11R6 Xvfb.tgz    # If you are installing Xvfb
+./extract -C /etc/X11 Xetc.tgz
+./extract -C /var Xvar.tgz
+ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11
+ln -s /etc/X11/fs /usr/X11R6/lib/X11
+ln -s /etc/X11/lbxproxy /usr/X11R6/lib/X11
+ln -s /etc/X11/proxymngr /usr/X11R6/lib/X11
+ln -s /etc/X11/rstart /usr/X11R6/lib/X11
+ln -s /etc/X11/twm /usr/X11R6/lib/X11
+ln -s /etc/X11/xdm /usr/X11R6/lib/X11
+ln -s /etc/X11/xinit /usr/X11R6/lib/X11
+ln -s /etc/X11/xsm /usr/X11R6/lib/X11
+ln -s /etc/X11/xserver /usr/X11R6/lib/X11
+chmod ug-w /usr/X11R6/lib           # Make sure the permissions are OK
+/sbin/ldconfig /usr/X11R6/lib       # For Linux
+/sbin/ldconfig -m /usr/X11R6/lib    # For FreeBSD, NetBSD, OpenBSD
+/usr/X11R6/bin/mkfontdir /usr/X11R6/lib/X11/fonts/misc
+</verb></tscreen>
+
+<sect1>Installing over an old installation
+<p>
+If you have an existing installation of X, you should make a backup copy
+of it before installing the new version over the top of it.
+
+Before doing anything else, make sure the <tt>extract</tt> command is
+executable, and also link it to the name "<tt>gnu-tar</tt>" so that it
+can be used as a regular <tt>tar</tt> command:
+
+<tscreen><verb>
+chmod +x extract
+rm -f gnu-tar
+ln extract gnu-tar
+</verb></tscreen>
+
+The first part of the procedure is to move the old run-time config files
+from <tt>/usr/X11R6/lib/X11</tt> to <tt>/etc/X11</tt>.  Create
+<tt>/etc/X11</tt> if it doesn't already exist.  For each of the following
+sub-directories (<tt>app-defaults</tt>, <tt>fs</tt>, <tt>lbxproxy</tt>,
+<tt>proxymngr</tt>, <tt>rstart</tt>, <tt>twm</tt>, <tt>xdm</tt>,
+<tt>xinit</tt>, <tt>xsm</tt>, <tt>xserver</tt>) that you want to move,
+check that there is a sub-directory of this name in
+<tt>/usr/X11R6/lib/X11</tt>.  Create a sub-directory of the same name
+under <tt>/etc/X11</tt>, then copy the files over by running:
+
+<tscreen><verb>
+./gnu-tar -C /usr/X11R6/lib/X11/subdir -c -f - . | \
+  ./gnu-tar -C /etc/X11/subdir -v -x -p -U -f -
+</verb></tscreen>
+
+For each subdirectory that is moved, remove the one under
+<tt>/usr/X11R6/lib/X11</tt> and create a symbolic link to the new
+location:
+
+<tscreen><verb>
+rm -fr /usr/X11R6/lib/X11/subdir
+ln -s /etc/X11/subdir /usr/X11R6/lib/X11
+</verb></tscreen>
+
+For those subdirectories that didn't already exist under
+<tt>/usr/X11R6/lib/X11</tt>, create one under <tt>/etc/X11</tt> and
+create the symbolic link to it:
+
+<tscreen><verb>
+mkdir /etc/X11/subdir
+ln -s /etc/X11/subdir /usr/X11R6/lib/X11
+</verb></tscreen>
+
+Once that is done, extract the config files from the <tt>Xetc.tgz</tt>
+tarball into a temporary directory:
+
+<tscreen><verb>
+mkdir tmpdir
+./extract -C tmpdir Xetc.tgz
+</verb></tscreen>
+
+and then copy each sub-directory over to the installed location:
+
+<tscreen><verb>
+./gnu-tar -C tmpdir/subdir -c -f - . | \
+  ./gnu-tar -C /usr/X11R6/lib/X11/subdir -v -x -p -U -f -
+</verb></tscreen>
+
+If you have customised any config files in your old installation, you
+may want to omit those sub-directories, or copy selected files over by
+hand.
+
+Once that's done, the main part of the installation can be done:
+
+<tscreen><verb>
+./extract -C /usr/X11R6 `pwd`/X[a-df-uw-z]*.tgz
+./extract -C /usr/X11R6 Xvfb.tgz    # If you are installing Xvfb
+./extract -C /var Xvar.tgz
+chmod ug-w /usr/X11R6/lib           # Make sure the permissions are OK
+/sbin/ldconfig /usr/X11R6/lib       # For Linux
+/sbin/ldconfig -m /usr/X11R6/lib    # For FreeBSD, NetBSD, OpenBSD
+/usr/X11R6/bin/mkfontdir /usr/X11R6/lib/X11/fonts/misc
+</verb></tscreen>
+
+]]>
+
+
+</article>
diff --git a/sgml/Japanese/1st.sgml b/sgml/Japanese/1st.sgml
new file mode 100644
index 0000000..b67b234
--- /dev/null
+++ b/sgml/Japanese/1st.sgml
@@ -0,0 +1,104 @@
+<!doctype linuxdoc system>
+
+<article>
+
+<!-- Title information -->
+<title> XFree86 PC98 General Information
+<author> The XFree86 Project Inc. / X98 CORE TEAM
+<date> 1999ǯ 7�� 19��
+
+<sect> �Ϥ����<p>
+XFree86�ϡ�NEC PC98����Ӹߴ�����ư���FreeBSD(98)��NetBSD/pc98
+(based on NetBSD 1.3.2)�ʹߡ�PANIX Ver.5.0 for 98��Linux/98�򥵥ݡ��Ȥ��ޤ���
+PC98�Υ������ƥ������XFree86�Υ������ĥ꡼�ǥ��ݡ��Ȥ��졢���γ�ȯ�ȥ�����
+���ݼ�ϡ�The XFree86 Project Inc��X98 CORE TEAM���ԤäƤ��ޤ���</p>
+
+<p>PC98�ѥɥ�����ȤǤϡ����PC98��ͭ�λ���ˤĤ����������ޤ���
+����¾�λ��ˤĤ��Ƥϡ�PC/AT�ߴ����ǤȤζ��̥ɥ�����Ȥ򻲾Ȥ��Ʋ�������
+¿���Υɥ�����Ȥ����ܸ첽����Ƥ��ޤ��Τǡ������򻲾Ȥ������
+�����ᤷ�ޤ���</p>
+
+<sect>���󸻡�Ϣ����<p>
+
+XFree86������Ū�ʥ��ݡ��ȤˤĤ��Ƥϡ�<it/&lt;XFree86@XFree86.Org&gt;/
+�رѸ�ǥ��󥿥��Ȥ��Ʋ�������PC98��ͭ������ˤĤ��Ƥϡ����ܸ��
+��ȯ�ԥ᡼��󥰥ꥹ��<it/&lt;x98@mech.titech.ac.jp&gt;/�إ��󥿥��Ȥ���
+��������</p>
+
+<p> ư������Х����󡢥ѥå��ʤɤ�̵���˴��ޤ������ޤ��Τǡ����������ꤤ
+�������ޤ���format ���䤤�ޤ��󤬡��ɥ�����Ȥ˵��Ҥ��������ƤˤĤ��Ƥ�
+�������Ϥ���θ��������</p>
+
+<p>NetNews��fj.windows.x��fj.os.bsd.*��NIFTY-SERVE(FUNIX, FEPSONX, SAISAP)��
+PC-VAN(JUNIX, JSPUNIX)��FreeBSD-users-jp ML��FreeBSD kit ML��FreeBSD98-testers
+ML��FreeBSD98-hackers ML��seraphim-bugs ML��seraphim-beta ML��¿���ε�����
+�����������Ԥ��Ƥ��ޤ���PC98�ˤĤ��Ƥξ���ˤĤ��ƤϤ����ξ����
+���ޤ��Τǡ����ä�����򤪴��ᤷ�ޤ���</p>
+
+<sect> PC98��ͭ�Υɥ������<p>
+<itemize>
+	<ITEM>README98.1st	����(���Υե�����)
+	<ITEM>README98	PC98�˴ؤ�������
+	<ITEM>XF86Config.98	ɸ��Ū��PC98��XF86Config
+	<ITEM>VideoBoard98	�б��ӥǥ��ܡ��ɤ˴ؤ������
+</itemize>
+
+<sect>���쥸�å�<p>
+	PC98�ѥ����ɤ�The XFree86 Project Inc�Ȱʲ���X98 CORE TEAM�������
+	����¾�ζ��ϼԤˤ���������ޤ�����
+  
+<p>X98 CORE TEAM
+<itemize>
+        <ITEM>���� ����<it/&lt;aizu@jaist.ac.jp&gt;/
+        <ITEM>���� ����<it/&lt;ishidakz@obp.cl.nec.co.jp&gt;/
+        <ITEM>���� ����<it/&lt;cs94006@mbox.sist.ac.jp&gt;/
+        <ITEM>��ƣ ��ͺ<it/&lt;ft4k-itu@asahi-net.or.jp&gt;/
+        <ITEM>���� �µ�<it/&lt;jagarl@creator.club.or.jp&gt;/
+        <ITEM>���� ����<it/&lt;uenos@ppp.bekkoame.or.jp&gt;/
+        <ITEM>���� ��ɧ<it/&lt;Kazuhiko.Uno@softvision.co.jp&gt;/
+        <ITEM>���� ����Ϻ<it/&lt;s-urata@nmit.tmg.nec.co.jp&gt;/
+        <ITEM>���� ��<it/&lt;ohishi@hf.rim.or.jp&gt;/
+        <ITEM>���� ����<it/&lt;atena@njk.co.jp&gt;/
+        <ITEM>�ݻ� ů��<it/&lt;kakefuda@tag.iijnet.or.jp&gt;/
+        <ITEM>��ƣ ��Ƿ<it/&lt;yasuyuki@acaets0.anritsu.co.jp&gt;/
+        <ITEM>��¼ ��<it/&lt;KFB03633@nifty.ne.jp&gt;/
+        <ITEM>���� ã��<it/&lt;koiket@focus.rim.or.jp&gt;/
+        <ITEM>H.Komatsuzaki	
+        <ITEM>���� ��<it/&lt;sakamoto@yajima.kuis.kyoto-u.ac.jp&gt;/
+        <ITEM>���״� ��<it/&lt;i931361@jks.is.tsukuba.ac.jp&gt;/
+        <ITEM>���� ƻ��<it/&lt;karl@spnet.ne.jp&gt;/
+        <ITEM>���� ����Ϻ<it/&lt;s-koichi@nims.nec.co.jp&gt;/
+        <ITEM>���� �θ�<it/&lt;suzuki@grelot.elec.ryukoku.ac.jp&gt;/
+        <ITEM>���� ����<it/&lt;suz@d2.bs1.fc.nec.co.jp&gt;/
+        <ITEM>��� ����<it/&lt;takigami@elsd.mt.nec.co.jp&gt;/
+        <ITEM>���� ��ʸ<it/&lt;tsuka@linkt.imasy.or.jp&gt;/
+        <ITEM>���� ����<it/&lt;nagao@cs.titech.ac.jp&gt;/
+        <ITEM>���� ̭<it/&lt;mnoda@cv.tottori-u.ac.jp&gt;/
+        <ITEM>��¼ ����<it/&lt;amadeus@yk.rim.or.jp&gt;/
+        <ITEM>ƣ�� ˭��<it/&lt;toyo@ibbsal.or.jp&gt;/
+        <ITEM>��¿ ��ʸ<it/&lt;honda@Kururu.math.hokudai.ac.jp&gt;/
+        <ITEM>���� ����<it/&lt;amorita@bird.scphys.kyoto-u.ac.jp&gt;/
+        <ITEM>Ȭ�� ����<it/&lt;QZR00522@nifty.ne.jp&gt;/
+        <ITEM>Ȭ�� ��ɧ<it/&lt;j2297222@ed.kagu.sut.ac.jp&gt;/
+        <ITEM>���� ��<it/&lt;yasuda@cc.hit-u.ac.jp&gt;/
+</itemize>
+<p>����¾�ζ��ϼ�
+<itemize>
+	<ITEM>���� ��(x98ML�������)
+	<ITEM>���� ��(x98ML������)
+	<ITEM>���� ����(PowerWindow805i�б���������)
+	<ITEM>���� �ػ�(PW928II��Ϳ)
+	<ITEM>���� ��ʸ(Linux/98�б�)
+	<ITEM>��� μ��(Ʊ��)
+	<ITEM>PC-VAN(JUNIX, JSPUNIX), NIFTY-SERVE(FUNIX, FEPSONX, SAISAP),
+	fj, x98 ML, FreeBSD-users-jp ML, FreeBSD kit ML, FreeBSD98-testers ML,
+	FreeBSD98-hackers ML, seraphim-bugs ML,	seraphim-beta ML ��ư�����
+	�򤯤����ä�����
+	<ITEM>����ޥ����󥯥��
+	<ITEM>FreeBSD PC98�ܿ�������
+	<ITEM>NetBSD/pc98 Core Team
+	<ITEM>���������������եȳ������
+</itemize>
+     ����
+
+</article>
diff --git a/sgml/Japanese/read98.sgml b/sgml/Japanese/read98.sgml
new file mode 100644
index 0000000..93909e4
--- /dev/null
+++ b/sgml/Japanese/read98.sgml
@@ -0,0 +1,265 @@
+<!doctype linuxdoc system>
+
+<article>
+
+<!-- Title information -->
+<title> XFree86 PC98 Dependent Information
+<author> The XFree86 Project Inc. and X98 CORE TEAM
+<date> 2000ǯ 6��20��
+<abstract>
+���Υɥ�����ȤǤϡ�PC98��ͭ�λ���ˤĤ��Ʋ��⤷�ޤ���
+PC/AT�ߴ����ȶ��̤λ���ˤĤ��Ƥϡ����̤Υɥ�����Ȥ򻲾Ȥ��Ʋ�������
+</abstract>
+
+<sect>�ܥ�꡼���ˤĤ���
+<p>�ܥ�꡼���Ǥϡ�PC98��X�����Ф�PC/AT�ߴ�����X�����Ф�����(�ե�����̾:
+XFree86)����Ƥ��ꡢ����Υܡ���/���åץ��å���Υ����Ф�ʤ��ʤ�ޤ�����
+�ޤ����ƥɥ饤�ФϤ��٤�SVGA�١����ǡ�XF86_S3�١����Υɥ饤�ФϤ���ޤ���
+���ߤΤȤ�����PC98��ư��Ƥ���Τϡ�mga��apm��glint��trident�ɥ饤�ФΤ�
+�Ǥ���Millennium��Mystique��VoodooRUSH��Permedia2��TGUI968x(�������PCI)��
+�ܡ��ɤ򤪻��������ʳ��ϡ�3.3�١���(ex. 3.3.6)�δĶ�������Ѳ�������
+����4.0�Ǥ�EGC��PEGC�������ѤǤ��ޤ��󡣳�ȯ���Ф����˾��ʤ��ʤäƤ���
+�Τǡ���ȯ�˶�̣�������������X98 Core Team�ޤǡ���Ϣ����������</p>
+
+<p>XF86Config�䵯ư���Υ��ץ���������ѹ��ˤĤ��Ƥϡ�RELNOTES�˾ܤ����񤤤�
+����ޤ��Τǡ����Ȥ��Ʋ�������/usr/X11R6/lib/X11/XF86Config.98����PC98��
+��XF86Config�ο����Ǥ���</p>
+
+<sect>���ݡ��Ⱦ���<p>
+����X������(XFree86)�ϡ��ʲ��γ�ĥ�ӥǥ��ܡ��ɡ���¢�ӥǥ������ƥ���б�
+���Ƥ��ޤ����ġ����б���ư������ˤĤ��Ƥ�VideoBoard98�򻲾Ȥ��Ʋ�������
+</p>
+
+<sect1>���ݡ��ȥ����ɰ��� <p>
+<verb>
+  �٥����	������̾��					������
+  ------------- ----------------------------------------------- -------
+  NEC		�ե륫�顼������ɥ���������졼���ܡ��� X2	XFree86
+  Matrox	MGA Millennium(PC/AT �ߴ�����)			XFree86
+  IO-DATA	GA-RUSH6/PCI					XFree86
+  Melco		WHP-PS8, WHP-PS4				XFree86
+  (IO-DATA	GA-PII8, GA-PIIH8				XFree86)
+</verb></p></sect1>
+
+<sect1>���ݡ�����¢�ӥǥ������ƥ����<p>
+<verb>
+  �٥����	���åץ��å�					������
+  ------------- ----------------------------------------------- -------
+  NEC		MGA Millennium/Mystique				XFree86
+  NEC		Trident TGUI968x(X-Mate,ValueStar��)		XFree86
+</verb></p>
+
+<sect>���̻���<p>
+<descrip>
+<tag>PC98�λ���</tag>
+	����X�����ФǤϡ�ʪ�����ɥ쥹0xf8e80�����2�Х��Ȥ򻲾Ȥ���0x98��
+	0x21�Υǡ����������PC98�ȼ�ưǧ��������ư���Υ�����
+
+	(--) Japanese PC98 architecture
+
+	�Ƚ��Ϥ��ޤ�����¿����PC98(Millennium,Mystique�����ѤǤ��뵡��Ǥ�
+	100%)�������ǧ�������Ȧ�Ǥ���������嵭��ɽ��������ʤ��ä����
+	�ϡ�XF86Config��Section "ServerFlags"�ˡ�
+
+	Option	"PC98"
+
+	�λ��������Ʋ������������PC98��ǧ�����졢������
+
+	(**) Japanese PC98 architecture
+
+	�Ƚ��Ϥ����褦�ˤʤ�ޤ���
+<tag>xf86config��xf86cfg</tag>
+	PC98�Ѥ˰ܿ�����Ƥ��ޤ���/usr/X11R6/lib/X11/XF86Config.98��
+	XF86Config�ȥ�͡��ष�ƻ��Ѥ��Ʋ�������
+<tag>xvidtune</tag>
+	���ʤ�ư���ǧ��ԤäƤ��ޤ��󤬡�ư���褦�Ǥ���
+<tag>SuperProbe</tag>
+	�ܿ�����Ƥ��ޤ��󡣥ϥ󥰥��åפ�ӥǥ��ܡ��ɤ�������줬����
+	�Τ����Ф˻��Ѥ��ʤ��ǲ�������
+<tag>XF86Setup</tag>
+	PC/AT�ߴ�����ޤᡢ�ܥ�꡼���Ǥϥ��ݡ��Ȥ���Ƥ��ޤ���
+	/usr/X11R6/lib/X11/XF86Config.98��XF86Config�ȥ�͡��ष�ƻ���
+	���Ʋ�������
+<tag>scanpci</tag>
+        ���ʤ�ư���ǧ��ԤäƤ��ޤ��󤬡�ư���褦�Ǥ���
+<tag>�ǥե���ȤΥ���ѥ����������</tag>
+	�Τ�PC98�ѥ����ФȰۤʤꡢXFree86�ϡ�GetValuesBC NO,BuildPexExt 
+	YES,BuildXIE YES���������Ƥ��ޤ��������ղ�������xengine����
+	��GetValues�ˤĤ��ƥ������ν�����ɬ�פǤ��� 
+<tag>16MB�����ƥ���֤�����</tag>
+	�ܡ���/���åץ��åȤˤ�äƤϡ�15M-16M���ΰ����Ѥ���ʪ������ޤ���
+	�����ͤʥܡ��ɤ���Ѥ��Ƥ����硢�����ƥॻ�åȥ��åץ�˥塼�ǡ�
+	16MB�����ƥ���֤���ڤ�Υ���פˤ��ƥ����Ф�ư����ȡ��ϥ󥰥��å�
+	���������������ǽ��������ޤ���Millennium��Mystique�˴ؤ��ƤϤ���
+	���֤���Ѥ��ޤ��󤬡����ζ��֤���Ѥ��ʤ��ȤϤä���ʬ�����ΰʳ�
+	��Ȥ����ϡ����ʤ餺�ֻ��Ѥ���פˤ��Ʋ�������
+<tag>XKB</tag>
+	XF86Config��Section "InputDevice"�ǡ�
+<verb>
+	XkbRules	"xfree86"
+	XkbModel	"pc98"
+	XkbLayout	"nec/jp"
+</verb>
+	�λ���򤷤Ʋ�������
+<tag>BusID</tag>
+	XF86Config��Section "Device"�ǡ�ɬ��
+<verb>
+	BusID	"0:10:0"
+</verb>
+	�Τ褦�ʻ���򤷤Ʋ�������������
+<verb>
+	(--) PCI: (0:7:0) NEC unknown chipset (0x0009) rev 2
+	(--) PCI: (0:12:0) S3 968 rev 0, Mem @ 0x24000000/25
+	(--) PCI: (0:14:0) Matrox MGA 2064W rev 1, Mem @ 0x20004000/14, 0x21000000/23
+</verb>
+	�Τ褦�˽ФƤ��ơ�Millennium����Ѥ�����ϡ�"0:14:0"����ꤷ�ޤ���
+	S3 968�ϻ��ѤǤ��ޤ���ǰ�ΰ١�
+<tag>CTRL,GRPH,+/- �ˤ����������ؤ�</tag>
+	�Ǥ��ʤ��ʤäƤ���褦�Ǥ���
+</descrip>
+
+<sect>�ɥ饤�ФˤĤ���
+<sect1>mga�ɥ饤��<p>
+	NEC����¢��������졼��(Matrox Millennium/Mystique), PC/AT�ߴ�����
+	Millennium ��ư���ɥ饤�ФǤ���</p>
+<sect2>XF86Config������<p>
+	README.MGA��˲��⤵��Ƥ��륪�ץ��������Ǥ��ޤ����̾���ä�
+	������ꤹ��ɬ��̵��Ȧ�Ǥ���
+<sect2>��𤵤�Ƥ�������<p>
+<itemize>
+	<ITEM>Millennium�Ǥϡ�Modeline������ˤ�äƤ�24bpp�ǽĤ���
+	���뤤�ϼ����ͤΥΥ������Ф뤫�⤷��ޤ���
+	<ITEM>Mystique�Ǥϡ�VideoRam������Ū�ʻ��꤬ɬ�ܤȤʤ�ޤ���
+</itemize>
+<sect2>����¾<p>
+<itemize>
+	<ITEM>PC/AT�ߴ����Ѥ�Millennium����Ѥ�����ϡ�VGA��disable
+	���Ʋ�������
+	<ITEM>PC/AT�ߴ����Ѥ�Millennium II, Mystique, G100, G200���ϡ�VGA��
+	disable�Ǥ��ʤ��Τǡ����ѤǤ��ޤ���
+	<ITEM>3.3�١�����X�����Ф�¸�ߤ��Ƥ�����Mystique����Ѥ��Ƥ������
+	Windows������˵�ư���Ƥ����ʤ���Фʤ�ʤ��Ȥ��������8bpp�Ǥ�ɽ��
+	�����������Ȥ�������ϲ�ä���Ƥ��ޤ���
+	<ITEM>�ޤ���ʬ�ʥƥ��Ȥ��Ԥ��Ƥ��ʤ��Τ�ư���ݡ��Ȥ򤪴ꤤ
+	���ޤ���
+</itemize>
+<sect2>��Ϣ<p>
+	README.MGA��XF86_SVGA man page</p>
+
+<sect1>apm�ɥ饤��<p>
+	IO-DATA��GA-RUSH6/PCI��ư���ɥ饤�ФǤ���</p>
+<sect2>XF86Config������<p>
+	README.apm��˲��⤵��Ƥ��륪�ץ��������Ǥ��ޤ����̾���ä�
+	������ꤹ��ɬ��̵��Ȧ�Ǥ���
+<sect2>��𤵤�Ƥ�������<p>
+<itemize>
+	<ITEM>�������Ǽ���Ū�˻��ѤǤ��������ǧ����Ƥ���Τ�1024x768 256��
+	�ΤߤǤ���16bpp��1280x1024����ɽ���Ǥ�Ʊ�������ʤ��ä��ꡢ���ߤʤ�
+	��ɽ�����줿�ꤷ�ޤ���
+	<ITEM>��VideoRam 4096�פλ��꤬ɬ�ܤǤ���
+</itemize>
+<sect2>����¾<p>
+<itemize>
+	<ITEM>���������θ����ʤ�1024x768 256������Ѥ��Ʋ�������
+	<ITEM>�ܥӥǥ������ɤ˴ؤ��Ƥ�XFree86 4.0�ʹߤ���Ѥ��Ʋ�������
+	<ITEM>�ޤ���ʬ�ʥƥ��Ȥ��Ԥ��Ƥ��ʤ��Τ�ư���ݡ��Ȥ򤪴ꤤ���ޤ���
+</itemize>
+<sect2>��Ϣ<p>
+	XF86_SVGA man page</p>
+
+<sect1>glint�ɥ饤��<p>
+	Melco��WHP-PS8,WHP-PS4��Permedia2��ܤΥӥǥ������ɤ�ư���ɥ饤��
+	�Ǥ���IO-DATA��GA-PII8��GA-PIIH8���Ǥ�ư��뤫�⤷��ޤ���</p>
+<sect2>XF86Config������<p>
+	README.3Dlabs��˲��⤵��Ƥ��륪�ץ��������Ǥ��ޤ����̾���ä�
+	������ꤹ��ɬ��̵��Ȧ�Ǥ���
+<sect2>��𤵤�Ƥ�������<p>
+<itemize>
+	<ITEM>PC-98�Ǥ�ư�����٤��б������ɤ��ޤޤ�Ƥ��ޤ�����ư���ǧ��
+	�ؤɤ���Ƥ��ޤ���
+</itemize>
+<sect2>����¾<p>
+<itemize>
+	<ITEM>�ޤ��ؤɥƥ��Ȥ��Ԥ��Ƥ��ʤ��Τ�ư���ݡ��Ȥ򤪴ꤤ���ޤ���
+	<ITEM>�ܥӥǥ������ɤ˴ؤ��Ƥ�XFree86 4.0�ʹߤ���Ѥ��Ʋ�������
+</itemize>
+<sect2>��Ϣ<p>
+	XF86_SVGA man page</p>
+
+<sect1>trident�ɥ饤��<p>
+	NEC ����¢��������졼��(Trident TGUI9680/9682)��ư���ɥ饤�ФǤ���
+	Accel�Ǥ��Ȥ���������
+<sect2>XF86Config ������<p>
+<descrip>
+<tag>VideoRam 2048(�ޤ��� 1024)</tag>
+VideoRam�����������ФǤ��ʤ��������ꤷ�Ʋ�������
+</descrip>
+
+�ʲ���Option(XaaNoScreenToScreenCopy�����)��TGUI9680�Ǥ����ꤷ�ʤ��Ƥ�
+ư��뤳�Ȥ���ǧ����Ƥ��ޤ�����TGUI9682�Ǥ��Բķ�Ǥ���
+���ꤷ�ʤ����ξ����ޤ�Ʋ��⤷�ޤ��������������꤬��������������
+<verb>
+   Trident : BitBLT engine time-out.
+</verb>
+������ʤ��ΤǤ�����������פǤ���
+�ʤ��������ꤷ�ʤ�����ư�®�����Ȥ�ǰƬ�ˤ����Ʋ���������
+
+<descrip>
+<tag>Option ``NoPciBurst''</tag>
+�ޥ������������뤬�ޥ�����ư�����ɽ��������ޤ��ޥ��������������ư������
+�ˤ��Ρ��ספ��Ĥ�������褵���ʸ���Υɥå�������Ӥ�������������
+��Ǥ���
+<tag>Option ``XaaNoScreenToScreenCopy''</tag>
+�����٤�1024x768�ʲ��Ǥ��������פǤ��������ۤ�������٤ˤ����ƥޥ�����
+�������뤬�ޥ�����ư���˶�ü���ɽ����ʤ�����������Ǥ���
+<tag>Option ``XaaNoCPUToScreenColorExpandFill''</tag>
+ʸ�������褬��ü���٤����ޤ������褷�ʤ�����������Ǥ���
+<tag>Option ``XaaNoScanlineCPUToScreenColorExpandFill''</tag>
+ʸ�������褬��ü���٤����ޤ������褷�ʤ�����������Ǥ���
+<tag>Option ``XaaNoScreenToScreenColorExpandFill''</tag>
+ʸ�������褬��ü���٤����ޤ������褷�ʤ�����������Ǥ���
+</descrip>
+
+<sect2>��𤵤�Ƥ�������<p>
+�������TGUI9682��ͭ��ɽ������������Ǥ���
+<itemize>
+	<ITEM>�ޥ�����ư�����ȡ���������ε��פ���������ޤ���
+	<ITEM>kterm��ǥޥ����κ��ܥ���򲡤��ʤ���ɥ�å�����ȡ�ʸ����
+	ȿž����Ȥ����˲������ΥΥ������Фޤ���
+	<ITEM>kterm��ɽ�������ʸ���ΥɥåȤ���������ޤ���
+</itemize>
+
+<sect2>����¾<p>
+<itemize>
+�ޤ���ʬ�ʥƥ��Ȥ��Ԥ��Ƥ��ʤ��Τ�ư���ݡ��Ȥ򤪴ꤤ���ޤ���
+</itemize>
+
+<sect2>��Ϣ<p>
+README.trident�ϸ�����(4.0)�Ǥ�3.3.6�Ѥ����ƤǤ��ꡢ����˵��ܤ���Ƥ���
+Option��¿���ϻ��ѤǤ��ʤ��Τ����դ��Ʋ�������
+
+<sect>��OS������ջ���<p>
+<sect1>FreeBSD(98)�Ǥ����ջ���<p>
+<itemize>
+	<ITEM>VT switch���Ǥ��ޤ���
+</itemize>
+
+<sect1>NetBSD/pc98�Ǥ����ջ���<p>
+<itemize>
+	<ITEM>�����Ǥ�NetBSD/pc98 1.4.x�����ѤǤ��ʤ��ʤäƤ��ޤ����к�
+	������Ǥ��Τǡ��ä����Ԥ����������ʤ���NetBSD/i386�Ǥ�����Ϥ�
+	��ޤ���
+</itemize>
+
+<sect1>PANIX for 98�Ǥ����ջ���<p>
+<itemize>
+	<ITEM>VT switch���Ǥ��ޤ���
+</itemize>
+
+<sect1>Linux/98�Ǥ����ջ���<p>
+<itemize>
+	<ITEM>2.1.57�Υ����ͥ�Ǥϡ�beta 14�ʹߤǤʤ��ȥ����Ф��ϥ�
+	���åפ��뤳�Ȥ�����ޤ���������򤱤�ˤϡ�root���¤ˤ�dmesg
+	-n 1��¹Ԥ���Ȥ����褦�Ǥ���
+</itemize>
+</article>
diff --git a/sgml/LICENSE.sgml b/sgml/LICENSE.sgml
new file mode 100644
index 0000000..d928d7c
--- /dev/null
+++ b/sgml/LICENSE.sgml
@@ -0,0 +1,688 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+<title>Licenses</title>
+<author>The XFree86 Project</author>
+<date>February 2003</date>
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/LICENSE.sgml,v 1.12 2003/02/24 03:41:16 dawes Exp $
+</ident>
+
+<sect>XFree86 License
+<p>
+XFree86 code without an explicit copyright is covered by the following
+copyright/license:
+
+<p>
+Copyright (C) 1994-2003 The XFree86 Project, Inc.  All Rights Reserved.
+
+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 name of 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 the
+XFree86 Project.
+
+<sect>Other Licenses
+<p>
+Portions of code are covered by the following licenses/copyrights.  See
+individual files for the copyright dates.
+
+<sect1>X/MIT Copyrights
+<p>
+<sect2>X Consortium
+<p>
+Copyright (C) <it>&lt;date&gt;</it> 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 X Consortium, Inc.
+
+<sect2>The Open Group
+<p>
+Copyright <it>&lt;date&gt;</it>  The Open Group
+
+Permission to use, copy, modify, distribute, and sell this software and its
+documentation for any purpose is hereby granted without fee, provided that
+the above copyright notice appear in all copies and that both that
+copyright notice and this permission notice appear in supporting
+documentation.
+
+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
+OPEN GROUP 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 Open Group 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 Open Group.
+
+
+<sect1>Berkeley-based copyrights:
+<p>
+<sect2>General
+<p>
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+<enum>
+<item>Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+<item>Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in the
+    documentation and/or other materials provided with the distribution.
+<item>The name of the author may not be used to endorse or promote products
+    derived from this software without specific prior written permission.
+</enum>
+
+ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+<sect2>UCB/LBL
+<p>
+ Copyright (c) 1993
+      The Regents of the University of California.  All rights reserved.
+
+ This software was developed by the Computer Systems Engineering group
+ at Lawrence Berkeley Laboratory under DARPA contract BG 91-66 and
+ contributed to Berkeley.
+
+ All advertising materials mentioning features or use of this software
+ must display the following acknowledgement:
+      This product includes software developed by the University of
+      California, Lawrence Berkeley Laboratory.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+
+<enum>
+<item>Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+<item>Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in the
+    documentation and/or other materials provided with the distribution.
+<item>All advertising materials mentioning features or use of this software
+    must display the following acknowledgement:
+      This product includes software developed by the University of
+      California, Berkeley and its contributors.
+<item>Neither the name of the University nor the names of its contributors
+    may be used to endorse or promote products derived from this software
+    without specific prior written permission.
+</enum>
+
+ THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ SUCH DAMAGE.
+
+<sect1>NVIDIA Corp
+<p>
+         Copyright (c) 1996 NVIDIA, Corp.  All rights reserved.        
+                                                                      
+    NOTICE TO USER: The source code is copyrighted under U.S. and
+    international laws.  NVIDIA, Corp. of Sunnyvale, California owns
+    the copyright and as design patents pending on the design and
+    interface of the NV chips.  Users and possessors of this source
+    code are hereby granted a nonexclusive, royalty-free copyright
+    and design patent license to use this code in individual and
+    commercial software.
+
+    Any use of this source code must include, in the user documentation
+    and internal comments to the code, notices to the end user
+    as follows:
+
+    Copyright (c) 1996 NVIDIA, Corp.  NVIDIA design patents pending
+    in the U.S. and foreign countries.
+
+    NVIDIA, CORP.  MAKES NO REPRESENTATION ABOUT THE SUITABILITY OF
+    THIS SOURCE CODE FOR ANY PURPOSE.  IT IS PROVIDED "AS IS" WITHOUT
+    EXPRESS OR IMPLIED WARRANTY OF ANY KIND.  NVIDIA, CORP. DISCLAIMS
+    ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, INCLUDING ALL
+    IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+    PARTICULAR PURPOSE.  IN NO EVENT SHALL NVIDIA, CORP.  BE LIABLE
+    FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
+    OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+    PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+    TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+    PERFORMANCE OF THIS SOURCE CODE.
+
+<sect1>GLX Public License
+<p>
+GLX PUBLIC LICENSE (Version 1.0 (2/11/99)) ("License")
+
+Subject to any third party claims, Silicon Graphics, Inc. ("SGI") hereby
+grants permission to Recipient (defined below), under Recipient's
+copyrights in the Original Software (defined below), to use, copy,
+modify, merge, publish, distribute, sublicense and/or sell copies of
+Subject Software (defined below), and to permit persons to whom the
+Subject Software is furnished in accordance with this License to do the
+same, subject to all of the following terms and conditions, which
+Recipient accepts by engaging in any such use, copying, modifying,
+merging, publishing, distributing, sublicensing or selling:
+
+1. Definitions.
+
+<quote>
+    (a) "Original Software" means source code of computer software code
+    which is described in Exhibit A as Original Software.
+</quote>
+ 
+<quote>
+    (b) "Modifications" means any addition to or deletion from the
+    substance or structure of either the Original Software or any
+    previous Modifications. When Subject Software is released as a
+    series of files, a Modification means (i) any addition to or
+    deletion from the contents of a file containing Original Software or
+    previous Modifications and (ii) any new file that contains any part
+    of the Original Code or previous Modifications.
+</quote>
+
+<quote>
+    (c) "Subject Software" means the Original Software or Modifications
+    or the combination of the Original Software and Modifications, or
+    portions of any of the foregoing.
+</quote>
+
+<quote>
+    (d) "Recipient" means an individual or a legal entity exercising
+    rights under, and complying with all of the terms of, this License.
+    For legal entities, "Recipient" includes any entity which controls,
+    is controlled by, or is under common control with Recipient. For
+    purposes of this definition, "control" of an entity means (a) the
+    power, direct or indirect, to direct or manage such entity, or (b)
+    ownership of fifty percent (50%) or more of the outstanding shares
+    or beneficial ownership of such entity.
+</quote>
+
+2. Redistribution of Source Code Subject to These Terms. Redistributions
+of Subject Software in source code form must retain the notice set forth
+in Exhibit A, below, in every file. A copy of this License must be
+included in any documentation for such Subject Software where the
+recipients' rights relating to Subject Software are described. Recipient
+may distribute the source code version of Subject Software under a
+license of Recipient's choice, which may contain terms different from
+this License, provided that (i) Recipient is in compliance with the
+terms of this License, and (ii) the license terms include this Section 2
+and Sections 3, 4, 7, 8, 10, 12 and 13 of this License, which terms may
+not be modified or superseded by any other terms of such license. If
+Recipient distributes the source code version under a different license
+Recipient must make it absolutely clear that any terms which differ from
+this License are offered by Recipient alone, not by SGI. Recipient
+hereby agrees to indemnify SGI for any liability incurred by SGI as a
+result of any such terms Recipient offers.
+
+3. Redistribution in Executable Form. The notice set forth in Exhibit A
+must be conspicuously included in any notice in an executable version of
+Subject Software, related documentation or collateral in which Recipient
+describes the user's rights relating to the Subject Software. Recipient
+may distribute the executable version of Subject Software under a
+license of Recipient's choice, which may contain terms different from
+this License, provided that (i) Recipient is in compliance with the
+terms of this License, and (ii) the license terms include this Section 3
+and Sections 4, 7, 8, 10, 12 and 13 of this License, which terms may not
+be modified or superseded by any other terms of such license. If
+Recipient distributes the executable version under a different license
+Recipient must make it absolutely clear that any terms which differ from
+this License are offered by Recipient alone, not by SGI. Recipient
+hereby agrees to indemnify SGI for any liability incurred by SGI as a
+result of any such terms Recipient offers.
+
+4. Termination. This License and the rights granted hereunder will
+terminate automatically if Recipient fails to comply with terms herein
+and fails to cure such breach within 30 days of the breach. Any
+sublicense to the Subject Software which is properly granted shall
+survive any termination of this License absent termination by the terms
+of such sublicense. Provisions which, by their nature, must remain in
+effect beyond the termination of this License shall survive.
+
+5. No Trademark Rights. This License does not grant any rights to use
+any trade name, trademark or service mark whatsoever. No trade name,
+trademark or service mark of SGI may be used to endorse or promote
+products derived from the Subject Software without prior written
+permission of SGI.
+
+6. No Other Rights. This License does not grant any rights with respect
+to the OpenGL API or to any software or hardware implementation thereof
+or to any other software whatsoever, nor shall any other rights or
+licenses not expressly granted hereunder arise by implication, estoppel
+or otherwise with respect to the Subject Software. Title to and
+ownership of the Original Software at all times remains with SGI. All
+rights in the Original Software not expressly granted under this License
+are reserved.
+
+7. Compliance with Laws; Non-Infringement. Recipient shall comply with
+all applicable laws and regulations in connection with use and
+distribution of the Subject Software, including but not limited to, all
+export and import control laws and regulations of the U.S. government
+and other countries. Recipient may not distribute Subject Software that
+(i) in any way infringes (directly or contributorily) the rights
+(including patent, copyright, trade secret, trademark or other
+intellectual property rights of any kind) of any other person or entity
+or (ii) breaches any representation or warranty, express, implied or
+statutory, which under any applicable law it might be deemed to have
+been distributed.
+
+8. Claims of Infringement. If Recipient at any time has knowledge of any
+one or more third party claims that reproduction, modification, use,
+distribution, import or sale of Subject Software (including particular
+functionality or code incorporated in Subject Software) infringes the
+third party's intellectual property rights, Recipient must place in a
+well-identified web page bearing the title "LEGAL" a description of each
+such claim and a description of the party making each such claim in
+sufficient detail that a user of the Subject Software will know whom to
+contact regarding the claim. Also, upon gaining such knowledge of any
+such claim, Recipient must conspicuously include the URL for such web
+page in the Exhibit A notice required under Sections 2 and 3, above, and
+in the text of any related documentation, license agreement or
+collateral in which Recipient describes end user's rights relating to
+the Subject Software. If Recipient obtains such knowledge after it makes
+Subject Software available to any other person or entity, Recipient
+shall take other steps (such as notifying appropriate mailing lists or
+newsgroups) reasonably calculated to inform those who received the
+Subject Software that new knowledge has been obtained.
+
+9. DISCLAIMER OF WARRANTY. SUBJECT SOFTWARE IS PROVIDED ON AN "AS IS"
+BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE SUBJECT SOFTWARE IS
+FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-
+INFRINGING. SGI ASSUMES NO RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+SOFTWARE. SHOULD ANY SOFTWARE PROVE DEFECTIVE IN ANY RESPECT, SGI
+ASSUMES NO COST OR LIABILITY FOR ANY SERVICING, REPAIR OR CORRECTION.
+THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS
+LICENSE. NO USE OF ANY SUBJECT SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT
+UNDER THIS DISCLAIMER.
+
+10. LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL
+THEORY, WHETHER TORT (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE OR
+STRICT LIABILITY), CONTRACT, OR OTHERWISE, SHALL SGI OR ANY SGI LICENSOR
+BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
+CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION,
+DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, LOSS OF DATA, COMPUTER
+FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR
+LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY
+OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY SHALL NOT APPLY TO
+LIABILITY FOR DEATH OR PERSONAL INJURY RESULTING FROM SGI's NEGLIGENCE
+TO THE EXTENT APPLICABLE LAW PROHIBITS SUCH LIMITATION. SOME
+JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR
+CONSEQUENTIAL DAMAGES, SO THAT EXCLUSION AND LIMITATION MAY NOT APPLY TO
+RECIPIENT.
+
+11. Indemnity. Recipient shall be solely responsible for damages
+arising, directly or indirectly, out of its utilization of rights under
+this License. Recipient will defend, indemnify and hold harmless Silicon
+Graphics, Inc. from and against any loss, liability, damages, costs or
+expenses (including the payment of reasonable attorneys fees) arising
+out of Recipient's use, modification, reproduction and distribution of
+the Subject Software or out of any representation or warranty made by
+Recipient.
+
+12. U.S. Government End Users. The Subject Software is a "commercial
+item" consisting of "commercial computer software" as such terms are
+defined in title 48 of the Code of Federal Regulations and all U.S.
+Government End Users acquire only the rights set forth in this License
+and are subject to the terms of this License.
+
+13. Miscellaneous. This License represents the complete agreement
+concerning subject matter hereof. If any provision of this License is
+held to be unenforceable, such provision shall be reformed so as to
+achieve as nearly as possible the same economic effect as the original
+provision and the remainder of this License will remain in effect. This
+License shall be governed by and construed in accordance with the laws
+of the United States and the State of California as applied to
+agreements entered into and to be performed entirely within California
+between California residents. Any litigation relating to this License
+shall be subject to the exclusive jurisdiction of the Federal Courts of
+the Northern District of California (or, absent subject matter
+jurisdiction in such courts, the courts of the State of California),
+with venue lying exclusively in Santa Clara County, California, with the
+losing party responsible for costs, including without limitation, court
+costs and reasonable attorneys fees and expenses. The application of the
+United Nations Convention on Contracts for the International Sale of
+Goods is expressly excluded. Any law or regulation which provides that
+the language of a contract shall be construed against the drafter shall
+not apply to this License.
+
+Exhibit A
+
+The contents of this file are subject to Sections 2, 3, 4, 7, 8, 10, 12
+and 13 of the GLX Public License Version 1.0 (the "License"). You may
+not use this file except in compliance with those sections of the
+License. You may obtain a copy of the License at Silicon Graphics, Inc.,
+attn: Legal Services, 2011 N. Shoreline Blvd., Mountain View, CA 94043
+or at http://www.sgi.com/software/opensource/glx/license.html.
+
+Software distributed under the License is distributed on an "AS IS"
+basis. ALL WARRANTIES ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY
+IMPLIED WARRANTIES OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR
+PURPOSE OR OF NON- INFRINGEMENT. See the License for the specific
+language governing rights and limitations under the License.
+
+The Original Software is GLX version 1.2 source code, released February,
+1999. The developer of the Original Software is Silicon Graphics, Inc.
+Those portions of the Subject Software created by Silicon Graphics, Inc.
+are Copyright (c) 1991-9 Silicon Graphics, Inc. All Rights Reserved.
+
+<sect1>CID Font Code Public License
+<p>
+CID FONT CODE PUBLIC LICENSE (Version 1.0 (3/31/99))("License")
+
+Subject to any applicable third party claims, Silicon Graphics, Inc. ("SGI")
+hereby grants permission to Recipient (defined below), under SGI's copyrights
+in the Original Software (defined below), to use, copy, modify, merge, publish,
+distribute, sublicense and/or sell copies of Subject Software (defined below)
+in both source code and executable form, and to permit persons to whom the
+Subject Software is furnished in accordance with this License to do the same,
+subject to all of the following terms and conditions, which Recipient accepts
+by engaging in any such use, copying, modifying, merging, publication, 
+distributing, sublicensing or selling:
+
+1. Definitions.
+<quote>
+        a. "Original Software" means source code of computer software code
+           that is described in Exhibit A as Original Software.
+</quote>
+
+<quote>
+        b. "Modifications" means any addition to or deletion from the
+           substance or structure of either the Original Software or any 
+           previous Modifications. When Subject Software is released as a 
+           series of files, a Modification means (i) any addition to or 
+           deletion from the contents of a file containing Original Software
+           or previous Modifications and (ii) any new file that contains any
+           part of the Original Code or previous Modifications. 
+</quote>
+
+<quote>
+        c. "Subject Software" means the Original Software or Modifications 
+           or the combination of the Original Software and Modifications, or
+           portions of any of the foregoing. 
+</quote>
+
+<quote>
+        d. "Recipient" means an individual or a legal entity exercising 
+           rights under the terms of this License. For legal entities, 
+           "Recipient" includes any entity that controls, is controlled by, 
+           or is under common control with Recipient. For purposes of this
+           definition, "control" of an entity means (i) the power, direct or 
+           indirect, to direct or manage such entity, or (ii) ownership of
+           fifty percent (50%) or more of the outstanding shares or 
+           beneficial ownership of such entity.
+</quote>
+
+<quote>
+        e. "Required Notice" means the notice set forth in Exhibit A to this
+           License. 
+</quote>
+
+<quote>
+        f. "Accompanying Technology" means any software or other technology
+           that is not a Modification and that is distributed or made 
+           publicly available by Recipient with the Subject Software. 
+           Separate software files that do not contain any Original Software
+           or any previous Modification shall not be deemed a Modification, 
+           even if such software files are aggregated as part of a product, 
+           or in any medium of storage, with any file that does contain 
+           Original Software or any previous Modification.
+</quote>
+
+  2. License Terms. All distribution of the Subject Software must be made
+     subject to the terms of this License. A copy of this License and the 
+     Required Notice must be included in any documentation for Subject 
+     Software where Recipient's rights relating to Subject Software and/or
+     any Accompanying Technology are described. Distributions of Subject 
+     Software in source code form must also include the Required Notice in 
+     every file distributed. In addition, a ReadMe file entitled "Important
+     Legal Notice" must be distributed with each distribution of one or more
+     files that incorporate Subject Software. That file must be included with 
+     distributions made in both source code and executable form. A copy of 
+     the License and the Required Notice must be included in that file.
+     Recipient may distribute Accompanying Technology under a license of
+     Recipient's choice, which may contain terms different from this License,
+     provided that (i) Recipient is in compliance with the terms of this 
+     License, (ii) such other license terms do not modify or supersede the 
+     terms of this License as applicable to the Subject Software, (iii) 
+     Recipient hereby indemnifies SGI for any liability incurred by SGI as a
+     result of the distribution of Accompanying Technology or the use of 
+     other license terms.
+
+  3. Termination. This License and the rights granted hereunder will 
+     terminate automatically if Recipient fails to comply with terms herein
+     and fails to cure such breach within 30 days of the breach. Any 
+     sublicense to the Subject Software that is properly granted shall 
+     survive any termination of this License absent termination by the terms
+     of such sublicense. Provisions which, by their nature, must remain in
+     effect beyond the termination of this License shall survive.
+
+  4. Trademark Rights. This License does not grant any rights to use any 
+     trade name, trademark or service mark whatsoever. No trade name, 
+     trademark or service mark of SGI may be used to endorse or promote 
+     products derived from or incorporating any Subject Software without 
+     prior written permission of SGI.
+
+  5. No Other Rights. No rights or licenses not expressly granted hereunder 
+     shall arise by implication, estoppel or otherwise. Title to and 
+     ownership of the Original Software at all times remains with SGI. All 
+     rights in the Original Software not expressly granted under this 
+     License are reserved.
+
+  6. Compliance with Laws; Non-Infringement. Recipient shall comply with all
+     applicable laws and regulations in connection with use and distribution
+     of the Subject Software, including but not limited to, all export and 
+     import control laws and regulations of the U.S. government and other 
+     countries. Recipient may not distribute Subject Software that (i) in any
+     way infringes (directly or contributorily) the rights (including patent,
+     copyright, trade secret, trademark or other intellectual property rights
+     of any kind) of any other person or entity, or (ii) breaches any 
+     representation or warranty, express, implied or statutory, which under
+     any applicable law it might be deemed to have been distributed. 
+
+  7. Claims of Infringement. If Recipient at any time has knowledge of any 
+     one or more third party claims that reproduction, modification, use, 
+     distribution, import or sale of Subject Software (including particular
+     functionality or code incorporated in Subject Software) infringes the 
+     third party's intellectual property rights, Recipient must place in a
+     well-identified web page bearing the title "LEGAL" a description of 
+     each such claim and a description of the party making each such claim in
+     sufficient detail that a user of the Subject Software will know whom to 
+     contact regarding the claim. Also, upon gaining such knowledge of any 
+     such claim, Recipient must conspicuously include the URL for such web
+     page in the Required Notice, and in the text of any related 
+     documentation, license agreement or collateral in which Recipient 
+     describes end user's rights relating to the Subject Software. If
+     Recipient obtains such knowledge after it makes Subject Software 
+     available to any other person or entity, Recipient shall take other 
+     steps (such as notifying appropriate mailing lists or newsgroups) 
+     reasonably calculated to provide such knowledge to those who received
+     the Subject Software.
+
+  8. DISCLAIMER OF WARRANTY. SUBJECT SOFTWARE IS PROVIDED ON AN "AS IS"
+     BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 
+     INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE SUBJECT SOFTWARE IS 
+     FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR 
+     NON-INFRINGING. SGI ASSUMES NO RISK AS TO THE QUALITY AND PERFORMANCE 
+     OF THE SOFTWARE. SHOULD ANY SOFTWARE PROVE DEFECTIVE IN ANY RESPECT, SGI
+     ASSUMES NO COST OR LIABILITY FOR ANY SERVICING, REPAIR OR CORRECTION. 
+     THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS 
+     LICENSE. NO USE OF ANY SUBJECT SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT
+     UNDER THIS DISCLAIMER.
+
+  9. LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL 
+     THEORY, WHETHER TORT (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE OR 
+     STRICT LIABILITY), CONTRACT, OR OTHERWISE, SHALL SGI OR ANY SGI LICENSOR
+     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 SUBJECT SOFTWARE OR THE USE OR OTHER DEALINGS IN
+     THE SUBJECT SOFTWARE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR
+     LIMITATION OF CERTAIN DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT
+     APPLY TO RECIPIENT TO THE EXTENT SO DISALLOWED. 
+
+ 10. Indemnity. Recipient shall be solely responsible for damages arising, 
+     directly or indirectly, out of its utilization of rights under this 
+     License. Recipient will defend, indemnify and hold SGI and its 
+     successors and assigns harmless from and against any loss, liability, 
+     damages, costs or expenses (including the payment of reasonable 
+     attorneys fees) arising out of (Recipient's use, modification, 
+     reproduction and distribution of the Subject Software or out of any 
+     representation or warranty made by Recipient.
+
+ 11. U.S. Government End Users. The Subject Software is a "commercial item" 
+     consisting of "commercial computer software" as such terms are defined
+     in title 48 of the Code of Federal Regulations and all U.S. Government
+     End Users acquire only the rights set forth in this License and are 
+     subject to the terms of this License.
+
+ 12. Miscellaneous. This License represents the complete agreement concerning
+     subject matter hereof. If any provision of this License is held to be 
+     unenforceable by any judicial or administrative authority having proper 
+     jurisdiction with respect thereto, such provision shall be reformed so 
+     as to achieve as nearly as possible the same economic effect as the 
+     original provision and the remainder of this License will remain in 
+     effect. This License shall be governed by and construed in accordance 
+     with the laws of the United States and the State of California as 
+     applied to agreements entered into and to be performed entirely within 
+     California between California residents. Any litigation relating to 
+     this License shall be subject to the exclusive jurisdiction of the 
+     Federal Courts of the Northern District of California (or, absent 
+     subject matter jurisdiction in such courts, the courts of the State of
+     California), with venue lying exclusively in Santa Clara County, 
+     California, with the losing party responsible for costs, including
+     without limitation, court costs and reasonable attorneys fees and 
+     expenses. The application of the United Nations Convention on Contracts
+     for the International Sale of Goods is expressly excluded. Any law or 
+     regulation that provides that the language of a contract shall be 
+     construed against the drafter shall not apply to this License.
+
+Exhibit A
+
+Copyright (c) 1994-1999 Silicon Graphics, Inc.
+
+The contents of this file are subject to the CID Font Code Public License
+Version 1.0 (the "License"). You may not use this file except in compliance 
+with the License. You may obtain a copy of the License at Silicon Graphics, 
+Inc., attn: Legal Services, 2011 N. Shoreline Blvd., Mountain View, CA 94043
+or at http://www.sgi.com/software/opensource/cid/license.html
+
+Software distributed under the License is distributed on an "AS IS" basis. 
+ALL WARRANTIES ARE DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED 
+WARRANTIES OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE OR OF
+NON-INFRINGEMENT. See the License for the specific language governing rights
+and limitations under the License.
+
+The Original Software (as defined in the License) is CID font code that was 
+developed by Silicon Graphics, Inc. Those portions of the Subject Software
+(as defined in the License) that were created by Silicon Graphics, Inc. are
+Copyright (c) 1994-1999 Silicon Graphics, Inc. All Rights Reserved.
+
+[NOTE: When using this text in connection with Subject Software delivered 
+solely in object code form, Recipient may replace the words "this file" with
+"this software" in both the first and second sentences.]
+
+<sect1>Bigelow &amp; Holmes Inc and URW++ GmbH Luxi font license
+<p>
+
+Luxi fonts copyright (c) 2001 by Bigelow &amp; Holmes Inc. Luxi font 
+instruction code copyright (c) 2001 by URW++ GmbH. All Rights 
+Reserved. Luxi is a registered trademark of Bigelow &amp; Holmes Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining 
+a copy of these Fonts and associated documentation files (the "Font 
+Software"), to deal in the Font Software, including without 
+limitation the rights to use, copy, merge, publish, distribute, 
+sublicense, and/or sell copies of the Font Software, and to permit 
+persons to whom the Font Software is furnished to do so, subject to 
+the following conditions:
+
+The above copyright and trademark notices and this permission notice 
+shall be included in all copies of one or more of the Font Software.
+
+The Font Software may not be modified, altered, or added to, and in 
+particular the designs of glyphs or characters in the Fonts may not 
+be modified nor may additional glyphs or characters be added to the 
+Fonts. This License becomes null and void when the Fonts or Font 
+Software have been modified.
+
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF 
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT 
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT.  IN NO EVENT SHALL 
+BIGELOW &amp; HOLMES INC. OR URW++ GMBH. BE LIABLE FOR ANY CLAIM, DAMAGES 
+OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, 
+INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF 
+CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR 
+INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT 
+SOFTWARE.
+
+Except as contained in this notice, the names of Bigelow &amp; Holmes 
+Inc. and URW++ GmbH. shall not be used in advertising or otherwise to 
+promote the sale, use or other dealings in this Font Software without 
+prior written authorization from Bigelow &amp; Holmes Inc. and URW++ GmbH.
+
+For further information, contact:
+
+info@urwpp.de
+or
+design@bigelowandholmes.com
+
+</article>
diff --git a/sgml/OS2Notes.sgml b/sgml/OS2Notes.sgml
new file mode 100644
index 0000000..6bdc7d1
--- /dev/null
+++ b/sgml/OS2Notes.sgml
@@ -0,0 +1,209 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+<article>
+
+<title>Notes on Rebuilding XFree86/OS2 from Scratch
+<author>Holger Veit
+<date>Last modified March 8th, 2000
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2Notes.sgml,v 1.2 2003/01/04 04:20:23 dawes Exp $
+</ident>
+
+<toc>
+
+<sect>Preface
+<p>
+X11 and XFree86 were initially developed on Unix-based systems. Usually
+Unix systems provide a rich number of tools and utilities to get certain
+things done. Under OS/2, these tools are not installed, but ports are
+available which are sometimes functionally equivalent to Unix utilities
+with the same name, but also differ sometimes in a subtle way.
+This guide will give you hints if you intend to rebuild the system
+from scratch under OS/2.
+<p>
+Please also read <htmlurl name=README.OS2 url=OS2.html> for end-user
+information, and set at least the environment variables described there.
+<p>
+At the current time, the most recent version available is XFree86-4.0.
+This is a full and unrestricted version which comes with complete source 
+code. 4.0 is a highly experimental release, so many features that might
+have worked in earlier versions, may now no longer work, or work differently.
+Be aware that for OS/2, XFree86-4.0 is considered to be alpha software.
+
+If you want to join the XFree86 developer team, e.g. to add support for
+certain hardware, please send a request to <email>BOD@XFree86.org</email>.
+Please think about such a step carefully before, though, since much work
+is involved. Please use the XFree86-4.0 source code as a test example
+how to compile the system. The ability to manage that is a basic
+requirement for becoming a developer.
+
+
+<sect>Tools required
+<p>
+
+I have tried to reduce the number of external tools, but when looking back
+it seems I were not very successful. At least I managed to get everything
+working with the native CMD.EXE shell only. However, there is still plenty
+of software required.
+Most of this software is available from <tt/hobbes.nmsu.edu/ or <tt/ftp.leo.org/
+via anonymous FTP. The following shopping list shows what you will need:
+
+<itemize>
+<item>gcc	EMX/gcc emx 0.9C patch4 or later (0.9d preferred!)
+<item>gzip	GNU zip/unzip
+<item>tar	GNU tar
+<item>patch	Larry Wall's patch utility (attention: incompatible tool with same name in OS/2)
+<item>install	BSD/GNU install
+<item>rm,mv,cp	GNU file utilities
+<item>tee,..	GNU shell utilities
+<item>groff	GNU nroff/troff
+<item>sed	GNU sed stream editor
+<item>grep	GNU grep
+<item>gawk	GNU awk
+<item>make	GNU make 3.71/3.72 (use the one from Xprog.zip!)
+<item>flex	GNU flex
+<item>bison	GNU bison
+<item>m4	GNU m4
+<item>find	GNU find    (attention: incompatible tool with the same name in OS/2)
+</itemize>
+
+If there is no version number given, any new version will do. Particularly
+critical is only EMX/gcc and GNU make. Note that the second GCC implementation
+which might still be available from some archives is NOT compatible.
+
+Furthermore, you need the XFree86 sources. These are available from 
+the common XFree86 repositories. Look into a directory which is 
+often named /pub/XFree86/4.0/source.
+
+<sect>Compiling and Installing
+<p>
+
+You need about 300MB of free HPFS space for the whole system. This does not
+include space for the postscript and troff documentation files. I have never
+installed them. Nor did I install the test subtree.
+
+<enum>
+<item>Install all the above utilities. Refer to the corresponding documentation.
+      Verify that everything works well, particularly EMX.
+<item>It is a good idea to use the same or a similar structure I have.
+      I have made a directory <tt>&bsol;x11</tt> on the partition for compiling and have
+      put everything below this tree. I found that a clean tree occupies
+      less than the half space of the disk, this gives me the opportunity to
+      rename this tree to <tt>&bsol;x11old</tt> and copy a new version to the
+      same disk to produce diffs. Last time the complete tree was
+      arranged under the root directory <tt>xc</tt>, this would become 
+      <tt>&bsol;x11&bsol;xc</tt> then.
+<item>To unpack the files you would usually execute the command
+      <verb>gzip -dc file.tar.gz | tar xvf -</verb> 
+      in the <tt>&bsol;x11</tt> directory. At the end you will usually see the
+      irritating, but non-fatal message "gzip: stdout Broken pipe". Ignore it.
+<item>After that, is is likely necessary to apply some patches, either from
+      the XConsortium or from the XFree86 project. Before you do this, enter
+      <verb>
+      chmod -R a+rw &bsol;x11&bsol;xc
+      </verb> 
+      to make certain files in the tree writable.
+<item>There should be a file <tt>added-XXX</tt> accompanying the patch file
+      which lists the files that are newly created. The patch program has
+      a problem with creating new directories, so we need to create them
+      on advance. For each <tt/added-XXX/ file you find, execute from
+      <tt>&bsol;x11</tt> <verb>xc&bsol;config&bsol;util&bsol;added added-XXX</verb>
+      If there is no <tt>added-XXX</tt> file available, you can make one with
+      the following instructions:
+      <verb>
+      grep "&bsol;*&bsol;*&bsol;* xc/" patchfile >added-file
+      </verb>
+      Edit <tt/added-file/ with a text editor and remove the <tt/*** / at
+      the beginning and the time stamp at the end (search for a TAB and
+      erase to the end of the line). You get a list of file paths, one in a
+      line, which is the input to the added utility.
+<item>After that you can apply the patches in the right order. Usually this
+      is done by a command
+      <verb>
+      patch -p -E <patchfile 2>&1 | tee patchlog
+      </verb>
+      from the <tt>&bsol;x11</tt> directory. Be aware to use the right
+      patch - OS/2 has a utility with the same name and different functionality.
+      Don't use the recommended <tt/-s/ option, this makes <tt/patch/ quiet,
+      and you won't see problems in the patchlog file. Use
+      <verb>
+      find &bsol;x11 -name *.rej -print 
+      find &bsol;x11 -name *# -print
+      </verb>
+      to find any rejects and unapplied patches (attention: yet another OS/2
+      program with wrong functionality). Normally there shouldn't
+      be any problems of this kind, else you have made a mistake. Finally
+      remove the original files with
+      <verb>
+      find &bsol;x11 -name *.orig -print -exec rm {} ;
+      </verb>
+<item>Go to the <tt>xc/config/cf</tt> directory and edit the <tt>xf86site.def</tt>
+      file to match your requirements (you probably don't want to compile
+      all X servers). Certain changes must be set to the following values:
+      <itemize>
+      <item>Disable if not already done any PC98 server; PC98 (Japanese XFree86)
+            does not work yet. Porters from Japan are welcome!
+      <item><tt>&num;define WacomSupport            NO
+            &num;define ElographicsSupport      NO</tt>
+            Both options are not yet supported.
+      <item>Tcl* and Tk* don't need to be set explicitly. Reasonable defaults
+            are in the other config files, provided you have a complete 
+            XFree86/OS2 binary tree with the tcl/tk runtime support installed.
+      <item><tt>&num;define BuildDynamicLoading   NO</tt>
+	    This does not work.
+      </itemize>
+<item>Go to the directory <tt>xc&bsol;util&bsol;compress</tt> and 
+      <tt>make compress.exe</tt> there. Install the program produced 
+      there in your path. I stumbled more than once on half-ported
+      compress programs on OS/2 ftp servers that are defective w.r.t.
+      reading and writing stdin/stdout. In some stage (font compression)
+      otherwise you will get a core dump of mkfontdir, because all
+      compressed fonts are corrupt.
+<item>Set the environment variable <tt/X11ROOT/ to something different than
+      it is; otherwise the installation process will overwrite your
+      original XFree86/OS2 installation. If you have not set this variable,
+      go back to the prefix section of this document: you have forgotten
+      something.
+<item>Copy the file <tt>xc/programs/Xserver/hw/xfree86/etc/bindist/OS2/host.def.os2</tt>
+      to the location <tt>xc/config/cf/host.def</tt>. Use this file to do
+      any specific modifications to imake variables, rather than editing
+      the file xfree86.cf, imake.tmpl, or os2.cf directly.
+<item>Copy the file <tt>xc/config/util/buildos2.cmd</tt> into the <tt/xc/
+      directory. If this is a second or later attempt, you might need to
+      copy the saved toplevel Makefile.os2 back to Makefile.
+<item>Execute this <tt/buildos2.cmd/ command in the <tt/xc/ directory;
+      it will produce a logfile <tt>buildxc.log</tt> in this directory.
+<item>Go have a bucket of coffee, or better, buy new coffee - in Colombia!
+      The compile will need between 2 and 20 hours, depending on your
+      selections, and the horse power of your hardware.
+<item>When finished, view the logfile for errors, and fix the problems if
+      there are some. I have managed to compile the whole system
+      flawlessly, so there is at least one configuration that works.
+<item>Finally, from the <tt/xc/ dir, execute
+      <verb>
+      xmake install
+      xmake install.man
+      </verb>
+<item>There are a few minor glitches in the installation:
+<enum>
+<item>The xdm and linkkit directories will fail in compile and installation.
+      This is no problem and has no effect on the rest of the system.
+<item>The imake.exe which is installed in <tt/&bsol;XFree86&bsol;bin/ is usually defective.
+      The one which was built initially and installed in the root directory
+      of the drive where you have the source tree is okay. So simply copy
+      this <tt/&bsol;imake.exe/ to the <tt/&bsol;XFree86&bsol;bin/ directory 
+      manually. Some day this might be fixed.
+<item><tt/XF86Setup/ is not ported yet and won't work with the tcl/tk port
+      available for XFree86/OS2. My idea was to replace this by some native
+      installation tool, which I didn't find the time to do yet. Feel free
+      to spend a bit of time to play with XF86Setup if you like.
+</enum>
+</enum>
+
+Well, you see, this was quite easy :-)
+
+
+
+
+
+</article>
diff --git a/sgml/RELNOTES.sgml b/sgml/RELNOTES.sgml
new file mode 100644
index 0000000..4fb915d
--- /dev/null
+++ b/sgml/RELNOTES.sgml
@@ -0,0 +1,1225 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+
+<title>Release Notes for XFree86&trade; &relvers;
+<author>The XFree86 Project, Inc
+<date>26 February 2003
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.81 2003/02/27 00:45:05 dawes Exp $
+</ident>
+
+<abstract>
+
+This document contains some information about features present
+in XFree86 &relvers; and their status.
+
+</abstract>
+
+<toc>
+
+<p>
+
+<sect>Introduction to the 4.x Release Series
+<p>
+XFree86 4.0 was the first official release of the new XFree86 4 series.
+<![ %updaterel [
+XFree86 &relvers; is the &whichupdaterel; update to &fullrelvers;, which
+is the latest full release in that series.
+]]>
+<![ %fullrel [
+The current release (&relvers;) is the latest in that series.
+]]>
+XFree86
+4 represents a significant redesign of the XFree86 X server.  Not all
+of the hardware drivers from 3.3.x have been ported to 4.x yet, but
+conversely, 4.x has support for a lot of hardware that is not supported
+in 3.3.x.  Our <htmlurl name="Driver Status document" url="Status.html">
+summarizes how the hardware driver support compares between &legacyvers;
+and &relvers;.  Please check there first before downloading &relvers;.
+
+The 4.0.1 release introduced a new graphical configuration tool,
+"<tt>xf86cfg</tt>", and a text mode interface was added to it for the
+4.0.2 release.  It is the preferred configuration tool provided by with
+XFree86.  The trusty old text-based tool "<tt>xf86config</tt>" can also
+be used for generating X server config files.  In addition to these
+tools, the XFree86 server has some built in capabilities for generating
+a base config file.  This works well for most hardware, and in most
+cases is the easiest way to get an initial config file.  To try it out,
+just run (as root):
+
+<tscreen><verb>
+XFree86 -configure
+</verb></tscreen>
+
+Each of these configuration options will give you a reasonable starting
+point for a suitable configuration file.  We've put some effort into
+documenting the &relvers; config file format, and you can find that
+information in the <htmlurl name="XF86Config manual page"
+url="XF86Config.5.html">.  Check there and the driver-specific manual
+pages and the related documentation for further information.  References
+to this driver-specific information can be found in the <ref id="drivertables"
+name="tables below">.
+
+We have plans to make the configuration file optional in a future release.
+The XFree86 server is close to being able to automatically determine
+a complete base configuration for most popular hardware configurations.
+
+Before you go to download and install the binary distributions for
+this release, please have a quick read through the <htmlurl
+name="Installation Document" url="Install.html">.  It may save you some
+time and help you figure out which of the binary releases you need.
+
+<![ %updaterel [
+The next sections describe what has changed in the update release(s)
+as well as what is new in the latest full release (&fullrelvers;).
+]]>
+<![ %fullrel [
+The next section describes what is new in the latest version (&relvers;)
+compared with the previous full release (&prevfullrelvers).
+]]>
+The other sections below describe some of the new features and changes
+between 3.3.x and 4.0.  There are lot's of new features, and we definitely
+don't have enough space to cover them all here.
+
+</sect>
+
+<![ %updaterel [
+<sect>Summary of updates in &relvers;.
+<p>
+
+</sect>
+]]>
+
+<sect>Summary of new features in &fullrelvers;.
+
+<sect1>Video Driver Enhancements
+
+<p>
+<itemize>
+<item> ATI Radeon 9x00 2D support added, and 3D support added for the
+	Radeon 8500, 9000, 9100, and M9.  The 3D support for the Radeon
+	now includes hardware TCL.
+
+<item> Support added to the i810 driver for Intel 845G, 852GM, 855GM
+	and 865G integrated graphics chipsets, including 2D, 3D (DRI)
+	and XVideo.  Support for the 830M has been improved, and XVideo
+	support added.
+
+<item> National Semiconductor SC1x00, GX1, and GX2 chipset support added
+	with the "nsc" driver.
+
+<item> Support added for the NVIDIA nForce2 integrated graphics, GeForce 4,
+	and GeForce FX.
+
+<item> Major SiS driver updates for some of the latest chipsets.  Unfortunately
+	the SiS 3D driver has had to be disabled because no one has yet
+	taken up the challenge to port it to Mesa 4.x.
+
+<item> The s3virge driver now has support for double scan modes on the DX
+	(with XVideo disabled).
+	
+<item> Updates to the savage driver, including fixing problems with the
+	TwisterK, and problems with incorrect memory size detection.
+
+<item> 2D acceleration added for the Trident CyberBladeXP/Ai1 chipsets.
+
+<item> Support for big endian architectures has been added to the C&amp;T
+	driver.
+
+<item> Various updates and bug fixes have been made to most other drivers.
+
+</itemize>
+
+<sect1>Input Driver Enhancements
+
+<p>
+<itemize>
+<item> The mouse driver now has automatic protocol detection for PS/2 mice.
+
+<item> Several new input drivers have been added, including tek4957,
+	jamstudio (js_x), fpit, palmax, and ur98 (Linux only).
+</itemize>
+
+<sect1>X Server and Extension Updates
+
+<p>
+<itemize>
+<item> Support for the RandR extension has been partially integrated
+	into the XFree86 server, providing support for resizing the root
+	window at run-time.
+
+<item> The Mesa version used for OpenGL&reg; 1.3 and DRI 
+	driver support has been updated to 4.0.4.
+
+<item> The XFree86 server's hot keys (including those for switching
+	modes and virtual terminals) can now be configured via XKB.
+	Previously they were hard coded.  An X server configuration
+	option has been added to allow the VT switching hot keys to be
+	disabled.
+
+</itemize>
+
+<sect1>Client and Library Updates
+
+<p>
+<itemize>
+<item> An Xcursor library providing support for alpha blended (ARGB)
+	and animated cursors.  Two Xcursor themes are provided (redglass
+	and whiteglass), as well as the default "core" theme (the traditional
+	cursors).
+
+<item> Xterm updated to patch level 173, including the following bugfixes:
+	<itemize>
+	<item> Fix two infinite loops (special cases of mouse hilite tracking,
+		DECUDK parsing).
+	<item> Make repainting of the 256-color example work properly.
+	<item> Modify parser tables to improve detection of malformed
+		control sequences, making xterm behave more like a real
+		DEC terminal.
+	<item> Fix a problem with the blinking cursor which occasionally caused
+		xterm to pause until a key was pressed.
+	<item> Fix improper parsing of multiple items in the ttyModes resource.
+
+	</itemize>
+	and the following improvements:
+	<itemize>
+	<item> Modify xterm to invoke luit.
+	<item> Add simple session management client capabilities.
+	<item> Add a modifyCursorKeys resource to control how the shift- and
+		similar modifiers are used to make a cursor escape sequence.
+	<item> Check if the printerCommand resource string is empty,
+		and use this to allow the user to disable printer function.
+	<item> Sort the options list which is displayed in help- and
+		syntax-messages at runtime to simplify maintenance.
+	</itemize>
+
+</itemize>
+
+<sect1>I18N and Font Updates
+
+<p>
+<itemize>
+<item> FreeType2 updated to version 2.1.1.
+
+<item> The "freetype" X server font backend has undergone a partial rewrite.
+	The new version is based on FreeType 2, and handles TrueType
+	(including OpenType/TTF), OpenType/CFF and Type 1 fonts.  The old
+	"type1" backend is now deprecated, and is only used for CIDFonts
+	by default.
+
+<item> A new utility called "mkfontscale", which builds fonts.scale files,
+	has been added.
+
+<item> The Xft library has undergone a major restructuring, and is now
+	split into fontconfig (which deals with font discovery and
+	configuration and is independent from X), and Xft itself (which
+	uses fontconfig and deals with font rasterisation and rendering.
+	The format of the Xft font configuration files has changed in
+	an incompatible manner.
+
+<item> Support has been added to the Xft library to do rendering with the
+	core X11 protocol.  This allows clients using this library to
+	render to X servers that don't have support for the RENDER extension.
+
+<item> There has been a significant reworking of the XKB support to allow
+	multi-layout configurations.  Multi-layout configurations provide
+	a flexible way of supporting multiple language layouts and switching
+	between them.
+
+</itemize>
+
+<sect1>OS Support Updates
+
+<p>
+<itemize>
+<item> Updates for Darwin/Mac OS X, including:
+	<itemize>
+	<item> Indirect GLX acceleration added.
+	<item> Smaller memory footprint and faster 2-D drawing in rootless
+		mode.
+	<item> Full screen mode now uses shadowfb for much faster 2-D drawing.
+	<item> Native fonts can be used on MacOS X.
+	</itemize>
+
+<item> Various Cygwin support updates, including an experimental rootless
+	X server for Cygwin/XFree86.
+
+<item> AMD x86-64 support (primarily for Linux so far) has been added.
+
+<item> Support added for OpenBSD/sparc64.
+
+<item> Major OS/2 support updates.
+
+<item> Major SCO OpenServer updates.
+
+<item> Multi-head support has been added for 460GX-based Itanium systems,
+	and for ZX1-based Itanium2 systems.
+
+<item> Experimental support for SunOS/Solaris on UltraSPARC systems.
+
+
+</itemize>
+
+A more complete list of changes can be found in the CHANGELOG that is
+part of the XFree86 source tree.  It can also be viewed online at our
+<url name="CVSweb server"
+url="http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/CHANGELOG?rev=HEAD">.
+
+<!--
+<sect>Summary of new features in &prevrelvers;.
+<p>
+-->
+
+<sect>Drivers<label id="drivertables">
+<p>
+
+<sect1>Video Drivers
+<p>
+
+XFree86 &relvers; includes the following video drivers:
+
+<table border=1 align="center">
+<tabular ca="|l|l|l|">
+   <tabrow>Driver Name<colsep>Description<colsep>Further Information</tabrow>
+   <hline>
+   <tabrow><tt>apm</tt><colsep>Alliance Pro Motion<colsep><htmlurl
+		name="README.apm" url="apm.html"></tabrow>
+   <tabrow><tt>ark</tt><colsep>Ark Logic<colsep>&nbsp;</tabrow>
+   <tabrow><tt>ati</tt><colsep>ATI<colsep><htmlurl
+		name="README.ati" url="ati.html">, <htmlurl
+		name="README.r128" url="r128.html">, <htmlurl
+		name="r128(4)" url="r128.4.html">, <htmlurl
+		name="radeon(4)" url="radeon.4.html"></tabrow>
+   <tabrow><tt>chips</tt><colsep>Chips &amp; Technologies<colsep><htmlurl
+		name="README.chips" url="chips.html">, <htmlurl
+		name="chips(4)" url="chips.4.html"></tabrow>
+   <tabrow><tt>cirrus</tt><colsep>Cirrus Logic<colsep>&nbsp;</tabrow>
+   <tabrow><tt>cyrix</tt> (*)<colsep>Cyrix MediaGX<colsep><htmlurl
+		name="README.cyrix" url="cyrix.html"></tabrow>
+   <tabrow><tt>fbdev</tt><colsep>Linux framebuffer device<colsep><htmlurl
+		name="fbdev(4)" url="fbdev.4.html"></tabrow>
+   <tabrow><tt>glide</tt><colsep>Glide2x (3Dfx)<colsep><htmlurl
+		name="glide(4)" url="glide.4.html"></tabrow>
+   <tabrow><tt>glint</tt><colsep>3Dlabs, TI<colsep><htmlurl
+		name="glint(4)" url="glint.4.html"></tabrow>
+   <tabrow><tt>i128</tt><colsep>Number Nine<colsep><htmlurl
+		name="README.I128" url="I128.html">, <htmlurl
+		name="i128(4)" url="i128.4.html"></tabrow>
+   <tabrow><tt>i740</tt><colsep>Intel i740<colsep><htmlurl
+		name="README.i740" url="i740.html"></tabrow>
+   <tabrow><tt>i810</tt><colsep>Intel i8xx<colsep><htmlurl
+		name="README.i810" url="i810.html">, <htmlurl
+		name="i810(4)" url="i810.4.html"></tabrow>
+   <tabrow><tt>imstt</tt><colsep>Integrated Micro Solns<colsep>&nbsp;</tabrow>
+   <tabrow><tt>mga</tt><colsep>Matrox<colsep><htmlurl
+		name="mga(4)" url="mga.4.html"></tabrow>
+   <tabrow><tt>neomagic</tt><colsep>NeoMagic<colsep><htmlurl
+		name="neomagic(4)" url="neomagic.4.html"></tabrow>
+   <tabrow><tt>newport</tt> (-)<colsep>SGI Newport<colsep><htmlurl
+		name="README.newport" url="newport.html">, <htmlurl
+		name="newport(4)" url="newport.4.html"></tabrow>
+   <tabrow><tt>nsc</tt><colsep>National Semiconductor<colsep><htmlurl
+		name="nsc(4)" url="nsc.4.html"></tabrow>
+   <tabrow><tt>nv</tt><colsep>NVIDIA<colsep><htmlurl
+		name="nv(4)" url="nv.4.html"></tabrow>
+   <tabrow><tt>rendition</tt><colsep>Rendition<colsep><htmlurl
+		name="README.rendition" url="rendition.html">, <htmlurl
+		name="rendition(4)" url="rendition.4.html"></tabrow>
+   <tabrow><tt>s3</tt><colsep>S3 (not ViRGE or Savage)<colsep>&nbsp;</tabrow>
+   <tabrow><tt>s3virge</tt><colsep>S3 ViRGE<colsep><htmlurl
+		name="README.s3virge" url="s3virge.html">, <htmlurl
+		name="s3virge(4)" url="s3virge.4.html"></tabrow>
+   <tabrow><tt>savage</tt><colsep>S3 Savage<colsep><htmlurl
+		name="savage(4)" url="savage.4.html"></tabrow>
+   <tabrow><tt>siliconmotion</tt><colsep>Silicon Motion<colsep><htmlurl
+		name="siliconmotion(4)" url="siliconmotion.4.html"></tabrow>
+   <tabrow><tt>sis</tt><colsep>SiS<colsep><htmlurl
+		name="README.SiS" url="SiS.html">, <htmlurl
+		name="sis(4)" url="sis.4.html"></tabrow>
+   <tabrow><tt>sunbw2</tt> (+)<colsep>Sun bw2<colsep>&nbsp;</tabrow>
+   <tabrow><tt>suncg14</tt> (+)<colsep>Sun cg14<colsep>&nbsp;</tabrow>
+   <tabrow><tt>suncg3</tt> (+)<colsep>Sun cg3<colsep>&nbsp;</tabrow>
+   <tabrow><tt>suncg6</tt> (+)<colsep>Sun GX and Turbo GX<colsep>&nbsp;</tabrow>
+   <tabrow><tt>sunffb</tt> (+)<colsep>Sun Creator/3D, Elite 3D<colsep>&nbsp;</tabrow>
+   <tabrow><tt>sunleo</tt> (+)<colsep>Sun Leo (ZX)<colsep>&nbsp;</tabrow>
+   <tabrow><tt>suntcx</tt> (+)<colsep>Sun TCX<colsep>&nbsp;</tabrow>
+   <tabrow><tt>tdfx</tt><colsep>3Dfx<colsep><htmlurl
+		name="tdfx(4)" url="tdfx.4.html"></tabrow>
+   <tabrow><tt>tga</tt><colsep>DEC TGA<colsep><htmlurl
+		name="README.DECtga" url="DECtga.html"></tabrow>
+   <tabrow><tt>trident</tt><colsep>Trident<colsep><htmlurl
+		name="trident(4)" url="trident.4.html"></tabrow>
+   <tabrow><tt>tseng</tt><colsep>Tseng Labs<colsep>&nbsp;</tabrow>
+   <tabrow><tt>vesa</tt><colsep>VESA<colsep><htmlurl
+		name="vesa(4)" url="vesa.4.html"></tabrow>
+   <tabrow><tt>vga</tt><colsep>Generic VGA<colsep><htmlurl
+		name="vga(4)" url="vga.4.html"></tabrow>
+   <tabrow><tt>vmware</tt><colsep>VMWare guest OS<colsep><htmlurl
+		name="vmware(4)" url="vmware.4.html"></tabrow>
+</tabular>
+</table>
+
+Drivers marked with (*) are present in a preliminary form in this release,
+but are not complete and/or stable yet.
+<p>
+
+Drivers marked with (+) are for Linux/Sparc only.
+<p>
+
+Drivers marked with (-) are for Linux/mips only.
+<p>
+
+Darwin/Mac OS X uses IOKit drivers and does not use the module loader drivers
+listed above. Further information can be found in
+<htmlurl name="README.Darwin" url="Darwin.html">.
+
+XFree86 &relvers; includes the following input drivers:
+
+<sect1>Input Drivers
+<p>
+
+<table border=1 align="center">
+<tabular ca="|l|l|l|">
+   <tabrow>Driver Name<colsep>Description<colsep>Further Information</tabrow>
+   <hline>
+<!--
+   <tabrow><tt>acecad</tt><colsep>AceCad<colsep>&nbsp;</tabrow>
+-->
+   <tabrow><tt>calcomp</tt><colsep>Calcomp<colsep>&nbsp;</tabrow>
+   <tabrow><tt>citron</tt><colsep>Citron<colsep><htmlurl
+		name="citron(4)" url="citron.4.html"></tabrow>
+   <tabrow><tt>digitaledge</tt><colsep>DigitalEdge<colsep>&nbsp;</tabrow>
+   <tabrow><tt>dmc</tt><colsep>DMC<colsep><htmlurl
+		name="dmc(4)" url="dmc.4.html"></tabrow>
+   <tabrow><tt>dynapro</tt><colsep>Dynapro<colsep>&nbsp;</tabrow>
+   <tabrow><tt>elographics</tt><colsep>EloGraphics<colsep>&nbsp;</tabrow>
+   <tabrow><tt>elographics</tt><colsep>EloGraphics<colsep>&nbsp;</tabrow>
+   <tabrow><tt>fpit</tt><colsep>Fujitsu Stylistic Tablet PCs<colsep><htmlurl
+		name="fpit(4)" url="fpit.4.html"></tabrow>
+   <tabrow><tt>hyperpen</tt><colsep>HyperPen<colsep>&nbsp;</tabrow>
+   <tabrow><tt>js_x</tt><colsep>JamStudio pentablet<colsep><htmlurl
+		name="js_x(4)" url="js_x.4.html"></tabrow>
+   <tabrow><tt>kbd</tt><colsep>generic keyboards (alternate)<colsep><htmlurl
+		name="kbd(4)" url="kbd.4.html"></tabrow>
+   <tabrow><tt>keyboard</tt><colsep>generic keyboards<colsep><htmlurl
+		name="keyboard(4)" url="keyboard.4.html"></tabrow>
+   <tabrow><tt>microtouch</tt><colsep>MicroTouch<colsep>&nbsp;</tabrow>
+   <tabrow><tt>mouse</tt><colsep>most mouse devices<colsep><htmlurl
+		name="mouse(4)" url="mouse.4.html"></tabrow>
+   <tabrow><tt>mutouch</tt><colsep>MicroTouch<colsep>&nbsp;</tabrow>
+   <tabrow><tt>palmax</tt><colsep>Palmax PD1000/PD1100<colsep><htmlurl
+		name="palmax(4)" url="palmax.4.html"></tabrow>
+   <tabrow><tt>penmount</tt><colsep>PenMount<colsep>&nbsp;</tabrow>
+   <tabrow><tt>spaceorb</tt><colsep>SpaceOrb<colsep>&nbsp;</tabrow>
+   <tabrow><tt>summa</tt><colsep>SummaGraphics<colsep>&nbsp;</tabrow>
+   <tabrow><tt>tek4957</tt><colsep>Tektronix 4957 tablet<colsep><htmlurl
+		name="tek4957(4)" url="tek4957.4.html"></tabrow>
+   <tabrow><tt>ur98(*)</tt><colsep>Union Reality UR-F98 headtracker<colsep><htmlurl
+		name="ur98(4)" url="ur98.4.html"></tabrow>
+   <tabrow><tt>void</tt><colsep>dummy device<colsep><htmlurl
+		name="void(4)" url="void.4.html"></tabrow>
+   <tabrow><tt>wacom</tt><colsep>Wacom tablets<colsep><htmlurl
+		name="wacom(4)" url="wacom.4.html"></tabrow>
+</tabular>
+</table>
+
+Drivers marked with (*) are available for Linux only.
+
+<sect>Overview of XFree86 4.x.
+<p>
+Unlike XFree86 3.3.x where there are multiple X server binaries, each
+of which drive different hardware, XFree86 &relvers; has a single X
+server binary called <tt>XFree86</tt>.  This binary can either have one
+or more video drivers linked in statically, or, more usually, dynamically
+load the video drivers and other modules that are needed.
+
+XFree86 &relvers; has X server support for most UNIX(R) and UNIX-like
+operating systems on Intel/x86 platforms, plus support for Linux on
+Alpha, PowerPC, IA-64, Sparc, and Mips platforms, and for Darwin on PowerPC.
+Work on support for additional architectures and operating systems is
+in progress, and is planned for future releases.
+
+<sect1>Loader and Modules
+<p>
+The XFree86 X server has a built-in run-time loader, donated by <url
+name="Metro Link" url="http://www.metrolink.com">.  This loader can load
+normal object files and libraries in most of the commonly used formats.
+Since the loader doesn't rely on an operating system's native dynamic
+loader support, it works on platforms that don't provide this feature,
+and makes it possible for the modules to be operating system independent
+(although not, of course, independent of CPU architecture).  This means
+that a module compiled on Linux/x86 can be loaded by an
+X server running on Solaris/x86, or FreeBSD, or even OS/2.  
+<p>
+One of the
+main benefits of this loader is that when modules are updated, they do not need
+to be recompiled for every different operating system.  In the future
+we plan to take advantage of this to provide more frequent driver module 
+updates in between major releases.
+
+The loader in version &relvers; has support for Intel (x86), Alpha and
+PowerPC platforms.  It also has preliminary support for Sparc platforms.
+
+The X server makes use of modules for video drivers, X server extensions,
+font rasterisers, input device drivers, framebuffer layers (like mfb,
+cfb, etc), and internal components used by some drivers (like XAA),
+
+The module interfaces (API and ABI) used in this release is still subject
+to change without notice.  While we will attempt to provide backward
+compatibility for the module interfaces as of the 4.0 release (meaning
+that 4.0 modules will work with future core X server binaries), we cannot
+guarantee this. 
+
+<bf>Note about module security</bf>
+<quote><p>
+	The XFree86 X server runs with root privileges, i.e. 
+	the X server loadable modules also run with these privileges.
+	For this reason we recommend that all users be careful to only
+	use loadable modules from reliable sources,  otherwise the
+        introduction of viruses and contaminated code can occur and wreak
+         havoc on your system.  We hope to have a
+	mechanism for signing/verifying the modules that we provide
+	available in a future release.
+
+</quote>
+
+<sect1>Configuration File <label id="config">
+<p>
+
+The X server configuration file format has been extended to handle some
+of the new functionality.  The <tt>xf86config</tt> utility can be used
+to generate a basic config file, that may require some manual editing.
+The X server also has preliminary support for generating a basic config
+file.  This is done by running (as root) "<tt>XFree86 -configure</tt>".
+Alternatively, the sample config file <tt>XF86Config.eg</tt> that is
+installed in <tt>/usr/X11R6/lib/X11</tt> may be used as a starting point.
+The <tt>xf86cfg</tt> utility can also be used to create a new configuration
+file or to edit an existing one.
+The <tt>XF86Setup</tt> utility is currently not usable, but work is
+continuing in this area.
+
+The main changes are covered here, but please refer to the <htmlurl
+name="XF86Config(5)" url="XF86Config.5.html">
+manual page for more comprehensive information:
+
+<itemize>
+  <item>The Module section is used to load server extension modules and
+	font modules, but not XInput drivers.  The <tt>.so</tt> suffix
+	should no longer be specified with module names.  Options may
+	be supplied for modules by loading the module via a SubSection
+	instead of the usual Load keyword.  The <tt>bitmap</tt> module
+	is the only font module that is loaded by default.  No server
+	extensions are loaded by default, but some are built-in to the
+	server.  It is strongly recommended that the extension module
+	containing a range of small miscellaneous extensions (<tt>extmod</tt>)
+	be loaded because some commonly used things won't work correctly
+	without it.  The following example shows how to load all the server
+	extensions plus the Type1 and TrueType fonts support, and a
+	commented example that shows how to pass options to an extension
+	(this one is for loading the misc extensions (<tt>extmod</tt>)
+	with the XFree86-VidModeExtension disabled):
+
+<quote><verb>
+Section "Module"
+
+    Load "dbe"
+    Load "record"
+    Load "glx"
+    Load "extmod"
+
+    Load "type1"
+    Load "freetype"
+
+  # SubSection "extmod"
+  #     Option "Omit XFree86-VidModeExtension"
+  # EndSubSection
+
+EndSection
+</verb></quote>
+
+  <item>Option flags have been extended and are now used more widely in the
+	config file.  Options flags come in two main types.  The first type
+	is exactly like the old form:
+
+<quote><verb>
+    Option "name"
+</verb></quote>
+
+	where the option just has a name specified.  The name is case
+	insensitive, and white space and underscore characters are ignored.
+	The second type consists of a name and a value:
+
+<quote><verb>
+    Option "name" "value"
+</verb></quote>
+
+	The value is passed transparently as a string to the code that
+	uses the option.  Common value formats are integer, boolean,
+	real, string and frequency.  The following boolean option values
+	are recognised as meaning TRUE: <tt>"true"</tt>, <tt>"yes"</tt>,
+	<tt>"on"</tt>, <tt>"1"</tt>, and no value.  The values recognised
+	as FALSE are <tt>"false"</tt>, <tt>"no"</tt>, <tt>"off"</tt>,
+	<tt>"0"</tt>.  In addition to this, <tt>"no"</tt> may be prepended
+	to the <em>name</em> of a boolean option to indicate that it is
+	false.  Frequency options can have the strings <tt>Hz</tt>,
+	<tt>kHz</tt>, or <tt>MHz</tt> appended to the numerical value
+	specified.
+
+	Note: the value must always be enclosed in double quotes
+	(<tt>"</tt>), even when it is numerical.
+
+  <item>The ServerFlags section now accepts its parameters as Options
+	instead of as special keywords.  The older keyword format is
+	still recognised for compatibility purposes, but is deprecated
+	and support for it will likely be dropped in a future release.
+	The DPMS and screen save timeout values are now specified in the
+	ServerFlags section rather than elsewhere (because they are global
+	parameters, not screen-specific).  This example shows the defaults
+	for these:
+
+<quote><verb>
+    Option "blank time"    "10"
+    Option "standby time"  "20"
+    Option "suspend time"  "30"
+    Option "off time"      "40"
+</verb></quote>
+
+	The new option <tt>AllowDeactivateGrabs</tt> allows deactivating
+	any active grab with the key sequence <tt>Ctrl+Alt+Keypad-Divide</tt>
+	and the new option <tt>AllowClosedownGrabs</tt> allows closing the
+	connection to the grabbing client with the key sequence
+	<tt>Ctrl+Alt+Keypad-Multiply</tt>. Note that these options are off
+	by default as they allow users to remove the grab used by screen
+	saver/locker programs.
+
+  <item>The Keyboard, Pointer and XInput sections have been replaced by a
+	more general InputDevice section.  The old Keyboard and Pointer
+	sections are still recognised for compatibility purposes, but
+	they are discommended and support for them may be dropped in future
+	releases.  The old XInput sections are no longer recognised.
+	The keywords from the old sections are expressed as Options in
+	the InputDevice sections.  The following example shows typical
+	InputDevice sections for the core mouse and keyboard.
+
+<quote><verb>
+Section "InputDevice"
+    Identifier  "Keyboard 1"
+    Driver      "keyboard"
+    Option      "AutoRepeat" "500 5"
+    Option      "XkbModel"   "pc104"
+    Option      "XkbLayout"  "us"
+EndSection
+
+Section "InputDevice"
+    Identifier  "Mouse 1"
+    Driver      "mouse"
+    Option      "Protocol"   "PS/2"
+    Option      "Device"     "/dev/mouse"
+    Option	"SampleRate" "80"
+EndSection
+</verb></quote>
+
+  <item>The Monitor section is mostly unchanged.  The main difference is
+	that a set of VESA modes is defined internally in the server,
+	and so for most monitors, it isn't necessary to specify any modes
+	explicitly in the Monitor section.  There is also a new Modes section
+	that can be used to define a set of modes separately from the
+	Monitor section, and the Monitor section may "include" them
+	with the "<tt>UseModes</tt>" keyword.  The Monitor section may also
+	include Options.  Options that are monitor-specific, like the
+	<tt>"DPMS"</tt> and <tt>"Sync on Green"</tt> options are best
+	specified in the Monitor sections.
+
+  <item>The Device sections are mostly unchanged.  The main difference
+	is the new (and mandatory) Driver keyword that specifies which
+	video driver should be loaded to drive the video card.  Another
+	difference is the BusID keyword that is used to specify which of
+	possibly multiple video cards the Device section is for.  The
+	following is an example for a Matrox card:
+
+<quote><verb>
+Section "Device"
+    Identifier "MGA 1"
+    Driver     "mga"
+    BusID      "PCI:1:0:0"
+EndSection
+</verb></quote>
+
+  <item>The Screen sections are mostly unchanged.  The old Driver keyword
+	is no longer used, and a mandatory Identifier keyword has been
+	added.  The DefaultColorDepth keyword has been renamed to
+	DefaultDepth.
+
+  <item>A new section called ServerLayout has been added to allow the
+	layout of the screens and the selection of input devices to be
+	specified.  The ServerLayout sections may also include options
+	that are normally found in the ServerFlags section.  Multiple
+	ServerLayout sections may be present, and selected from the command
+	line.  The following example shows a ServerLayout section for a
+	dual-headed configuration with two Matrox cards, and two mice:
+
+<quote><verb>
+Section "ServerLayout"
+    Identifier  "Layout 1"
+    Screen      "MGA 1"
+    Screen      "MGA 2" RightOf "MGA 1"
+    InputDevice "Keyboard 1" "CoreKeyboard"
+    InputDevice "Mouse 1"    "CorePointer"
+    InputDevice "Mouse 2"    "SendCoreEvents"
+    Option      "BlankTime"  "5"
+EndSection
+</verb></quote>
+
+See the <htmlurl name="XF86Config(5)" url="XF86Config.5.html"> man page
+for a more detailed explanation of the format of the new ServerLayout
+section.
+
+
+</itemize>
+
+The config file search patch has been extended, with the directories
+<tt>/etc/X11</tt> and <tt>/usr/X11R6/etc/X11</tt> being added.  The full
+search path details are documented in the XF86Config manual page.
+
+
+<sect1>Command Line Options
+<p>
+
+The following new X server command line options have been added:
+
+<quote><p>
+
+<tt>-depth</tt> <it>n</it>
+<quote><p>
+	This specifies the colour depth that the server is running at.
+	The default is 8 for most drivers.  Most drivers support the
+	values 8, 15, 16 and 24.  Some drivers also support the values
+	1 and 4.  Some drivers may also support other depths.  Note that
+	the depth is different from the ``bpp'' that was specified with
+	previous versions.  The depth is the number of bits in each
+	pixel that are significant in determining the pixel's value.
+	The bpp is the total size occupied by each pixel, including bits
+	that are not used.  The old <tt>-bpp</tt> option is no longer
+	recognised because it isn't a good way of specifying the server
+	behaviour.
+
+</quote>
+
+<tt>-fbbpp</tt> <it>n</it>
+<quote><p>
+	This specifies the bpp format to use for the framebuffer.  This
+	may be used in 24-bit mode to force a framebuffer format that is
+	different from what the driver chooses by default.  In most cases
+	there should be no need to use this option.
+
+</quote>
+
+<tt>-pixmap24</tt>
+<quote><p>
+	This specifies that the client-side pixmap format should be the
+	packed 24-bit format that was often used by the 3.3.x servers.
+	The default is the more common 32-bit format.  There should normally
+	be no need to use this option.
+
+</quote>
+
+<tt>-pixmap32</tt>
+<quote><p>
+	This specifies that the client-side pixmap format should be the
+	sparse 32-bit format.  This is the default, so there should
+	normally be no need to use this option.
+
+</quote>
+
+<tt>-layout</tt> <it>name</it>
+<quote><p>
+	This specifies which ServerLayout section in the config file to
+	use.  When this option is not specified, the first ServerLayout
+	section is used.  When there is no ServerLayout section, the
+	first Screen section is used.
+
+</quote>
+
+<tt>-screen</tt> <it>name</it>
+<quote><p>
+	This specifies which Screen section in the config file to
+	use.  When this option is not specified, the first ServerLayout
+	section is used.  When there is no ServerLayout section, the
+	first Screen section is used.
+
+</quote>
+
+<tt>-keyboard</tt> <it>name</it>
+<quote><p>
+	This specifies which InputDevice section in the config file to
+	use for the core keyboard.  This option may be used in conjunction
+	with the <tt>-screen</tt> option.
+
+</quote>
+
+<tt>-pointer</tt> <it>name</it>
+<quote><p>
+	This specifies which InputDevice section in the config file to
+	use for the core pointer.  This option may be used in conjunction
+	with the <tt>-screen</tt> option.
+
+</quote>
+
+<tt>-modulepath</tt> <it>path</it>
+<quote><p>
+	This specifies the module search path.  The path should be a
+	comma-separated list of absolute directory paths to search for
+	server modules.  When specified here, it overrides the value
+	specified in the config file.  This option is only available
+	when the server is started by the <tt>root</tt> user.
+
+</quote>
+
+<tt>-logfile</tt> <it>file</it>
+<quote><p>
+	This specifies the log file name.  When specified here, it
+	overrides the default value.  This option is only available when
+	the server is started by the <tt>root</tt> user.
+
+</quote>
+
+<tt>-scanpci</tt>
+<quote><p>
+	This specifies that the <tt>scanpci</tt> module should be loaded and
+	executed.  This does a scan of the PCI bus.
+
+</quote>
+
+<tt>-logverbose</tt> [<it>n</it>]
+<quote><p>
+	This options specifies the verbosity level to use for the log file.
+	The default is 3.
+
+</quote>
+
+</quote>
+
+The following X server command line options have been changed since 3.3.x:
+
+<quote><p>
+
+<tt>-verbose</tt> [<it>n</it>]
+<quote><p>
+	This option specifies the verbosity level to use for the server
+	messages that get written to stderr.  It may be specified multiple
+	times to increase the verbosity level (as with 3.3.x), or the
+	verbosity level may be specified explicitly as a number.  The
+	default verbosity level is 0.
+
+</quote>
+
+<tt>-xf86config</tt> <it>filename</it>
+<quote><p>
+	This option has been extended to allow non-root users to specify
+	a relative config file name.  The config file search path will be
+	used to locate the file in this case.  This makes it possible for
+	users to choose from multiple config files that the the sysadmin
+	has provided.
+
+</quote>
+
+
+</quote>
+
+A more complete list of XFree86 X server command line options can be found
+in the <htmlurl name="XFree86(1)" url="XFree86.1.html"> manual page.
+
+<sect1>XAA
+<p>
+
+The XFree86 Acceleration Architecture (XAA) has been completely rewritten
+from scratch for XFree86 4.x.  Most drivers implement acceleration by
+making use of the XAA module.
+
+<sect1>Multi-head
+<p>
+Some multi-head configurations are supported in XFree86 4.x, primarily
+with multiple PCI/AGP cards.  However, this is an area that is still
+being worked on, and we expect that the range of configurations for which
+it works well will increase in future releases.  A configuration that
+is known to work well in most cases is multiple (supported) Matrox cards.
+
+One of the main problems is with drivers not sufficiently initialising
+cards that were not initialised at boot time.  This has been improved
+somewhat with the INT10 support that is used by most drivers (which
+allows secondary card to be "soft-booted", but in some cases there are
+other issues that still need to be resolved.  Some combinations can be
+made to work better by changing which card is the primary card (either
+by using a different PCI slot, or by changing the system BIOS's preference
+for the primary card).
+
+<sect1>Xinerama
+<p>
+Xinerama is an X server extension that allows multiple physical screens
+to behave as a single screen.  With traditional multi-head in X11,
+windows cannot span or cross physical screens.  Xinerama removes this
+limitation.  Xinerama does, however, require that the physical screens
+all have the same root depth, so it isn't possible, for example, to use
+an 8-bit screen together with a 16-bit screen in Xinerama mode.
+
+Xinerama is not enabled by default, and can be enabled with the
+<tt>+xinerama</tt> command line option for the X server.
+
+Xinerama was included with X11R6.4.  The version included in XFree86 4.x
+was completely rewritten for improved performance and correctness.
+
+Known problems:
+<itemize>
+  <item>Most window managers are not Xinerama-aware, and so some
+	operations like window placement and resizing might not behave
+	in an ideal way.  This is an issue that needs to be dealt with
+	in the individual window managers, and isn't specifically an
+	XFree86 problem.
+
+</itemize>
+
+<sect1>DGA version 2
+<p>
+
+DGA 2.0 is included in &relvers;, but is not implemented by all drivers.
+Preliminary documentation for the client libraries can be found in the
+<tt>README.DGA</tt> document.  A good degree of backwards compatibility
+with version 1.0 is provided.
+
+
+<sect1>DDC
+<p>
+The VESA(R) Display Data Channel (DDC&trade;) standard allows the monitor
+to tell the video card (or on some cases the computer directly) about
+itself; particularly the supported screen resolutions and refresh rates.
+
+Partial or complete DDC support is available in most of the video drivers.
+DDC is enabled by default, but can be disabled with a "Device" section
+entry:  <tt>Option "NoDDC"</tt>.  We have support for DDC versions 1
+and 2; these can be disabled independently with <tt>Option "NoDDC1"</tt>
+and <tt>Option "NoDDC2"</tt>.
+
+At startup the server prints out DDC information from the display, and
+can use this information to set or warn about monitor sync limits (but
+not modelines yet).  For some drivers, the X server's new
+<tt>-configure</tt> option uses the DDC information when generating the
+config file.
+
+<sect2>Changed behavior caused by DDC.
+<p>
+Several drivers uses DDC information to
+set the screen size and pitch.  This can be overridden by explicitly
+resetting it to the and non-DDC default value 75 with the <tt>-dpi
+75</tt> command line option for the X server, or by specifying appropriate
+screen dimensions with the "DisplaySize" keyword in the "Monitor" section
+of the config file.
+
+
+<sect1>GLX and the Direct Rendering Infrastructure (DRI)
+<p>
+
+<url name="Precision Insight" url="http://www.precisioninsight.com">
+was provided with funding and support from <url name="Red Hat"
+url="http://www.redhat.com">, <url name="SGI" url="http://www.sgi.com">,
+<url name="3Dfx" url="http://www.3dfx.com">, <url name="Intel"
+url="http://www.intel.com">, <url name="ATI" url="http://www.ati.com">,
+and <url name="Matrox" url="http://www.matrox.com"> to integrate the GLX
+extension for 3D rendering in an X11 window.  The 3D core rendering
+component is the <url name="Mesa" url="http://www.mesa3d.org"> library.
+SGI has released the sources to the GLX extension framework under an
+open license, which essentially provides the glue between the 3D
+library and this windowing system.  Precision Insight has integrated
+these components into the XFree86 X Server and added a Direct Rendering
+Infrastructure (DRI).  Direct Rendering provides a highly optimized
+path for sending 3D data directly to the graphics hardware.  This
+release provides a complete implementation of direct rendering support
+for the 3Dfx Banshee, Voodoo3 and Voodoo5 graphics cards, as well as
+the Intel i810/i815 cards, ATI Rage 128, and Matrox G400.
+Updated information on DRI
+compatible drivers can be found at the <url name="DRI Project"
+url="http://dri.sourceforge.net"> on <url name="SourceForge"
+url="http://www.sourceforge.net">.
+
+<sect1>XVideo Extension (Xv)
+<p>
+
+The XVideo extension is supported in XFree86 4.x.
+An XvQueryPortAttributes function has been added as well as
+support for XvImages.  XvImages are XImages in alternate color spaces 
+such as YUV and can be passed to the server through shared memory
+segments.  This allows clients to display YUV data with high quality
+hardware scaling and filtering.
+
+<sect1>X Rendering Extension (Render) <label id="render">
+<p>
+
+The X Rendering extension provides a 2D rendering model that more
+closely matches application demands and hardware capabilities.  It provides
+a rendering model derived from Plan 9 based on Porter/Duff image
+composition rather than binary raster operations.
+
+<p>
+Using simple compositing operators provided by most hardware, Render
+can draw anti-aliased text and geometric objects as well as perform 
+translucent image overlays and other image operations not possible with 
+the core X rendering system.
+
+<p>
+XFree86 &relvers; provides a partial implementation of Render sufficient 
+for drawing anti-aliased text and image composition.  Still to be 
+implemented are geometric primitives and affine transformation of images.
+
+<p>
+Unlike the core protocol, Render provides no font support for applications,
+rather it allows applications to upload glyphs for display on the screen.
+This allows the client greater control over text rendering and complete
+access to the available font information while still providing hardware
+acceleration.  The Xft library provides font access for
+Render applications.
+
+<sect2>The Xft Library
+<p>
+
+On the client side, the Xft library provides access to fonts for
+applications using the FreeType library, version 2.  FreeType currently
+supports Type1 and TrueType font files, a future release is expected to 
+support BDF and PCF files as well, so Render applications will have access 
+to the complete range of fonts available to core applications.  One 
+important thing to note is that Xft uses the vertical size of the monitor 
+to compute accurate pixel sizes for provided point sizes; if your monitor 
+doesn't provide accurate information via DDC, you may want to add that 
+information to <tt>XF86Config</tt>.
+
+<p>
+
+To allow a graceful transition for applications moving from core text
+rendering to the Render extension, Xft can use either core fonts or FreeType
+and the Render extension for text.  By default, Xft is configured to support
+both core fonts and FreeType fonts using the supplied version of FreeType
+2.  See the section on FreeType support in Xft for instructions on
+configuring XFree86 to use an existing FreeType installation.
+
+<p>
+The Xft library uses a configuration file, <tt>XftConfig</tt>, which
+contains information about which directories contain font files and also
+provides a sophisticated font aliasing mechanism.  Documentation for that
+file is included in the <htmlurl name="Xft(3)" url="Xft.3.man"> man page.
+
+</sect2>
+<sect2>FreeType support in Xft
+<p>
+
+XFree86 &relvers; includes sources for FreeType version 2.1.1, and, by
+default, they are built and installed automatically.
+
+</sect2>
+
+<sect2>Application Support For Anti-Aliased Text
+<p>
+
+Only three applications have been modified in XFree86 &relvers; to work 
+with the Render extension and the Xft and FreeType libraries to provide 
+anti-aliased text.  Xterm, xditview and x11perf.  Migration of other 
+applications may occur in future releases.
+
+<p>
+By default, xterm uses core fonts through the standard core API.  It has
+a command line option and associated resource to direct it to use
+Xft instead:
+<itemize>
+  <item><tt>-fa</tt> family / <tt>.VT100.faceName:</tt> family.  Selects the 
+	font family to use.
+</itemize>
+
+<p>
+Xditview will use Xft instead of the core API by default.  X11perf 
+includes tests to measure the performance of text rendered in three ways, 
+anti-aliased, anti-aliased with sub-pixel sampling and regular chunky 
+text, but through the Render extension, a path which is currently somewhat
+slower than core text.
+</sect2>
+
+<sect1>Other extensions
+<p>
+
+The XFree86-Misc extension has not been fully ported to the new server
+architecture yet.  This should be completed in a future release.
+
+The XFree86-VidModeExtension extension has been updated, and mostly
+ported to the new server architecture.  The area of mode validation
+needs further work, and the extension should be used with care.  This
+extension has support for changing the gamma setting at run-time, for
+modes where this is possible.  The <tt>xgamma</tt> utility makes
+use of this feature.  Compatibility with the 3.3.x version of the
+extension is provided.  The missing parts of this extension and some
+new features should be completed in a future release.
+
+
+<!--
+<sect>X libraries and clients
+<p>
+-->
+
+<sect1>xedit
+<p>
+
+Xedit has several new features, including:
+<itemize>
+  <item>An embedded lisp interpreter that allows easier extension of the editor.
+  <item>Several new syntax highlight modes, and indentation rules for C and Lisp.
+  <item>Flexible search/replace interface that allows regex matches.
+  <item>Please refer to <tt><htmlurl name="xedit(1)" url="xedit.1.html"></tt>
+	for more details.
+</itemize>
+
+<!--
+<sect>Fonts and Internationalisation
+<p>
+-->
+
+<sect1>Font support
+<p>
+
+Details about the font support in XFree86 4.x can be found
+in the <htmlurl name="README.fonts" url="fonts.html"> document.
+
+<sect1>TrueType support
+<p>
+
+XFree86 4.x comes with two TrueType backends, known as
+`xfsft' (the <tt>"freetype"</tt> module) and `X-TrueType' (the
+<tt>"xtt"</tt> module).  Both of these backends are based on the FreeType
+library.
+
+<sect1>CID font support
+<p>
+
+Support for CID-keyed fonts is included in XFree86 4.x.
+The CID-keyed font format was designed by <url name="Adobe Systems"
+url="http://www.adobe.com"> for fonts with large character sets.  The
+CID-keyed font support in XFree86 was donated by <url name="SGI"
+url="http://www.sgi.com">.  See the <htmlurl name="LICENSE"
+url="LICENSE.html"> document for a copy of the CID Font Code Public
+License.
+
+<sect1>Internationalisation of the scalable font backends
+<p>
+
+XFree86 4.x has a ``fontenc'' layer to allow the scalable font backends
+to use a common method of font re-encoding.  This re-encoding makes it
+possible to uses fonts in encodings other than their their native
+encoding.  This layer is used by the Type1 and Speedo backends and the
+`xfsft' version of the TrueType backend.  The `X-TrueType' version of
+the TrueType backend uses a different re-encoding method based on loadable
+encoding modules.
+
+<sect1>Large font optimisation
+<p>
+
+The glyph metrics array, which all the X clients using a particular font
+have access to, is placed in shared memory, so as to reduce redundant
+memory consumption.  For non-local clients, the glyph metrics array is
+transmitted in a compressed format.
+
+<sect1>Unicode/ISO 10646 support
+<p>
+What is included in 4.x:
+
+<itemize>
+  <item>All ``-misc-fixed-*'' BDF fonts are now available in the
+        ISO10646-1 encoding and cover at least the 614 characters
+        found in ISO 8859-{1-5,7-10,14,15}, CP1252, and MES-1. The
+        non-bold fonts also cover all Windows Glyph List 4 (WGL4)
+        characters, including those found in all 8-bit MS-DOS/Windows
+        code pages. The 8-bit variants of the ``-misc-fixed-*'' BDF
+        fonts (ISO8859-1, ISO8859-2, KOI8-R, etc.) have all been
+        automatically generated from the new ISO10646-1 master fonts.
+
+  <item>Some ``-misc-fixed-*'' BDF ISO10646-1 fonts now cover a
+        comprehensive Unicode repertoire of over 3000 characters
+        including all Latin, Greek, Cyrillic, Armenian, Gregorian,
+        Hebrew, IPA, and APL characters, plus numerous scientific,
+	typographic, technical, and backwards-compatibility
+        symbols. Some of these fonts also cover Arabic, Ethiopian,
+        Thai, Han/Kanji, Hangul, full ISO 8859, and more. For the 6x13
+        font there is now a 12x13ja Kanji extension and for the 9x18
+        font there is a 18x18ja Kanji/Han/Hangul extension, which
+        covers all ISO-2022-JP-2 (RFC 1554) characters. The 9x18 font
+        can also be used to implement simple combining characters by
+        accent overstriking. For more information, read Markus Kuhn's
+        <url name="UTF-8 and Unicode FAQ"
+        url="http://www.cl.cam.ac.uk/~mgk25/unicode.html">.
+
+  <item>Mark Leisher's ClearlyU proportional font (similar to Computer
+	Modern).
+
+  <item>ISO 10646/Unicode UTF-8 Level 1 support added to xterm
+	(enabled with the <tt>-u8</tt> option).
+
+  <item>Both the xfsft (the <tt>"freetype"</tt> module) and the X-TrueType
+	(the <tt>"xtt"</tt> module) TrueType font backends support
+	Unicode-encoded fonts.
+
+</itemize>
+
+<sect1>Luxi fonts from Bigelow and Holmes <label id="luxi">
+<p>
+
+XFree86 now includes the ``Luxi'' family of Type&nbsp;1 fonts and TrueType
+fonts.  This family consists of the fonts ``Luxi&nbsp;Serif'',
+``Luxi&nbsp;Sans'' and ``Luxi&nbsp;Mono'' in Roman, oblique, bold and
+bold oblique variants.  The TrueType version have glyphs covering the
+basic ASCII Unicode range, the Latin&nbsp;1 range, as well as the
+<it/Extended Latin/ range and some additional punctuation characters.
+In particular, these fonts include all the glyphs needed for ISO&nbsp;8859
+parts 1, 2, 3, 4, 9, 13 and 15, as well as all the glyphs in the Adobe
+Standard encoding and the Windows 3.1  character set.
+
+The glyph coverage of the Type&nbsp;1 versions is somewhat reduced,
+and only covers ISO&nbsp;8859 parts 1, 2 and 15 as well as the Adobe
+Standard encoding.
+
+The Luxi fonts are original designs by Kris Holmes and Charles Bigelow
+from Bigelow and Holmes Inc., who developed the Luxi typeface designs
+in Ikarus digital format.  URW++ Design and Development GmbH converted
+the Ikarus format fonts to TrueType and Type&nbsp;1 font programs and
+implemented the grid-fitting "hints" and kerning tables in the Luxi
+fonts.
+
+The license terms for the Luxi fonts are included in the file
+`<tt/COPYRIGHT.BH/', as well as in the <htmlurl
+name="License document" url="LICENSE.html">.  For further information,
+please contact
+<email>design@bigelowandholmes.com</email> or
+<email>info@urwpp.de</email>, or consult the
+<url name="URW++ web site" url="http://www.urwpp.de">.
+
+
+<!--
+<sect>Miscellaneous
+<p>
+-->
+
+<sect1>Directory rearrangements
+<p>
+
+Some changes to the installed XFree86 directory structure have been
+implemented for 4.x.
+One important
+change is a modified search path for the X
+server's <tt>XF86Config</tt> file.  The details of this can be found
+in the XF86Config manual page.  The other main change is moving
+most of the run-time configuration files to <tt>/etc/X11</tt>, with
+symbolic links in the old <tt>/usr/X11R6/lib/X11</tt> location pointing
+to the new location.  Some run-time generated files are now located
+under the appropriate subdirectories of <tt>/var</tt>, again with the
+relevant symbolic links in the old location.
+
+
+
+
+</article>
diff --git a/sgml/Solaris.sgml b/sgml/Solaris.sgml
new file mode 100644
index 0000000..8061af8
--- /dev/null
+++ b/sgml/Solaris.sgml
@@ -0,0 +1,216 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+<article>
+
+<!-- Title information -->
+<title>Information for Solaris
+<author>David Holland, modified by Marc Aurele La France
+<date>2001 October 01
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Solaris.sgml,v 1.4 2003/01/04 04:20:23 dawes Exp $
+</ident>
+
+<!-- Table of contents -->
+<toc>
+
+<!-- Begin the document -->
+<sect>What is XFree86<p>
+XFree86 is a port of X11R6.5.1 that supports several versions of Unix.
+It is derived from X386 1.2 which was the X server distributed with X11R5.
+This release consists of many new features and performance improvements as well
+as many bug fixes.
+The release is available as a source code distribution, as well as binary
+distributions for many architectures.
+<p>
+The sources for XFree86 are available by anonymous ftp from:
+<quote>
+	<htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current"
+	url="ftp://ftp.XFree86.org/pub/XFree86/current">
+</quote>
+Solaris binaries for XFree86 are available for anonymous ftp at the same
+address.
+Currently, two binary distributions are available:  one for Solaris 8 x86, the
+other for previous Solaris x86 releases.
+They are <it>not</it> interchangeable.
+No binary distribution is available for Solaris/SPARC as it is still under
+development.<p>
+<sect>The VT-switching sub-system in Solaris x86<p>
+The virtual terminal sub-system is a undocumented, and unsupported feature of
+Solaris x86.
+Therefore if you use virtual terminals, you do so at <bf>YOUR OWN RISK</bf>.<p>
+Virtual terminals are not available in Solaris SPARC, and their availability
+has been removed in Solaris8 x86.<p>
+When available, the virtual terminals of Solaris work basically the same way as
+most other SVR4 VT sub-systems.
+However, there are a number of limitations documented below.<p>
+First, if you are running a Solaris 2.4 x86 system, and you want VT's, you will
+have to create the necessary devices first, so become root.<p>
+
+Verify the chanmux device driver's major number is 100:<p>
+<tscreen><verb>
+	# grep -i chanmux /etc/name_to_major
+	chanmux 100
+	#
+</verb></tscreen>
+If the number after 'chanmux' is anything but 100, I would suggest you
+immediately abort your attempt to create virtual terminals, and learn to live
+without them.<p>
+However, if it is 100, then as root type the following commands to create the
+maximum allowable number of virtual terminals.<p>
+<tscreen><verb>
+	# cd /dev
+	# mknod vt01 c 100 1
+	# mknod vt02 c 100 2
+	# mknod vt03 c 100 3
+	# mknod vt04 c 100 4
+	# mknod vt05 c 100 5
+	# mknod vt06 c 100 6
+	# mknod vt07 c 100 7
+</verb></tscreen>
+There is no need for a reconfiguration boot.<p>
+Secondly, for both 2.1, and 2.4 x86 systems, add a few lines to the
+<tt/inittab/ to enable logins on them.<p>
+
+(<bf>Note</bf>, do <bf>NOT</bf> make a mistake here, you could lock yourself
+out of the system)<p>
+<verb>
+--------------------->Snip Snip<-----------------------------------------------
+v1:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` VT01 login: " -T AT386 -d /dev/vt01 -l console
+v2:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` VT02 login: " -T AT386 -d /dev/vt02 -l console
+v3:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` VT03 login: " -T AT386 -d /dev/vt03 -l console
+v4:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` VT04 login: " -T AT386 -d /dev/vt04 -l console
+---------------------->End Here<-----------------------------------------------
+</verb>
+These four lines enable four VT's on Alt-SysReq-F1 through Alt-SysReq-F4.<p>
+Then execute the command '<tt>init q</tt>' to immediately enable the virtual
+terminals.<p>
+The keys used for VT switching are as follows:<p>
+<quote>
+	<tt>Alt-SysReq-F1</tt> through <tt>Alt-SysReq-F7</tt>
+	enable VT screens 1-7 respectively
+	(if the VT is active).<p>
+	<tt>Alt-SysReq-n</tt> enables the next active VT screen.<p>
+	<tt>Alt-SysReq-p</tt> enables the previous active VT screen.<p>
+	<tt>Alt-SysReq-h</tt> returns to the console.<p>
+</quote>
+If you are using virtual terminals, you must leave at least one free for use by
+the Xserver.<p>
+Limitations of the virtual terminal sub-system under Solaris x86:<p>
+There are only a total of 8 available VT's (7 normal VT's + 1 console) not the
+usual 15.
+If you have all 8 allocated, and you attempt to allocate a additional VT you
+will panic the system.
+(This bug is worked around in the Solaris XFree86 Xserver.)<p>
+From a programming stand point, they work pretty much as documented in the
+AT&amp;T Unix System V/386 Release 4 Integrated Software Development Guide,
+however a number of <tt>ioctl()</tt> calls are broken.<p>
+<sect>Notes for building XFree86 on Solaris<p>
+<enum>
+<item>
+Both GCC, and ProWorks are supported by XFree86.
+The minimum recommended GCC release is 2.7.2.
+Some earlier GCC's are known to not work and should be avoided.<p>
+You should also make certain your version of GCC predefines `sun'.
+If needed edit <tt>/usr/local/lib/gcc-lib/*/*/specs</tt>, and modify the
+<tt>*predefines:</tt> line.<p>
+On SPARCs, regardless of the compiler you use, ensure it generates 32-bit
+binaries.
+At this time, 64-bit binaries will probably not work.<p>
+<item>
+Also on SPARCs, you will need to set BuildXFree86OnSparcSunOS to YES in
+~xc/config/cf/host.def.
+Otherwise, you can only build the old deprecated Xsun* servers.<p>
+<item>
+A Threaded Xlib compiled with GCC has subtle problems.
+It'll work 98&percnt; of the time, however clients will occasionally exhibit
+strange hangs.
+Most notably image viewers such as xv-3.10 exhibit this problem.<p>
+It is recommended that you set ThreadedX in <tt>~xc/config/cf/host.def</tt> to
+NO, if you are using GCC.
+ProWorks does not have this problem.
+Whether this behaviour still exists with newer GCC's has not been verified.<p>
+<item>
+To build XFree86 with GCC you need gcc and (optionally) c++filt from GNU
+binutils.
+Don't install gas or ld from GNU binutils, use the one provided by Sun.<p>
+You might need to setup a /opt/SUNWspro/bin directory containing symbolic links
+named <tt/cc/, <tt/CC/, and <tt/c++filt/ pointing respectively to the actual
+<tt/gcc/, <tt/g++/ and <tt/c++filt/ commands.<p>
+<item>
+If you are using ProWorks to compile the XFree86 distribution, you need to
+modify your PATH appropriately so the ProWorks tools are available.
+Normally, they should be in <tt>/opt/SUNWspro/bin</tt><p>
+<item>
+You <bf>MUST</bf> put <tt>/usr/ccs/bin</tt> at the front of your PATH.
+There are known problems with some GNU replacements for the utilities found
+there.
+So the <tt>/usr/ccs/bin</tt> versions of these programs must be found before
+any possible GNU versions.
+(Most notably GNU '<tt/ar/' does not work during the build).<p>
+</enum>
+<sect>Notes for running XFree86 on Solaris<p>
+<enum>
+<item>
+Depending on the release or architecture of Solaris you are running, you might
+need to install an OS driver for an aperture device.<p>
+Under Solaris x86 2.5 and later, there's a system driver (<tt>/dev/xsvc</tt>)
+that provides this functionality.
+It will be detected automatically by the server, so you don't need to install
+the aperture driver.<p>
+For older Solaris x86 and for Solaris SPARC releases, the source for this
+driver is included in
+<tt>xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar</tt> of the source
+distribution.
+This file can usually also be found in the <tt>/usr/X11R6/lib/X11/etc</tt>
+directory when XFree86 is installed.
+Building, and installing the driver is relatively straight forward. Please read
+its accompanying README file.<p>
+<item>
+If you have not made the Virtual Terminal devices, you will need to specify the
+terminal device to run the Xserver on.
+The correct device is vt00 so your <tt>xinit</tt> command would look like
+so:<p>
+<tscreen><verb>
+	xinit -- vt00
+</verb></tscreen>
+If you have made the virtual terminal devices you do not need to specify the VT
+to run the Xserver on.<p>
+<item>
+For Solaris you will probably want to set your LD_LIBRARY_PATH to
+<tt>/usr/X11R6/lib:/usr/openwin/lib:/usr/dt/lib</tt>.
+Including <tt>/usr/X11R6/lib</tt> in your LD_LIBRARY_PATH is probably not
+necessary, however it doesn't hurt. :)<p>
+Including <tt>/usr/openwin/lib</tt> in the LD_LIBRARY_PATH is recommended
+because some Sun supplied binaries were not compiled with LD_RUN_PATH set
+properly at compile time.<p>
+Motif and CDE applications may require <tt>/usr/dt/lib</tt> in your
+LD_LIBRARY_PATH too.
+<item>
+Xqueue is <bf>NOT</bf> supported under Solaris.
+The includes necessary for Xqueue are available, however the driver does not
+seem to be in the kernel.
+(Go figure)<p>
+<item>
+If you want to use xdm with Solaris, extract the files from the shar file in
+<tt>/usr/X11R6/lib/X11/etc/XdmConf.svr4</tt> into a temporary directory.
+The <tt>README</tt> file tells where the individual files need to be installed.
+Be sure to read through each file and make any site-specific changes that you
+need.<p>
+</enum>
+<sect> Known bugs, and work arounds with Solaris<p>
+<enum>
+<item>
+The Solaris 2.1 for x86 OpenWindows filemgr does not work against a X11R5
+Xserver, it probably will also not work against a X11R6 Xserver.
+Attempting to 'Drag and Drop' a file causes the filemgr to abort with an
+'X error'<p>
+Solaris x86 2.4 does not have this problem.<p>
+There is no known work around.<p>
+<item>
+The SPARC port is still quite new, so instability is to be expected (and
+reported!).
+It might even have broken some aspects of the x86 port.<p>
+</enum>
+<sect>Bug Notification<p>
+Bug reports should be sent to <email>XFree86@XFree86.org</email>.
+</article>
diff --git a/sgml/Versions.sgml b/sgml/Versions.sgml
new file mode 100644
index 0000000..4eea959
--- /dev/null
+++ b/sgml/Versions.sgml
@@ -0,0 +1,355 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+
+<article>
+
+<title>XFree86 Version Numbering Schemes
+<author>The XFree86 Project, Inc
+<date>23 February 2003
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Versions.sgml,v 1.4 2003/02/24 03:41:23 dawes Exp $
+</ident>
+
+<abstract>
+
+The version numbering schemes used by XFree86 have changed from time to
+time.  The schemes used since version 3.3 are explained here.
+
+</abstract>
+
+<toc>
+
+<sect>Releases, Development Streams and Branches
+<p>
+
+As of the release of version 4.0.2 in December 2000, XFree86 has three
+release branches.  First is trunk of the CVS repository.  This is the
+main development stream, where all new work and work for future releases
+is done.
+
+Second is the stable bugfix branch for the latest full release
+(&fullrelvers;).  It is created around the time of the release.  The branch
+for this one is called "<tt>&relbranchtag;</tt>".  Fixes for bugs found
+in the release will be added to this branch (as well as the trunk), and
+updates to this release (if any) will be cut from this branch.  Similar
+stable branches are present for previous full releases.
+
+Finally there is the 3.3.x legacy branch, which is called
+"<tt>xf-3_3-branch</tt>".  While this branch is not actively being
+maintained, it does include some important post-3.3.6 bug fixes and
+security updates.  Relevant security updates in particular are usually
+back-ported to this branch.
+
+XFree86 is planning to make full releases from the main development
+stream at regular intervals in the 6-12 month range.  The feature
+freezes for these releases will usually be 2-3 months before the release
+dates.  This general plan is a goal, not a binding commitment.  The
+actual release intervals and dates will depend to a large degree on the
+resource available to XFree86.  Full releases consist of full source
+code tarballs, plus full binary distributions for a range of supported
+platforms.  Update/bugfix releases will be made on an as-required basis,
+depending also on the availability of resources, and will generally be
+limited to serious bug and security fixes.  New features will not usually
+be added in update releases.  Update/bugfix releases will not be full
+releases, and will consist of source code patches, plus binary updates
+to be layered on top of the previous full release.
+
+The next full release will be version &nextfullrelvers;.  There is no
+scheduled update release, but if one is needed, the version will be
+&nextupdrelvers;.
+
+<!--
+The next release on the legacy branch will be 3.3.7.  There is currently
+no schedule for that release.  The 3.3.7 release is likely to be the
+final release on that branch.
+-->
+
+Aside from actual releases, snapshots of the active release branches
+are tagged in the CVS repository from time to time.  Each such snapshot
+has an identifiable version number.
+
+<sect>Current (new) Version Numbering Scheme
+<p>
+
+Starting with the main development branch after 4.0.2, the XFree86
+versions are numbered according to the scheme outlined here.
+Both the 4.0.2 stable branch and the 3.3.x legacy branch continue
+to use the previous scheme, which is outlined in the sections below.
+
+The version numbering format is <tt>M.m.P.s</tt>, where <tt>M</tt> is
+the major version number, <tt>m</tt> is the minor version number,
+<tt>P</tt> is the patch level, and <tt>s</tt> is the snapshot number.
+Full releases have <tt>P</tt> set to zero, and it is incremented for each
+subsequent bug fix release on the post-release stable branch.  The
+snapshot number <tt>s</tt> is present only for between-release snapshots
+of the development and stable branches.
+
+<sect1>Development Branch
+<p>
+
+Immediately after forming a release stable branch, the patch level number
+for the main development branch is bumped to 99, and the snapshot number
+is reset.  The snapshot number is incremented for each tagged development
+snapshot.  The CVS tag for snapshots is "<tt>xf-M_m_P_s</tt>".  When
+the development branch enters feature freeze, the snapshot number may be
+bumped to 900, and a stable branch may be created for the next full release.
+The branch is called "<tt>xf-M_m-branch</tt>".  The snapshot number is
+incremented from there until the release is finalised.  Each of these
+snapshots is a "release candidate".  When the release is finalised, the
+minor version is incremented, the patch level is set to zero, and the
+snapshot number removed.
+
+Here's an example which shows the version number sequence for the
+development leading up to version 4.1.0:
+
+<descrip>
+  <tag><tt>4.0.99.1</tt></tag>
+	The first snapshot of the pre-4.1 development branch.
+  <tag><tt>4.0.99.23</tt></tag>
+	The twenty-third snapshot of the pre-4.1 development branch.
+  <tag><tt>4.0.99.900</tt></tag>
+	The start of the 4.1 feature freeze, which marks the creation of
+	the "<tt>xf-4_1-branch</tt>" branch.  That branch is the "stable"
+	branch for the 4.1.x releases.
+  <tag><tt>4.0.99.903</tt></tag>
+	The third 4.1.0 release candidate.
+  <tag><tt>4.1.0</tt></tag>
+	The 4.1.0 release.
+  <tag><tt>4.1.99.1</tt></tag>
+	The first pre-4.2 development snapshot, which  is the first main
+	branch snapshot after creating the 4.1 stable branch.
+</descrip>
+
+<sect1>Stable Branch
+<p>
+
+After a full release, the stable branch for the release will be maintained
+with bug fixes and important updates until the next full release.  All
+snapshots on this branch are considered "release candidates", so the
+first is indicated by setting <tt>s</tt> to 901.  The snapshot number
+is then incremented for each subsequent release candidate until the
+update release if finalised.  The patch level value (<tt>P</tt>) is
+incremented for each update release.
+
+Here's an example which shows the version number sequence for the
+4.1.x stable branch.
+
+<descrip>
+  <tag><tt>4.0.99.900</tt></tag>
+	The start of the 4.1 feature freeze, which marks the creation of
+	the "<tt>xf-4_1-branch</tt>" branch.  That branch is the "stable"
+	branch for the 4.1.x releases.
+  <tag><tt>4.0.99.903</tt></tag>
+	The third 4.1.0 release candidate.
+  <tag><tt>4.1.0</tt></tag>
+	The 4.1.0 release.
+  <tag><tt>4.1.0.901</tt></tag>
+	The first pre 4.1.1 snapshot.
+  <tag><tt>4.1.0.903</tt></tag>
+	The third pre 4.1.1 snapshot, also known as the third 4.1.1 release
+	candidate.
+  <tag><tt>4.1.1</tt></tag>
+	The 4.1.1 release.
+  <tag><tt>4.1.1.901</tt></tag>
+	The first pre 4.1.2 snapshot.
+  <tag><tt>4.1.2</tt></tag>
+	The 4.1.2 release.
+</descrip>
+
+<sect>Version Numbering Scheme for XFree86 4.0.x.
+<p>
+
+The version numbering format for XFree86 4.0.x releases is <tt>M.m.nx</tt>,
+where <tt>M</tt> is the major version number (4), <tt>m</tt> is the
+minor version number (0), <tt>n</tt> is the sub-minor version number,
+and <tt>x</tt> is a letter.  Full release versions up to and including
+4.0.2 were 4.0, 4.0.1, and 4.0.2.  Between-release snapshots are
+indicated by including <tt>x</tt>, a lower case letter.  For example,
+the first post-4.0.1 snapshot was 4.0.1a.  Release candidates have
+been indicated by setting <tt>x</tt> to a one or two letter combination
+with the first letter being "Z".  For example, 4.0.1Z was the first
+4.0.2 release candidate.
+
+The next 4.0.x release will be an update release, not a full release.
+These update releases will be indicated by incrementing the sub-minor
+version number.  So, the first post-4.0.2 update release will be 4.0.3.
+Between-release snapshots will continue to be indicated with a lower
+case letter, so the first pre-4.0.3 snapshot will be 4.0.2a.
+
+The following example illustrates the release sequence from 4.0 through
+to the post-4.0.2 update releases.
+
+<descrip>
+  <tag><tt>4.0</tt></tag>
+	The 4.0 release.
+  <tag><tt>4.0a</tt></tag>
+	The first post-4.0 development snapshot.
+  <tag><tt>4.0f</tt></tag>
+	The sixth post-4.0 development snapshot.
+  <tag><tt>4.0Z</tt></tag>
+	The 4.0.1 release candidate.
+  <tag><tt>4.0.1</tt></tag>
+	The 4.0.1 release.
+  <tag><tt>4.0.1a</tt></tag>
+	The first post-4.0.1 development snapshot.
+  <tag><tt>4.0.1f</tt></tag>
+	The sixth post-4.0.1 development snapshot.
+  <tag><tt>4.0Z</tt></tag>
+	The first 4.0.2 release candidate.
+  <tag><tt>4.0Zb</tt></tag>
+	The third 4.0.2 release candidate.
+  <tag><tt>4.0.2</tt></tag>
+	The 4.0.2 release.
+  <tag><tt>4.0.2a</tt></tag>
+	The first pre-4.0.3 snapshot/release candidate.
+  <tag><tt>4.0.2c</tt></tag>
+	The third pre-4.0.3 snapshot/release candidate.
+  <tag><tt>4.0.3</tt></tag>
+	The 4.0.3 update release.
+  <tag><tt>4.0.3a</tt></tag>
+	The first pre-4.0.4 snapshot/release candidate.
+  <tag><tt>4.0.4</tt></tag>
+	The 4.0.4 update release.
+</descrip>
+  
+<sect>Pre-4.0 Development Versions
+<p>
+
+This section is included mostly for historical reasons.
+
+The development leading up to 4.0 started from version 3.2A, but much of
+it happened on a separate development branch.  The "new design" work on
+that development branch was first folded into the main development branch
+at version 3.9N.  Up until the XFree86 CVS was made publicly available,
+all versions containing one or more letters were internal development
+snapshots.  The internal development snapshots continued through the
+following sequence: 3.9N, 3.9Na, ..., 3.9Nz, 3.9P, 3.9Pa, ..., 3.9Py,
+3.9.15, 3.9.15a, ..., 3.9.16, 3.9.16a, ..., 3.9.17, 3.9.17a, ..., 3.9.18,
+3.9.18a, ..., 4.0.  The 3.9.15, 3.9.16, etc versions were public pre-4.0
+beta releases.
+
+<sect>Version Numbering Scheme for XFree86 3.3.x.
+<p>
+
+The version numbering format for XFree86 3.3.x releases is <tt>M.m.nx</tt>,
+where <tt>M</tt> is the major version number (3), <tt>m</tt> is the
+minor version number (3), <tt>n</tt> is the sub-minor version number,
+and <tt>x</tt> is a letter.  Between-release snapshots are indicated by
+including <tt>x</tt>, a lower case letter.  An exception to this scheme
+was the 3.3.3.1 release, which was an update to the 3.3.3 release.
+
+<descrip>
+  <tag><tt>3.3</tt></tag>
+	The 3.3 release.
+  <tag><tt>3.3a</tt></tag>
+	The first post-3.3 development snapshot.
+  <tag><tt>3.3.1</tt></tag>
+	The 3.3.1 release.
+  <tag><tt>3.3.1a</tt></tag>
+	The first post-3.3.1 development snapshot.
+  <tag><tt>3.3.2</tt></tag>
+	The 3.3.2 release.
+  <tag><tt>3.3.2a</tt></tag>
+	The first post-3.3.2 development snapshot.
+  <tag><tt>3.3.3</tt></tag>
+	The 3.3.3 release.
+  <tag><tt>3.3.3a</tt></tag>
+	The first post-3.3.3 development snapshot.
+  <tag><tt>3.3.3.1</tt></tag>
+	The 3.3.3.1 release.
+  <tag><tt>3.3.3.1a</tt></tag>
+	The first post-3.3.3.1 development snapshot.
+  <tag><tt>3.3.4</tt></tag>
+	The 3.3.4 release.
+  <tag><tt>3.3.4a</tt></tag>
+	The first post-3.3.4 snapshot.
+  <tag><tt>3.3.5</tt></tag>
+	The 3.3.5 release.
+  <tag><tt>3.3.5a</tt></tag>
+	The first post-3.3.5 snapshot.
+  <tag><tt>3.3.6</tt></tag>
+	The 3.3.6 release.
+  <tag><tt>3.3.6a</tt></tag>
+	The first post-3.3.6 snapshot.
+</descrip>
+  
+<sect>Finding the XFree86 X Server Version From a Client
+<p>
+
+The XFree86 X servers report a <tt>VendorRelease</tt> value that matches
+the XFree86 version number.  There have been some cases of releases where
+this value wasn't set correctly.  The rules for interpreting this value
+as well as the known exceptions are outlined here.
+
+For 3.3.x versions, the <tt>VendorRelease</tt> value is <tt>Mmnp</tt>.
+That is, version <tt>M.m.n.p</tt> has <tt>VendorRelease</tt> set to
+<tt>M&nbsp;*&nbsp;1000&nbsp;+&nbsp;m&nbsp;*&nbsp;100&nbsp;+&nbsp;n&nbsp;*&nbsp;10&nbsp;+&nbsp;p</tt>.
+Exceptions to this are:  The value wasn't incremented for the 3.3.3.1
+release, and for the 3.3.4 and 3.3.5 releases the value was incorrectly
+set to <tt>Mmn</tt>
+(<tt>M&nbsp;*&nbsp;100&nbsp;+&nbsp;m&nbsp;*&nbsp;10&nbsp;+&nbsp;n</tt>).
+This was corrected for the 3.3.6 release.
+
+For versions 3.9.15 to 4.0.x, the <tt>VendorRelease</tt> value is
+<tt>Mmnn</tt>.  That is, version <tt>M.m.n</tt> has <tt>VendorRelease</tt>
+set to
+<tt>M&nbsp;*&nbsp;1000&nbsp;+&nbsp;m&nbsp;*&nbsp;100&nbsp;+&nbsp;n</tt>.
+There have been no exceptions to this rule.
+
+For post-4.0.2 development and release versions using the new numbering
+scheme, the <tt>VendorRelease</tt> value is <tt>MMmmPPsss</tt>.  That
+is, version <tt>M.m.P.s</tt> has <tt>VendorRelease</tt> set to
+<tt>M&nbsp;*&nbsp;10000000&nbsp;+&nbsp;m&nbsp;*&nbsp;100000&nbsp;+&nbsp;P&nbsp;*&nbsp;1000&nbsp;+&nbsp;s</tt>.
+Note: 4.0.3 and any other 4.0.x releases will continue with the
+<tt>Mmnn</tt> scheme.
+
+The following is a code fragment taken from <tt>xdpyinfo.c</tt> that shows
+how the <tt>VendorRelease</tt> information can be interpreted.
+
+<tscreen><verb>
+
+    if (strstr(ServerVendor(dpy), "XFree86")) {
+        int vendrel = VendorRelease(dpy);
+
+        printf("XFree86 version: ");
+        if (vendrel < 336) {
+            /*
+             * vendrel was set incorrectly for 3.3.4 and 3.3.5, so handle
+             * those cases here.
+             */
+            printf("%d.%d.%d", vendrel / 100,
+                              (vendrel / 10) % 10,
+                               vendrel       % 10);
+        } else if (vendrel < 3900) {
+            /* 3.3.x versions, other than the exceptions handled above */
+            printf("%d.%d", vendrel / 1000,
+                           (vendrel /  100) % 10);
+            if (((vendrel / 10) % 10) || (vendrel % 10)) {
+                printf(".%d", (vendrel / 10) % 10);
+                if (vendrel % 10) {
+                    printf(".%d", vendrel % 10);
+                }
+            }
+        } else if (vendrel < 40000000) {
+            /* 4.0.x versions */
+            printf("%d.%d", vendrel / 1000,
+                           (vendrel /   10) % 10);
+            if (vendrel % 10) {
+                printf(".%d", vendrel % 10);
+            }
+        } else {
+            /* post-4.0.x */
+            printf("%d.%d.%d", vendrel / 10000000,
+                              (vendrel /   100000) % 100,
+                              (vendrel /     1000) % 100);
+            if (vendrel % 1000) {
+                printf(".%d", vendrel % 1000);
+            }
+        }
+    }
+</verb></tscreen>
+
+</article>
diff --git a/sgml/XKB-Config.sgml b/sgml/XKB-Config.sgml
new file mode 100644
index 0000000..564fe03
--- /dev/null
+++ b/sgml/XKB-Config.sgml
@@ -0,0 +1,221 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+
+<article>
+<title>The XKB Configuration Guide
+<author>Kamil Toman, Ivan U. Pascal
+<date>25 November 2002
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $
+</ident>
+
+<abstract>
+This document describes how to configure XFree86 XKB from a user's point
+a few. It converts basic configuration syntax and gives also a few examples.
+</abstract>
+
+<toc>
+
+<p>
+<sect>Overview
+<p>
+The XKB configuration is decomposed into a number of components. Selecting
+proper parts and combining them back you can achieve most of configurations
+you might need. Unless you have a completely atypical keyboard you really don't
+need to touch any of xkb configuration files.
+
+<sect>Selecting XKB Configuration
+<p>
+The easiest and the most natural way how to specify a keyboard mapping is
+tu use <tt>rules</tt> component. As its name suggests it describes a number of general
+rules how to combine all bits and pieces into a valid and useful keyboard 
+mapping. All you need to do is to select a suitable rules file and then to
+feed it with a few parameters that will adjust the keyboard behaviour to
+fulfill your needs.
+<p>
+The parameters are:
+<itemize>
+<item><tt>XkbRules </tt>- files of rules to be used for keyboard mapping 
+composition
+<item><tt>XkbModel </tt>- name of model of your keyboard type
+<item><tt>XkbLayout </tt>- layout(s) you intend to use
+<item><tt>XkbVariant </tt>- variant(s) of layout you intend to use
+<item><tt>XkbOptions </tt>- extra xkb configuration options
+</itemize>
+<p>
+The proper rules file depends on your vendor. In reality, the commonest
+file of rules is <tt>xfree86</tt>. For each rules file there is a description
+file named <tt>&lt;vendor-rules&gt;.lst</tt>, for instance <tt>xfree86.lst</tt> 
+which is located in xkb configuration subdirectory <tt>rules</tt> (for example 
+<tt>/etc/X11/xkb/rules</tt>).
+
+<sect1>Basic Configuration
+<p>
+Let's say you want to configure a PC style America keyboard with 104
+keys as described in <tt>xfree86.lst</tt>. It can be done by simply writing
+several lines from below to you XFree86 configuration file (often
+found as <tt>/etc/X11/XF86Config-4</tt> or <tt>/etc/X11/XF86Config</tt>):
+<tscreen><verb>
+Section "InputDevice"
+    Identifier "Keyboard1"
+    Driver "Keyboard"
+
+    Option "XkbModel" "pc104"
+    Option "XkbLayout" "us"
+    Option "XKbOptions" ""
+EndSection
+</verb></tscreen>
+The values of parameters <tt>XkbModel</tt> and <tt>XkbLayout</tt> are really 
+not surprising. The parameters <tt>XkbOptions</tt> has been explicitly set to 
+empty set of parameters. The parameter <tt>XkbVariant</tt> has been left out. 
+That means the default variant named <tt>basic</tt> is loaded.
+<p>
+Of course, this can be also done at runtime using utility setxkbmap.
+Shell command loading the same keyboard mapping would look like:
+<tscreen><verb>
+setxkbmap -rules xfree86 -model pc104 -layout us -option ""
+</verb></tscreen>
+The configuration and the shell command would be very analogical
+for most other layouts (internationalized mappings). 
+
+<sect1>Advanced Configuration
+<p>
+Since XFree86 4.3.x you can use multi-layouts xkb configuration.
+What does it mean? Basically it allows to load up to four different
+keyboard layouts at a time. Each such layout would reside in its
+own group. The groups (unlike complete keyboard remapping) can be
+switched very fast from one to another by a combination of keys.
+<p>
+Let's say you want to configure your new Logitech cordless desktop
+keyboard, you intend to use three different layouts at the same
+time - us, czech and german (in this order), and that you are used
+to <tt>Alt-Shift</tt> combination for switching among them.
+<p>
+Then the configuration snippet could look like this:
+<tscreen><verb>
+Section "InputDevice"
+    Identifier "Keyboard1"
+    Driver "Keyboard"
+
+    Option "XkbModel" "logicordless"
+    Option "XkbLayout" "us,cz,de"
+    Option "XKbOptions" "grp:alt_shift_toggle"
+EndSection
+</verb></tscreen>
+Of course, this can be also done at runtime using utility setxkbmap.
+Shell command loading the same keyboard mapping would look like:
+<tscreen><verb>
+setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \
+         -option "grp:alt_shift_toggle"
+</verb></tscreen>
+
+
+<sect1>Even More Advanced Configuration
+<p>
+Okay, let's say you are more demanding. You do like the example
+above but you want it to change a bit. Let's imagine you want
+the czech keyboard mapping to use another variant but basic.
+The configuration snippet then changes into:
+<tscreen><verb>
+Section "InputDevice"
+    Identifier "Keyboard1"
+    Driver "Keyboard"
+
+    Option "XkbModel" "logicordless"
+    Option "XkbLayout" "us,cz,de"
+    Option "XkbVariant" ",bksl,"
+    Option "XKbOptions" "grp:alt_shift_toggle"
+EndSection
+</verb></tscreen>
+That's seems tricky but it is not. The logic for settings of variants
+is the same as for layouts, that means the first and the third variant
+settings are left out (set to <tt>basic</tt>), the second is set to 
+<tt>bksl</tt> (a special variant with an enhanced definition of the backslash 
+key).
+<p>
+Analogically, the loading runtime will change to:
+<tscreen><verb>
+setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \
+         -variant ",bksl," -option "grp:alt_shift_toggle"
+</verb></tscreen>
+
+<sect1>Basic Global Options
+<p>
+See rules/*.lst files.
+
+<!-- 
+  TODO: More detailed descriptions of options. User's often get confused.
+-->
+
+<sect>Direct XKB Configuration
+<p>
+Generally, you can directly prescribe what configuration of each of basic
+xkb components should be used to form the resulting keyboard mapping.
+This method is rather "brute force". You precisely need to know the structure
+and the meaning of all of used configuration components. 
+<p>
+This method also exposes all xkb configuration details directly into XFree86
+configuration file which is a not very fortunate fact.
+In rare occasions it may be needed, though. So how does it work?
+
+<sect1>Basic Components
+<p>
+There are five basic components used to form a keyboard mapping:
+<itemize>
+<item><em>key codes</em> - a translation of the scan codes produced by the 
+                        keyboard into a suitable symbolic form
+              
+<item><em>types</em> - a specification of what various combinations of 
+modifiers produce
+
+<item><em>key symbols</em> - a translation of symbolic key codes into actual 
+symbols
+
+<item><em>geometry</em> - a description of physical keyboard geometry
+
+<item><em>compatibility maps</em> - a specification of what action should
+each key produce in order to preserve compatibility with XKB-unware clients
+</itemize>
+
+<sect1>Example Configuration
+<p>
+Look at the following example:
+<tscreen><verb>
+Section "InputDevice"
+    Identifier "Keyboard0"
+    Driver "Keyboard"
+
+    Option "XkbKeycodes" "xfree86"
+    Option "XkbTypes"    "default"
+    Option "XkbSymbols"  "en_US(pc104)+de+swapcaps"
+    Option "XkbGeometry" "pc(pc104)"
+    Option "XkbCompat"   "basic+pc+iso9995"
+EndSection
+</verb></tscreen>
+
+This configuration sets the standard XFree86 default interpretation of keyboard 
+keycodes, sets the default modificator types. The
+symbol table is composed of extended US keyboard layout in its
+variant for pc keyboards with 104 keys plus all keys
+for german layout are redefined respectively. Also the logical
+meaning of <tt>Caps-lock</tt> and <tt>Control</tt> keys is swapped.
+The standard keyboard geometry (physical look) is set to pc style
+keyboard with 104 keys. The compatibility map is set to allow
+basic shifting, to allow Alt keys to be interpreted and also
+to allow iso9995 group shifting.
+
+<!--
+    TODO: add information about layout shifting:
+    TODO: us+ru(winkeys):2+de:3
+-->
+
+<sect>Keymap XKB Configuration
+<p>
+It is the formerly used way to configure xkb. The user included a special
+keymap file which specified the direct xkb configuration. This method
+has been obsoleted by previously described rules files which are far
+more flexible and allow simpler and more intuitive syntax. It is
+preserved merely for compatibility reasons. Avoid using it if it is possible.
+<p>
+
+</article>
diff --git a/sgml/XKB-Enhancing.sgml b/sgml/XKB-Enhancing.sgml
new file mode 100644
index 0000000..44bc10f
--- /dev/null
+++ b/sgml/XKB-Enhancing.sgml
@@ -0,0 +1,557 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+
+<article>
+<title>How to further enhance XKB configuration
+<author>Kamil Toman, Ivan U. Pascal
+<date>25 November 2002
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml,v 1.2 2003/02/25 19:31:02 dawes Exp $
+</ident>
+
+<abstract>
+This guide is aimed to relieve one's labour to create a new (internationalized)
+keyboard layout. Unlike other documents this guide accents the keymap 
+developer's point of view.
+</abstract>
+
+<toc>
+
+<p>
+
+<sect>Overview
+<p>
+The developer of a new layout should read the xkb
+protocol specification (<url url="http://www.x-docs.org/XKB/XKBproto.pdf"
+name="The X Keyboard Extension: Protocol Specification">) at least
+to clarify for himself some xkb-specific terms used in this document
+and elsewhere in xkb configuration. Also it shows wise to understand
+how the X server and a client digest their keyboard inputs 
+(with and without xkb).
+<p>
+A useful source is also <url url="http://www.tsu.ru/~pascal/en/xkb" name="Ivan 
+Pascal's text about xkb configuration"> often referenced throughout this 
+document.
+
+<p>
+Note that this document covers only enhancements which
+are to be made to XFree86 version 4.3.x and above.
+
+
+<sect>The Basics
+<p>
+At the startup (or at later at user's command) X server starts its xkb
+keyboard module extension and reads data from a compiled configuration
+file.
+<p>
+This compiled configuration file is prepared by the program <tt>xkbcomp</tt>
+which behaves altogether as an ordinary compiler (see <tt>man xkbcomp</tt>). 
+Its input are human readable xkb configuration files which are verified and
+then composed into a useful xkb configuration. Users don't need to mess with
+<tt>xkbcomp</tt> themselves, for them it is invisible. Usually, it is started 
+upon X server startup.
+<p>
+As you probably already know, the xkb configuration consists of five
+main modules:
+<descrip>
+<tag/Keycodes/
+     Tables that defines translation from keyboard scan codes into reasonable
+     symbolic names, maximum, minimum legal keycodes, symbolic aliases and
+     description of physically present LED-indicators. The primary sence of 
+     this component is to allow definitions of maps of symbols (see below) 
+     to be independent of physical keyboard scancodes. There are two main 
+     naming conventions for symbolic names (always four bytes long): 
+     <itemize>
+       <item> names which express some traditional meaning like 
+       <tt>&lt;SPCE&gt;</tt> (stands for space bar) or 
+       <item> names which express some relative positioning on a keyboard, for 
+       example <tt>&lt;AE01&gt;</tt> (an exclamation mark on US keyboards), on 
+       the right there are keys <tt>&lt;AE02&gt;</tt>, <tt>&lt;AE03&gt;</tt> 
+       etc.
+     </itemize>
+
+<tag/Types/
+    Types describe how the produced key is changed by active modifiers (like
+    Shift, Control, Alt, ...). There are several predefined types which
+    cover most of used combinations.
+
+<tag/Compat/
+    Compatibility component defines internal behaviour of modifiers. Using
+    compat component you can assign various actions (elaborately described
+    in xkb specification) to key events. This is also the place where
+    LED-indicators behaviour is defined.
+
+<tag/Symbols/
+    For i18n purposes, this is the most important table. It defines what
+    values (=symbols) are assigned to what keycodes (represented by their
+    symbolic name, see above). There may be defined more than one value
+    for each key and then it depends on a key type and on modifiers state
+    (respective compat component) which value will be the resulting one.
+
+<tag/Geometry/
+    Geometry files aren't used by xkb itself but they may be used by some
+    external programs to depict a keyboard image.
+</descrip>
+All these components have the files located in xkb configuration tree
+in subdirectories with the same names (usually in <tt>/usr/lib/X11/xkb</tt>).
+
+
+<sect>Enhancing XKB Configuration
+<p>
+Most of xkb enhancements concerns a need to define new output symbols
+for the some input key events. In other words, a need to define a new
+symbol map (for a new language, standard or just to feel more comfortable
+when typing text).
+<p>
+What do you need to do? Generally, you have to define following things:
+<itemize>
+<item> the map of symbols itself
+<item> the rules to allow users to select the new mapping
+<item> the description of the new layout
+</itemize>
+<p>
+First of all, it is good to go through existing layouts and to examine
+them if there is something you could easily adjust to fit your needs.
+Even if there is nothing similar you may get some ideas about basic
+concepts and used tricks.
+<p>
+<sect1>Levels And Groups
+<p>
+Since XFree86 4.3.0 you can use <bf>multi-layout</bf> concept of xkb 
+configuration.
+Though it is still in boundaries of xkb protocol and general ideas, the
+keymap designer must obey new rules when creating new maps. In exchange
+we get a more powerful and cleaner configuration system.
+<p>
+Remember that it is the application which must decide which symbol
+matches which keycode according to effective modifier state. The X server
+itself sends only an input event message to. Of course, usually
+the general interpretation is processed by Xlib, Xaw, Motif, Qt, Gtk
+and similar libraries. The X server only supplies its mapping table
+(usually upon an application startup).
+<p>
+You can think of the X server's symbol table as of a irregular table where each
+keycode has its row and where each combination of modifiers determines exactly
+one column. The resulting cell then gives the proper symbolic value. Not all
+keycodes need to bind different values for different combination of modifiers.
+<tt>&lt;ENTER&gt;</tt> key, for instance, usually doesn't depend on any
+modifiers so it its row has only one column defined.
+<p>
+Note that in XKB there is no prior assumption that certain modifiers are bound
+to certain columns. By editing proper files (see <ref id="keytypes">) this 
+mapping can be changed as well.
+<p>
+Unlike the original X protocol the XKB approach is far more
+flexible. It is comfortable to add one additional XKB term - group. You can
+think of a group as of a vector of columns per each keycode (naturally the
+dimension of this vector may differ for different keycodes). What is it good
+for? The group is not very useful unless you intend to use more than one
+logically different set of symbols (like more than one alphabet) defined in a
+single mapping table. But then, the group has a natural meaning - each symbol
+set has its own group and changing it means selecting a different one.
+XKB approach allows up to four different groups. The columns inside each group 
+are called (shift) levels. The X server knows the current group and reports it 
+together with modifier set and with a keycode in key events.
+<p>
+To sum it up:
+<p>
+<itemize>
+<item> for each keycode XKB keyboard map contains up to four one-dimensional
+   tables - groups (logically different symbol sets)
+<item> for each group of a keycode XKB keyboard map contains some columns 
+   - shift levels (values reached by combinations of Shift, Ctrl, Alt, ... 
+     modifiers)
+<item> different keycodes can have different number of groups
+<item> different groups of one keycode can have different number of shift levels
+<item> the current group number is tracked by X server 
+</itemize>
+<p>
+It is clear that if you sanely define levels, groups and sanely bind
+modifiers and associated actions you can have simultaneously loaded up to
+four different symbol sets where each of them would reside in its own group.
+<p>
+The multi-layout concept provides a facility to manipulate xkb groups
+and symbol definitions in a way that allows almost arbitrary composition of 
+predefined symbol tables. To keep it fully functional you have to:
+<itemize>
+<item> define all symbols only in the first group
+<item> (re)define any modifiers with extra care to avoid strange (anisometric)
+   behaviour
+</itemize>
+<p>
+<sect>Defining New Layouts
+<p>
+<!--
+  TODO: It may be better to merge IP01 docs and this guide.
+-->
+See <url url="http://www.tsu.ru/~pascal/en/xkb/internals.html" name="Some Words 
+About XKB internals"> for explanation of used xkb terms and problems
+addressed by XKB extension.
+<p>
+See <url url="http://www.tsu.ru/~pascal/en/xkb/gram-common.html" name="Common 
+notes about XKB configuration files language"> for more precise explanation of 
+syntax of xkb configuration files.
+<p>
+<sect1>Predefined XKB Symbol Sets
+<p>
+If you are about to define some European symbol map extension, you might
+want to use on of four predefined latin alphabet layouts.
+<!--
+    TODO: more details
+    TODO: something similiar for phonetic layouts
+    TODO: what are pc/pc layouts good for???
+-->
+<p>
+Okay, let's assume you want extend an existing keymap and you want to override
+a few keys. Let's take a simple U.K. keyboard as an example (defined in 
+<tt>pc/gb</tt>):
+<p>
+<tscreen><verb>
+partial default alphanumeric_keys
+xkb_symbols "basic" {
+  include "pc/latin"
+
+  name[Group1]="Great Britain";
+
+  key <AE02>  { [         2,   quotedbl,  twosuperior,    oneeighth ] };
+  key <AE03>  { [         3,   sterling, threesuperior,    sterling ] };
+  key <AC11>  { [apostrophe,         at, dead_circumflex, dead_caron] };
+  key <TLDE>  { [     grave,    notsign,          bar,          bar ] };
+  key <BKSL>  { [numbersign, asciitilde,   dead_grave,   dead_breve ] };
+  key <RALT>  { type[Group1]="TWO_LEVEL",
+                [ ISO_Level3_Shift, Multi_key ]   };
+
+  modifier_map Mod5   { <RALT> };
+};
+</verb></tscreen>
+<!--
+    TODO: ref IP01 file syntax TODO: some words about symbolic names like 
+    'sterling' and also about
+    TODO: unicode characters (for non-latin alphabets),
+    TODO: ref to compatibility symbolic names vs. unicode
+-->
+<p>
+It defines a new layout in <tt>basic</tt> variant as an extension of common 
+latin alphabet layout. The layout (symbol set) name is set to "Great Britain".
+Then there are redefinitions of a few keycodes and a modifiers binding. As you 
+can see the number of shift levels is the same for <tt>&lt;AE02&gt;</tt>, 
+<tt>&lt;AE03&gt;</tt>, <tt>&lt;AC11&gt;</tt>, <tt>&lt;TLDE&gt;</tt> and 
+<tt>&lt;BKSL&gt;</tt> keys but it differs from number of shift levels of 
+<tt>&lt;RALT&gt;</tt>.
+<p>
+Note that the <tt>&lt;RALT&gt;</tt> key itself is a binding key for Mod5 and 
+that it
+serves like a shift modifier for LevelThree, together with Shift
+as a multi-key. It is a good habit to respect this rule in a new similar
+layout.
+<p>
+Okay, you could now define more variants of your new layout besides
+<tt>basic</tt> simply by including (augmenting/overriding/...) the basic 
+definition and altering what may be needed.
+
+<sect1>Key Types<label id="keytypes">
+<p>
+
+The differences in the number of columns (shift levels) are caused by 
+a different types of keys (see the types definition in section basics).  Most 
+keycodes have implicitly set the keytype in the included 
+<tt>&dquot;pc/latin&dquot;</tt> file to 
+<tt>&dquot;FOUR_LEVEL_ALPHABETIC&dquot;</tt>. The only exception is 
+<tt>&lt;RALT&gt;</tt> keycode which is explicitly set 
+<tt>&dquot;TWO_LEVEL&dquot;</tt> keytype.
+<p>
+All those names refer to pre-defined shift level schemes. Usually you can
+choose a suitable shift level scheme from <tt>default</tt> types scheme list
+in proper xkb component's subdirectory. 
+<p>
+The most used schemes are:
+<descrip>
+<tag/ONE_LEVEL/
+   The key does not depend on any modifiers. The symbol from first level
+   is always chosen.
+
+<tag/TWO_LEVEL/
+   The key uses a modifier Shift and may have two possible values.
+   The second level may be chosen by Shift modifier. If Lock modifier
+   (usually Caps-lock) applies the symbol is further processed using
+   system-specific capitalization rules. If both Shift+Lock modifier apply the
+   symbol from the second level is taken and capitalization rules are applied
+   (and usually have no effect).
+    
+<tag/ALPHABETIC/
+   The key uses modifiers Shift and Lock. It may have two possible
+   values. The second level may be chosen by Shift modifier. When Lock
+   modifier applies, the symbol from the first level is taken and further
+   processed using system-specific capitalization rules. If both Shift+Lock
+   modifier apply the symbol from the first level is taken and no
+   capitalization rules applied. This is often called shift-cancels-caps
+   behaviour.
+
+<tag/THREE_LEVEL/
+   Is the same as TWO_LEVEL but it considers an extra modifier -
+   LevelThree which can be used to gain the symbol value from the third
+   level. If both Shift+LevelThree modifiers apply the value from the third
+   level is also taken. As in TWO_LEVEL, the Lock modifier doesn't influence
+   the resulting level. Only Shift and LevelThree are taken into that
+   consideration. If the Lock modifier is active capitalization rules
+   are applied on the resulting symbol.
+   
+<tag/FOUR_LEVEL/
+   Is the same as THREE_LEVEL but unlike LEVEL_THREE if both Shift+LevelThree
+   modifiers apply the symbol is taken from the fourth level.
+
+<tag/FOUR_LEVEL_ALPHABETIC/
+   Is similar to FOUR_LEVEL but also defines shift-cancels-caps behaviour
+   as in ALPHABETIC. If Lock+LevelThree apply the symbol from the
+   third level is taken and the capitalization rules are applied.
+   If Lock+Shift+LevelThree apply the symbol from the third level is taken
+   and no capitalization rules are applied.
+ 
+<tag/KEYPAD/
+   As the name suggest this scheme is primarily used for numeric keypads.
+   The scheme considers two modifiers - Shift and NumLock. If none
+   of modifiers applies the symbol from the first level is taken. If either 
+   Shift or NumLock modifiers apply the symbol from the second level is taken.
+   If both Shift+NumLock modifiers apply the symbol from the first level
+   is taken. Again, shift-cancels-caps variant.
+   
+<tag/FOUR_LEVEL_KEYPAD/
+   Is similar to KEYPAD scheme but considers also LevelThree modifier.
+   If LevelThree modifier applies the symbol from the third level is taken.
+   If Shift+LevelThree or NumLock+LevelThree apply the symbol from the fourth
+   level is taken. If all Shift+NumLock+LevelThree modifiers apply the symbol
+   from the third level is taken. This also, shift-cancels-caps variant.
+</descrip>
+<p>
+Besides that, there are several schemes for special purposes:
+<descrip>
+<tag/PC_BREAK/
+    It is similar to TWO_LEVEL scheme but it considers the Control
+    modifier rather than Shift. That means, the symbol from the second level
+    is chosen by Control rather than by Shift.
+<tag/PC_SYSRQ/
+    It is similar to TWO_LEVEL scheme but it considers the Alt modifier rather 
+    than Shift. That means, the symbol from the second level
+    is chosen by Alt rather than by Shift.
+<tag/CTRL+ALT/
+    The key uses modifiers Alt and Control. It may have two possible
+    values. If only one modifier (Alt or Control) applies the symbol
+    from the first level is chosen. Only if both Alt+Control modifiers apply
+    the symbol from the second level is chosen.
+<tag/SHIFT+ALT/
+    The key uses modifiers Shift and Alt. It may have two possible values.
+    If only one modifier (Alt or Shift) applies the symbol
+    from the first level is chosen. Only if both Alt+Shift modifiers apply
+    the symbol from the second level is chosen.
+</descrip>
+<p>
+If needed, special <tt>caps</tt> schemes may be used. They redefine the 
+standard behaviour of all <tt>*ALPHABETIC</tt> types. The layouts (maps of 
+symbols) with keys defined in respective types then automatically change
+their behaviour accordingly. Possible redefinitions are:
+<itemize>
+<item>internal
+<item>internal_nocancel
+<item>shift
+<item>shift_nocancel
+</itemize>
+None of these schemes should be used directly. They are defined merely
+for <tt>'caps:'</tt> xkb options (used to globally change the layouts 
+behaviour).
+<p>
+Don't alter any of existing key types. If you need a different behaviour
+create a new one.
+
+<sect2>More On Definitions Of Types
+<p>
+When the XKB software deals with a separate type description it gets
+a complete list of modifiers that should be taken into account from the 
+<tt>'modifiers=&lt;list of modifiers&gt;'</tt> list and expects that a set
+of <tt>'map[&lt;combination of modifiers&gt;]=&lt;list of modifiers&gt;'</tt>
+instructions that contain the mapping for each combination of modifiers 
+mentioned in that list. Modifiers that are not explicitly listed are NOT taken 
+into account
+when the resulting shift level is computed.
+If some combination is omitted the program (subroutine) should choose the first
+level for this combination (a quite reasonable behavior).
+<p>
+Lets consider an example with two modifiers <tt>ModOne</tt> and <tt>ModTwo</tt>:
+<tscreen><verb>
+type "..." {
+    modifiers = ModOne+ModTwo;
+    map[None] = Level1;
+    map[ModOne] = Level2;
+};
+</verb></tscreen>
+In this case the map statements for <tt>ModTwo</tt> only and 
+<tt>ModOne+ModTwo</tt> are omitted.  It means that if the <tt>ModTwo</tt> is 
+active the subroutine can't found explicit mapping for such combination an will 
+use the <em>default level</em> i.e. Level1.
+<p>
+But in the case the type described as:
+<tscreen><verb>
+type "..." {
+    modifiers = ModOne;
+    map[None] = Level1;
+    map[ModOne] = Level2;
+};
+</verb></tscreen>
+the ModTwo will not be taken into account and the resulting level depends on 
+the ModOne state only. That means, ModTwo alone produces the Level1 but the 
+combination ModOne+ModTwo produces the Level2 as well as ModOne alone.
+<p>
+What does it mean if the second modifier is the Lock? It means that in
+the first case (the Lock itself is included in the list of modifiers but 
+combinations with this modifier aren't mentioned in the map statements) 
+the internal capitalization rules will be applied to the symbol from the first 
+level. But in the second case the capitalization will be applied to the symbol
+chosen accordingly to he first modifier - and this can be the symbol from the
+first as well as from the second level.
+<p>
+Usually, all modifiers introduced in <tt>'modifiers=&lt;list of 
+modifiers&gt;'</tt> list are used for shift level calculation and then 
+discarded. Sometimes this is not desirable. If you want to use a modifier
+for shift level calculation but you don't want to discard it, you may
+list in '<tt>preserve[&lt;combination of modifiers&gt;]=&lt;list of 
+modifiers&gt;'</tt>. That means, for a given combination all listed modifiers
+will be preserved. If the Lock modifier is preserved then the resulting
+symbol is passed to internal capitalization routine regardless whether
+it has been used for a shift level calculation or not.
+<p>
+Any key type description can use both real and virtual modifiers. Since real 
+modifiers always have standard names it is not necessary to explicitly declare  
+them. Virtual modifiers can have arbitrary names and can be declared (prior
+using them) directly in key type definition:
+<tscreen><verb>
+virtual_modifiers &lt;comma-separated list of modifiers&gt;  ;
+</verb></tscreen>
+as seen in for example <tt>basic</tt>, <tt>pc</tt> or <tt>mousekeys</tt> key 
+type definitions.
+
+<sect1>Rules
+<p>
+Once you are finished with your symbol map you need to add it
+to rules file. The rules file describes how all the
+five basic keycodes, types, compat, symbols and geometry components
+should be composed to give a sensible resulting xkb configuration.
+<p>
+The main advantage of rules over formerly used keymaps is a possibility
+to simply parameterize (once) fixed patterns of configurations and thus
+to elegantly allow substitutions of various local configurations
+into predefined templates.
+<p>
+A pattern in a rules file (often located in 
+<tt>/usr/lib/X11/xkb/rules</tt>) can be parameterized with four other arguments:
+<tt>Model</tt>, <tt>Layout</tt>, <tt>Variant</tt> and <tt>Options</tt>.
+For most cases parameters <tt>model</tt> and <tt>layout</tt> should
+be sufficient for choosing a functional keyboard mapping.
+<p>
+The rules file itself is composed of pattern lines and lines with rules. The pattern line starts with an exclamation mark ('<tt>!</tt>') 
+and describes how will the xkb interpret the following lines (rules). A sample 
+rules file looks like this:
+<tscreen><verb>
+! model 	                =	keycodes
+  macintosh_old	                =	macintosh
+  ...
+  *		                =	xfree86
+  
+! model		                =	symbols
+  hp		                =	+inet(&percnt;m)
+  microsoftpro	                =	+inet(&percnt;m)
+  geniuscomfy	                =	+inet(&percnt;m)
+
+! model	    layout[1]	        =	symbols
+  macintosh	us	        =	macintosh/us&percnt;(v[1])
+  *             *               =       pc/pc(&percnt;m)+pc/&percnt;l[1]&percnt;(v[1])
+  
+! model     layout[2]	        =	symbols
+  macintosh     us              =	+macintosh/us[2]&percnt;(v[2]):2
+  *		*               =	+pc/&percnt;l[2]&percnt;(v[2]):2
+  
+! option			=	types
+  caps:internal			=	+caps(internal)
+  caps:internal_nocancel	=	+caps(internal_nocancel)
+</verb></tscreen>
+
+Each rule defines what certain combination of values on the left side
+of equal sign ('<tt>=</tt>') results in. For example a (keyboard) model 
+<tt>macintosh_old</tt> instructs xkb to take definitions of keycodes
+from file <tt>keycodes/macintosh</tt> while the rest of models
+(represented by a wild card '<tt>*</tt>') instructs it to take them from
+file <tt>keycodes/xfree86</tt>. The wild card represents all possible
+values on the left side which were not found in any of the previous rules.
+The more specialized (more complete) rules have higher precedence than general 
+ones, i.e. the more general rules supply reasonable default values.
+<p>
+As you can see some lines contain substitution parameters - the parameters 
+preceded by the percent sign ('<tt>&percnt;</tt>'). The first alphabetical character 
+after the percent sign expands to the value which has been found on the left 
+side. For example <tt>+&percnt;l&percnt;(v)</tt> expands into <tt>+cz(bksl)</tt> if the 
+respective values on the left side were <tt>cz</tt> layout in its <tt>bksl</tt> 
+variant. More, if the layout resp. variant  parameter is followed by a pair of 
+brackets ('<tt>[</tt>', '<tt>]</tt>') it means that xkb should <em>place the 
+layout resp. variant into specified xkb group</em>. If the brackets are omitted
+the first group is the default value.
+<p>
+So the second block of rules enhances symbol definitions for some particular 
+keyboard models with extra keys (for internet, multimedia, ...) . Other models 
+are left intact. Similarly, the last block overrides some key type definitions,
+so the common global behaviour ''shift cancels caps'' or ''shift doesn't cancel 
+caps'' can be selected. The rest of rules produces special symbols for each 
+variant <tt>us</tt> layout of <tt>macintosh</tt> keyboard and standard pc 
+symbols in appropriate variants as a default. 
+
+<!--
+  TODO: more words about group switching (XkbOptions grp:...)?
+-->
+
+<!--
+    TODO: user & 3rd party xkb tree?
+    TODO: better and more complex explanation of rules
+-->
+
+<sect1>Descriptive Files of Rules
+<p>
+Now you just need to add a detailed description to <tt>&lt;rules&gt;.xml</tt> 
+description file so the other users (and external programs which often parse 
+this file) know what is your work about.
+
+
+<!-- 
+    TODO: format and semantics
+-->
+
+<sect2>Old Descriptive Files
+<p>
+The formerly used descriptive files were named <tt>&lt;rules&gt;.lst</tt>
+Its structure is very simple and quite self descriptive but such simplicity
+had also some cavities, for example there was no way how to describe local 
+variants of layouts and there were problems with the localization of 
+descriptions. To preserve compatibility with some older programs,
+new XML descriptive files can be converted to old format '.lst'.
+<p>
+For each parameter of rules file should be described its meaning. For the rules 
+file described above the <tt>.lst</tt> file could look like:
+<tscreen><verb>
+! model
+  pc104		Generic 104-key PC
+  microsoft	Microsoft Natural
+  pc98		PC-98xx Series
+  macintosh     Original Macintosh
+  ...
+
+! layout
+  us		U.S. English
+  cz		Czech
+  de		German
+  ...
+
+! option
+  caps:internal		 uses internal capitalization. Shift cancels Caps
+  caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps  
+  
+</verb></tscreen>
+<p>
+And that should be it. Enjoy creating your own xkb mapping.
+
+</article>
diff --git a/sgml/add.sh b/sgml/add.sh
new file mode 100644
index 0000000..f3d1671
--- /dev/null
+++ b/sgml/add.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/add.sh,v 1.1 1999/08/23 09:06:04 dawes Exp $
+#
+name=`basename $1 .sgml`
+sgmlfmt -f index $name.sgml | \
+	sed -e 's,<title>,<item><htmlurl name=",' \
+	    -e 's,</title>," url="'$name.html'">,' \
+	    -e 's,<author>,<!-- ,' \
+	    -e 's,</author>, -->,' \
+	    -e 's,<date>,<!-- ,' \
+	    -e 's,</date>, -->,' >> index.sgml
+exit 0
diff --git a/sgml/dps.sgml b/sgml/dps.sgml
new file mode 100644
index 0000000..77b4341
--- /dev/null
+++ b/sgml/dps.sgml
@@ -0,0 +1,193 @@
+<!doctype LINUXDOC PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+
+<title>XFree86 and DPS
+<author>Juliusz Chroboczek, <email/jch@xfree86.org/
+<date>27 February 2001</date>
+
+<ident>$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/dps.sgml,v 1.2 2003/01/20 03:43:07 dawes Exp $</ident>
+
+<toc>
+
+<sect>Introduction
+
+<p>Display Postscript (or DPS for short) is a rendering extension for
+X11.  DPS is slightly atypical in that it is based on <it/code
+mobility/, the ability to send executable code from client to server.
+Thus, a DPS client does not request that a line should be rendered;
+instead, it uploads code to the server which, when executed, causes a
+line to be drawn.
+
+<p>This document does not aim at teaching programming with DPS; it is
+only a summary description of the DPS support code included with
+XFree86.  More information about DPS, including a DPS bibliography, is
+available from
+<url url="http://dps.sourceforge.net" name="the DPS extension site">.
+
+<tscreen>
+<it>Note: Adobe, PostScript and Display PostScript are trademarks of
+Adobe Systems Incorporated which may be registered in certain
+jurisdictions.</it>
+</tscreen>
+
+As all X11 extensions, DPS consists of client-side and server-side
+components.  The DPS client side consists of a number of libraries and
+a number of tools for programming and configuration.  The DPS server
+side may consist either of an X server extension, or of a client-side
+process known as the ``DPS agent.''  In this latter case, the term
+``server-side'' is somewhat misleading.
+
+At the time of writing, only the client side is included with XFree86;
+the server side must be obtained separately.  Please see <ref
+id="sec:server-side" name="server side"> later in this document for
+more information.
+
+<sect>The DPS client side
+
+<p>The DPS client side consists of four libraries and a number of
+basic tools for programming and configuration; these are all included
+with XFree86.
+
+<sect1>Libraries
+
+<p>The <tt/libpsres/ library is a library for management of
+<it/PostScript resources/, on-disk files representing PostScript data
+structures such as fonts, font encodings, procsets, <it/etc./ It is
+closely related to the <tt/makepsres/ tool (see <ref id="sec:tools"
+name="client-side tools"> later in this document).
+
+The basic DPS client library is <tt/libdps/.  This library contains a
+number of functions for connection establishment, resource management,
+as well as stubs for all standard PostScript operators.  Normally, all
+DPS clients should link with <tt/libdps/; in addition, <tt/libdps/ may
+be used for printing by non-DPS clients (this is done, for example, by
+Sun's JDK).  This library is documented in [CLRM] and [CLSX].
+
+The <tt/libdpstk/ library contains a number of additional utilities
+for managing DPS contexts, user paths and user objects, and for
+previewing EPS files.  It is documented in [DPTX].
+
+The <tt/libdpstkXm/ library contains four Motif widgets.  The <it/DPS
+Scrolling Widget/ is a DPS drawing area that automatically manages
+issues such as scrolling, scaling, client-side backing store,
+incremental redisplay, <it/etc./ The <it/Font Selection Box/, and its
+associated <it/Font Preview/, present a convenient and powerful
+interface for choosing scalable fonts.  Finally, the <it/Color Picker/
+presents an interface for choosing colours using either of the RGB or
+HSV spaces.  The latter three widgets are documented in [DPTX]; some
+summary Scrolling Widget documentation is available in the <tt/doc/
+subdirectory of the <tt/DPS.tar.gz/ file, available from <url
+url="ftp://dps.sourceforge.net/pub/dps/DPS.tar.gz">.
+
+The source code for <tt/libdpstkXm/ is included with XFree86; however,
+as it depends on Motif, this library is not built by default.
+A GTK-based library providing some of the functionality of
+<tt/libdpstkXm/ is available from
+<url url="http://www.gyve.org/gtkDPS/"
+     name="the gtkDPS site">.
+
+<sect2>Libdps and Xt
+
+<p>In X11R5, <tt/libdps/ did not depend on <tt/libXt/.  In X11R6,
+however, code was added to make the Xt main loop dispatch to sundry
+code on DPS events; with this addition, all programs that link with
+<tt/libdps/ need to link with <tt/libXt/, whether they use Xt or not.
+
+This state of affairs is unfortunately true of the version of
+<tt/libdps/ included with XFree86.  We are currently considering
+various solutions to this problem (including the use of weak linker
+symbols or splitting off the guilty functions into a separate
+library).
+
+<sect1>Client-side tools <label id="sec:tools">
+
+<p>In addition to the libraries, the client side of DPS consists of two
+utilities.
+
+The <tt/makepsres/ utility is used for managing PostScript resources.
+Its basic operation consists in walking recursively a filesystem tree,
+noting all resources, and then writing out a ``Unix PostScript
+Resources,'' file, basically a directory of all the resources found.
+This utility is documented in the <htmlurl name="makepsres(1)"
+url="makepsres.1.html"> manual page.
+
+The <tt/pswrap/ utility is a stub generator for PostScript clients.
+Roughly speaking, it takes as its input textual PostScript code, and
+generates a collection of C functions that transmit that code in
+pre-tokenised form to the DPS extension.  <tt/Pswrap/ is documented in
+[PSWRAP].
+
+<sect1>Sample clients
+
+<p>XFree86 contains three sample DPS clients, <tt/dpsinfo/,
+<tt/dpsexec/ and <tt/texteroids/.  They are documented in their
+respective manual pages.
+
+A number of sample clients that depend on Motif are available in <url
+url="ftp://dps.sourceforge.net/pub/ftp/DPS.tar.gz">.  Additional
+sample clients can be found as part of GtkDPS (see above).
+
+The GNUstep environment can be compiled to use DPS for
+all rendering; for more information, please see
+<url url="http://www.gnustep.org" name="the GNUstep site">.
+
+<sect>The DPS server side <label id="sec:server-side">
+
+<p>In order to use DPS clients, you need to install a DPS server side,
+which can be either a server extension (a ``DPS/X extension''), or a
+separate process (referred to, variously, either as a ``DPS/NX agent''
+or, rather confusingly, as ``Client-Side DPS'' (CSDPS).
+
+<sect1>Display Ghostscript
+
+<p>Display Ghostscript (note the capitalisation), or DGS, is a
+client-side implementation of DPS based on the Ghostscript
+PostScript interpreter.  DGS is still in beta at the time of writing;
+it does, however, provide a very usable implementation of DPS,
+although it still has some problems with the semantics of multiple DPS
+contexts.
+
+DGS is available from
+<url url="http://www.gnustep.org/resources/sources.html"
+     name="the GNUstep download area">.
+
+<sect1>The DPS extension
+
+<p>The DPS extension is a much younger project aiming at producing an
+efficient server-side implementation of DPS.  The extension is
+currently in a state best described as alpha; current versions are
+known to crash the X server under some circumstances.
+
+The DPS extension is available from
+<url url="http://dps.sourceforge.net" name="the DPS extension site">.
+
+<sect>References
+
+<p>Links to electronic versions of all of these, and more, are
+available from <url url="http://dps.sourceforge.net" name="the DPS
+extension site">.
+
+[PLRM2] PostScript language reference manual. Adobe Systems, 2nd ed. Addison-Wesley, 1990. ISBN 0-201-18127-4. 
+
+[PLRM] PostScript language reference. Adobe Systems Incorporated, 3rd
+ed. Addison-Wesley, 1999. ISBN 0-201-37922-8.
+
+[INTRO] Display PostScript System. Introduction: Perspective for
+Software Developers. 15 April 1993.
+
+[CLRM] Display PostScript System. Client Library Reference Manual. 15
+April 1993.
+
+[CLSX] Display PostScript System. Client Library Supplement for X. 15
+April 1993.
+
+[DPTX] Display PostScript System. Display PostScript Toolkit for X. 15
+April 1993.
+
+[PSWRAP] Display PostScript System. pswrap Reference Manual. 15 April
+1993.
+
+</article>
diff --git a/sgml/fonts.sgml b/sgml/fonts.sgml
new file mode 100644
index 0000000..1feab53
--- /dev/null
+++ b/sgml/fonts.sgml
@@ -0,0 +1,1267 @@
+<!doctype LINUXDOC PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+<article>
+
+<title>Fonts in XFree86
+<author>Juliusz Chroboczek, <email/jch@xfree86.org/
+<date>17 January 2003</date>
+
+<ident>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/fonts.sgml,v 1.20 2003/01/20 03:43:07 dawes Exp $
+</ident>
+
+<toc>
+
+<sect>Introduction
+
+<p>This document describes the support for fonts in XFree86.  <ref
+id="sec:installing" name="Installing fonts"> is aimed at the 
+casual user wishing to install fonts in XFree86; the rest of the
+document describes the font support in more detail.
+
+We assume some familiarity with digital fonts.  If anything is not
+clear to you, please consult <ref id="sec:background"
+name="Appendix: Background"> at the end of this document for background
+information.
+
+<sect1>Two font systems
+
+<p>XFree86 includes two font systems: the core X11 fonts system, which
+is present in all implementations of X11, and the Xft fonts system,
+which is not currently distributed with implementations of X11 that
+are not based on XFree86 but will hopefully be included by them in
+the future
+
+The core X11 fonts system is directly derived from the fonts system
+included with X11R1 in 1987, which could only use monochrome bitmap
+fonts.  Over the years, it has been more or less happily coerced into
+dealing with scalable fonts and rotated glyphs.
+
+Xft was designed from the start to provide good support for scalable
+fonts, and do so efficiently.  Unlike the core fonts system, it
+supports features such as anti-aliasing and sub-pixel rasterisation.
+Perhaps more importantly, it gives applications full control over the
+way glyphs are rendered, making fine typesetting and WYSIWIG display
+possible.  Finally, it allows applications to use fonts that are not
+installed system-wide for displaying documents with embedded fonts.
+
+Xft is not compatible with the core fonts system: usage of Xft
+requires making fairly extensive changes to toolkits (user-interface
+libraries).  While XFree86 will continue to maintain the core fonts
+system, toolkit authors are encouraged to switch to Xft as soon as
+possible.
+
+<sect>Installing fonts<label id="sec:installing">
+
+<p>This section explains how to configure both Xft and the core fonts
+system to access newly-installed fonts.
+
+<sect1>Configuring Xft<label id="sec:configuring-xft">
+
+<p>Xft has no configuration mechanism itself, rather it relies upon
+the fontconfig library to configure and customize fonts.  That library
+is not specific to XFree86 or indeed on any particular font output
+mechanism.  This discussion describes how fontconfig, rather than Xft,
+works.
+
+<sect2>Installing fonts in Xft
+
+<p>Fontconfig looks for fonts in a set of well-known directories that
+include all of XFree86's standard font directories
+(`<tt>/usr/X11R6/lib/X11/lib/fonts/*</tt>') by default) as well as a
+directory called `<tt>.fonts/</tt>' in the user's home directory.
+Installing a font for use by Xft applications is as simple
+as copying a font file into one of these directories.
+<tscreen><verb>
+$ cp lucbr.ttf ~/.fonts/
+</verb></tscreen>
+Fontconfig will notice the new font at the next opportunity and rebuild its
+list of fonts.  If you want to trigger this update from the command
+line (for example in order to globally update the system-wide Fontconfig
+information), you may run the command `<tt/fc-cache/'.
+<tscreen><verb>
+$ fc-cache
+</verb></tscreen>
+
+<sect2>Fine-tuning Xft
+
+<p>Fontconfig's behaviour is controlled by a set of configuration files: a
+system-wide configuration file, `<tt>/etc/fonts/fonts.conf</tt>', and
+a user-specific file called `<tt>.fonts.conf</tt>' in the user's home
+directory (this can be overridden with the `<tt/FONTCONFIG_FILE/'
+environment variable).
+
+Every Fontconfig configuration file must start with the following
+boilerplate:
+<tscreen><verb>
+&lt;?xml version="1.0"?&gt;
+&lt;!DOCTYPE fontconfig SYSTEM "fonts.dtd"&gt;
+&lt;fontconfig&gt;
+</verb></tscreen>
+In addition, every Fontconfig configuration file must end with the
+following line:
+<tscreen><verb>
+&lt;/fontconfig&gt;
+</verb></tscreen>
+
+The default Fontconfig configuration file includes the directory
+`<tt>~/.fonts/</tt>' in the list of directories searched for font
+files, and this is where user-specific font files should be installed.
+In the unlikely case that a new font directory needs to be added, this
+can be done with the following syntax:
+<tscreen><verb>
+&lt;dir&gt;/usr/local/share/fonts/&lt;/dir&gt;
+</verb></tscreen>
+
+Another useful option is the ability to disable anti-aliasing (font
+smoothing) for selected fonts.  This can be done with the following
+syntax:
+<tscreen><verb>
+&lt;match target="font"&gt;
+    &lt;test qual="any" name="family"&gt;
+        &lt;string&gt;Lucida Console&lt;/string&gt;
+    &lt;/test&gt;
+    &lt;edit name="antialias" mode="assign"&gt;
+        &lt;bool&gt;false&lt;/bool&gt;
+    &lt;/edit&gt;
+&lt;/match&gt;
+</verb></tscreen>
+Anti-aliasing can be disabled for all fonts by the following incantation:
+<tscreen><verb>
+&lt;match target="font"&gt;
+    &lt;edit name="antialias" mode="assign"&gt;
+        &lt;bool&gt;false&lt;/bool&gt;
+    &lt;/edit&gt;
+&lt;/match&gt;
+</verb></tscreen>
+
+Xft supports sub-pixel rasterisation on LCD displays.  XFree86 should
+automatically enable this feature on laptops and when using an LCD
+monitor connected with a DVI cable; you can check whether this was
+done by typing
+<tscreen><verb>
+$ xdpyinfo -ext RENDER | grep sub-pixel
+</verb></tscreen>
+If this doesn't print anything, you will need to configure Render for
+your particular LCD hardware manually; this is done with the following
+syntax:
+<tscreen><verb>
+&lt;match target="font"&gt;
+    &lt;edit name="rgba" mode="assign"&gt;
+        &lt;const&gt;rgb&lt;/const&gt;
+    &lt;/edit&gt;
+&lt;/match&gt;
+</verb></tscreen>
+The string `<tt/rgb/' within the
+`<tt/&lt;const&gt;/'...`<tt>&lt;/const&gt;</tt>'
+specifies the order of pixel components on your display, and should be
+changed to match your hardware; it can be one of `<tt/rgb/ (normal
+LCD screen), `<tt/bgr/' (backwards LCD screen), `<tt/vrgb/' (LCD
+screen rotated clockwise) or `<tt/vbgr/' (LCD screen rotated
+counterclockwise).
+
+<sect2>Configuring applications
+
+<p>Because most current applications use the core fonts system by
+default, it is necessary to explicitly configure them to use Xft.
+How this is done depends on the application.
+
+XTerm can be set to use Xft by using the `<tt/-fa/' command line
+option or by setting the `<tt/XTerm*faceName/' resource:
+<tscreen><verb>
+XTerm*faceName: Courier
+</verb></tscreen>
+or
+<tscreen><verb>
+$ xterm -fa "Courier"
+</verb></tscreen>
+
+For applications based on GTK+ 2.0 (including GNOME 2 applications),
+the environment variable `<tt/GDK_USE_XFT/' should be set to `<tt/1/':
+<tscreen><verb>
+$ export GDK_USE_XFT=1
+</verb></tscreen>
+
+GTK+ 2.2 uses Xft by default.
+
+For KDE applications, you should select ``Anti-alias fonts'' in the
+``Fonts'' panel of KDE's ``Control Center''.  Note that this option is
+misnamed: it switches KDE to using Xft but doesn't enable
+anti-aliasing in case it was disabled by your Xft configuration file.
+
+<it>(What about Mozilla?)</it>
+
+<sect2>Troubleshooting <label id="sec:troubleshooting-xft">
+
+<p>If some Xft-based applications don't seem to notice the changes you
+are making to your configuration files, they may be linked against the
+XFree86 4.2 version of Xft.  In order to fix the problem, you should
+relink them against a current version of Xft; on most systems, it is
+enough to install the current version of the Xft and Fontconfig
+libraries.
+
+If, for some reason, you cannot upgrade the shared libraries, please
+check the <htmlurl name="Xft(3)" url="Xft.3.html"> manual page included
+with XFree86 4.2 for the configuration mechanisms of the previous version
+of Xft.
+
+<sect1>Configuring the core X11 fonts system
+
+<p>Installing fonts in the core system is a two step process.  First,
+you need to create a <it/font directory/ that contains all the
+relevant font files as well as some index files.  You then need to
+inform the X server of the existence of this new directory by
+including it in the <it/font path/.
+
+<sect2>Installing bitmap fonts
+
+<p>The XFree86 server can use bitmap fonts in both the cross-platform
+BDF format and the somewhat more efficient binary PCF format.
+(XFree86 also supports the obsolete SNF format.)
+
+Bitmap fonts are normally distributed in the BDF format.  Before
+installing such fonts, it is desirable (but not absolutely necessary)
+to convert the font files to the PCF format.  This is done by using the
+command `<tt/bdftopcf/', <it/e.g./ 
+<tscreen><verb>
+$ bdftopcf courier12.bdf
+</verb></tscreen>
+You will then want to compress the resulting PCF font files:
+<tscreen><verb>
+$ gzip courier12.pcf
+</verb></tscreen>
+
+After the fonts have been converted, you should copy all the font
+files that you wish to make available into a arbitrary directory, say
+`<tt>/usr/local/share/fonts/bitmap/</tt>'.  You should then create the
+index file `<tt/fonts.dir/' by running the command `<tt/mkfontdir/'
+(please see the <htmlurl name="mkfontdir(1)" url="mkfontdir.1.html">
+manual page for more information):
+<tscreen><verb>
+$ mkdir /usr/local/share/fonts/bitmap/
+$ cp *.pcf.gz /usr/local/share/fonts/bitmap/
+$ mkfontdir /usr/local/share/fonts/bitmap/
+</verb></tscreen>
+
+All that remains is to tell the X server about the existence of the
+new font directory; see <ref id="sec:set-font-path" name="Setting the
+server font path"> below.
+
+<sect2>Installing scalable fonts
+
+<p>The XFree86 server supports scalable fonts in four formats:
+Type&nbsp;1, Speedo, TrueType and CIDFont.  This section only applies
+to the former three; for information on CIDFonts, please see
+<ref id="sec:cid-fonts" name="Installing CIDFonts"> later in this
+document.
+
+Installing scalable fonts is very similar to installing bitmap fonts:
+you create a directory with the font files, and run `<tt/mkfontdir/'
+to create an index file called `<tt/fonts.dir/'.
+
+There is, however, a big difference: `<tt/mkfontdir/' cannot
+automatically recognise scalable font files.  For that reason, you
+must first index all the font files in a file called
+`<tt/fonts.scale/'.  While this can be done by hand, it is best done
+by using the `<tt/mkfontscale/' utility.
+<tscreen><verb>
+$ mkfontscale /usr/local/share/fonts/Type1/
+$ mkfontdir /usr/local/share/fonts/Type1/
+</verb></tscreen>
+Under some circumstances, it may be necessary to modify the
+`<tt/fonts.scale/' file generated by <tt/mkfontscale/; for more
+information, please see the <htmlurl name="mkfontdir(1)"
+url="mkfontdir.1.html"> and <htmlurl name="mkfontscale(1)"
+url="mkfontscale.1.html"> manual pages and <ref
+id="sec:internationalisation" name="Core fonts and internationalisation">
+later in this document.
+
+<sect2>Installing CID-keyed fonts <label id="sec:cid-fonts">
+
+<p>The CID-keyed font format was designed by Adobe Systems for fonts
+with large character sets.  A CID-keyed font, or CIDFont for short,
+contains a collection of glyphs indexed by <it/character ID/ (CID).
+
+In order to map such glyphs to meaningful indices, Adobe provide a set
+of <it/CMap/ files.  The PostScript name of a font generated from a
+CIDFont consists of the name of the CIDFont and the name of the CMap
+separated by two dashes.  For example, the font generated from the
+CIDFont `<tt/Munhwa-Regular/' using the CMap `<tt/UniKS-UCS2-H/' is
+called
+<tscreen><verb>
+Munhwa-Regular--UniKS-UCS2-H
+</verb></tscreen>
+
+The CIDFont code in XFree86 requires a very rigid directory
+structure.  The main directory must be called `<tt/CID/' (its location
+defaults to `<tt>/usr/X11R6/lib/X11/fonts/CID</tt>' but it may be
+located anywhere), and it should contain a subdirectory for every CID
+collection.  Every subdirectory <it/must/ contain subdirectories
+called <tt/CIDFont/ (containing the actual CIDFont files), <tt/CMap/
+(containing all the needed CMaps), <tt/AFM/ (containing the font
+metric files) and <tt/CFM/ (initially empty).  For example, in the
+case of the font <tt/Munhwa-Regular/ that uses the CID collection
+<tt/Adobe-Korea1-0/, the directory structure should be as follows:
+<tscreen><verb>
+CID/Adobe-Korea1/CIDFont/Munhwa-Regular
+CID/Adobe-Korea1/CMap/UniKS-UCS2-H
+CID/Adobe-Korea1/AFM/Munhwa-Regular.afm
+CID/Adobe-Korea1/CFM/
+CID/fonts.dir
+CID/fonts.scale
+</verb></tscreen>
+
+After creating this directory structure and copying the relevant
+files, you should create a <`tt/fonts.scale/' file.  This file has the
+same format as in the case of (non-CID) scalable fonts, except that
+its first column contains PostScript font names with the extension
+`<tt/.cid/' appended rather than actual filenames:
+<tscreen><verb>
+1
+Adobe-Korea1/Munhwa-Regular--UniKS-UCS2-H.cid \
+  -adobe-munhwa-medium-r-normal--0-0-0-0-p-0-iso10646-1
+</verb></tscreen>
+(both names on the same line).  Running `<tt/mkfontdir/'
+creates the `<tt/fonts.dir/' file:
+<tscreen><verb>
+$ cd /usr/local/share/fonts/CID
+$ mkfontdir
+</verb></tscreen>
+
+Finally, you should create the font metrics summary files in the
+directory `<tt/CFM/' by running the command `<tt/mkcfm/':
+<tscreen><verb>
+$ mkcfm /usr/local/share/fonts/CID
+</verb></tscreen>
+If no CFM files are available, the server will still be able to use
+the CID fonts but querying them will take a long time.  You should run
+`<tt/mkcfm/' again whenever a change is made to any of the CID-keyed
+fonts, or when the CID-keyed fonts are copied to a machine with a
+different architecture.
+
+<sect2>Setting the server's font path <label id="sec:set-font-path">
+
+<p>The list of directories where the server looks for fonts is known
+as the <it/font path/.  Informing the server of the existence of a new
+font directory consists of putting it on the font path.
+
+The font path is an ordered list; if a client's request matches
+multiple fonts, the first one in the font path is the one that gets
+used.  When matching fonts, the server makes two passes over the font
+path: during the first pass, it searches for an exact match; during
+the second, it searches for fonts suitable for scaling.
+
+For best results, scalable fonts should appear in the font path before
+the bitmap fonts; this way, the server will prefer bitmap fonts to
+scalable fonts when an exact match is possible, but will avoid scaling
+bitmap fonts when a scalable font can be used.  (The `<tt/:unscaled/'
+hack, while still supported, should no longer be necessary in XFree86
+4.0 and later.)
+
+You may check the font path of the running server by typing the command
+<tscreen><verb>
+$ xset q
+</verb></tscreen>
+
+<sect3>Temporary modification of the font path
+
+<p>The `<tt/xset/' utility may be used to modify the font path for the
+current session.  The font path is set with the command <tt/xset fp/;
+a new element is added to the front with <tt/xset +fp/, and added to
+the end with <tt/xset fp+/.  For example,
+<tscreen><verb>
+$ xset +fp /usr/local/fonts/Type1
+$ xset fp+ /usr/local/fonts/bitmap
+</verb></tscreen>
+
+Conversely, an element may be removed from the front of the font path
+with `<tt/xset -fp/', and removed from the end with `<tt/xset fp-/'.
+You may reset the font path to its default value with 
+`<tt/xset fp default/'.
+
+For more information, please consult the <htmlurl name="xset(1)"
+url="xset.1.html"> manual page.
+
+<sect3>Permanent modification of the font path
+
+<p>The default font path (the one used just after server startup or
+after `<tt/xset fp default/') is specified in the X server's
+`<tt/XF86Config/' file.  It is computed by appending all the
+directories mentioned in the `<tt/FontPath/' entries of the
+`<tt/Files/' section in the order in which they appear.
+<tscreen><verb>
+FontPath "/usr/local/fonts/Type1"
+...
+FontPath "/usr/local/fonts/bitmap"
+</verb></tscreen>
+
+For more information, please consult the <htmlurl name="XF86Config(5)"
+url="XF86Config.5.html"> manual page.
+
+<sect2>Troubleshooting <label id="sec:troubleshooting-core">
+
+<p>If you seem to be unable to use some of the fonts you have
+installed, the first thing to check is that the `<tt/fonts.dir/' files
+are correct and that they are readable by the server (the X server
+usually runs as root, beware of NFS-mounted font directories).  If
+this doesn't help, it is quite possible that you are trying to use a
+font in a format that is not supported by your server.
+
+XFree86 supports the BDF, PCF, SNF, Type 1, Speedo, TrueType, OpenType
+and CIDFont font formats.  However, not all XFree86 servers come with
+all the font backends configured in.
+
+On most platforms, the XFree86 servers are <it/modular/: the font
+backends are included in modules that are loaded at runtime.  The
+modules to be loaded are specified in the `<tt/XF86Config/' file using
+the `<tt/Load/' directive:
+<tscreen><verb>
+Load "type1"
+</verb></tscreen>
+If you have trouble installing fonts in a specific format, you may
+want to check the server's log file in order to see whether the
+relevant modules are properly loaded.  The list of font modules
+distributed with XFree86 is as follows:
+<itemize>
+<item> <tt/"bitmap"/: bitmap fonts (`<tt/*.bdf/', `<tt/*.pcf/'
+and `<tt/*.snf/');
+<item> <tt/"freetype"/: TrueType fonts (`<tt/*.ttf/' and
+`<tt/*.ttc/'), OpenType fonts (`<tt/*.otf/' and `<tt/*.otc/') and
+Type&nbsp;1 fonts (`<tt/*.pfa/' and `<tt/*.pfb/');
+<item> <tt/"type1"/: alternate Type&nbsp;1 backend (`<tt/*.pfa/' and
+`<tt/*.pfb/') and CIDFont backend;
+<item> <tt/"xtt"/: alternate TrueType backend (`<tt/*.ttf/' and
+`<tt/*.ttc/');
+<item> <tt/"speedo"/: Bitstream Speedo fonts (`<tt/*.spd/').
+</itemize>
+Please note that the argument of the `<tt/Load/' directive is
+case-sensitive.
+
+<sect>Fonts included with XFree86
+
+<sect1>Standard bitmap fonts
+
+<p>The Sample Implementation of X11 (SI) comes with a large number of
+bitmap fonts, including the `<tt/fixed/' family, and bitmap versions
+of Courier, Times, Helvetica and some members of the Lucida family.  In
+the SI, these fonts are provided in the ISO&nbsp;8859-1 encoding (ISO
+Latin Western-European).
+
+In XFree86, a number of these fonts are provided in Unicode-encoded
+font files instead.  At build time, these fonts are split into font
+files encoded according to legacy encodings, a process which allows
+us to provide the standard fonts in a number of regional encodings
+with no duplication of work.
+
+For example, the font file
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/misc/6x13.bdf
+</verb></tscreen>
+with XLFD
+<tscreen><verb>
+-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
+</verb></tscreen>
+is a Unicode-encoded version of the standard `<tt/fixed/' font with
+added support for the Latin, Greek, Cyrillic, Georgian, Armenian, IPA
+and other scripts plus numerous technical symbols.  It contains over
+2800 glyphs, covering all characters of ISO&nbsp;8859 parts 1-5,
+7-10, 13-15, as well as all European IBM and Microsoft code pages,
+KOI8, WGL4, and the repertoires of many other character sets.
+
+This font is used at build time for generating the font files
+<tscreen><verb>
+6x13-ISO8859-1.bdf
+6x13-ISO8859-2.bdf
+...
+6x13-ISO8859-15.bdf
+6x13-KOI8-R.bdf
+</verb></tscreen>
+with respective XLFDs
+<tscreen><verb>
+-misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1
+...
+-misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-15
+-misc-fixed-medium-r-normal--13-120-75-75-c-60-koi8-r
+</verb></tscreen>
+The standard short name `<tt/fixed/' is normally an alias for
+<tscreen><verb>
+-misc-fixed-medium-r-normal--13-120-75-75-c-60-iso8859-1
+</verb></tscreen>
+
+<sect1>The ClearlyU Unicode font family
+
+<p>The ClearlyU family of fonts provides a set of 12&nbsp;pt,
+100&nbsp;dpi proportional fonts with many of the glyphs needed for
+Unicode text.  Together, the fonts contain approximately 7500 glyphs.
+
+The main ClearlyU font has the XLFD
+<tscreen><verb>
+-mutt-clearlyu-medium-r-normal--17-120-100-100-p-101-iso10646-1 
+</verb></tscreen>
+and resides in the font file
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz 
+</verb></tscreen>
+Additional ClearlyU fonts include
+<tscreen><verb>
+-mutt-clearlyu alternate glyphs-medium-r-normal--17-120-100-100-p-91-iso10646-1 
+-mutt-clearlyu pua-medium-r-normal--17-120-100-100-p-111-iso10646-1
+-mutt-clearlyu arabic extra-medium-r-normal--17-120-100-100-p-103-fontspecific-0
+-mutt-clearlyu ligature-medium-r-normal--17-120-100-100-p-141-fontspecific-0
+</verb></tscreen>
+
+The <it/Alternate Glyphs/ font contains additional glyph shapes that
+are needed for certain languages.  A second alternate glyph font will
+be provided later for cases where a character has more than one
+commonly used alternate shape (<it/e.g./ the Urdu heh).
+
+The <it/PUA/ font contains extra glyphs that are useful for certain
+rendering purposes.
+
+The <it/Arabic Extra/ font contains the glyphs necessary for
+characters that don't have all of their possible shapes encoded in
+ISO&nbsp;10646.  The glyphs are roughly ordered according to the order
+of the characters in the ISO&nbsp;10646 standard.
+
+The <it/Ligature/ font contains ligatures for various scripts that
+may be useful for improved presentation of text.
+
+<sect1>Standard scalable fonts
+
+<p>XFree86 includes all the scalable fonts distributed with X11R6.
+
+<sect2>Standard Type&nbsp;1 fonts
+
+<p>The IBM Courier set of fonts cover ISO&nbsp;8859-1 and
+ISO&nbsp;8859-2 as well as Adobe Standard Encoding.  These fonts have
+XLFD
+<tscreen><verb>
+-adobe-courier-medium-*-*--0-0-0-0-m-0-*-*
+</verb></tscreen>
+and reside in the font files
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/Type1/cour*.pfa
+</verb></tscreen>
+
+The Adobe Utopia set of fonts only cover ISO&nbsp;8859-1 as well as
+Adobe Standard Encoding.  These fonts have XLFD
+<tscreen><verb>
+-adobe-utopia-*-*-normal--0-0-0-0-p-0-iso8859-1
+</verb></tscreen>
+and reside in the font files
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/Type1/UT*.pfa
+</verb></tscreen>
+
+Finally, XFree86 also comes with Type&nbsp;1 versions of Bitstream
+Courier and Charter.  These fonts have XLFD
+<tscreen><verb>
+-bitstream-courier-*-*-normal--0-0-0-0-m-0-iso8859-1
+-bitstream-charter-*-*-normal--0-0-0-0-p-0-iso8859-1
+</verb></tscreen>
+and reside in the font files
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/Type1/c*bt_.pfb
+</verb></tscreen>
+
+<sect2>Standard Speedo fonts
+
+<p>XFree86 includes Speedo versions of the Bitstream Courier and
+Charter fonts.  In order to use these fonts, you should ensure that
+your X server is loading the `<tt/Speedo/' font backend; see 
+<ref id="sec:troubleshooting-core" name="Troubleshooting">.
+
+These fonts cover all of ISO&nbsp;8859-1 and almost all of
+ISO&nbsp;8859-2.  They have XLFD name
+<tscreen><verb>
+-bitstream-courier-*-*-normal--0-0-0-0-m-0-*-*
+-bitstream-charter-*-*-normal--0-0-0-0-p-0-*-*
+</verb></tscreen>
+and reside in the font files
+<tscreen><verb>
+/usr/X11R6/lib/X11/fonts/Speedo/font*.spd
+</verb></tscreen>
+
+<sect1>The Bigelow &amp; Holmes Luxi family
+
+<p>XFree86 includes the <it/Luxi/ family of scalable fonts, in both
+TrueType and Type&nbsp;1 format.  This family consists of the fonts
+<it/Luxi Serif/, with XLFD
+<tscreen><verb>
+-b&amp;h-luxi serif-medium-*-normal--*-*-*-*-p-*-*-*
+</verb></tscreen>
+<it/Luxi Sans/, with XLFD
+<tscreen><verb>
+-b&amp;h-luxi sans-medium-*-normal--*-*-*-*-p-*-*-*
+</verb></tscreen>
+and <it/Luxi Mono/, with XLFD
+<tscreen><verb>
+-b&amp;h-luxi mono-medium-*-normal--*-*-*-*-m-*-*-*
+</verb></tscreen>
+Each of these fonts comes Roman, oblique, bold and bold oblique variants
+The TrueType version have glyphs covering the basic ASCII Unicode
+range, the Latin&nbsp;1 range, as well as the <it/Extended Latin/
+range and some additional punctuation characters.  In particular,
+these fonts include all the glyphs needed for ISO&nbsp;8859 parts 1,
+2, 3, 4, 9, 13 and 15, as well as all the glyphs in the Adobe Standard
+encoding and the Windows 3.1 character set.
+
+The glyph coverage of the Type&nbsp;1 versions is somewhat reduced,
+and only covers ISO&nbsp;8859 parts 1, 2 and 15 as well as the Adobe
+Standard encoding.
+
+The Luxi fonts are original designs by Kris Holmes and Charles 
+Bigelow.  Luxi fonts include seriffed, sans serif, and monospaced 
+styles, in roman and oblique, and normal and bold weights. The fonts 
+share stem weight, x-height, capital height, ascent and descent, for 
+graphical harmony.
+
+The character width metrics of Luxi roman and bold fonts match those 
+of core fonts bundled with popular operating and window systems.
+
+The license terms for the Luxi fonts are included in the file
+`<tt/COPYRIGHT.BH/', as well as in the <htmlurl
+name="License document" url="LICENSE.html">.
+
+Charles Bigelow and Kris Holmes from Bigelow and Holmes Inc. 
+developed the Luxi typeface designs in Ikarus digital format.
+
+URW++ Design and Development GmbH converted the Ikarus format fonts 
+to TrueType and Type1 font programs and implemented the grid-fitting 
+"hints" and kerning tables in the Luxi fonts.
+
+For more information, please contact
+<email>design@bigelowandholmes.com</email> or 
+<email>info@urwpp.de</email>, or consult 
+<url name="the URW++ web site" url="http://www.urwpp.de">.
+
+An earlier version of the Luxi fonts was made available under the
+name <em/Lucidux/.  This name should no longer be used due to trademark
+uncertainties, and all traces of the <em/Lucidux/ name have been
+removed from XFree86.
+
+<sect>More about core fonts <label id="sec:more-core">
+
+<p>This section describes XFree86-specific enhancements to the core
+X11 fonts system.
+
+<sect1>Core fonts and internationalisation <label id="sec:internationalisation">
+
+<p>The scalable font backends (Type&nbsp;1, Speedo and TrueType) can
+automatically re-encode fonts to the encoding specified in the
+XLFD in `<tt/fonts.dir/'.  For example, a `<tt/fonts.dir/' file can
+contain entries for the Type&nbsp;1 Courier font such as
+<tscreen><verb>
+cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 
+cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2
+</verb></tscreen>
+which will lead to the font being recoded to ISO&nbsp;8859-1 and
+ISO&nbsp;8859-2 respectively.
+
+<sect2>The <it/fontenc/ layer <label id="sec:fontenc">
+
+<p>Three of the scalable backends (Type&nbsp;1, Speedo, and the
+<it/FreeType/ TrueType backend) use a common <it/fontenc/ layer for
+font re-encoding.  This allows these backends to share their encoding
+data, and allows simple configuration of new locales independently of
+font type.
+
+<it/Please note:/ the X-TrueType (X-TT) backend does not use the
+<it/fontenc/ layer, but instead uses its own method for font
+reencoding.  If you are only interested in X-TT you may want to skip
+to <ref id="sec:symbol-fonts" name="Using Symbol Fonts">, as
+the intervening information does not apply to X-TT.  X-TT itself is
+described in more detail in <ref id="sec:X-TT" name="X-TrueType">.
+
+In the <it/fontenc/ layer, an encoding is defined by a name (such as
+<tt/iso8859-1/), possibly a number of aliases (alternate names), and
+an ordered collection of mappings.  A mapping defines the way the
+encoding can be mapped into one of the <it/target encodings/ known to
+<it/fontenc/; currently, these consist of Unicode, Adobe glyph names,
+and arbitrary TrueType ``cmap''s.
+
+A number of encodings are hardwired into <it/fontenc/, and are
+therefore always available; the hardcoded encodings cannot easily be
+redefined.  These include:
+<itemize>
+<item> <tt/iso10646-1/: Unicode;
+<item> <tt/iso8859-1/: ISO&nbsp;Latin-1 (Western Europe);
+<item> <tt/iso8859-2/: ISO&nbsp;Latin-2 (Eastern Europe);
+<item> <tt/iso8859-3/: ISO&nbsp;Latin-3 (Southern Europe);
+<item> <tt/iso8859-4/: ISO&nbsp;Latin-4 (Northern Europe);
+<item> <tt/iso8859-5/: ISO&nbsp;Cyrillic;
+<item> <tt/iso8859-6/: ISO&nbsp;Arabic;
+<item> <tt/iso8859-7/: ISO&nbsp;Greek;
+<item> <tt/iso8859-8/: ISO&nbsp;Hebrew;
+<item> <tt/iso8859-9/: ISO&nbsp;Latin-5 (Turkish);
+<item> <tt/iso8859-10/: ISO&nbsp;Latin-6 (Nordic);
+<item> <tt/iso8859-15/: ISO&nbsp;Latin-9, or Latin-0 (Revised
+  Western-European);
+<item> <tt/koi8-r/: KOI8 Russian;
+<item> <tt/koi8-u/: KOI8 Ukrainian (see RFC 2319);
+<item> <tt/koi8-ru/: KOI8 Russian/Ukrainian;
+<item> <tt/koi8-uni/: KOI8 ``Unified'' (Russian, Ukrainian, and
+  Byelorussian);
+<item> <tt/koi8-e/: KOI8 ``European,'' ISO-IR-111, or ECMA-Cyrillic;
+<item> <tt/microsoft-symbol/ and <tt/apple-roman/: these are only
+  likely to be useful with TrueType symbol fonts.
+</itemize>
+
+Additional encodings can be added by defining <it/encoding files/.
+When a font encoding is requested that the <it/fontenc/ layer doesn't
+know about, the backend checks the directory in which the font file
+resides (not necessarily the directory with <tt/fonts.dir/!) for a
+file named `<tt/encodings.dir/'.  If found, this file is scanned for
+the requested encoding, and the relevant encoding definition file is
+read in.  The `<tt/mkfontdir/' utility, when invoked with the
+`<tt/-e/' option followed by the name of a directory containing
+encoding files, can be used to automatically build `<tt/encodings.dir/'
+files.  Please see the <htmlurl name="mkfontdir(1)" url="mkfontdir.1.html">
+manual page for more details.
+
+A number of encoding files for common encodings are included with
+XFree86.  Information on writing new encoding files can be found in
+<ref id="sec:format-encoding-directory-files" name="Format of
+encodings directory files"> and <ref id="sec:format-encoding-files"
+name="Format of encoding files"> later in this document.
+
+<sect2>Backend-specific notes about fontenc
+
+<sect3>The <it/FreeType/ backend <label id="sec:fontenc-freetype"
+
+<p>For TrueType and OpenType fonts, the FreeType backend scans the
+mappings in order.  Mappings with a target of PostScript are ignored;
+mappings with a TrueType or Unicode target are checked against all the
+cmaps in the file.  The first applicable mapping is used.
+
+For Type&nbsp;1 fonts, the FreeType backend first searches for a
+mapping with a target of PostScript.  If one is found, it is used.
+Otherwise, the backend searches for a mapping with target Unicode,
+which is then composed with a built-in table mapping codes to glyph
+names.  Note that this table only covers part of the Unicode code
+points that have been assigned names by Adobe.
+
+Specifying an encoding value of <tt/adobe-fontspecific/ for a
+Type&nbsp;1 font disables the encoding mechanism.  This is useful with
+symbol and incorrectly encoded fonts (see <ref
+id="sec:incorrect-encoding" name="Incorrectly encoded fonts"> below).
+
+If a suitable mapping is not found, the FreeType backend defaults to
+ISO&nbsp;8859-1.
+
+<sect3>Type&nbsp;1
+
+<p>The Type&nbsp;1 backend behaves similarly to the FreeType backend
+with Type&nbsp;1 fonts, except that it limits all encodings to 8-bit
+codes.
+
+<sect3>Speedo
+
+<p>The Speedo backend searches for a mapping with a target of Unicode,
+and uses it if found.  If none is found, the backend defaults to
+ISO&nbsp;8859-1.
+
+The Speedo backend limits all encodings to 8-bit codes.
+
+<sect2>Format of encoding directory files <label id="sec:format-encoding-directory-files">
+
+<p>In order to use a font in an encoding that the font backend does
+not know about, you need to have an `<tt/encodings.dir/' file either
+in the same directory as the font file used or in a system-wide
+location (`<tt>/usr/X11R6/lib/X11/fonts/encodings/</tt>' by default).
+
+The `<tt/encodings.dir/' file has a similar format to
+`<tt/fonts.dir/'.  Its first line specifies the number of encodings,
+while every successive line has two columns, the name of the encoding,
+and the name of the encoding file; this can be relative to the current
+directory, or absolute.  Every encoding name should agree with the
+encoding name defined in the encoding file.  For example,
+
+<tscreen><verb>
+3
+mulearabic-0 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-0.enc
+mulearabic-1 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-1.enc
+mulearabic-2 /usr/X11R6/lib/X11/fonts/encodings/mulearabic-2.enc
+</verb></tscreen>
+
+The name of an encoding <it/must/ be specified in the encoding file's
+`<tt/STARTENCODING/' or `<tt/ALIAS/' line.  It is not enough to create
+an `<tt/encodings.dir/' entry.
+
+If your platform supports it (it probably does), encoding files may be
+compressed or gzipped.
+
+The `<tt/encoding.dir/' files are best maintained by the
+`<tt/mkfontdir/' utility.  Please see the <htmlurl name="mkfontdir(1)"
+url="mkfontdir.1.html"> manual page for more information.
+
+<sect2>Format of encoding files <label id="sec:format-encoding-files">
+
+<p>The encoding files are ``free form,'' <it/i.e./ any string of
+whitespace is equivalent to a single space.  Keywords are parsed in a
+non-case-sensitive manner, meaning that `<tt/size/', `<tt/SIZE/', and
+`<tt/SiZE/' all parse as the same keyword; on the other hand, case is
+significant in glyph names.
+
+Numbers can be written in decimal, as in `<tt/256/', in hexadecimal,
+as in `<tt/0x100/', or in octal, as in `<tt/0400/'.
+
+Comments are introduced by a hash sign `<tt/#/'.  A `<tt/#/' may
+appear at any point in a line, and all characters following the
+`<tt/#/' are ignored, up to the end of the line.
+
+The encoding file starts with the definition of the name of the
+encoding, and possibly its alternate names (aliases):
+<tscreen><verb>
+STARTENCODING mulearabic-0
+ALIAS arabic-0
+</verb></tscreen>
+The name of the encoding and its aliases should be suitable for use in
+an XLFD font name, and therefore contain exactly one dash `<tt/-/'.
+
+The encoding file may then optionally declare the size of the
+encoding.  For a linear encoding (such as ISO&nbsp;8859-1), the SIZE
+line specifies the maximum code plus one:
+<tscreen><verb>
+SIZE 0x2B
+</verb></tscreen>
+For a matrix encoding, it should specify two numbers.  The first is
+the number of the last row plus one, the other, the highest column
+number plus one.  In the case of `<tt/jisx0208.1990-0/'
+(JIS&nbsp;X&nbsp;0208(1990), double-byte encoding, high bit clear), it
+should be
+<tscreen><verb>
+SIZE 0x75 0x80
+</verb></tscreen>
+In the case of a matrix encoding, a `<tt/FIRSTINDEX/' line may be
+included to specify the minimum glyph index in an encoding.  The
+keyword `<tt/FIRSTINDEX/' is followed by two integers, the minimum row
+number followed by the minimum column number:
+<tscreen><verb>
+FIRSTINDEX 0x20 0x20
+</verb></tscreen>
+In the case of a linear encoding, a `<tt/FIRSTINDEX/' line is not very
+useful.  If for some reason however you chose to include on, it should
+be followed by a single integer.
+
+Note that in most font backends inclusion of a `<tt/FIRSTINDEX/' line
+has the side effect of disabling default glyph generation, and this
+keyword should therefore be avoided unless absolutely necessary.
+
+Codes outside the region defined by the `<tt/SIZE/' and
+`<tt/FIRSTINDEX/' lines are understood to be undefined.  Encodings
+default to linear encoding with a size of 256 (0x100).  This means
+that you must declare the size of all 16 bit encodings.
+
+What follows is one or more mapping sections.  A mapping section
+starts with a `<tt/STARTMAPPING/' line stating the target of the mapping.
+The target may be one of:
+<itemize>
+<item>Unicode (ISO&nbsp;10646):
+<tscreen><verb>
+STARTMAPPING unicode
+</verb></tscreen>
+<item>a given TrueType ``cmap'':
+<tscreen><verb>
+STARTMAPPING cmap 3 1
+</verb></tscreen>
+<item>PostScript glyph names:
+<tscreen><verb>
+STARTMAPPING postscript
+</verb></tscreen>
+</itemize>
+Every line in a mapping section maps one from the encoding being
+defined to the target of the mapping.  In mappings with a Unicode or
+TrueType mapping, codes are mapped to codes:
+<tscreen><verb>
+0x21 0x0660
+0x22 0x0661
+...
+</verb></tscreen>
+As an abbreviation, it is possible to map a contiguous range of codes
+in a single line.  A line consisting of three integers
+<tscreen><verb>
+<it/start/ <it/end/ <it/target/
+</verb></tscreen>
+is an abbreviation for the range of lines
+<tscreen>
+<it/start/     <it/target/
+</tscreen><tscreen>
+<it/start/+1   <it/target/+1
+</tscreen><tscreen>
+...
+</tscreen><tscreen>
+<it/end/       <it/target/+<it/end/-<it/start/
+</tscreen>
+For example, the line
+<tscreen><verb>
+0x2121 0x215F 0x8140
+</verb></tscreen>
+is an abbreviation for
+<tscreen><verb>
+0x2121 0x8140
+0x2122 0x8141
+...
+0x215F 0x817E
+</verb></tscreen>
+Codes not listed are assumed to map through the identity (<it/i.e./ to
+the same numerical value).  In order to override this default mapping,
+you may specify a range of codes to be undefined by using an
+`<tt/UNDEFINE/' line:
+<tscreen><verb>
+UNDEFINE 0x00 0x2A
+</verb></tscreen>
+or, for a single code,
+<tscreen><verb>
+UNDEFINE 0x1234
+</verb></tscreen>
+
+PostScript mappings are different.  Every line in a PostScript mapping
+maps a code to a glyph name
+<tscreen><verb>
+0x41 A
+0x42 B
+...
+</verb></tscreen>
+and codes not explicitly listed are undefined.
+
+A mapping section ends with an <tt/ENDMAPPING/ line
+<tscreen><verb>
+ENDMAPPING
+</verb></tscreen>
+After all the mappings have been defined, the file ends with an
+<tt/ENDENCODING/ line
+<tscreen><verb>
+ENDENCODING
+</verb></tscreen>
+
+In order to make future extensions to the format possible, lines
+starting with an unknown keyword are silently ignored, as are mapping
+sections with an unknown target.
+
+<sect2>Using symbol fonts <label id="sec:symbol-fonts">
+
+<p>Type&nbsp;1 symbol fonts should be installed using the
+<tt/adobe-fontspecific/ encoding.
+
+In an ideal world, all TrueType symbol fonts would be installed using
+one of the <tt/microsoft-symbol/ and <tt/apple-roman/ encodings. A
+number of symbol fonts, however, are not marked as such; such fonts
+should be installed using <tt/microsoft-cp1252/, or, for older fonts,
+<tt/microsoft-win3.1/.
+
+In order to guarantee consistent results (especially between
+Type&nbsp;1 and TrueType versions of the same font), it is possible to
+define a special encoding for a given font. This has already been done
+for the <tt/ZapfDingbats/ font; see the file
+`<tt>encodings/adobe-dingbats.enc</tt>'.
+
+<sect2>Hints about using badly encoded fonts <label id="sec:incorrect-encoding">
+
+<p>A number of text fonts are incorrectly encoded. Incorrect encoding
+is sometimes done by design, in order to make a font for an exotic
+script appear like an ordinary Western text font on systems which are
+not easily extended with new locale data.  It is often the result of
+the font designer's laziness or incompetence; for some reason, most
+people seem to find it easier to invent idiosyncratic glyph names
+rather than follow the Adobe glyph list.
+
+There are two ways of dealing with such fonts: using them with the
+encoding they were designed for, and creating an <it/ad hoc/ encoding
+file.
+
+<sect3>Using fonts with the designer's encoding
+
+<p>In the case of Type&nbsp;1 fonts, the font designer can specify a
+default encoding; this encoding is requested by using the
+`<tt/adobe-fontspecific/' encoding in the XLFD name. Sometimes, the
+font designer omitted to specify a reasonable default encoding, in
+which case you should experiment with `<tt/adobe-standard/',
+`<tt/iso8859-1/', `<tt/microsoft-cp1252/', and
+`<tt/microsoft-win3.1/'. (The encoding `<tt/microsoft-symbol/' doesn't
+make sense for Type&nbsp;1 fonts).
+
+TrueType fonts do not have a default encoding.  However, most TrueType
+fonts are designed with either Microsoft or Apple platforms in mind,
+so one of `<tt/microsoft-symbol/', `<tt/microsoft-cp1252/',
+`<tt/microsoft-win3.1/', or `<tt/apple-roman/' should yield reasonable
+results.
+
+<sect3>Specifying an <it/ad hoc/ encoding file
+
+<p>It is always possible to define an encoding file to put the glyphs
+in a font in any desired order. Again, see the
+`<tt>encodings/adobe-dingbats.enc</tt>' file to see how this is done.
+
+<sect3>Specifying font aliases
+
+<p>By following the directions above, you will find yourself with a
+number of fonts with unusual names --- with encodings such as
+`<tt/adobe-fontspecific/', `<tt/microsoft-win3.1/' <it/etc/.  In order
+to use these fonts with standard applications, it may be useful to
+remap them to their proper names.
+
+This is done by writing a `<tt/fonts.alias/' file. The format of this file
+is very simple: it consists of a series of lines each mapping an alias 
+name to a font name.  A `<tt/fonts.alias/' file might look as follows:
+<tscreen><verb>
+"-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-iso8859-2" \
+  "-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
+</verb></tscreen>
+(both XLFD names on a single line).  The syntax of the
+`<tt/fonts.alias/' file is more precisely described in the
+<htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> manual page.
+
+<sect1>Additional notes about scalable core fonts
+
+<p>The FreeType backend (module `<tt/freetype/', formerly known
+as <it/xfsft/) is able to deal with both TrueType and Type&nbsp;1
+fonts.  This puts it in conflict with the X-TT and Type&nbsp;1
+backends respectively.
+
+If both the FreeType and the Type&nbsp;1 backends are loaded, the
+FreeType backend will be used for Type&nbsp;1 fonts.  If both the
+FreeType and X-TT backends are loaded, X-TT will be used for TrueType
+fonts.
+
+<sect2>Delayed glyph rasterisation
+
+<p>Both FreeType and X-TT delay glyph rasterisation up to the time at
+which a glyph is first used.  For this reason, they only provide an
+approximate value for the ``average width'' font property.
+
+Both backends also support an optimisation for character-cell fonts
+(fonts with all glyph metrics equal, or terminal fonts).  A font with
+an XLFD specifying a character-cell spacing `<tt/c/', as in
+<tscreen><verb>
+-misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0
+</verb></tscreen>
+will not rasterise glyphs at metrics computation time, but instead
+trust the font really to be a character-cell font.  You are
+encouraged to make use of this optimisation when useful, but be warned
+that not all monospaced fonts are character-cell fonts.
+
+<sect2>About the <it/FreeType/ backend
+
+<p>The <it/FreeType/ backend (formerly <it/xfsft/) is a backend based
+on version 2 of the FreeType library (see <url
+url="http://www.freetype.org/" name="the FreeType web site">) and has
+support for the ``fontenc'' style of internationalisation (see 
+<ref id="sec:fontenc" name="The fontenc layer">).  This backend
+supports TrueType font files (`<tt/*.ttf/'), OpenType font files
+(`<tt/*.otf/'), TrueType Collections (`<tt/*.ttc/'), OpenType
+Collections (`<tt/*.otc/') and Type 1 font files (`<tt/*.pfa/' and
+`<tt/*.pfb/').
+
+In order to access the faces in a TrueType Collection file, the face
+number must be specified in the fonts.dir file before the filename
+within colons.  For example,
+<tscreen><verb>
+:2:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0
+</verb></tscreen>
+refers to face 2 in the `<tt/mincho.ttc/' TrueType Collection file.
+
+The <it/FreeType/ backend uses the <it/fontenc/ layer in order to
+support recoding of fonts; this was described in <ref
+id="sec:fontenc" name="The fontenc layer"> and especially <ref
+id="sec:fontenc-freetype" name="FreeType-specific notes about
+fontenc"> earlier in this document.
+
+<sect2>About the <it/X-TrueType/ TrueType backend <label id="sec:X-TT">
+
+<p>The `X-TrueType' backend is a backend based on version 1 of the
+FreeType library.  X-TrueType doesn't use the `fontenc' layer for
+managing font encodings, but instead uses its own database of
+encodings.
+
+X-TrueType extends the `<tt/fonts.dir/' syntax with a number of options,
+collectively known as `TTCap'.  A `TTCap' entry follows the general
+syntax
+<tscreen><verb>
+:option=value:
+</verb></tscreen>
+and should be specified before the filename.
+
+The most useful TTCap option is used to specify the face number to use
+with TTCs; this is the `<tt/fn/' TTCap option.  For example, face 2 of
+font file `<tt/mincho.ttc/' is specified using:
+<tscreen><verb>
+:fn=2:mincho.ttc -misc-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0
+</verb></tscreen>
+More information on the TTCap syntax, and on X-TrueType in general,
+may be found on <url url="http://x-tt.dsl.gr.jp/" name="the X-TrueType
+home page">.
+
+<sect>Appendix: background and terminology <label id="sec:background">
+<sect1>Characters and glyphs
+
+<p>A computer text-processing system inputs keystrokes and outputs
+<it/glyphs/, small pictures that are assembled on paper or on a
+computer screen.  Keystrokes and glyphs do not, in general, coincide:
+for example, if the system does generate ligatures, then to the
+sequence of two keystrokes &lt;<tt/f/&gt;&lt<tt/i/&gt; will typically
+correspond a single glyph.  Similarly, if the system shapes Arabic
+glyphs in a vaguely reasonable manner, then multiple different glyphs
+may correspond to a single keystroke.
+
+The complex transformation rules from keystrokes to glyphs are usually
+factored into two simpler transformations, from keystrokes to
+<it/characters/ and from characters to glyphs.  You may want to think
+of characters as the basic unit of text that is stored <it/e.g./ in
+the buffer of your text editor.  While the definition of a character
+is intrinsically application-specific, a number of standardised
+collections of characters have been defined.
+
+A <it/coded character set/ is a set of characters together with a
+mapping from integer codes --- known as <it/codepoints/ --- to
+characters.  Examples of coded character sets include US-ASCII,
+ISO&nbsp;8859-1, KOI8-R, and JIS&nbsp;X&nbsp;0208(1990).
+
+A coded character set need not use 8 bit integers to index characters.
+Many early systems used 6 bit character sets, while 16 bit (or more)
+character sets are necessary for ideographic writing systems.
+
+<sect1>Font files, fonts, and XLFD <label id="sec:xlfd">
+
+<p>Traditionally, typographers speak about <it/typefaces/ and
+<it/founts/.  A typeface is a particular style or design, such as
+Times Italic, while a fount is a molten-lead incarnation of a given
+typeface at a given size.
+
+Digital fonts come in <it/font files/.  A font file contains the
+information necessary for generating glyphs of a given typeface, and
+applications using font files may access glyph information in an
+arbitrary order.
+
+Digital fonts may consist of bitmap data, in which case they are said
+to be <it/bitmap fonts/.  They may also consist of a mathematical
+description of glyph shapes, in which case they are said to be
+<it/scalable fonts/.  Common formats for scalable font files are
+<it/Type&nbsp;1/ (sometimes incorrectly called <it/ATM fonts/ or
+<it/PostScript fonts/), <it/TrueType/ and <it/Speedo/.
+
+The glyph data in a digital font needs to be indexed somehow.  How
+this is done depends on the font file format.  In the case of
+Type&nbsp;1 fonts, glyphs are identified by <it/glyph names/.  In the
+case of TrueType fonts, glyphs are indexed by integers corresponding
+to one of a number of indexing schemes (usually Unicode --- see below).
+
+The X11 core fonts system uses the data in a font file to generate
+<it/font instances/, which are collections of glyphs at a given size
+indexed according to a given encoding.
+
+X11 core font instances are usually specified using a notation known
+as the <it/X Logical Font Description/ (XLFD).  An XLFD starts with a
+dash `<tt/-/', and consists of fourteen fields separated by dashes,
+for example:
+<tscreen><verb>
+-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
+</verb></tscreen>
+Or particular interest are the last two fields `<tt/iso8859-1/', which
+specify the font instance's encoding.
+
+A scalable font is specified by an XLFD which contains zeroes instead
+of some fields:
+<tscreen><verb>
+-adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
+</verb></tscreen>
+
+X11 font instances may also be specified by short name.  Unlike an
+XLFD, a short name has no structure and is simply a conventional name
+for a font instance.  Two short names are of particular interest, as
+the server will not start if font instances with these names cannot be
+opened.  These are `<tt/fixed/', which specifies the fallback font to
+use when the requested font cannot be opened, and `<tt/cursor/', which
+specifies the set of glyphs to be used by the mouse pointer.
+
+Short names are usually implemented as aliases to XLFDs; the
+standard `<tt/fixed/' and `<tt/cursor/' aliases are defined in
+<tscreen><verb>
+/usr/X11R6/lib/X11/font/misc/fonts.alias
+</verb></tscreen>
+
+<sect1>Unicode
+
+<p>Unicode (<url url="http://www.unicode.org">) is a coded character
+set with the goal of uniquely identifying all characters for all
+scripts, current and historical.  While Unicode was explicitly not
+designed as a glyph encoding scheme, it is often possible to use it as
+such.
+
+Unicode is an <it/open/ character set, meaning that codepoint
+assignments may be added to Unicode at any time (once specified,
+though, an assignment can never be changed).  For this reason, a
+Unicode font will be <it/sparse/, meaning that it only defines glyphs
+for a subset of the character registry of Unicode.
+
+The Unicode standard is defined in parallel with the international
+standard ISO&nbsp;10646.  Assignments in the two standards are always
+equivalent, and we often use the terms <it/Unicode/ and
+<it/ISO&nbsp;10646/ interchangeably.
+
+When used in the X11 core fonts system, Unicode-encoded fonts should
+have the last two fields of their XLFD set to `<tt/iso10646-1/'.
+
+<sect>References
+
+<p>XFree86 comes with extensive documentation in the form of manual
+pages and typeset documents.  Before installing fonts, you really should
+read the <htmlurl name="fontconfig(3)" url="fontconfig.3.html"> and
+<htmlurl name="mkfontdir(1)" url="mkfontdir.1.html"> manual pages; other
+manual pages of interest include <htmlurl name="X(7)" url="X.7.html">,
+<htmlurl name="Xserver(1)" url="Xserver.1.html">, <htmlurl name="xset(1)"
+url="xset.1.html">, <htmlurl name="Xft(3)" url="Xft.3.html">, <htmlurl
+name="xlsfonts(1)" url="xlsfonts.1.html"> and <htmlurl name="showfont(1)"
+url="showfont.1.html">.  In addition, you may want to read the X Logical
+Font Description document, by Jim Flowers, which is provided in the file
+`<tt>xc/doc/xlfd.PS.Z</tt>'.
+
+The latest released version of the XFree86 documentation (including
+this document and all manual pages) is available as
+<url name="current XFree86 documentation"
+     url="http://www.xfree86.org/current/">.
+
+The <url name="comp.fonts FAQ"
+         url="http://www.netmeg.net/faq/computers/fonts/">, 
+which is unfortunately no longer being maintained, contains a wealth
+of information about digital fonts.
+
+Xft and Fontconfig are described on
+<url name="Keith Packard's Fontconfig site"
+     url="http://www.fontconfig.org">.
+
+The 
+<url name="xfsft home page"
+     url="http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/">
+has been superseded by this document, and is now obsolete; you may
+however still find some of the information that it contains useful.
+<url name="Joerg Pommnitz' xfsft page"
+     url="http://www.joerg-pommnitz.de/TrueType/xfsft.html"> 
+is the canonical source for the `<tt/ttmkfdir/' utility, which is the
+ancestor of <tt/mkfontscale/.
+
+<url name="The author's software pages"
+     url="http://www.pps.jussieu.fr/~jch/software/">
+might or might not contain related scribbles and development versions
+of software.
+
+The documentation of <it/X-TrueType/ is available from
+<url url="http://x-tt.dsl.gr.jp/" name="the X-TrueType home page">.
+
+A number of East-Asian CIDFonts are available from 
+<url name="O'Reilly's FTP site"
+     url="ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/">. 
+
+While the <url url="http://www.unicode.org" name="Unicode consortium site">
+may be of interest,  you are more likely to find what you need in
+Markus Kuhn's <url url="http://www.cl.cam.ac.uk/~mgk25/unicode.html"
+name="UTF-8 and Unicode FAQ">.
+
+The IANA RFC documents, available from a number of sites throughout
+the world, often provide interesting information about character set
+issues; see for example RFC&nbsp;373.
+
+</article>
+<!-- Who was it who designed Linuxdoc, and was he drunk at the time? -->
diff --git a/sgml/index.post b/sgml/index.post
new file mode 100644
index 0000000..17e6c2f
--- /dev/null
+++ b/sgml/index.post
@@ -0,0 +1,22 @@
+
+</itemize>
+
+<![ %manpages; [
+<p>
+Manual pages:
+<itemize>
+<item><htmlurl name="Section 1" url="manindex1.html">: Commands
+<item><htmlurl name="Section 3" url="manindex3.html">: Library Functions
+<item><htmlurl name="Section &drvsuffix;" url="manindex&drvsuffix;.html">: Drivers
+<item><htmlurl name="Section &filesuffix;" url="manindex&filesuffix;.html">: Files and file formats
+<item><htmlurl name="Section &miscsuffix;" url="manindex&miscsuffix;.html">: Miscellaneous
+</itemize>
+<p>
+]]>
+
+
+</article>
+
+<!--
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/index.post,v 1.2 2000/03/21 19:57:10 dawes Exp $
+-->
diff --git a/sgml/index.pre b/sgml/index.pre
new file mode 100644
index 0000000..35b97ac
--- /dev/null
+++ b/sgml/index.pre
@@ -0,0 +1,19 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+<!ENTITY % mdefs SYSTEM "mdefs.ent"> %mdefs;
+]>
+ 
+<article>
+
+<!-- Title information -->
+<title>Documentation for XFree86&trade; version &relvers;
+<author>The XFree86 Project, Inc
+<date>27 February 2003
+
+<!--
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre,v 1.19 2003/02/24 03:41:25 dawes Exp $ 
+-->
+
+<p>
+<itemize>
+
diff --git a/sgml/mdefs.pre b/sgml/mdefs.pre
new file mode 100644
index 0000000..ecf6540
--- /dev/null
+++ b/sgml/mdefs.pre
@@ -0,0 +1,14 @@
+<!-- $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/mdefs.cpp,v 1.1 2000/03/21 19:57:11 dawes Exp $ -->
+
+<!-- entity definitions for man pages -->
+
+#ifdef HTML_MANPAGES
+<!ENTITY % manpages 'INCLUDE'>
+#else
+<!ENTITY % manpages 'IGNORE'>
+#endif
+
+<!ENTITY drvsuffix CDATA __drivermansuffix__ >
+<!ENTITY filesuffix CDATA __filemansuffix__ >
+<!ENTITY miscsuffix CDATA __miscmansuffix__ >
+
diff --git a/specs/GL/libGL.txt b/specs/GL/libGL.txt
new file mode 100644
index 0000000..cb98840
--- /dev/null
+++ b/specs/GL/libGL.txt
@@ -0,0 +1,197 @@
+
+
+
+Introduction
+------------
+
+This document describes the implementation of the XFree86 4.0 libGL.so
+library defined by the Linux/OpenGL Base specification found at
+http://reality.sgi.com/opengl/linux/linuxbase.html.
+
+The documentation is divided into two sections:
+    User's Guide
+    Driver Developer's Guide
+
+Author:  Brian Paul     (brian@precisioninsight.com)
+Date:    February 2000
+
+
+
+User's Guide
+------------
+
+Using libGL.so
+
+The libGL.so library defines the gl- and glX-prefixed functions needed to
+run OpenGL programs.  OpenGL client applications should link with the
+-lGL option to use it.
+
+libGL.so serves two primary functions: GLX protocol generation for indirect
+rendering and loading/management of hardware drivers for direct rendering.
+
+When libGL.so initializes itself it uses the DRI to determine the
+appropriate hardware driver for each screen on the local X display.
+The hardware drivers are expected to be in the /usr/X11R6/lib/modules/dri/
+directory.  Drivers are named with the convention <name>_dri.so where
+<name> is a driver such as "tdfx", "i810", "gamma", etc.
+
+The LIBGL_DRIVERS_DIR environment variable may be used to specify a
+different DRI modules directory, overriding /usr/X11R6/lib/modules/dri/.
+This environment variable is ignored in setuid programs for security
+reasons.
+
+When libGL.so is unable to locate appropriate hardware drivers it will
+fall back to using indirect GLX rendering.
+
+To aid in solving problems, libGL.so will print diagnostic messages to
+stderr if the LIBGL_DEBUG environment variable is defined.
+
+libGL.so is thread safe.  The overhead of thread safety for common,
+single-thread clients is negligible.  However, the overhead of thread
+safety for multi-threaded clients is significant.  Each GL API call
+requires two calls to pthread_get_specific() which can noticably
+impact performance.  Warning:  libGL.so is thread safe but individual
+DRI drivers may not be.  Please consult the documentation for a driver
+to learn if it is thread safe.
+
+
+
+Indirect Rendering
+
+You can force indirect rendering mode by setting the LIBGL_ALWAYS_INDIRECT
+environment variable.  Hardware acceleration will not be used.
+
+
+
+libGL.so Extensibility
+
+libGL.so is designed to be extended without upgrading.  That is,
+drivers may install new OpenGL extension functions into libGL.so
+without requiring libGL.so to be replaced.  Clients of libGL.so should
+use the glXGetProcAddressEXT() function to obtain the address of
+functions by name.  For more details of GLX_ARB_get_proc_address see
+http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.spec
+
+libGL.so is also designed with flexibility such that it may be used
+with many generations of hardware drivers to come.
+
+
+
+
+Driver Developer's Guide
+------------------------
+
+This section describes the requirements to make an XFree86 4.0
+libGL.so-compatible hardware driver.  It is not intended for end
+users of libGL.so.
+
+
+XFree86 source files
+
+libGL.so is built inside XFree86 with sources found in xc/lib/GL/.
+Specifically, libGL.so is built from:
+
+	xc/lib/GL/glx/*.c
+	xc/lib/dri/XF86dri.c
+	xc/lib/dri/dri_glx.c
+	xc/lib/GL/mesa/src/glapi.c
+	xc/lib/GL/mesa/src/glapitemp.h
+	xc/lib/GL/mesa/src/glapitable.h
+	xc/lib/GL/mesa/src/glapioffsets.h
+	xc/lib/GL/mesa/src/glapinoop.c
+	xc/lib/GL/mesa/src/glheader.h
+	xc/lib/GL/mesa/src/glthread.c
+	xc/lib/GL/mesa/src/glthread.h
+	xc/lib/GL/mesa/src/X86/glapi_x86.S
+	xc/lib/GL/mesa/src/X86/assyntax.h
+
+Understand that the mesa/src/gl*.[ch] files are not tied to Mesa.  They
+have no dependencies on the rest of Mesa and are designed to be reusable
+in a number of projects.
+
+The glapi_x86.X and assyntax.h files implement x86-optimized dispatch
+of GL functions.  They are not required; C-based dispatch can be used
+instead, with a slight performance penalty.
+
+
+
+Driver loading and binding
+
+When libGL.so initializes itself (via the __glXInitialize function) a
+call is made to driCreateDisplay().  This function uses DRI facilities
+to determine the driver file appropriate for each screen on the local
+display.  Each screen's driver is then opened with dlopen() and asked
+for its __driCreateScreen() function.  The pointers to the __driCreateScreen()
+functions are kept in an array, indexed by screen number, in the
+__DRIdisplayRec struct.
+
+When a driver's __driCreateScreen() function is called, it must initialize
+a __DRIscreenRec struct.  This struct acts as the root of a tree of
+function pointers which are called to create and destroy contexts and
+drawables and perform all the operations needed by the GLX interface.
+See the xc/lib/GL/glx/glxclient.h file for details.
+
+
+
+Dynamic Extension Function Registration
+
+In order to provide forward compatibility with future drivers, libGL.so
+allows drivers to register new OpenGL extension functions which weren't
+known when libGL.so was built.
+
+The register_extensions() function in xc/lib/GL/dri/dri_glx.c is called
+as soon as libGL.so is loaded.  This is done with gcc's constructor
+attribute.  This mechanism will likely have to be changed for other compilers.
+
+register_extensions() loops over all local displays and screens, determines
+the DRI driver for each, and calls the driver's __driRegisterExtensions()
+function, if present.
+
+The __driRegisterExtensions() function can add new entrypoints to libGL
+by calling:
+
+    GLboolean _glapi_add_entrypoint(const char *funcName, GLuint offset)
+
+The parameters are the name of the function (such as "glFoobarEXT") and the
+offset of the dispatch slot in the API dispatch table.  The return value
+indicates success (GL_TRUE) or failure (GL_FALSE).
+
+_glapi_add_entrypoint() will synthesize entrypoint code in assembly
+language.  Assembly languages is required since parameter passing
+can't be handled correctly using a C-based solution.
+
+The address of the new entrypoint is obtained by calling the
+glXGetProcAddressARB() function.
+
+The dispatch offset number MUST be a number allocated by SGI in the same
+manner in which new GL_* constants are allocated.  Using an arbitrary
+offset number will result in many problems.
+
+
+
+Dispatch Management
+
+When a GL context is made current, the driver must install its dispatch
+table as the current dispatch table.  This is done by calling
+
+	void _glapi_set_dispatch(struct _glapi_table *dispatch);
+
+This will install the named dispatch table for the calling thread.
+The current dispatch table for a thread can be obtained by calling
+
+	struct _glapi_table *_glapi_get_dispatch(void);
+
+For higher performance in the common single-thread case, the global
+variable _glapi_Dispatch will point to the current dispatch table.
+This variable will be NULL when in multi-thread mode.
+
+
+
+Context Management
+
+libGL.so uses the XFree86 xthreads package to manage a thread-specific
+current context pointer.  See __glXGet/SetCurrentContext() in glext.c
+
+Drivers may use the _glapi_set/get_context() functions to maintain
+a private thread-specific context pointer.
+
diff --git a/specs/Randr/protocol.txt b/specs/Randr/protocol.txt
new file mode 100644
index 0000000..aa15f83
--- /dev/null
+++ b/specs/Randr/protocol.txt
@@ -0,0 +1,519 @@
+	The X Resize, Rotate and Reflect Extension
+		      Version 1.0
+		      2002-10-4
+
+		      Jim Gettys
+	          Jim.Gettys@hp.com
+
+	            Keith Packard
+	         keithp@xfree86.org
+
+	     Cambridge Research Laboratory
+		      HP Labs
+	       Hewlett Packard Company
+
+1. Introduction
+
+The X Resize, Rotate and Reflect Extension, called RandR for short,
+brings the ability to resize, rotate and reflect the root window of a
+screen.  It is based on the X Resize and Rotate Extension as specified
+in the Proceedings of the 2001 Usenix Technical Conference [RANDR].
+
+RandR as implemented and integrated into the XFree86 server differs in
+one substantial fashion from the design discussed in that paper: that
+is, RandR 1.0 does not implement the depth switching described in that
+document, and the support described for that in the protocol in that
+document and in the XFree86 implementationhas been removed from the
+protocol described here, as it has been overtaken by events.
+
+These events include:
+      o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
+        of implementing migration between screens of arbitrary depths
+      o The continued advance of Moore's law has made limited amounts of VRAM
+        less of an issue, reducing the pressure to implement depth switching
+	on laptops or desktop systems
+      o The continued decline of legacy toolkits whose design would have
+        required depth switching to support migration
+      o The lack of depth switchin implementation experience in the 
+        intervening time, due to events beyond our control
+
+Additionally, the requirement to support depth switching might
+complicate other re-engineering of the device independent part of the
+X server that is currently being contemplated.
+	
+Rather than further delaying RandR's widespread deployment for a
+feature long wanted by the community (resizing of screens,
+particularly on laptops), or the deployment of a protocol design that
+might be flawed due to lack of implementation experience, we decided
+to remove depth switching from the protocol.  It may be implementated
+at a later time if resources and interests permit as a revision to the
+protocol described here, which will remain a stable base for
+applications.  The protocol described here has been implemented in the
+main XFree86 server, and more fully in the TinyX implementation in the
+XFree86 distribution, which fully implements resizing, rotation and
+reflection.
+
+2. Acknowlegements
+
+Our thanks to the contributors to the design found on the xpert mailing list.
+
+2. Screen change model
+
+Screens may change dynamically, either under control of this
+extension, or due to external events. Examples include: monitors being
+swapped, you pressing a button to switch from internal display to an
+external monitor on a laptop, or, eventually, the hotplug of a display
+card entirely on busses such as Cardbus which permit hot-swap (which
+will require other work in addition to this extension).
+
+Since the screen configuration is dynamic and asynchronous to the
+client and may change at any time RandR provides mechanisms to ensure
+that your clients view is up to date with the configuration
+possibilities of the moment and enforces applications that wish to
+control the configuration to prove that their information is up to
+date before honoring requests to change the screen configuration (by
+requiring a timestamp on the request).
+
+Interested applications are notified whenever the screen configuration
+changes, providing the current size of the screen and subpixel order
+(see the Render extension [RENDER]), to enabel proper rendering of
+subpixel decimated client text to continue, along with a time stamp of
+the configuration change.  A client must refresh its knowledge of the
+screen configuration before attempting to change the configuration
+after a notification, or the request will fail.
+
+To avoid multiplicative explosion between orientation, reflection
+and sizes, the sizes are only those sizes in the normal (0) rotation.
+
+Rotation and reflection and how they interact can be confusing.  In
+Randr, the coordinate system is rotated in a counter-clockwise
+direction relative to the normal orientation.  Reflection is along the
+window system coordinate system, not the physical screen X and Y axis,
+so that rotation and reflection do not interact.  The other way to
+consider reflection is to is specified in the "normal" orientation,
+before rotation, if you find the other way confusing.
+
+We expect that most clients and toolkits will be oblivious to changes
+to the screen stucture, as they generally use the values in the
+connections Display structure directly.  By toolkits updating the
+values on the fly, we believe pop-up menus and other pop up windows
+will position themselves correctly in the face of screen configuration
+changes (the issue is ensuring that pop-ups are visible on the
+reconfigured screen).
+
+3. Data Types
+
+The subpixel order is shared with the Render extension, and is
+documented there.  The only datatype defined is the screen size,
+defined in the normal (0 degree) orientation.
+
+
+4. Errors
+
+There are no new error types defined by this extension.
+
+5. Protocol Types
+
+ROTATION {
+	 RR_rotate_0
+	 RR_rotate_90
+	 RR_rotate_180
+	 RR_rotate_270
+	 RR-Reflect_X
+	 RR_Reflect_Y }
+
+RRSELECTMASK { RRScreenChangeNotifyMask }
+
+SIZEID { CARD16 }
+
+SUBPIXELORDER { SubPixelUnknown		The subpixel order uses the Render
+	      SubPixelHorizontalRGB	extensions definitions; they are here
+	      SubPixelHorizontalBGR	only for convenience.
+	      SubPixelVerticalRGB
+	      SubPixelVerticalBGR
+	      SubPixelNone }
+
+
+6. Extension Initialization
+
+The name of this extension is "RANDR".
+
+RRQueryVersion
+	client-major-version:	CARD32
+	client-minor-version:	CARD32
+	->
+	major-version:		CARD32
+	minor-version:		CARD32
+
+	The client sends the highest supported version to the server
+	and the server sends the highest version it supports, but no
+	higher than the requested version.  Major versions changes can
+	introduce incompatibilities in existing functionality, minor
+	version changes introduce only backward compatible changes.
+	It is the clients responsibility to ensure that the server
+	supports a version which is compatible with its expectations.
+
+7. Extension Requests
+
+RRSelectInput
+	window: WINDOW
+	enable: SETofRRSELECTMASK
+
+	Errors: BadWindow, BadValue
+
+	If enable is RRScreenChangeNotifyMask, RRScreenChangeNotify
+	events will be sent anytime the screen configuration changes,
+	either from this protocol extension, or due to detected
+	external screen configuration changes. RRScreenChangeNotify
+	may also be sent immediately if the screen configuration has
+	changed since the client connected, to avoid race conditions.
+
+RRSetScreenConfig
+	drawable: DRAWABLE
+	timestamp: TIMESTAMP
+	config-timestamp: TIMESTAMP
+	sizeID: SIZEID
+	rotation: ROTATION
+	rate: CARD16
+
+	->
+
+	new-timestamp: TIMESTAMP
+	config-timestamp: TIMESTAMP
+	root: WINDOW
+	subpixelOrder: SUBPIXELORDER
+
+	Errors: BadValue, BadMatch
+
+	If the timestamp in this request is less than the time when
+	the configuration was last successfully set, the request is
+	ignored and False returned in success.  If the
+	config-timestamp in this request is not equal to when the
+	server's screen configurations last changed, the request is
+	ignored and False returned in success.  This could occur if
+	the screen changed since you last made a RRGetScreenInfo
+	request, perhaps by a different piece of display hardware
+	being installed.  Rather than allowing an incorrect call to be
+	executed based on stale data, the server will ignore the
+	request.
+
+	If rate is zero, the server selects an appropriate rate.
+
+	If the request succeeds, this request sets the screen to the
+	specified size, rate, rotation and reflection. If the requests
+	succeeds, the new-time-stamp is returned containing the time
+	when the screen configuration was changed and config-timestamp
+	is returned to indicate when the possible screen
+	configurations were last changed, and success is set to True.
+	The root window for the screen indicated by the drawable
+	argument is also returned, along with the subpixel order, to
+	allow correct subpixel rendering.
+
+	BadValue errors are generated if the rotation is not an
+	allowed rotation. BadValue errors are generated, if, when the
+	timestamps would allow the operation to succeed, or size-index
+	are not possible (out of range).
+
+
+RRGetScreenInfo
+	window: WINDOW
+
+	->	
+
+	rotations: SETofROTATION
+	root: WINDOW
+	timestamp: TIMESTAMP
+	config-timestamp: TIMESTAMP
+	nSizes: CARD16
+	sizeID: SIZEID
+	rotation: ROTATION
+	rate: CARD16
+	sizes: LISTofSCREENSIZE
+	refresh: LISTofREFRESH
+
+	where:
+
+	SCREENSIZE {    
+		 widthInPixels, heightInPixels: CARD16
+		  widthInMillimeters, heightInMillimeters: CARD16 }
+
+	REFRESH {
+		rates: LISTofCARD16
+	}
+
+	Errors: BadWindow
+
+	This event is delivered to clients selecting for notification
+	with RRSelectInput requests using a RRScreenChangeNotifyMask.
+
+	Size-index indicates which size is active.  The returned
+	window is the window requsting notification.
+
+	This call returns the root window of the screen which has changed.
+
+	Rotations contains the set of rotations and reflections
+	supported by the screen of the window requested. The root
+	window of that screen is reported. The number of current sizes
+	supported is returned, along with which size rotation and
+	reflection the screen is currently set to.
+
+	The config-timestamp indicates when the screen configuration
+	information last changed: requests to set the screen will fail
+	unless the timestamp indicates that the information the client
+	is using is up to date, to ensure clients can be well behaved
+	in the face of race conditions. Similarly, timestamp indicates
+	when the configuration was last set, and must both must be up
+	to date in a call to RRSetScreenConfig for it to succeed.
+	
+	Rate is the current refresh rate.  This is zero when the refresh
+	rate is unknown or on devices for which refresh is not relevant.
+
+	Sizes is the list of possible frame buffer sizes (at the
+	normal orientation, each provide both the linear physical size
+	of the screen and the pixel size.
+
+	Refresh is the list of refresh rates for each size, each element
+	of sizes has a cooresponding element in refresh.  An empty list
+	indicates no known rates, or a device for which refresh is not
+	relevant.
+
+	The default size of the screen (the size that would become the
+	current size when the server resets) is the first size in the
+	list.  The potential screen sizes themselves are also
+	returned.
+
+	Toolkits SHOULD use RRScreenChangeSelectInput to be notified
+	via a RRScreenChangeNotify event, so that they can adapt to
+	screen size changes.
+
+
+8. Extension Events
+
+Clients MAY select for ConfigureNotify on the root window to be
+informed of screen changes.  This may be advantageous if all your
+clients need to know is the size of the root window, as it avoids
+round trips to set up the extension.
+
+RRScreenChangeNotify is sent if RRSelectInput has requested it
+whenever properties of the screen change, which may be due to external
+factors, such as recabling a monitor, etc.
+
+RRScreenChangeNotify
+
+	rotation: ROTATION;		new rotation
+	sequenceNumber: CARD16		low 16 bits of request's seq. number
+	timestamp: TIMESTAMP		time screen was changed
+	configTimestamp: TIMESTAMP	time config data was changed
+	root: WINDOW			root window of screen
+	window: WINDOW			window requesting notification
+	sizeID: SIZEID			new ID of size
+	subpixelOrder: SUBPIXELORDER	order of subpixels
+	widthInPixels: INT16
+	heightInPixels: INT16
+	widthInMillimeters: INT16
+	heightInMillimeters: INT16
+
+	This event is generated whenever the screen configuration is
+	changed and sent to requesting clients. The timestamp included
+	indicates when the screen configuration was changed, and
+	configTimestamp says when the last time the configuration was
+	changed. The root is the root of the screen the change
+	occurred on, and the event window is also returned.  SizeID
+	contains an index indicating which size is current.
+
+	This event is sent whenever the screen's configuration changes
+	or if a new screen configuration becomes available that was
+	not available in the past.  In this case (config-timestamp in
+	the event not being equal to the config-timestamp returned in
+	the last call to RRGetScreenInfo), the client MUST call
+	RRGetScreenInfo to update its view of possible screen
+	configurations to have a correct view of possible screen
+	organizations. Timestamp is set to when the active screen
+	configuration was changed.
+
+	Clients which select screen change notification events may be
+	sent an event immediately if the screen configuration was
+	changed between when they connected to the X server and
+	selected for notification.  This is to prevent a common race
+	that might occur on log-in, where many applications start up
+	just at the time when a display manager or log in script might
+	be changing the screen size or configuration.
+
+
+9. Extension Versioning
+
+The RandR extension was developed in parallel with the implementation
+to ensure the feasibility of various portions of the design.  As
+portions of the extension are implemented, the version number of the
+extension has changed to reflect the portions of the standard provied.
+This document describes the version 1.0 of the specification, the
+partial implementations have version numbers less than that.  Here's a
+list of what each version before 1.0 implemented:
+
+	0.0: This prototype implemented resize and rotation in the
+	     TinyX server Used approximately the protocol described in
+	     the Usenix paper.  Appeared in the TinyX server in
+	     XFree86 4.2, but not in the XFree86 main server.
+
+	0.1: Added subpixel order, added an event for subpixel order.
+	     This version was never checked in to XFree86 CVS.
+
+	1.0: Implements resize, rotation, and reflection.  Implemented
+	     both in the XFree86 main server (size change only at this
+	     date), and fully (size change, rotation, and reflection)
+	     in XFree86's TinyX server.
+
+	1.1: Added refresh rates
+
+Compatibility between 0.0 and 1.0 was *NOT* preserved, and 0.0 clients
+will fail against 1.0 servers.  The wire encoding op-codes were
+changed for GetScreenInfo to ensure this failure in a relatively
+graceful way.  Version 1.1 servers and clients are cross compatible with
+1.0.  Version 1.1 is considered to be stable and we intend upward
+compatibility from this point.
+
+
+Appendix A. Protocol Encoding
+
+Syntactic Conventions
+
+This document uses the same syntactic conventions as the core X
+protocol encoding document.
+
+
+A.1 Common Types
+
+	SETofROTATION
+
+	0x0001	RR_Rotate_0
+	0x0002	RR_Rotate_90
+	0x0004	RR_Rotate_180
+	0x0008	RR_Rotate_270
+	0x0010	RR_Reflect_X
+	0x0020	RR_Reflect_Y
+
+
+	SETofRRSELECTMASK
+
+	0x0001	RRScreenChangeNotifyMask
+
+
+A.2 Protocol Requests
+
+
+Opcodes 0x1 and 0x3 were used in the 0.0 protocols, and will return
+errors if used in version 1.0.
+
+	RRQueryVersion
+
+	1	CARD8			major opcode
+	1	0x01			RandR opcode
+	2	3			length
+	4	CARD32			major version
+	4	CARD32			minor version
+	->
+	1	1			Reply
+        1				unused
+	2	CARD16			sequence number
+	4	0			reply length
+	1	CARD32			major version
+        1	CARD32			minor version
+
+	RRSetScreenConfig
+
+	1	CARD8			major opcode
+	1	0x02			RandR opcode
+	2	5			length
+	4	DRAWABLE		drawable on screen to be configured
+	4	TIMESTAMP		timestamp
+	2	SIZEID			size id
+	2	ROTATION		rotation/reflection
+	2	CARD16			refresh rate (1.1 only)
+	2	CARD16			pad
+	->
+	1	1			Reply
+	1	CARD8			status
+		0x0 RRSetConfigSuccess
+		0x1 RRSetConfigInvalidConfigTime
+		0x2 RRSetConfigInvalidTime
+		0x3 RRSetConfigFailed
+	2	CARD16			sequence number
+	4	0			reply length
+	4	TIMESTAMP		new timestamp
+	4	TIMESTAMP		new configuration timestamp
+	4	WINDOW			root
+	2	SUBPIXELORDER		subpixel order defined in Render
+	2	CARD16			pad4
+	4	CARD32			pad5
+	4	CARD32			pad6
+
+	
+	RRSelectInput
+
+	1	CARD8			major opcode
+	1	0x04			RandR opcode
+	2	3			length
+	4	WINDOW			window
+	2	SETofRRSELECTMASK	enable
+	2	CARD16			pad
+
+
+	RRGetScreenInfo
+
+	1	CARD8			major opcode
+	1	0x05			RandR opcode
+	2	2			length
+	4	WINDOW			window
+	->
+	1	1			Reply
+	1	CARD8			set of Rotations
+	2	CARD16			sequence number
+	4	0			reply length
+	4	WINDOW			root window
+	4	TIMESTAMP		timestamp
+	4	TIMESTAMP		config timestamp
+	2	CARD16			number of SIZE following
+	2	SIZEID			sizeID
+	2	ROTATION		current rotation and reflection
+	2	CARD16			rate (1.1)
+	2	CARD16			length of rate info (number of CARD16s)
+	2	CARD16			pad
+
+	SIZE
+	2	CARD16			width in pixels
+	2	CARD16			height in pixels
+	2	CARD16			width in millimeters
+	2	CARD16			height in millimeters
+
+	REFRESH
+	2	CARD16			number of rates (n)
+	2n	CARD16			rates
+
+A.2 Protocol Event
+
+	RRScreenChangeNotify
+
+	1	Base + 0		code
+	1	ROTATION		new rotation and reflection
+	2	CARD16			sequence number
+	4	TIMESTAMP		timestamp
+	4	TIMESTAMP		configuration timestamp
+	4	WINDOW			root window
+	4	WINDOW			request window
+	2	SIZEID			size ID
+	2	SUBPIXELORDER		subpixel order defined in Render
+	2	CARD16			width in pixels
+	2	CARD16			height in pixels
+	2	CARD16			width in millimeters
+	2	CARD16			height in millimeters
+
+
+Bibliography
+
+[RANDR] Gettys, Jim and Keith Packard, "The X Resize and Rotate
+	Extension - RandR", Proceedings of the 2001 USENIX Annual
+	Technical Conference, Boston, MA
+
+[RENDER] 
+	Packard, Keith, "The X Rendering Extension", work in progress,
+	documents found in xc/specs/Render.
diff --git a/specs/Render/library b/specs/Render/library
new file mode 100644
index 0000000..97081c1
--- /dev/null
+++ b/specs/Render/library
@@ -0,0 +1,600 @@
+                         The Xrender Library
+			    Version 0.7
+			      2002-11-6
+			    Keith Packard
+			  keithp@xfree86.org
+
+1. Introduction
+
+The Xrender library is designed as a lightweight library interface to the
+Render extension.  This document describes how the library maps to the
+protocol without duplicating the semantics described by that document.
+
+2. Data Types
+
+2.1 Primitive Types
+
+For resources represented as CARD32 or XID on the wire, Xrender exposes them
+using an 'unsigned long' type as is the norm for 32-bit data objects in an
+Xlib compatible API.
+
+	typedef unsigned long	Glyph;
+	typedef unsigned long	GlyphSet;
+	typedef unsigned long	Picture;
+	typedef unsigned long	PictFormat;
+
+Glyphs are just CARD32 objects, while GlyphSet, Picture and PictFormat
+values are XIDs.
+
+	typedef int XFixed;
+
+Fixed point numbers buck the Xlib convention by being represented as ints.
+Machines for which 'int' is smaller than 32 bits cannot support the Xrender
+library.
+
+2.2 PictFormat descriptions.
+
+The definition of a PictFormat is exposed by two data structures:
+
+	typedef struct {
+	    short   red;
+	    short   redMask;
+	    short   green;
+	    short   greenMask;
+	    short   blue;
+	    short   blueMask;
+	    short   alpha;
+	    short   alphaMask;
+	} XRenderDirectFormat;
+
+	typedef struct {
+	    PictFormat		id;
+	    int			type;
+	    int			depth;
+	    XRenderDirectFormat	direct;
+	    Colormap		colormap;
+	} XRenderPictFormat;
+
+These serve both as a description of the available formats and as patterns
+against which available formats are matched.
+
+2.3 Picture Attributes
+
+When creating or changing Picture objects, attributes are passed much as
+they are for XCreateWindow/XChangeWindowAttributes.  A structure capable of
+holding all of the attributes has the relevant ones set and a bitmask passed
+as a separate argument which marks the valid entries.
+
+	typedef struct _XRenderPictureAttributes {
+	    Bool		repeat;
+	    Picture		alpha_map;
+	    int			alpha_x_origin;
+	    int			alpha_y_origin;
+	    int			clip_x_origin;
+	    int			clip_y_origin;
+	    Pixmap		clip_mask;
+	    Bool		graphics_exposures;
+	    int			subwindow_mode;
+	    int			poly_edge;
+	    int			poly_mode;
+	    Atom		dither;
+	    Bool		component_alpha;
+	} XRenderPictureAttributes;
+
+2.4 Colors
+
+The core protocol XColor type doesn't include an alpha component, so Xrender
+has a separate type.
+
+	typedef struct {
+	    unsigned short   red;
+	    unsigned short   green;
+	    unsigned short   blue;
+	    unsigned short   alpha;
+	} XRenderColor;
+
+2.5 Glyph Types
+
+Glyphs are stored in the server, so these definitions are passed from the
+client to the library and on to the server as glyphs are rasterized and
+transmitted over the wire.
+
+	typedef struct _XGlyphInfo {
+	    unsigned short  width;
+	    unsigned short  height;
+	    short	    x;
+	    short	    y;
+	    short	    xOff;
+	    short	    yOff;
+	} XGlyphInfo;
+
+2.6 Glyph Rendering types
+
+Glyph rendering can either take a single string of glyph indices or an array
+of one of the following structures.
+
+	typedef struct _XGlyphElt8 {
+	    GlyphSet		    glyphset;
+	    _Xconst char	    *chars;
+	    int			    nchars;
+	    int			    xOff;
+	    int			    yOff;
+	} XGlyphElt8;
+	
+	typedef struct _XGlyphElt16 {
+	    GlyphSet		    glyphset;
+	    _Xconst unsigned short  *chars;
+	    int			    nchars;
+	    int			    xOff;
+	    int			    yOff;
+	} XGlyphElt16;
+	
+	typedef struct _XGlyphElt32 {
+	    GlyphSet		    glyphset;
+	    _Xconst unsigned int    *chars;
+	    int			    nchars;
+	    int			    xOff;
+	    int			    yOff;
+	} XGlyphElt32;
+	
+2.7 Geometric Types
+
+Geometric operations directly expose the available protocol datatypes
+
+	typedef struct _XPointFixed {
+	    XFixed  x, y;
+	} XPointFixed;
+	
+	typedef struct _XLineFixed {
+	    XPointFixed	p1, p2;
+	} XLineFixed;
+	
+	typedef struct _XTriangle {
+	    XPointFixed	p1, p2, p3;
+	} XTriangle;
+	
+	typedef struct _XTrapezoid {
+	    XFixed  top, bottom;
+	    XLineFixed	left, right;
+	} XTrapezoid;
+
+	typedef struct _XTransform {
+	    XFixed  matrix[3][3];
+	} XTransform;
+
+2.8 Transformation Filters
+
+All of the filters are named simultaneously; Xrender provides no convenience
+functions for dealing with them.
+
+	typedef struct _XFilters {
+	    int	    nfilter;
+	    char    **filter;
+	    int	    nalias;
+	    short   *alias;
+	} XFilters;
+
+2.9 Index type PictFormat colors
+
+PictFormats of Index type advertise which colors will be used for drawing
+through this type.
+
+	typedef struct _XIndexValue {
+	    unsigned long    pixel;
+	    unsigned short   red, green, blue, alpha;
+	} XIndexValue;
+
+
+3 Application Startup Functions
+
+3.1 Initialization functions
+
+	Bool XRenderQueryExtension (Display *dpy, 
+			            int     *event_basep, 
+				    int     *error_basep)
+
+This function returns True if the Render extension is available on dpy.
+event_basep and error_basep will be filled in with the first event and error
+numbers used by the extension (note that Render currently uses no events).
+
+	Status XRenderQueryVersion (Display *dpy,
+				    int     *major_versionp,
+				    int     *minor_versionp)
+
+XRenderQueryVersion returns zero if the Render extension is not present or
+some error occurred while attempting to discover the current Render version
+number.  Otherwise, XRenderQueryVersion returns 1 and stores the version
+number returned by the server in *major_versionp and *minor_versionp, which
+will be less than or equal to the library version numbers RENDER_MAJOR and
+RENDER_MINOR.
+
+	Status XRenderQueryFormats (Display *dpy)
+
+XRenderQueryFormats returns 1 if it successfully fetches the available
+PictFormat information from the X server, 0 otherwise.  Applications needn't
+invoke this function directly (hmm, perhaps it should be removed from the
+external interfaces then).
+
+3.2 Subpixel Order
+
+	int XRenderQuerySubpixelOrder (Display *dpy, int screen)
+
+	Bool XRenderSetSubpixelOrder (Display *dpy, int screen, int subpixel)
+
+Applications interested in the geometry of the elements making up a single
+pixel on the screen should use XRenderQuerySubpixelOrder and not cache the
+return value.  XRenderSetSubpixelOrder is used by the XRandR library to
+update the value stored by Xrender when the subpixel order changes as a
+result of screen reconfiguration.
+
+3.3 PictFormat matching
+
+Xrender provides these APIs to help locate appropriate PictFormats; they are
+intended to work much like the Visual matching APIs in Xlib.  The
+application provides a specification including the necessary PictFormat
+characteristics and Xrender returns a matching XRenderPictFormat structure
+which describes the PictFormat.
+
+	XRenderPictFormat *
+	XRenderFindFormat (Display			*dpy,
+			   unsigned long		mask,
+			   _Xconst XRenderPictFormat	*templ,
+			   int				count)
+    
+	#define PictFormatID	    (1 << 0)
+	#define PictFormatType	    (1 << 1)
+	#define PictFormatDepth	    (1 << 2)
+	#define PictFormatRed	    (1 << 3)
+	#define PictFormatRedMask   (1 << 4)
+	#define PictFormatGreen	    (1 << 5)
+	#define PictFormatGreenMask (1 << 6)
+	#define PictFormatBlue	    (1 << 7)
+	#define PictFormatBlueMask  (1 << 8)
+	#define PictFormatAlpha	    (1 << 9)
+	#define PictFormatAlphaMask (1 << 10)
+	#define PictFormatColormap  (1 << 11)
+	
+XRenderFindFormat locates a PictFormat matching the characteristics provided
+in the templ.  Only elements whose associated bit in mask are compared.
+
+	XRenderPictFormat *
+	XRenderFindVisualFormat (Display *dpy, _Xconst Visual *visual)
+
+Finds the PictFormat suitable for use with the specified visual.
+
+	XRenderPictFormat *
+	XRenderFindStandardFormat (Display		*dpy,
+				   int			format)
+
+	#define PictStandardARGB32  0
+	#define PictStandardRGB24   1
+	#define PictStandardA8	    2
+	#define PictStandardA4	    3
+	#define PictStandardA1	    4
+	#define PictStandardNUM	    5
+
+As a convenience, this function locates PictFormats that coorespond to
+commonly used formats.
+
+	ARGB32		depth 32, bits 31-24 A, 23-16 R, 15-8 G, 7-0 B
+	RGB24		depth 24, bits 23-16 R, 15-8 G, 7-0 B
+	A8		depth 8, bits 7-0 A
+	A4		depth 4, bits 3-0 A
+	A1		depth 1, bits 0 A
+
+Any server supporting Render must have a PictFormat cooresponding to each of
+these standard formats.
+
+3.4 Index type PictFormat color values
+
+	XIndexValue *
+	XRenderQueryPictIndexValues(Display			*dpy,
+				    _Xconst XRenderPictFormat	*format,
+				    int				*num)
+
+If format refers to an Index type PictFormat, XRenderQueryPictIndexValues
+returns the set of pixel values and their associated colors used when
+drawing to Pictures created with that format.  Otherwise,
+XRenderQueryPictIndexValues generates a BadMatch error.
+
+3.5 Querying available filters
+
+	XFilters *
+	XRenderQueryFilters (Display *dpy, Drawable drawable);
+
+Filters are used with non-identity transformation matrices, this function
+returns a datastructure identifying the available filters on display that
+can be associated with pictures for the screen associated with drawable.
+
+Free this structure with XFree.
+
+4 Picture Functions
+
+	Picture
+	XRenderCreatePicture (Display				*dpy,
+			      Drawable				drawable,
+			      _Xconst XRenderPictFormat		*format,
+			      unsigned long			valuemask,
+			      _Xconst XRenderPictureAttributes	*attributes)
+	
+	#define CPRepeat			    (1 << 0)
+	#define CPAlphaMap			    (1 << 1)
+	#define CPAlphaXOrigin			    (1 << 2)
+	#define CPAlphaYOrigin			    (1 << 3)
+	#define CPClipXOrigin			    (1 << 4)
+	#define CPClipYOrigin			    (1 << 5)
+	#define CPClipMask			    (1 << 6)
+	#define CPGraphicsExposure		    (1 << 7)
+	#define CPSubwindowMode			    (1 << 8)
+	#define CPPolyEdge			    (1 << 9)
+	#define CPPolyMode			    (1 << 10)
+	#define CPDither			    (1 << 11)
+	#define CPComponentAlpha		    (1 << 12)
+	#define CPLastBit			    11
+
+Creates a picture for drawable in the specified format.  Any values
+specified in 'attributes' and 'valuemask' are used in place of the default
+values.
+
+	void
+	XRenderChangePicture (Display				*dpy,
+			      Picture				picture,
+			      unsigned long			valuemask,
+			      _Xconst XRenderPictureAttributes  *attributes)
+
+Change values in picture to those specified by valuemask and attributes.
+			      
+
+	void
+	XRenderSetPictureClipRectangles (Display	    *dpy,
+					 Picture	    picture,
+					 int		    xOrigin,
+					 int		    yOrigin,
+					 _Xconst XRectangle *rects,
+					 int		    n)
+
+Sets the clip mask in picture to the union of rects offset by
+xOrigin/yOrigin.
+
+	void
+	XRenderSetPictureClipRegion (Display	    *dpy,
+				     Picture	    picture,
+				     Region	    r)
+
+Sets the clip mask in picture to r.
+
+	void
+	XRenderSetPictureTransform (Display	    *dpy,
+				    Picture	    picture,
+				    XTransform	    *transform)
+
+Sets the projective transformation matrix of picture to transform.
+
+	void
+	XRenderFreePicture (Display                   *dpy,
+			    Picture                   picture)
+	
+Instructs the server to free picture.
+
+5 GlyphSet functions
+
+	GlyphSet
+	XRenderCreateGlyphSet (Display *dpy, _Xconst XRenderPictFormat *format)
+	
+Creates a glyphset, every glyph in the set will use PictFormat format.
+
+	GlyphSet
+	XRenderReferenceGlyphSet (Display *dpy, GlyphSet existing)
+	
+Creates a new GlyphSet ID which references an existing GlyphSet.  The
+two IDs refer to the same object so that changes using one ID will be
+visible through the other ID.  This is designed to allow multiple clients to
+share the same GlyphSet so that it doesn't get destroyed when the first
+client exits.
+
+	void
+	XRenderFreeGlyphSet (Display *dpy, GlyphSet glyphset)
+	
+Frees the glyphset ID.  If no other GlyphSet IDs refer to the underlying
+GlyphSet, it will be destroyed.
+
+	void
+	XRenderAddGlyphs (Display		*dpy,
+			  GlyphSet		glyphset,
+			  _Xconst Glyph		*gids,
+			  _Xconst XGlyphInfo	*glyphs,
+			  int			nglyphs,
+			  _Xconst char		*images,
+			  int			nbyte_images)
+	
+Add glyphs to glyphset.  The images are packed together in Z-pixmap format
+according to the depth of the PictFormat used in creating glyphset.
+
+	void
+	XRenderFreeGlyphs (Display	    *dpy,
+			   GlyphSet	    glyphset,
+			   _Xconst Glyph    *gids,
+			   int		    nglyphs)
+
+Free some glyphs from glyphset.
+
+6 Glyph Drawing Routines
+
+Xrender provides two parallel APIs for glyph rendering, a simple API which
+accepts a single string similar to XDrawString and a more complex API which
+accepts an array of XGlyphElt{8,16,32} structures, each of which includes a
+glyphset, string and x/y offsets which parallel the XDrawText API.  Xrender
+also provides glyphs in three sizes, 8 16 and 32 bits.  The simple API is
+just a convenience for the user as both forms generate the same underlying
+Render protocol.
+
+6.1 Simple single-string glyph drawing functions
+
+These are identical except for the format of the glyph ids.
+
+	void
+	XRenderCompositeString8 (Display		    *dpy,
+				 int			    op,
+				 Picture		    src,
+				 Picture		    dst,
+				 _Xconst XRenderPictFormat  *maskFormat,
+				 GlyphSet		    glyphset,
+				 int			    xSrc,
+				 int			    ySrc,
+				 int			    xDst,
+				 int			    yDst,
+				 _Xconst char		    *string,
+				 int			    nchar)
+	
+	void
+	XRenderCompositeString16 (Display		    *dpy,
+				  int			    op,
+				  Picture		    src,
+				  Picture		    dst,
+				  _Xconst XRenderPictFormat *maskFormat,
+				  GlyphSet		    glyphset,
+				  int			    xSrc,
+				  int			    ySrc,
+				  int			    xDst,
+				  int			    yDst,
+				  _Xconst unsigned short    *string,
+				  int			    nchar)
+	
+	void
+	XRenderCompositeString32 (Display		    *dpy,
+				  int			    op,
+				  Picture		    src,
+				  Picture		    dst,
+				  _Xconst XRenderPictFormat *maskFormat,
+				  GlyphSet		    glyphset,
+				  int			    xSrc,
+				  int			    ySrc,
+				  int			    xDst,
+				  int			    yDst,
+				  _Xconst unsigned int	    *string,
+				  int			    nchar)
+	
+6.2 Complete glyph drawing functions 
+
+As with the simple functions above, these differ only in the type of the
+underlying glyph id storage type.
+
+	void
+	XRenderCompositeText8 (Display			    *dpy,
+			       int			    op,
+			       Picture			    src,
+			       Picture			    dst,
+			       _Xconst XRenderPictFormat    *maskFormat,
+			       int			    xSrc,
+			       int			    ySrc,
+			       int			    xDst,
+			       int			    yDst,
+			       _Xconst XGlyphElt8	    *elts,
+			       int			    nelt)
+	
+	void
+	XRenderCompositeText16 (Display			    *dpy,
+				int			    op,
+				Picture			    src,
+				Picture			    dst,
+				_Xconst XRenderPictFormat   *maskFormat,
+				int			    xSrc,
+				int			    ySrc,
+				int			    xDst,
+				int			    yDst,
+				_Xconst XGlyphElt16	    *elts,
+				int			    nelt)
+	
+	void
+	XRenderCompositeText32 (Display			    *dpy,
+				int			    op,
+				Picture			    src,
+				Picture			    dst,
+				_Xconst XRenderPictFormat   *maskFormat,
+				int			    xSrc,
+				int			    ySrc,
+				int			    xDst,
+				int			    yDst,
+				_Xconst XGlyphElt32	    *elts,
+				int			    nelt)
+	
+7 Basic Graphics Functions
+
+These are the simplest graphics functions upon which the other functions are
+conceptually built.
+
+7.1 Composite
+
+XRenderComposite exposes the RenderComposite protocol request directly.
+
+	void
+	XRenderComposite (Display   *dpy,
+			  int	    op,
+			  Picture   src,
+			  Picture   mask,
+			  Picture   dst,
+			  int	    src_x,
+			  int	    src_y,
+			  int	    mask_x,
+			  int	    mask_y,
+			  int	    dst_x,
+			  int	    dst_y,
+			  unsigned int	width,
+			  unsigned int	height)
+	
+
+7.2 Rectangles
+
+These functions composite rectangles of the specified color, they differ
+only in that XRenderFillRectangles draws more than one at a time.
+
+	void
+	XRenderFillRectangle (Display		    *dpy,
+			      int		    op,
+			      Picture		    dst,
+			      _Xconst XRenderColor  *color,
+			      int		    x,
+			      int		    y,
+			      unsigned int	    width,
+			      unsigned int	    height)
+	
+	void
+	XRenderFillRectangles (Display		    *dpy,
+			       int		    op,
+			       Picture		    dst,
+			       _Xconst XRenderColor *color,
+			       _Xconst XRectangle   *rectangles,
+			       int		    n_rects)
+	
+8 Geometric Objects
+
+All geometric drawing with Render is performed with sequences of trapezoids
+or triangles; the client is responsible for breaking more complex figures
+into these simple shapes.
+
+8.1 Trapezoids
+
+	void
+	XRenderCompositeTrapezoids (Display		*dpy,
+				    int			op,
+				    Picture		src,
+				    Picture		dst,
+				    _Xconst XRenderPictFormat	*maskFormat,
+				    int			xSrc,
+				    int			ySrc,
+				    _Xconst XTrapezoid	*traps,
+				    int			ntrap)
+
+XRenderCompositeTrapezoids builds RenderTrapezoids requests to composite the
+specified list of trapezoids to dst.  XRenderCompositeTrapezoids will split
+the list of trapezoids to build requests no larger than the maximum request
+size supported by the server.  This can create rendering artifacts as the
+precompositing done by RenderTrapezoids when a maskFormat is specified
+cannot span multiple requests.
+
+8.2 Triangles
+
+Render provides three different ways of encoding triangles on the wire,
+Xrender exposes those with three separate triangle drawing routines.  As
+with trapezoids above, Xrender will split the arguments to fit requests into
+the servers limits, but this may cause rendering artifacts.
diff --git a/specs/Render/protocol b/specs/Render/protocol
new file mode 100644
index 0000000..72b3b61
--- /dev/null
+++ b/specs/Render/protocol
@@ -0,0 +1,1143 @@
+			The X Rendering Extension
+			      Version 0.7
+			        2002-11-6
+			      Keith Packard
+			    keithp@xfree86.org
+
+1. Introduction
+
+The X Rendering Extension (Render) introduces digital image composition as
+the foundation of a new rendering model within the X Window System.
+Rendering geometric figures is accomplished by client-side tesselation into
+either triangles or trapezoids.  Text is drawn by loading glyphs into the
+server and rendering sets of them.
+
+2. Acknowledgments
+
+This extension was the work of many people, in particular:
+
+ +	Thomas Porter and Tom Duff for their formal description
+	of image compositing.
+
+ +	Rob Pike and Russ Cox who designed the Plan 9 window system from
+	which the compositing model was lifted.
+
+ +	Juliusz Chroboczek and Raph Levien whose proposal for client-side
+	glyph management eliminated font handling from the X server.
+
+ +	Jon Leech, Brad Grantham and Allen Akin for patiently explaining
+	how OpenGL works.
+
+ +	Carl Worth for providing the sample implementation of
+ 	trapezoid rendering
+
+ +	Sam Pottle and Jamey Sharp for helping demonstrate the correctness
+ 	of the trapezoid specification.
+
+ +	Owen Taylor for helping specify projective transformations
+
+3. Rendering Model
+
+Render provides a single rendering operation which can be used in a variety of
+ways to generate images:
+
+	dest = (source IN mask) OP dest
+
+Where 'IN' is the Porter/Duff operator of that name and 'OP' is any of the
+list of compositing operators described below, among which can be found all
+of the Porter/Duff binary operators.
+
+To use this operator several additional values are required:
+
+ +	The destination rectangle.  This is a subset of the destination
+ 	within which the rendering is performed.
+
+ +	The source location. This identifies the coordinate in the
+ 	source aligned with the upper left corner of the
+	destination rectangle.
+
+ +	The mask location. This identifies the coordinate in the
+ 	mask aligned with the upper left corner of the
+	destination rectangle.
+
+ +	A clip list.  This limits the rendering to the intersection of the
+ 	destination rectangle with this clip list.
+
+ +	The OP to use
+
+ +	Whether the source should be repeated to cover the destination
+ 	rectangle, extended with a constant pixel value or extended by
+	using the nearest available source pixel.
+
+ +	Whether the mask should be repeated to cover the destination
+ 	rectangle, extended with a constant pixel value or extended by
+	using the nearest available mask pixel.
+
+ +	Whether the mask has a single alpha value for all four channels or
+ 	whether each mask channel should affect the associated source/dest
+	channels.
+
+ +	Whether the source should be reshaped with a projective
+        transformation, and if so, what filter to apply while
+	resampling the data.
+	
+ +	Whether the mask should be reshaped with a projective
+        transformation, and if so, what filter to apply while
+	resampling the data.
+	
+These parameters are variously attached to the operands or included in each
+rendering request.
+
+4. Data types
+
+The core protocol rendering system uses a pixel model and applies color only
+in the final generation of the video signal.  A compositing model operates
+on colors, not pixel values so a new datatype is needed to interpret data as
+color instead of just bits.
+
+The "PictFormat" object holds information needed to translate pixel values
+into red, green, blue and alpha channels.  The server has a list of picture
+formats corresponding to the various visuals on the screen.  There are two
+classes of formats, Indexed and Direct.  Indexed PictFormats hold a list of
+pixel values and RGBA values while Direct PictFormats hold bit masks for each
+of R, G, B and A.
+
+The "Picture" object contains a Drawable, a PictFormat and some
+rendering state.  More than one Picture can refer to the same Drawable.
+
+5. Errors
+
+Errors are sent using core X error reports.
+
+PictFormat
+	A value for a PICTFORMAT argument does not name a defined PICTFORMAT.
+
+Picture
+	A value for a PICTURE argument does not name a defined PICTURE.
+
+PictOp
+	A value for a PICTOP argument does not name a defined PICTOP.
+
+GlyphSet
+	A value for a GLYPHSET argument does not name a defined GLYPHSET.
+
+Glyph
+	A value for a GLYPH argument does not name a defined GLYPH in the
+	glyphset.
+
+6. Protocol Types
+
+PICTURE		32-bit value (top three bits guaranteed to be zero)
+PICTFORMAT	32-bit value (top three bits guaranteed to be zero)
+PICTTYPE	{ Indexed, Direct }
+PICTOP		{ Clear, Src, Dst, Over, OverReverse, In, InReverse,
+		  Out, OutReverse, Atop, AtopReverse, Xor, Add, Saturate,
+		  DisjointClear, DisjointSrc, DisjointDst, DisjointOver,
+		  DisjointOverReverse, DisjointIn, DisjointInReverse,
+		  DisjointOut, DisjointOutReverse, DisjointAtop,
+		  DisjointAtopReverse, DisjointXor,
+		  ConjointClear, ConjointSrc, ConjointDst, ConjointOver,
+		  ConjointOverReverse, ConjointIn, ConjointInReverse,
+		  ConjointOut, ConjointOutReverse, ConjointAtop,
+		  ConjointAtopReverse, ConjointXor }
+SUBPIXEL	{ Unknown, HorizontalRGB, HorizontalBGR, 
+		  VerticalRGB, VerticalBGR, None
+		}
+COLOR		[	
+			red, green, blue, alpha: CARD16
+		]
+CHANNELMASK	[
+			shift, mask: CARD16
+		]
+DIRECTFORMAT	[
+			red, green, blue, alpha: CHANNELMASK 
+		]
+INDEXVALUE	[ 
+			pixel: Pixel; 
+			red, green, blue, alpha: CARD16 
+		]
+PICTFORMINFO	[
+			id:		PICTFORMAT
+			type:		PICTTYPE
+			depth:		CARD8
+			direct:		DIRECTFORMAT
+			colormap:	COLORMAP or None
+		]
+
+PICTVISUAL	[
+			visual:		VISUALID or None
+			format:		PICTFORMAT
+		]
+
+PICTDEPTH	[
+			depth:		CARD8
+			visuals:	LISTofPICTVISUAL
+		]
+
+PICTSCREEN	LISTofPICTDEPTH
+
+FIXED		32-bit value (top 16 are integer portion, bottom 16 are fraction)
+TRANSFORM	[
+			p11, p12, p13:	FIXED
+			p21, p22, p23:	FIXED
+			p31, p32, p33:	FIXED
+		]
+POINTFIX	[
+			x, y: FIXED
+		]
+POLYEDGE	{ Sharp, Smooth }
+POLYMODE	{ Precise, Imprecise }
+COLORPOINT	[
+			point:		POINTFIX
+			color:		COLOR
+		]
+SPANFIX		[
+			left, right, y: FIXED
+		]
+COLORSPANFIX	[
+			left, right, y: FIXED
+			left_color:	COLOR
+			right_color:	COLOR
+QUAD		[
+			p1, p2, p3, p4:	POINTFIX
+		]
+TRIANGLE	[
+			p1, p2, p3:	POINTFIX
+		]
+LINEFIX		[
+			p1, p2:		POINTFIX
+		]
+TRAP		[
+			top, bottom:	FIXED
+			left, right:	LINEFIX
+		]
+COLORTRIANGLE	[
+			p1, p2, p3:	COLORPOINT
+		]
+COLORTRAP	[
+			top, bottom:	COLORSPANFIX
+		]
+GLYPHSET	32-bit value (top three bits guaranteed to be zero)
+GLYPH		32-bit value
+GLYPHINFO	[
+			width, height:	CARD16
+			x, y:		INT16
+			off-x, off-y:	INT16
+		]
+PICTGLYPH	[
+			info:		GLYPHINFO
+			x, y:		INT16
+		]
+GLYPHABLE	GLYPHSET or FONTABLE
+GLYPHELT8	[
+			dx, dy:		INT16
+			glyphs:		LISTofCARD8
+		]
+GLYPHITEM8	GLYPHELT8 or GLYPHABLE
+GLYPHELT16	[
+			dx, dy:		INT16
+			glyphs:		LISTofCARD16
+		]
+GLYPHITEM16	GLYPHELT16 or GLYPHABLE
+GLYPHELT32	[
+			dx, dy:		INT16
+			glyphs:		LISTofCARD32
+		]
+GLYPHITEM32	GLYPHELT32 or GLYPHABLE
+
+7. Standard PictFormats
+
+The server must support a Direct PictFormat with 8 bits each of red, green,
+blue and alpha as well as a Direct PictFormat with 8 bits of red, green and
+blue and 0 bits of alpha.  The server must also support Direct PictFormats
+with 1, 4 and 8 bits of alpha and 0 bits of r, g and b.
+
+Pixel component values lie in the close range [0,1].  These values are
+encoded in a varying number of bits.  Values are encoded in a straight
+forward manner.  For a component encoded in m bits, a binary encoding b
+is equal to a component value of b/(2^m-1).
+
+A Direct PictFormat with zero bits of alpha component is declared to have
+alpha == 1 everywhere.  A Direct PictFormat with zero bits of red, green and
+blue is declared to have red, green, blue == 0 everywhere.  If any of red,
+green or blue components are of zero size, all are of zero size.  Direct
+PictFormats never have colormaps and are therefore screen independent.
+
+Indexed PictFormats never have alpha channels and the direct component is all
+zeros.  Indexed PictFormats always have a colormap in which the specified
+colors are allocated read-only and are therefore screen dependent.  Drawing
+to in Indexed Picture uses only pixel values listed by QueryPictIndexValues.
+Reading from an Indexed Picture uses red, green and blue values from the
+colormap and alpha values from those listed by QueryPictIndexValues.  Pixel
+values not present in QueryPictIndexValues are given alpha values of 1.
+
+8. Compositing Operators
+
+For each pixel, the four channels of the image are computed with:
+
+	C = Ca * Fa + Cb * Fb
+
+where C, Ca, Cb are the values of the respective channels and Fa and Fb
+come from the following table:
+
+	PictOp			Fa			Fb
+	--------------------------------------------------
+	Clear			0			0
+	Src			1			0
+	Dst			0			1
+	Over			1			1-Aa
+	OverReverse		1-Ab			1
+	In			Ab			0
+	InReverse		0			Aa
+	Out			1-Ab			0
+	OutReverse		0			1-Aa
+	Atop			Ab			1-Aa
+	AtopReverse		1-Ab			Aa
+	Xor			1-Ab			1-Aa
+	Add			1			1
+	Saturate		min(1,(1-Ab)/Aa)	1
+	DisjointClear		0			0
+	DisjointSrc		1			0
+	DisjointDst		0			1
+	DisjointOver		1			min(1,(1-Aa)/Ab)
+	DisjointOverReverse	min(1,(1-Ab)/Aa)	1
+	DisjointIn		max(1-(1-Ab)/Aa,0)	0
+	DisjointInReverse	0			max(1-(1-Aa)/Ab,0)
+	DisjointOut		min(1,(1-Ab)/Aa)	0
+	DisjointOutReverse	0			min(1,(1-Aa)/Ab)
+	DisjointAtop		max(1-(1-Ab)/Aa,0)	min(1,(1-Aa)/Ab)
+	DisjointAtopReverse	min(1,(1-Ab)/Aa)	max(1-(1-Aa)/Ab,0)
+	DisjointXor		min(1,(1-Ab)/Aa)	min(1,(1-Aa)/Ab)
+	ConjointClear		0			0
+	ConjointSrc		1			0
+	ConjointDst		0			1
+	ConjointOver		1			max(1-Aa/Ab,0)
+	ConjointOverReverse	max(1-Ab/Aa,0)		1
+	ConjointIn		min(1,Ab/Aa)		0
+	ConjointInReverse	0			min(Aa/Ab,1)
+	ConjointOut		max(1-Ab/Aa,0)		0
+	ConjointOutReverse	0			max(1-Aa/Ab,0)
+	ConjointAtop		min(1,Ab/Aa)		max(1-Aa/Ab,0)
+	ConjointAtopReverse	max(1-Ab/Aa,0)		min(1,Aa/Ab)
+	ConjointXor		max(1-Ab/Aa,0)		max(1-Aa/Ab,0)
+
+Saturate and DisjointOverReverse are the same.  They match OpenGL
+compositing with FUNC_ADD, SRC_ALPHA_SATURATE, ONE, except that Render uses
+premultiplied alpha while Open GL uses non-premultiplied alpha.
+
+The result of any compositing operator is always limited to the range
+[0,1] for each component.  Components whose value would be greater than 1
+are set to 1.
+
+For operations involving division, when the divisor is zero, define the
+quotient to be positive infinity.  The result is always well defined
+because the division is surrounded with a max or min operator which will
+give a finite result.
+
+When the mask contains separate alpha values for each channel, the
+alpha value resulting from the combination of that value with the source
+alpha channel is used in the final image composition.
+
+9. Source and Mask Transformations
+
+When fetching pixels from the source or mask pictures, Render provides three
+options for pixel values which fall outside the drawable (this includes
+pixels within a window geometry obscured by other windows).
+
+ +	Transparent.  Missing values are replaced with transparent.
+ 
+ +	Nearest.  Replace missing pixels with the nearest available
+ 	pixel.  Where multiple pixels are equidistant, select
+	those with smallest Y and then smallest X coordinates
+
+ +	Tile.  Select the pixel which would appear were the
+ 	drawable tiled to enclose the missing coordinate.  If
+	the tiling doesn't cover the coordinate, use the
+	selected Constant or Nearest mode.
+
+When GraphicsExposures are selected in the destination picture, a region
+containing at least the union of all destination pixel values affected by
+data replaced as above is delivered after each compositing operation.  If
+the resulting region is empty, a NoExpose event is delivered instead.
+
+To construct the source and mask operands, the computed pixels values are
+transformed through a homogeneous matrix, filtered and then used in the
+fundemental rendering operator described above.  Each screen provides a list
+of supported filter names. There are a few required filters, and several
+required filter alias which must map to one of the available filters.
+
+10. Polygon Rasterization
+
+All polygons must be convex.  Rendering of concave polygons is unspecified
+except that the result must obey the clipping rules.
+
+Each polygon request fills the region closed by the specified path.  The
+path is automatically closed if the last point does not coincide with the
+first point.
+
+A point is infinitely small and the path is an infinitely thin line.  A
+pixel is inside if the center point of the pixel is inside and the center
+point is not on the boundary.  If the center point is on the boundary, the
+pixel is inside if and only if the polygon interior is immediately to its
+right (x increasing direction).  Pixels with centers along a horizontal edge
+are a special case and are inside if and only if the polygon interior is
+immediately below (y increasing direction).  A polygon contains a pixel if
+the pixel is inside the polygon.
+
+Polygons are rasterized by implicit generating an alpha mask and using that
+in the general compositing operator along with a supplied source image:
+
+	tmp = Rasterize (polygon)
+	Composite (op, dst, src, tmp)
+
+When rasterized with Sharp edges, the mask is computed with a depth of 1 so
+that all of the mask values are either 0 or 1.
+
+When rasterized with Smooth edges, the mask is generated by creating a square
+around each pixel coordinate and computing the amount of that square covered
+by the polygon.  This ignores sampling theory but it provides a precise
+definition which is close to the right answer.  This value is truncated to
+the alpha width in the fallback format before application of the compositing
+operator.
+
+---
+
+This needs rewriting to match current trapezoid specification and
+base other polygons on that.  I suspect imprecise polygons will need
+to have a relaxed specification as well; hardware is unlikely to
+meet the "sum to one" constraint.
+
+---
+
+When rasterized in Precise mode, the pixelization will match this
+specification exactly.
+
+When rasterized in Imprecise mode, the pixelization may deviate from this
+specification by up to 1/2 pixel along any edge subject to the following
+constraints:
+
+ +	Abutting edges must match precisely.  When specifying two polygons
+	abutting along a common edge, if that edge is specified with the
+	same coordinates in each polygon then the sum of alpha values for
+	pixels inside the union of the two polygons must be precisely one.
+
+ +	Translationally invarient.  The pixelization of the polygon must
+	be the same when either the polygon or the target drawable
+	are translated by any whole number of pixels in any direction.
+
+ +	Sharp edges are honored.  When the polygon is rasterized with Sharp
+	edges, the implicit alpha mask will contain only 1 or 0 for
+	each pixel.
+
+ +	Order independent. Two identical polygons specified with vertices
+	in different orders must generate identical results.
+
+Polygons can also be specified with colors for each vertex.  These color
+values are interpolated along the edges and across each scanline.
+
+When rasterized in Precise mode, the interpolated colors are exact.
+
+When rasterized in Imprecise mode, the color of each pixel may optionally be
+interpolated from a triangle containing the pixel which is formed from any
+three polygon vertices.  Any interpolated color value can err up to 1 lsb in
+each channel.
+
+11. Image Filtering
+
+When computing pixels from source and mask images, a filter may be applied
+to the data.  This is usually used with a non-identity transformation
+matrix, but filtering may be applied with an identity transformation.
+
+Each filter is given a unique name encoded as an ISO Latin-1 string.
+Filters may be configured with a list of fixed point values; the number of
+parameters and their interpretation is currently left to conventions passed
+outside of the protocol.  A set of standard filters are required to be
+provided:
+
+	Filter Name	Description
+
+	Nearest		Nearest neighbor filtering
+	Bilinear	Linear interpolation in two dimensions
+
+Additional names may be provided for any filter as aliases.  A set of
+standard alias names are required to be mapped to a provided filter so that
+applications can use the alias names without checking for availability.
+
+	Alias name	Intended interpretation
+	
+	Fast		High performance, quality similar to Nearest
+	Good		Reasonable performance, quality similar to Bilinear
+	Best		Highest quality available, performance may not
+			be suitable for interactive use
+
+Aliases must map directly to a non-aliased filter name.
+
+12. Glyph Rendering
+
+Glyphs are small alpha masks which can be stored in the X server and
+rendered by referring to them by name.  A set of glyphs can be rendered in a
+single request.  Glyphs are positioned by subtracting the x, y elements of
+the GLYPHINFO from the requested rendering position.  The next glyph
+rendering position is set to the current rendering position plus the off-x
+and off-y elements.
+
+Glyphs are stored in GlyphSets and are named within the GlyphSet with
+client-specified 32-bit numbers.
+
+Glyphs can be stored in any PictFormat supported by the server.  All glyphs
+in a GlyphSet are stored in the same format.
+
+13. Extension Initialization
+
+The client must negotiate the version of the extension before executing
+extension requests.  Behavior of the server is undefined otherwise.
+
+QueryVersion
+
+	client-major-version:		CARD32
+	client-minor-version:		CARD32
+
+	->
+
+	major-version:			CARD32
+	minor-version:			CARD32
+
+	The client sends the highest supported version to the server and
+	the server sends the highest version it supports, but no higher than
+	the requested version.  Major versions changes can introduce
+	incompatibilities in existing functionality, minor version
+	changes introduce only backward compatible changes.  It is
+	the clients responsibility to ensure that the server supports
+	a version which is compatible with its expectations.
+
+QueryPictFormats
+
+	->
+
+	fallback:	PICTFORMAT
+	formats:	LISTofPICTFORMINFO
+	screens:	LISTofPICTSCREEN
+	subpixels:	LISTofSUBPIXEL
+
+	Errors:
+		<none>
+
+	The server responds with a list of supported PictFormats and
+	a list of which PictFormat goes with each visual on each screen.
+	Every PictFormat must match a supported depth, but not every
+	PictFormat need have a matching visual.
+
+	The fallback format is used as an intermediate representation
+	in cases where there is no ideal choice.
+
+	The relationship between the red, green and blue elements making
+	up each pixel indexed by screen is returned in subpixels.
+	This list is not present in servers advertising protocol
+	versions earlier than 0.6.  This list may be shorter than
+	the number of screens, in which case the remaining screens
+	are given sub pixel order Unknown.
+
+QueryPictIndexValues
+
+	format:		PICTFORMAT
+
+	->
+
+	values:		LISTofINDEXVALUE
+
+	Errors:
+		PictFormat, Match
+
+	Returns the mapping from pixel values to RGBA values for the
+	specified Indexed PictFormat.  If 'format' does not refer to
+	an Indexed PictFormat a Match error is generated.
+
+QueryFilters
+
+	drawable:	DRAWABLE
+
+	->
+
+	filters:	LISTofSTRING8
+	aliases:	LISTofCARD16
+
+	
+14. Extension Requests
+
+CreatePicture
+
+	pid:		PICTURE
+	drawable:	DRAWABLE
+	format:		PICTFORMAT
+	value-mask:	BITMASK
+	value-list:	LISTofVALUE
+
+	Errors:
+		Alloc, Drawable, IDChoice, Match, Pixmap, Picture,
+		PictFormat, Value
+
+	This request creates a Picture object associated with the specified
+	drawable and assigns the identifier pid to it.  Pixel data in the
+	image are interpreted according to 'format'.  It is a Match error
+	to specify a format with a different depth than the drawable.  If
+	the drawable is a Window then the Red, Green and Blue masks must
+	match those in the visual for the window else a Match error is
+	generated.
+
+	The value-mask and value-list specify attributes of the picture that
+	are to be explicitly initialized.  The possible values are:
+	
+	repeat:			BOOL
+	fill-nearest:		BOOL
+	alpha-map:		PICTURE or None
+	alpha-x-origin:		INT16
+	alpha-y-origin:		INT16
+	clip-x-origin:		INT16
+	clip-y-origin:		INT16
+	clip-mask:		PIXMAP or None
+	graphics-exposures:	BOOL
+	subwindow-mode:		{ ClipByChildren, IncludeInferiors }
+	poly-edge:		POLYEDGE
+	poly-mode:		POLYMODE
+	dither:			ATOM or None
+	component-alpha:	BOOL
+	
+	When used as a source or mask operand, the repeat and fill-constant
+	values control how pixels outside the geometry of the drawable are
+	computed.
+	
+	Fill-nearest indicates that pixel values outside of the drawable
+	geometry should be replaced the nearest available pixel within the
+	drawable geometry is used.  When multiple pixels are equidistant,
+	those with smaller Y and then X values are preferred.  Otherwise,
+	missing pixels are replaced with transparent.
+
+	Repeat indicates that the drawable contents should be treated
+	as if tiled in both directions.  Pixels falling in missing
+	areas of this tile are replaced according to the fill-nearest
+	rule.
+	
+	The alpha channel of alpha-map is used in place of any alpha channel
+	contained within the drawable for all rendering operations.  The
+	alpha-mask origin is interpreted relative to the origin of drawable.
+	Rendering is additionally clipped by the geometry of alpha-map.
+	Exposures to the window do not affect the contents of alpha-map.
+	Alpha-map must refer to a picture containing a Pixmap, not a Window
+	(or a Match error results).
+
+	The clip-mask restricts reads and writes to drawable.  Only pixels
+	where the clip-mask has bits set to 1 are read or written.  Pixels
+	are not accessed outside the area covered by the clip-mask or where
+	the clip-mask has bits set to 0.  The clip-mask affects all graphics
+	requests, including sources.  The clip-mask origin is interpreted
+	relative to the origin of drawable.  If a pixmap is specified as the
+	clip-mask, it must have depth 1 and have the same root as the
+	drawable (or a Match error results).  If clip-mask is None, then
+	pixels are always drawn, regardless of the clip origin.  The
+	clip-mask can also be set with the SetPictureClipRectangles request.
+	
+	For ClipByChildren, both source and destination windows are
+	additionally clipped by all viewable InputOutput children.  For
+	IncludeInferiors , neither source nor destination window is clipped
+	by inferiors.  This will result in including subwindow contents in
+	the source and drawing through subwindow boundaries of the
+	destination.  The use of IncludeInferiors with a source or
+	destination window of one depth with mapped inferiors of differing
+	depth is not illegal, but the semantics are undefined by this
+	extension.
+
+	The graphics-exposures flag controls GraphicsExposure event
+	generation for Composite requests (and any similar requests
+	defined by additional extensions).
+
+	Poly-edge and poly-mode control the rasterization of polygons
+	as described above.
+
+	Dither selects which of the available dither patterns should
+	be used.  If dither is None, no dithering will be done.
+
+	Component-alpha indicates whether each image component is
+	intended as a separate alpha value when the picture is used
+	as a mask operand.
+
+	The default component values are
+
+		Component		Default
+		-------------------------------
+		repeat			False
+		fill-nearest:		False
+		clip-x-origin        	0
+		clip-y-origin          	0
+		clip-mask		None
+		graphics-exposures	True
+		subwindow-mode		ClipByChildren
+		poly-edge		Smooth
+		poly-mode		Precise
+		dither			None
+		component-alpha		False
+
+ChangePicture
+
+	pid:		PICTURE
+	value-mask:     BITMASK
+	value-list:     LISTofVALUE
+
+	Errors:
+		Picture, Alloc, Pixmap, PictOp, Value
+
+	The value-mask and value-list specify which attributes are to be
+	changed.  The values and restrictions are the same as for 
+	CreatePicture.
+
+SetPictureClipRectangles
+
+	picture:	PICTURE
+	clip-x-origin:	INT16
+	clip-y-origin:	INT16
+	rectangles:	LISTofRECTANGLE
+
+	Errors:
+		Alloc, Picture
+
+	This request changes clip-mask in picture to the specified list of
+	rectangles and sets the clip origin.  Input and output will be
+	clipped to remain contained within the rectangles.  The clip origin
+	is interpreted relative to the origin of the drawable associated
+	with picture.  The rectangle coordinates are interpreted relative to
+	the clip origin.  Note that the list of rectangles can be empty,
+	which effectively disables output.  This is the opposite of passing
+	None as the clip-mask in CreatePicture and ChangePicture.
+	
+	Note that output is clipped to the union of all of the rectangles
+	and that no particular ordering among the rectangles is required.
+
+SetPictureTransform
+
+	picture:	PICTURE
+	transform:	TRANSFORM
+
+	Errors:
+		Alloc, Value, Picture
+
+	This request changes the projective transformation used to
+	map coordinates when 'picture' is used as the source or
+	mask in any compositing operation.  The transform
+	maps from destination pixel geometry back to the source pixel
+	geometry.
+
+	The matrix must be invertable, else a Value error is generated.
+
+SetPictureFilter
+
+	picture:	PICTURE
+	filter:		STRING8
+	values:		LISTofFIXED
+
+	Errors:
+		Value, Match, Picture
+
+	This request sets the current filter used when picture is a source
+	or mask operand.  Filter must be one of the filters supported
+	for the screen associated with picture, else a Match error
+	is generated.  If the filter accepts additional parameters,
+	they can be provided in values, incorrect values generate Value
+	errors, too many values generate Match errors.  Too few values
+	cause the filter to assume default values for the missing
+	parameters.
+
+	When created, Pictures are set to the Nearest filter.
+
+FreePicture
+
+	pid:		PICTURE
+
+	Errors:
+		Picture
+
+	This request deletes the association between the resource ID and the
+	picture.  The picture storage will be freed when no other resource
+	references it.
+
+Composite
+
+	op:		PICTOP
+	src:		PICTURE
+	mask:		PICTURE or None
+	dst:		PICTURE
+	src-x, src-y:	INT16
+	mask-x, mask-y:	INT16
+	dst-x, dst-y:	INT16
+	width, height:	CARD16
+
+	This request combines the specified rectangle of the transformed
+	src and mask operands with the specified rectangle of dst using op
+	as the compositing operator.  The coordinates are relative their
+	respective (transformed) drawable's origin.  Rendering is clipped
+	to the geometry of the dst drawable and then to the dst clip-list.
+
+	Pixels outside the geometry of src or mask needed for this
+	computation are substituted as described in the Source and Mask
+	Transformations section above.
+	
+	If src, mask and dst are not in the same format, and one of their
+	formats can hold all without loss of precision, they are converted
+	to that format.  Alternatively, the server will convert each
+	operand to the fallback format.
+
+	If mask is None, it is replaced by a constant alpha value of 1.
+
+	When dst has graphics-exposures true, a region covering all dst
+	pixels affected by substitutions performed on src or mask pixels
+	outside their respective geometries is computed.  If that region is
+	empty, a NoExpose event is sent.  Otherwise, a sequence of
+	GraphicsExpose events are sent covering that region.
+
+FillRectangles
+
+	op:		PICTOP
+	dst:		PICTURE
+	color:		COLOR
+	rects:		LISTofRECTANGLE
+
+	This request combines color with the destination drawable in the
+	area specified by rects.  Each rectangle is combined separately;
+	overlapping areas will be rendered multiple times.  The effect is
+	equivalent to compositing with a repeating source picture filled with
+	the specified color.
+
+Trapezoids
+
+	op:		PICTOP
+	src:		PICTURE
+	src-x, src-y:   INT16
+	dst:		PICTURE
+	mask-format:	PICTFORMAT or None
+	traps:		LISTofTRAP
+
+	This request rasterizes the list of trapezoids.  For each trap, the
+	area between the left and right edges is filled from the top to the
+	bottom.  src-x and src-y register the pattern to the floor of the
+	top x and y coordinate of the left edge of the first trapezoid, they
+	are adjusted for subsequent trapezoids so that the pattern remains
+	globally aligned within the destination.
+
+	When mask-format is not None, trapezoids are rendered in the
+	following way with the effective mask computed in mask-format:
+
+		tmp = temporary alpha picture (in mask-format)
+		Combine (Zero, tmp, tmp, None)
+		for each trapezoid
+			Combine (Add, tmp, trapezoid, None)
+		Combine (op, dst, source, tmp)
+
+	When mask-format is None, trapezoids are rendered in the order
+	specified directly to the destination:
+
+		for each trapezoid
+			Combine (op, dst, source, trapezoid)
+
+Triangles
+
+	op:		PICTOP
+	src:		PICTURE
+	src-x, src-y:   INT16
+	dst:		PICTURE
+	mask-format:	PICTFORMAT or None
+	triangles:	LISTofTRIANGLE
+
+	This request rasterizes the list of triangles in the order they
+	occur in the list.
+
+	When mask-format is not None, triangles are rendered in the
+	following way with the effective mask computed in mask-format:
+
+		tmp = temporary alpha picture (in mask-format)
+		Combine (Zero, tmp, tmp, None)
+		for each triangle
+			Combine (Add, tmp, triangle, None)
+		Combine (op, dst, source, tmp)
+
+	When mask-format is None, triangles are rendered in the order
+	specified directly to the destination:
+
+		for each triangle
+			Combine (op, dst, source, triangle)
+
+TriStrip
+
+	op:		PICTOP
+	src:		PICTURE
+	src-x, src-y:   INT16
+	dst:		PICTURE
+	mask-format:	PICTFORMAT or None
+	points:		LISTofPOINTFIX
+
+	Triangles are formed by initially using the first three points and
+	then by eliminating the first point and appending the next point in
+	the list. If fewer than three points are provided, this request does
+	nothing.
+
+	When mask-format is not None, triangles are rendered in the
+	following way with the effective mask computed in mask-format:
+
+		tmp = temporary alpha picture (in mask-format)
+		Combine (Zero, tmp, tmp, None)
+		for each triangle
+			Combine (Add, tmp, triangle, None)
+		Combine (op, dst, source, tmp)
+
+	When mask-format is None, triangles are rendered in the order
+	specified directly to the destination:
+
+		for each triangle
+			Combine (op, dst, source, triangle)
+
+TriFan
+	op:		PICTOP
+	src:		PICTURE
+	src-x, src-y:   INT16
+	dst:		PICTURE
+	mask-format:	PICTFORMAT or None
+	points:		LISTofPOINTFIX
+
+	Triangles are formed by initially using the first three points and
+	then by eliminating the second point and appending the next point
+	int the list. If fewer than three points are provided, this request
+	does nothing.
+
+	When mask-format is not None, triangles are rendered in the
+	following way with the effective mask computed in mask-format:
+
+		tmp = temporary alpha picture (in mask-format)
+		Combine (Zero, tmp, tmp, None)
+		for each triangle
+			Combine (Add, tmp, triangle, None)
+		Combine (op, dst, source, tmp)
+
+	When mask-format is None, triangles are rendered in the order
+	specified directly to the destination:
+
+		for each triangle
+			Combine (op, dst, source, triangle)
+
+ColorTrapezoids
+
+	op:		PICTOP
+	dst:		PICTURE
+	trapezoids:	LISTofCOLORTRAP
+
+	The geometry of the trapezoids must meet the same requirements as
+	for the Trapezoids request.  The trapezoids are filled in the order
+	they occur in the list.
+
+ColorTriangles
+
+	op:		PICTOP
+	dst:		PICTURE
+	triangles:	LISTofCOLORTRIANGLE
+
+	The colored triangles are rasterized in the order they occur in the
+	list.
+
+???
+
+Should I included compressed triangle representations here?
+
+???
+
+CreateGlyphSet
+
+	gsid:		GLYPHSET
+	format:		PICTFORMAT
+
+	Errors:
+		Alloc, IDChoice, PictFormat, Match
+
+	This request creates a container for glyphs.  The glyphset and
+	all contained glyphs are destroyed when gsid and any other names
+	for the glyphset are freed.  Format must be a Direct format, when
+	it contains RGB values, the glyphs are composited using
+	component-alpha True, otherwise they are composited using
+	component-alpha False.
+
+ReferenceGlyphSet
+
+	gsid:		GLYPHSET
+	existing:	GLYPHSET
+
+	Errors:
+		Alloc, IDChoice, GlyphSet
+
+	This request creates an additional name for the existing glyphset.
+	The glyphset will not be freed until all references to it are
+	destroyed.
+
+FreeGlyphSet
+
+	glyphset:	GLYPHSET
+
+	Errors:
+		GlyphSet
+
+	This request frees the name for the glyphset.  When all names have
+	been freed, the glyphset and all contained glyphs are freed.
+
+AddGlyphs
+	glyphset:	GLYPHSET
+	glyphids:	LISTofCARD32
+	glyphs:		LISTofGLYPHINFO
+	data:		LISTofBYTE
+
+	Errors:
+		GlyphSet, Alloc
+
+	This request adds glyphs to glyphset.  The image for the glyphs
+	are stored with each glyph in a separate Z-format image padded to a
+	32-bit boundary.  Existing glyphs with the same names are replaced.
+
+AddGlyphsFromPicture
+
+	glyphset:	GLYPHSET
+	src:		PICTURE
+	glyphs:		LISTofPICTGLYPH
+
+	Errors:
+		GlyphSet, Alloc
+
+	This request adds glyphs to glyphset by copying them from src from
+	the locations included in glyphs.  Existing glyphs with the same
+	names are replaced.  Src may be in a different PictFormat than
+	glyphset, in which case the images are converted to the glyphset
+	format.
+	
+FreeGlyphs
+
+	glyphset:	GLYPHSET
+	glyphs:		LISTofGLYPH
+
+	Errors:
+		GlyphSet, Match
+
+	This request removes glyphs from glyphset.  Each glyph must exist
+	in glyphset (else a Match error results).
+
+CompositeGlyphs8
+CompositeGlyphs16
+CompositeGlyphs32
+
+	op:		PICTOP
+	src:		PICTURE
+	dst:		PICTURE
+	mask-format:	PICTFORMAT or None
+	glyphset:	GLYPHABLE
+	src-x, src-y:	INT16
+	dst-x, dst-y:	INT16
+	glyphcmds:	LISTofGLYPHITEM8	CompositeGlyphs8
+	glyphcmds:	LISTofGLYPHITEM16	CompositeGlyphs16
+	glyphcmds:	LISTofGLYPHITEM32	CompositeGlyphs32
+
+	Errors:
+		Picture, PictOp, PictFormat, GlyphSet, Glyph
+
+	The dst-x and dst-y coordinates are relative to the drawable's
+	origin and specify the baseline starting position (the initial glyph
+	origin).  Each glyph item is processed in turn.  A glyphset item
+	causes the glyhpset to be used for subsequent glyphs.  Switching
+	among glyphsets does not affect the next glyph origin.  A glyph
+	element delta-x and delta-y specify additional changes in the
+	position along the x and y axes before the string is drawn; the
+	deltas are always added to the glyph origin.
+
+	All contained GLYPHSETs are always transmitted most significant byte
+	first.  
+	
+	If a GlyphSet error is generated for an item, the previous items may
+	have been drawn.
+	
+	When mask-format is not None, glyphs are rendered in the following
+	way with the effective mask computed in mask-format:
+
+		tmp = temporary alpha picture
+		Combine (Zero, tmp, tmp, None)
+		for each glyph
+			Combine (Add, tmp, glyph, None)
+		Combine (op, dst, source, tmp)
+
+	When mask-format is None, glyphs are rendered in the order specified
+	directly to the destination:
+
+		for each glyph
+			Combine (op, dst, source, glyph)
+
+CreateCursor
+
+	cid:		CURSOR
+	source:		PICTURE
+	x, y:		CARD16
+
+	Errors:		Alloc, IDChoice, Match, Picture
+
+	This request creates a cursor and associates identifier cid with it.
+	The x and y coordinates define the hotspot relative to the source's
+	origin and must be a point within the source (or a Match error
+	results).  The resulting picture will nominally be drawn to the
+	screen with PictOpOver. 
+	
+	The components of the cursor may be transformed arbitrarily to meet
+	display limitations.  In particular, if the display supports only
+	two colors cursors without translucency, the cursor will be
+	transformed so that areas less than .5 alpha will be transparent,
+	else opaque, and areas darker than 50% gray will be black else white.
+
+	The source picture can be freed immediately if no further explicit
+	references to it are to be made.
+
+	Subsequent drawing in the source has an undefined effect on the
+	cursor.  The server might or might not make a copy of the picture.
+
+15. Extension Versioning
+
+The Render extension was developed in parallel with the implementation to
+ensure the feasibility of various portions of the design.  As portions of
+the extension are implemented, the version number of the extension has
+changed to reflect the portions of the standard provied.  This document
+describes the intent for version 1.0 of the specification, the partial
+implementations have version numbers less than that.  Here's a list of
+what each version before 1.0 implemented:
+
+	0.0:	
+		No disjoint/conjoint operators
+		No component alpha
+		Composite
+		CreateGlyphSet
+		FreeGlyphSet
+		AddGlyphs
+		CompositeGlyphs
+
+	0.1:
+		Component alpha
+		FillRectangles
+
+	0.2:
+		Disjoint/Conjoint operators
+
+	0.3:
+		FreeGlyphs
+
+	0.4:
+		Trapezoids
+		Triangles
+		TriStrip
+		TriFan
+
+	0.5:
+		CreateCursor
+
+	0.6:
+		SetPictureTransform
+		QueryFilters
+		SetPictureFilter
+		subpixels member of QueryPictFormats
+
+	0.7:
+		QueryPictIndexValues
diff --git a/specs/Xv/xv-protocol-v2.txt b/specs/Xv/xv-protocol-v2.txt
new file mode 100644
index 0000000..31e2013
--- /dev/null
+++ b/specs/Xv/xv-protocol-v2.txt
@@ -0,0 +1,654 @@
+
+
+
+
+
+
+
+
+
+			  X Video Extension
+			 Protocol Description
+
+			      Version 2
+
+			      25-JUL-91
+
+			     David Carver
+
+		    Digital Equipment Corporation
+		Workstation Engineering/Project Athena
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
+  Copyright 1991 by Digital Equipment Corporation, Maynard, Massachusetts, 
+  and the Massachusetts Institute of Technology, Cambridge, Massachusetts.
+
+                        All Rights Reserved
+
+  Permission to use, copy, modify, and distribute this software and its
+  documentation for any purpose and without fee is hereby granted, provided
+  that the above copyright notice appear in all copies and that both that
+  copyright notice and this permission notice appear in supporting
+  documentation, and that the names of Digital or MIT not be used in
+  advertising or publicity pertaining to distribution of the software
+  without specific, written prior permission.
+
+  DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING 
+  ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL 
+  DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR 
+  ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER 
+  IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING 
+  OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.  
+  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+
+
+
+  Preface
+  -------
+  
+    The following is an outline for an X video extension protocol.  It
+    is preliminary and subject to change.  My goal in writing this was
+    to fix some the shortcomings of existing overly simplistic
+    extensions while avoiding pitfalls in an overly complex extension.
+  
+    Your feedback is desired, and since the major design directions
+    have been stable for some time, feel free to hammer on the details
+    of the protocol.
+
+    When you receive a revision of the document, refer to the changes
+    and issues sections to guide your review and analysis.
+
+
+  Acknowledgements
+  ---------------
+
+    The following people have made major contributions to the design of
+    the Xv protocol:
+
+      Branko Gerovac (DEC/Corporate Research)
+      Russ Sasnett (GTE/Project Athena)
+      Ralph Swick (DEC/Project Athena)
+
+    Many ideas and approaches in Xv were the product of discussions
+    with several groups, including
+
+      Project Athena's Visual Computing Group
+      The MIT X Consortium 
+      The MIT Media Lab's Interactive Cinema Group
+      
+  
+  
+  Changes
+  -------
+
+    From version 1.3 to 2.0
+
+    -- Changed SetPortControl and GetPortControl to GetPortAttribute
+       and SetPortAttribute.
+
+    -- Changed QueryBestSize
+
+    -- Simplified SelectVideoNotify and SelectPortNotify requests.
+
+    -- Changed the way SetPortControl and GetPortControl works.
+
+    -- Added a QueryExtension request to return the version and
+       revision information of the extension.
+
+    -- Changed the name of the QueryVideo request to QueryAdaptors;
+       Removed the list of encodings from QueryVideo and added a
+       QueryEncodings request.
+
+    -- Added a PortNotify event that notifies interested clients that
+       a port control has been changed.
+
+    -- Added SelectPortNotify request to select for PortNotify events.
+
+    -- The XvInterruped reason has been replaced by two new reasons:
+       one for when video is preempted by another video request and
+       one for when video is terminated because of hard transmission
+       or reception errors.
+
+    -- Changed the wording of the QueryBestSize request.  Added issue
+       about whether or not returned sizes should maintain the
+       requested aspect ratio.
+
+
+
+  Introduction
+  ------------
+  
+    Video technology is moving very quickly.  Standards for processing
+    high resolution video are currently a hot topic of discussion
+    internationally, and it will soon be possible to process video
+    entirely within the digital domain.  The Xv extension, however,
+    does not attempt to address issues of digital video.  Its purpose
+    is to provide a mechanism for support of current and near term
+    interactive video technology.
+    
+    It is somewhat ironic that Xv contains nothing particularly
+    innovative.  It takes a minimalistic approach, and without a doubt
+    it could have been defined years ago, and with several revisions.
+    So, the life expectancy of Xv is not long.  Nevertheless, it may
+    undergo further revision and experimentation that will help our
+    progress towards digital video systems.
+  
+    One premise of the Xv extension is that the X server is not alone.
+    A separate video server is often used to manage other aspects of
+    video processing, though the partition between what the X server
+    does and what a video server does is a matter of great debate.
+
+  
+  Model
+  -----
+  
+    This extension models video monitor capabilities in the X Window
+    System.  Some advanced monitors support the simultaneous display
+    of multiple video signals (into separate windows), and that is
+    prepresented here through the ability to display video from
+    multiple video input adaptors into X drawables.
+  
+    Some monitors support multiple video encodings (mostly for
+    internationalization purposes) either through switches or
+    automatic detection, thus each video adaptor specifies the set of
+    encodings it supports.
+  
+    The requests to display video from an adaptor into a drawable are
+    modeled after the core PutImage request, though extended to
+    support scaling and source clipping.
+  
+    Video output is also supported and is symmetric with the video
+    input function, though fewer GC components are used.
+  
+  
+  Mechanism
+  ---------
+  
+    The Xv extension does the following:
+  
+      --  lists available video adaptors
+      --  identifies the number of ports each adaptor supports
+      --  describes what drawable formats each adaptor supports
+      --  describes what video encodings each adaptor supports
+      --  displays video from a port to a drawable
+      --  captures video from a drawable to a port
+      --  grabs and ungrabs ports
+      --  sets and gets port attributes
+      --  delivers event notification
+  
+
+  
+  Adaptors
+  --------
+  
+    A display may have multiple video input and output adaptors.  An
+    adaptor may support multiple simultaneously active ports, and in
+    some cases the number of ports has no fixed limit.
+  
+    An input port receives encoded video data and converts it to a
+    stream of data used to update a drawable.  An output port samples
+    data from a drawable and produces a stream of encoded video data.
+  
+    The ADAPTORINFO structure is used to describe a video adaptor.
+    
+    ADAPTORINFO:
+  	[base-id: PORT
+         num-ports: CARD16
+         type: SETofADAPTORTYPE
+         formats: LISTofFORMAT
+         name: STRING]
+  
+    ADAPTORTYPE: {Input, Output}
+
+    FORMAT:
+  	[depth: CARD8
+  	 visual: VISUALID]
+  
+    The base-id field specifies the XID of the first port of the
+    adaptor.  The `num-ports' field specifies how many ports the
+    adaptor supports.  The ports of the adaptor have XIDs in the range
+    [base-id..base-id + num-ports - 1]
+
+    The type attribute determines if the adaptor can process video
+    input, output, or input and output.  The if the adaptor can
+    process input then Input is asserted, if the adaptor can process
+    output then Output is asserted.
+
+    The drawable depths and visual types supported by the adaptor are
+    listed in `formats'.  Note: that when video is being processed for
+    pixmaps the visual format is taken to be the visual of the first
+    pair that matches the depth of the pixmap.
+
+    The name field contains an a vendor specific string that
+    identifies the adaptor.
+
+    It should be noted that the existence of separate adaptors doesn't
+    necessarily imply that simultaneous operation is supported.
+
+
+  
+  Errors
+  ------
+  
+    Port
+  
+    A Port error is returned if any request names a PORT that does not
+    exist.
+
+  
+    Encoding
+  
+    An Encoding error is returned if any request names an ENCODINGID
+    that does not exist.
+
+
+
+  
+  Query Requests
+  -------------------
+
+    QueryExtension
+    ==>
+      version: CARD16
+      revision: CARD16
+
+    The QueryExtension request returns the extension version and
+    revision numbers.
+
+  
+    QueryAdaptors
+      win: WINDOW
+    ==>
+      adaptors: LISTofADAPTORINFO
+  
+    The QueryAdaptors request returns the video adaptor information for
+    the screen of the specified window.
+  
+    Errors: {Window}
+
+
+    QueryEncodings    
+      port: PORT
+    ==>
+      encodings: LISTofENCODINGINFO
+
+    The QueryEncodings request returns the list of encodings supported
+    by the port adaptor.  Use the SetPortAttribute request to set
+    which encoding a port is to process.  The ENCODINGINFO record
+    describes an encoding:
+
+    ENCODINGINFO:
+  	[encoding: ENCODINGID
+  	 name: STRING
+  	 width, height: CARD16
+  	 rate: FRACTION]
+  
+    The `encoding' field identifies an encoding supported by a port.
+    Its value is unique for a screen.  Width and height specify the
+    size of the video image and rate specifies the rate at which
+    fields of image information are encoded.
+  
+    An encoding is identified by a string that names the encoding.
+    Encoding naming conventions need to be established (i.e.,
+    something along the lines of font naming, but simpler)
+  
+    FRACTION
+          [numerator, denominator: INT32]
+  
+    The FRACTION structure is used to specify a fractional number.
+
+    Errors: {Port}
+
+
+  
+  Put Video Requests
+  ------------------
+  
+    PutVideo
+      port: PORT
+      drawable: DRAWABLE
+      gc: GCONTEXT
+      vid-x, vid-y: INT16
+      vid-w, vid-h: CARD16
+      drw-x, drw-y: INT16
+      drw-w, drw-h: CARD16
+  
+    The PutVideo request writes video into a drawable.  The position
+    and size of the source rectangle is specified by vid-x, vid-y,
+    vid-w, and vid-h.  The position and size of the destination
+    rectangle is specified by drw-x, drw-y, drw-w, drw-h.
+  
+    Video data is clipped to the bounds of the video encoding, scaled
+    to the requested drawable region size (or the closest size
+    supported), and clipped to the bounds of the drawable.
+
+    If video is successfully initiated, a VideoNotify event with
+    detail Started is generated for the drawable.  If the port is
+    already in use, its video is preempted, and if the new drawable is
+    different than the old, a VideoNotify event with detail Preempted
+    is generated for the old drawable.  If the port is grabbed by
+    another client, this request is ignored, and a VideoNotify event
+    with detail Busy is generated for the drawable.  If the port is
+    not receiving a valid video signal or if the video signal is
+    interrupted while video is active a VideoNotify event with detail
+    HardError is generated for the drawable.
+
+    GC components: subwindow-mode, clip-x-origin, clip-y-origin, clip-mask.
+  
+    Errors: {Match, Value, GContext, Port, Alloc}
+  
+  
+    PutStill
+      port: PORT
+      drawable: DRAWABLE
+      gc: GCONTEXT
+      vid-x, vid-y: INT16
+      vid-w, vid-h: CARD16
+      drw-x, drw-y: INT16
+      drw-w, drw-h: CARD16
+  
+    The PutStill request writes a single frame of video into a
+    drawable.  The position and size of the source rectangle is
+    specified by vid-x, vid-y, vid-w, and vid-h.  The position and
+    size of the destination rectangle is specified by drw-x, drw-y,
+    drw-w, drw-h.
+  
+    Video data is clipped to the bounds of the video encoding, scaled
+    to the requested drawable region size (or the closest size
+    supported) and clipped to the bounds of the drawable.
+
+    If the port is grabbed by another client, this request is ignored,
+    and a VideoNotify event with detail Busy is generated for the
+    drawable.  If the port is not receiving a valid video signal a
+    VideoNotify event with detail HardError is generated for the
+    drawable.
+
+    GC components: subwindow-mode, clip-x-origin, clip-y-origin, clip-mask.
+  
+    Errors: {Match, Value, GContext, Port, Alloc}
+  
+  
+  
+  Get Video Requests
+  ------------------
+  
+    GetVideo
+      port: PORT
+      drawable: DRAWABLE
+      gc: GCONTEXT
+      vid-x, vid-y: INT16
+      vid-w, vid-h: CARD16
+      drw-x, drw-y: INT16
+      drw-w, drw-h: CARD16
+  
+    The GetVideo request outputs video from a drawable.  The position
+    and size of the destination rectangle is specified by vid-x,
+    vid-y, vid-w, and vid-h.  The position and size of the source
+    rectangle is specified by drw-x, drw-y, drw-w, and drw-h.
+  
+    Drawable data is clipped to the bounds of the drawable, scaled to
+    the requested video region size (or the closest size supported)
+    and clipped to the bounds of the video encoding.  The contents of
+    any region not updated with drawable data is undefined.
+
+    If video is successfully initiated, a VideoNotify event with
+    detail Started is generated for the drawable.  If the port is
+    already in use, its video is preempted, and if the new drawable is
+    different than the old, a VideoNotify event with detail Preempted
+    is generated for the old drawable.  If the port is grabbed by
+    another client, this request is ignored, and a VideoNotify event
+    with detail Busy is generated for the drawable.
+
+    GC components: subwindow-mode, clip-x-origin, clip-y-origin,
+    clip-mask.
+  
+    Errors: {Match, Value, GContext, Port, Alloc}
+  
+  
+    GetStill
+      port: PORT
+      drawable: DRAWABLE
+      gc: GCONTEXT
+      vid-x, vid-y: INT16
+      vid-w, vid-h: CARD16
+      drw-x, drw-y: INT16
+      drw-w, drw-h: CARD16
+  
+    The GetStill request outputs video from a drawable.  The position
+    and size of the destination rectangle is specified by vid-x,
+    vid-y, vid-w, and vid-h.  The position and size of the source
+    rectangle is specified by drw-x, drw-y, drw-w, and drw-h.
+  
+    Drawable data is clipped to the bounds of the drawable, scaled to
+    the requested video region size (or the closest size supported)
+    and clipped to the bounds of the video encoding.  The contents of
+    any region not updated with drawable data is undefined.
+
+    If the still is successfully captured a VideoNotify event with
+    detail Still is generated for the drawable.  If the port is
+    grabbed by another client, this request is ignored, and a
+    VideoNotify event with detail Busy is generated for the drawable.
+
+    GC components: subwindow-mode, clip-x-origin, clip-y-origin,
+    clip-mask.
+  
+    Errors: {Match, Value, GContext, Port, Alloc}
+  
+  
+  
+  
+  Grab Requests
+  -------------
+  
+    GrabPort
+      port: PORT    
+      timestamp: {TIMESTAMP, CurrentTime}
+    ==>
+      status: {Success, AlreadyGrabbed, InvalidTime}
+  
+    The GrabPort request grabs a port.  While a port is grabbed, only
+    video requests from the grabbing client are permitted.
+  
+    If timestamp specifies a time older than the current port time, a
+    status of InvalidTime is returned.  If the port is already grabbed
+    by another client, a status of AlreadyGrabbed is returned.
+    Otherwise a status of Success is returned. The port time is
+    updated when the following requests are processed: GrabPort,
+    UngrabPort, PutVideo, PutStill, GetVideo, GetStill
+  
+    If the port is actively processing video for another client, the
+    video is preempted, and an VideoNotify event with detail Preempted
+    is generated for its drawable.
+
+    Errors: {Port}
+  
+  
+    UngrabPort
+      port: PORT    
+      timestamp: {TIMESTAMP, CurrentTime}
+  
+    The UngrabPort request ungrabs a port.  If timestamp specifies a
+    time before the last connection request time of this port, the
+    request is ignored.
+  
+    Errors: {Port}
+  
+
+
+  Other Requests
+  --------------
+  
+    StopVideo
+      port: PORT
+      drawable: DRAWABLE
+  
+    The StopVideo request stops active video for the specified port
+    and drawable.  If the port isn't processing video, or if it is
+    processing video in a different drawable, the request is ignored.
+    When video is stopped a VideoNotify event with detail Stopped is
+    generated for the associated drawable.
+
+    Errors: {Drawable, Port}  
+
+  
+    SelectVideoNotify
+      drawable: DRAWABLE
+      onoff: BOOL
+  
+    The SelectVideoNotify request enables or disables VideoNotify
+    event delivery to the requesting client.  VideoNotify events are
+    generated when video starts and stops.
+
+    Errors: {Drawable}
+
+
+    SelectPortNotify
+      port: PORT
+      onoff: BOOL
+  
+    The SelectPortNotify request enables or disables PortNotify event
+    delivery to the requesting client.  PortNotify events are
+    generated when port attributes are changed using SetPortAttribute.
+
+    Errors: {Port}
+
+  
+    QueryBestSize
+      port: PORT
+      motion: BOOL
+      vid-w, vid-h: CARD16
+      drw-w, drw-h: CARD16
+    ==>
+      actual-width, actual-height: CARD16
+  
+    The QueryBestSize request returns, for the given source size and
+    desired destination size, the closest destination size that the
+    port adaptor supports.  The returned size will be equal
+    or smaller than the requested size if one is supported.  If motion
+    is True then the requested size is intended for use with full
+    motion video.  If motion is False, the requested size is intended
+    for use with stills only.
+
+    The retuned size is also chosen to maintain the requested aspect ratio
+    if possible.
+  
+    Errors: {Port}
+  
+
+    
+    SetPortAttribute
+      port: PORT
+      attribute: ATOM
+      value: INT32
+  
+    The SetPortAttribute request sets the value of a port attribute.
+    The port attribute is identified by the attribute atom.  The
+    following strings are guaranteed to generate valid atoms using the
+    InternAtom request.
+
+    String                Type          
+    -----------------------------------------------------------------
+  
+    "XV_ENCODING"         ENCODINGID
+    "XV_HUE"	          [-1000..1000] 
+    "XV_SATURATION"       [-1000..1000] 
+    "XV_BRIGHTNESS"       [-1000..1000] 
+    "XV_CONTRAST"         [-1000..1000]
+  
+
+    If the given attribute doesn't match an attribute supported by the
+    port adaptor a Match error is generated.  The supplied encoding
+    must be one of the encodings listed for the adaptor, otherwise an
+    Encoding error is generated.
+
+    If the adaptor doesn't support the exact hue, saturation,
+    brightness, and contrast levels supplied, the closest levels
+    supported are assumed.  The GetPortAttribute request can be used
+    to query the resulting levels.
+
+    When a SetPortAttribute request is processed a PortNotify event is
+    generated for all clients that have requested port change
+    notification using SelectPortNotify.
+
+    Errors: {Port, Match, Value}
+  
+  
+    GetPortAttribute
+      port: PORT
+      attribute: ATOM
+    ==>
+      value: INT32  
+        
+
+    The GetPortAttribute request returns the current value of the
+    attribute identified by the given atom.  If the given atom
+    doesn't match an attribute supported by the adaptor a Match
+    error is generated.
+
+    Errors: {Port, Match}
+
+
+
+  Events
+  ------
+  
+    VideoNotify
+      drawable: DRAWABLE
+      port: PORT
+      reason: REASON
+      time: TIMESTAMP
+
+    REASON: {Started, Still, Stopped, Busy, Preempted, HardError}
+
+    A VideoNotify event is generated when video activity is started,
+    stopped, or unable to proceed in a drawable.
+
+    A Started reason is generated when video starts in a drawable.
+
+    A Stopped reason is generated when video is stopped in a
+    drawable upon request.
+
+    A Busy reason is generated when a put or get request cannot
+    proceed because the port is grabbed by another client.
+
+    A Preempted reason is generated when video is stopped by a
+    conflicting request.
+  
+    A HardError reason is generated when the video port cannot
+    initiate or continue processing a video request because of an
+    underlying transmission or reception error.
+  
+
+    PortNotify
+      port: PORT
+      attribute: ATOM
+      value: INT32
+      time: TIMESTAMP
+  
+    The PortNotify event is generated when a SetPortAttribute request
+    is processed.  The event is delivered to all clients that have
+    performed a SelectPortNotify request for the port.  The event
+    contains the atom identifying the attribute that changed, and the
+    new value of that attribute.
diff --git a/specs/XvMC/XvMC_API.txt b/specs/XvMC/XvMC_API.txt
new file mode 100644
index 0000000..9aded3a
--- /dev/null
+++ b/specs/XvMC/XvMC_API.txt
@@ -0,0 +1,1293 @@
+
+   X-Video Motion Compensation - API specification v. 1.0
+
+   Mark Vojkovich <markv@xfree86.org>
+
+
+/* history */
+
+   first draft (9/6/00)
+   second draft (10/31/00) - Changed to allow acceleration at both
+      the motion compensation and IDCT level.
+   third draft (1/21/01) - Some refinements and subpicture support.
+   fourth draft (5/2/01) - Dual Prime clarification, add
+      XvMCSetAttribute.
+   fifth draft (6/26/01) - Change definition of XvMCCompositeSubpicture
+      plus some clarifications and fixed typographical errors.
+   sixth draft (9/24/01) - Added XVMC_SECOND_FIELD and removed 
+      XVMC_PROGRESSIVE_FRAME and XVMC_TOP_FIELD_FIRST flags.
+   seventh draft (10/26/01) - Added XVMC_INTRA_UNSIGNED option.
+   eighth draft (11/13/02) - Removed IQ level acceleration and
+      changed some structures to remove unused fields.
+
+/* acknowledgements */
+
+   Thanks to Matthew J. Sottek from Intel for lots of input.
+
+/********************************************************************/
+
+      OVERVIEW
+
+/********************************************************************/
+
+     XvMC extends the X-Video extension (Xv) and makes use of the
+  familar concept of the XvPort.  Ports have attributes that can be set 
+  and queried through Xv.  In XvMC ports can also have hardware motion
+  compensation contexts created for use with them.  Ports which support 
+  XvImages (ie. they have an "XV_IMAGE" port encoding as described in 
+  the Xv version 2.2 API addendum) can be queried for the list of XvMCSurface
+  types they support.  If they support any XvMCSurface types an 
+  XvMCContext can be created for that port.
+
+     An XvMCContext describes the state of the motion compensation
+  pipeline.  An individual XvMCContext can be created for use with
+  a single port, surface type, motion compensation type, width and
+  height combination.  For example, a context might be created for a
+  particular port that does MPEG-2 motion compensation on 720 x 480
+  4:2:0 surfaces.  Once the context is created, referencing it implies 
+  the port, surface type, size and the motion compensation type.  Contexts
+  may be "direct" or "indirect".  For indirect contexts the X server
+  renders all video using the data passed to it by the client.  For
+  direct contexts the client libraries render the video with little
+  or no interaction with the X server.
+
+     XvMCSurfaces are buffers into which the motion compensation
+  hardware can render.  The data in the buffers themselves are not client
+  accessible and may be stored in a hardware-specific format.  Any
+  number of buffers can be created for use with a particular context
+  (resources permitting).
+
+     XvMC provides video acceleration starting at one of two places
+  in the video pipeline.  Acceleration starting at the first point,
+  which we shall call the "Motion Compensation" level, begins after the
+  the inverse quantization and IDCT at the place where motion compensation
+  is to be applied.  The second point, which we shall call the "IDCT" 
+  level, begins before the IDCT just after the inverse quantization.
+
+     Rendering is done by presenting the library with a target XvMCSurface
+  and up to two reference XvMCSurfaces for the motion compensation, a 
+  buffer of 8x8 blocks and a command buffer which describes how to
+  use the 8x8 blocks along with motion compensation vectors to construct
+  the data in the target XvMCSurface.  When the pipeline starts at the
+  IDCT level, Xv will perform the IDCT on the blocks before performing
+  the motion compensation. A function is provided to copy/overlay a
+  portion of the XvMCSurface to a drawable with arbitrary scaling.
+
+    XvMCSubpictures are separate surfaces that may be blended with the
+  target surface.  Any number of XvMCSubpictures may be created for use
+  with a context (resources permitting).  Both "backend" and "frontend"
+  subpicture behavior are supported.
+
+/********************************************************************/
+
+          QUERYING THE EXTENSION 
+
+/********************************************************************/
+
+/* Errors */
+#define XvMCBadContext		0
+#define XvMCBadSurface		1
+#define XvMCBadSubpicture	2
+
+Bool XvMCQueryExtension (Display *display, int *eventBase, int *errBase)
+
+   Returns True if the extension exists, False otherwise.  Also returns
+ the error and event bases.
+
+   display - The connection to the server.
+
+   eventBase -
+   errBase -  The returned event and error bases.  Currently there
+              are no events defined.
+
+Status XvMCQueryVersion (Display *display, int *major, int *minor)
+
+   Query the major and minor version numbers of the extension.
+
+   display - The connection to the server.
+
+   major -
+   minor -  The returned major and minor version numbers.
+
+/********************************************************************/
+
+          QUERYING SURFACE TYPES
+
+/********************************************************************/
+
+/* Chroma formats */
+#define XVMC_CHROMA_FORMAT_420		0x00000001
+#define XVMC_CHROMA_FORMAT_422		0x00000002
+#define XVMC_CHROMA_FORMAT_444		0x00000003
+
+/* XvMCSurfaceInfo Flags */
+#define XVMC_OVERLAID_SURFACE			0x00000001
+#define XVMC_BACKEND_SUBPICTURE			0x00000002
+#define XVMC_SUBPICTURE_INDEPENDENT_SCALING	0x00000004
+#define XVMC_INTRA_UNSIGNED                     0x00000008
+
+/* Motion Compensation types */
+#define XVMC_MOCOMP			0x00000000
+#define XVMC_IDCT			0x00010000
+
+#define	XVMC_MPEG_1			0x00000001
+#define XVMC_MPEG_2			0x00000002
+#define XVMC_H263			0x00000003
+#define XVMC_MPEG_4			0x00000004
+
+
+typedef struct {
+   int surface_type_id;
+   int chroma_format;
+   unsigned short max_width;       
+   unsigned short max_height;	
+   unsigned short subpicture_max_width;
+   unsigned short subpicture_max_height;
+   int mc_type;  	
+   int flags;
+} XvMCSurfaceInfo;
+
+   surface_type_id - Unique descriptor for this surface type.
+
+   chroma_format - Chroma format of this surface (eg. XVMC_CHROMA_FORMAT_420, 
+		XVMC_CHROMA_FORMAT_422, XVMC_CHROMA_FORMAT_444).
+
+   max_width -
+   max_height -  Maximum dimensions of the luma data in pixels.
+
+   subpicture_max_width -
+   subpicture_max_height -  The Maximum dimensions of the subpicture 
+                            that can be created for use with this surface
+                            Both fields are zero if subpictures are not
+                            supported.
+
+   mc_type -  The type of motion compensation available for this
+              surface.  This consists of XVMC_MPEG_1, XVMC_MPEG_2, XVMC_H263
+              or XVMC_MPEG_4 OR'd together with any of the following:
+
+                 XVMC_MOCOMP - Acceleration starts at the motion compensation
+                               level;
+
+                 XVMC_IDCT - Acceleration starts at the IDCT level.
+               
+   flags -  Any combination of the following may be OR'd together.
+
+	XVMC_OVERLAID_SURFACE - Displayed data is overlaid and not
+	                        physically in the visible framebuffer.
+                                When this is set the client is responsible
+                                for painting the colorkey.
+
+	XVMC_BACKEND_SUBPICTURE - The supicture is of the "backend" 
+                                  variety.  It is "frontend" otherwise.
+                                  There is more information on this in the
+                                  section on subpictures below.
+
+	XVMC_SUBPICTURE_INDEPENDENT_SCALING - The subpicture can be scaled
+                                              independently of the video
+                                              surface.  See the section on
+                                              subpictures below.
+
+        XVMC_INTRA_UNSIGNED - When this flag is set, the motion compenstation
+                              level Intra macroblock data should be in an
+                              unsigned format rather than the signed format
+                              present in the mpeg stream.  This flag applies
+                              only to motion compensation level acceleration.
+
+XvMCSurfaceInfo * XvMCListSurfaceTypes(Display *dpy, XvPortID port, int *num)
+
+   Returns the number of surface types supported by the XvPort and an array 
+   of XvMCSurfaceInfo describing each surface type.  The returned array 
+   should be freed with XFree().
+
+   dpy -  The connection to the server.
+
+   port - The port we want to get the XvMCSurfaceInfo array for.
+
+   num  - The number of elements returned in the array.
+
+   Errors:
+
+      XvBadPort -  The requested port does not exist.
+
+      BadAlloc - There are insufficient resources to complete this request.
+
+
+/********************************************************************/
+
+          CREATING A CONTEXT
+
+/********************************************************************/
+
+/* XvMCContext flags */
+#define XVMC_DIRECT			0x00000001
+
+typedef struct {
+   XID context_id;
+   int surface_type_id;
+   unsigned short width;
+   unsigned short height;
+   XVPortID port;
+   int flags;
+   void * privData;  /* private to the library */
+} XvMCContext;
+
+   context_id - An XID associated with the context.
+
+   surface_type_id - This refers to the XvMCSurfaceInfo that describes
+                     the surface characteristics.
+   
+   width -
+   height -  The dimensions (of the luma data) this context supports.
+
+   port -  The port that this context supports.
+
+   flags -  Any combination may be OR'd together.
+
+	XVMC_DIRECT -  This context is direct rendered.
+
+
+Status XvMCCreateContext (
+   Display display,
+   XVPortID port,
+   int surface_type_id,
+   int width,
+   int height,
+   int flags,
+   XvMCContext * context
+);
+
+   This creates a context by filling out the XvMCContext structure passed 
+   to it and returning Success.
+
+   display -  Specifies the connection to the server.
+
+   port -  Specifies the port to create the context for.
+
+   surface_type_id -
+   width -
+   height -  Specifies the surface type and dimensions that this
+             context will be used for.  The surface_type_id corresponds
+             to the surface_type_id referenced by the XvMCSurfaceInfo.
+	     The surface returned may be larger than the surface requested
+             (usually the next larger multiple of 16x16 pixels).
+
+   flags -  Any of the following may by OR'd together:
+
+	 XVMC_DIRECT -  A direct context is requested.
+                        If a direct context cannot be created the request
+                        will not fail, rather, an indirect context will 
+			be created instead.
+    
+   context - Pointer to the pre-allocated XvMCContext structure.
+ 
+
+
+   Errors:
+
+      XvBadPort -  The requested port does not exist.
+
+      BadValue -  The dimensions requested are not supported by the
+                  surface type.
+
+      BadMatch -  The surface_type_id is not supported by the port.
+
+      BadAlloc -  There are not sufficient resources to fulfill this
+                  request.
+
+
+Status XvMCDestroyContext (Display display, XvMCContext * context)
+
+     Destroys the specified context.  
+
+      display - Specifies the connection to the server.
+
+      context - The context to be destroyed.
+
+     Errors:    
+
+       XvMCBadContext - The XvMCContext is not valid.
+
+
+/*********************************************************************/
+
+          SURFACE CREATION
+
+/*********************************************************************/
+
+typedef struct {
+  XID surface_id;	   
+  XID context_id;
+  int surface_type_id;
+  unsigned short width;
+  unsigned short height;
+  void *privData;  /* private to the library */
+} XvMCSurface;
+
+  surface_id -  An XID associated with the surface.
+
+  context_id -  The XID of the context for which the surface was created.
+
+  surface_type_id - Derived from the context_id, it specifies the
+                    XvMCSurfaceInfo describing the surface.
+
+  width -
+  height -  The width and height of the luma data.
+
+
+Status 
+XvMCCreateSurface(
+  Display *display,
+  XvMCContext * context;
+  XvMCSurface * surface;
+);
+
+     Creates a surface (Frame) for use with the specified context.  
+   The surface structure is filled out and Success is returned if no
+   error occured.
+
+   context - pointer to a valid context.  The context implies
+             the surface type to be created, and its dimensions.
+
+   surface - pointer to a pre-allocated XvMCSurface structure.
+
+   Errors:
+
+	XvMCBadContext - the context is not valid.
+
+        BadAlloc - there are insufficient resources to complete 
+                   this operation.
+
+Status XvMCDestroySurface(Display *display, XvMCSurface *surface);
+
+   Destroys the given surface.
+
+    display - Specifies the connection to the server.
+
+    surface - The surface to be destroyed.
+
+    Errors:
+
+       XvMCBadSurface - The XvMCSurface is not valid.
+
+
+
+/*********************************************************************/
+
+    RENDERING A FRAME
+
+/*********************************************************************/
+
+typedef struct {
+  XID context_id;
+  unsigned int num_blocks;
+  short *blocks;
+  void *privData;	/* private to the library */
+} XvMCBlockArray;
+
+   num_blocks - Number of 64 element blocks in the blocks array.
+
+   context_id - XID of the context these blocks were allocated for.
+
+   blocks -  Pointer to an array of (64 * num_blocks) shorts.
+
+Status XvMCCreateBlocks (
+    Display *display, 
+    XvMCContext *context,
+    unsigned int num_blocks,
+    XvMCBlockArray * block
+);
+
+   This allocates an array of DCT blocks in the XvMCBlockArray
+   structure passed to it.  Success is returned if no error occured.
+
+    display - The connection to the server.
+
+    context -  The context the block array is being created for.
+
+    num_blocks - The number of 64 element short blocks to be allocated.
+                 This number must be non-zero.
+
+    block -  A pointer to a pre-allocated XvMCBlockArray structure.
+                
+      Errors: 
+
+	  XvMCBadContext - the context is invalid.
+
+          BadAlloc -  There are insufficient resources to complete the 
+                      operation.
+
+          BadValue -  num_blocks was zero.
+
+Status XvMCDestroyBlocks (Display *display, XvMCBlockArray * block)
+
+   Frees the given array.
+
+     display -  The connection to the server.
+
+     block - The block array to be freed.
+
+
+   ----------------------------------------------------------
+
+#define XVMC_MB_TYPE_MOTION_FORWARD	0x02
+#define XVMC_MB_TYPE_MOTION_BACKWARD	0x04
+#define XVMC_MB_TYPE_PATTERN		0x08
+#define XVMC_MB_TYPE_INTRA		0x10
+
+#define XVMC_PREDICTION_FIELD		0x01
+#define XVMC_PREDICTION_FRAME		0x02
+#define XVMC_PREDICTION_DUAL_PRIME	0x03
+#define XVMC_PREDICTION_16x8		0x02 
+#define XVMC_PREDICTION_4MV		0x04
+
+#define XVMC_SELECT_FIRST_FORWARD	0x01
+#define XVMC_SELECT_FIRST_BACKWARD	0x02
+#define XVMC_SELECT_SECOND_FORWARD	0x04
+#define XVMC_SELECT_SECOND_BACKWARD	0x08
+
+#define XVMC_DCT_TYPE_FRAME		0x00
+#define XVMC_DCT_TYPE_FIELD		0x01
+
+typedef struct {
+   unsigned short x;
+   unsigned short y;
+   unsigned char macroblock_type;
+   unsigned char motion_type;   
+   unsigned char motion_vertical_field_select;
+   unsigned char dct_type;
+   short PMV[2][2][2];
+   unsigned int index;
+   unsigned short coded_block_pattern;
+   unsigned short pad0;
+} XvMCMacroBlock;
+
+    x, y -  location of the macroblock on the surface in units of macroblocks.
+
+    macroblock_type - can be any of the following flags OR'd together:
+
+	XVMC_MB_TYPE_MOTION_FORWARD - Forward motion prediction should
+                                      be done.  This flag is ignored for
+				      Intra frames.
+
+	XVMC_MB_TYPE_MOTION_BACKWARD - Backward motion prediction should
+                                       be done.  This flag is ignored when
+				       the frame is not bidirectionally
+                                       predicted.
+
+        XVMC_MB_TYPE_PATTERN -  Blocks are referenced and they contain 
+                                differentials.  The coded_block_pattern will
+                                indicate the number of blocks and index will
+                                note their locations in the block array.
+
+	XVMC_MB_TYPE_INTRA -  Blocks are referenced and they are intra blocks. 
+                              The coded_block_pattern will indicate the number
+                              of blocks and index will note their locations in 
+                              the block array.  XVMC_MB_TYPE_PATTERN and
+                              XVMC_MB_TYPE_INTRA are mutually exclusive.  If
+                              both are specified, XVMC_MB_TYPE_INTRA takes
+                              precedence.
+
+    motion_type -  If the surface is a field, the following are valid:
+			XVMC_PREDICTION_FIELD
+			XVMC_PREDICTION_16x8
+			XVMC_PREDICTION_DUAL_PRIME
+		   If the surface is a frame, the following are valid:
+			XVMC_PREDICTION_FIELD
+			XVMC_PREDICTION_FRAME
+			XVMC_PREDICTION_DUAL_PRIME
+
+    motion_vertical_field_select - The following flags may be OR'd together
+
+		XVMC_SELECT_FIRST_FORWARD
+		XVMC_SELECT_FIRST_BACKWARD
+		XVMC_SELECT_SECOND_FORWARD
+		XVMC_SELECT_SECOND_BACKWARD
+              
+              If the bit is set the bottom field is indicated.
+              If the bit is clear the top field is indicated.
+
+              X X X X D C B A
+              ------- | | | |_  First vector forward
+                |     | | |___  First vector backward
+              unused  | |_____ Second vector forward
+                      |_______ Second vector backward
+
+    PMV -  The motion vector(s)
+             
+               PMV[c][b][a]
+
+                  a - This holds the vector. 0 = horizontal, 1 = vertical.
+                  b - 0 = forward, 1 = backward.
+                  c - 0 = first vector, 1 = second vector.
+
+	    The motion vectors are used only when XVMC_MB_TYPE_MOTION_FORWARD
+            or XVMC_MB_TYPE_MOTION_BACKWARD are set.
+
+            DualPrime vectors must be fully decoded and placed in the PMV
+            array as follows. 
+
+            Field structure:
+
+                PMV[0][0][1:0]  from same parity
+                PMV[0][1][1:0]  from opposite parity
+
+            Frame structure:
+ 
+                PMV[0][0][1:0]  top from top
+                PMV[0][1][1:0]  bottom from bottom
+                PMV[1][0][1:0]  top from bottom
+                PMV[1][1][1:0]  bottom from top
+
+
+    index -  The offset in units of (64 * sizeof(short)) from the start of
+             the block array where this macroblock's DCT blocks, as indicated
+             by the coded_block_pattern, are stored.
+
+    coded_block_pattern - Indicates the blocks to be updated.  The bitplanes
+                          are specific to the mc_type of the surface.  This
+                          field is valid only if XVMC_MB_TYPE_PATTERN or 
+                          XVMC_MB_TYPE_INTRA are set.  In that case the blocks
+                          are differential or intra blocks respectively.
+			  The bitplanes are described in ISO/IEC 13818-2
+			  Figures 6.10-12.
+
+    dct_type -  This field indicates whether frame pictures are frame DCT
+                coded or field DCT coded. ie XVMC_DCT_TYPE_FIELD or
+                XVMC_DCT_TYPE_FRAME.
+
+
+typedef struct {
+  unsigned int num_blocks;
+  XID context_id;
+  XvMCMacroBlock *macro_blocks;
+  void *privData;	/* private to the library */
+} XvMCMacroBlockArray;
+
+
+   num_blocks - Number of XvMCMacroBlocks in the macro_blocks array.
+
+   context_id - XID of the context these macroblocks were allocated for.
+
+   macro_blocks -  Pointer to an array of num_blocks XvMCMacroBlocks.
+
+
+Status XvMCCreateMacroBlocks (
+    Display *display, 
+    XvMCContext *context,
+    unsigned int num_blocks,
+    XvMCMacroBlockArray * blocks
+);
+
+   This allocates an array of XvMCMacroBlocks in the XvMCMacroBlockArray
+   structure passed to it.  Success is returned if no error occured.
+
+    display - The connection to the server.
+
+    context -  The context the macroblock array is being created for.
+
+    num_blocks - The number of XvMCMacroBlocks to be allocated.
+                 This number must be non-zero.
+
+    blocks -  A pointer to a pre-allocated XvMCMacroBlockArray structure.
+                
+      Errors: 
+
+	  XvMCBadContext - the context is invalid.
+
+          BadAlloc -  There are insufficient resources to complete the 
+                      operation.
+
+          BadValue -  num_blocks was zero.
+
+Status XvMCDestroyMacroBlocks (Display *display, XvMCMacroBlockArray * block)
+
+   Frees the given array.
+
+    display - The connection to the server.
+
+    block -  The macro block array to be freed.
+
+ 
+    ------------------------------------------------------------
+
+#define XVMC_TOP_FIELD		0x00000001
+#define XVMC_BOTTOM_FIELD	0x00000002
+#define XVMC_FRAME_PICTURE	(XVMC_TOP_FIELD | XVMC_BOTTOM_FIELD)
+
+#define XVMC_SECOND_FIELD       0x00000004
+
+Status XvMCRenderSurface(
+    Display *display,
+    XvMCContext *context,
+    unsigned int picture_structure,
+    Surface *target_surface,
+    Surface *past_surface,
+    Surface *future_surface,
+    unsigned int flags,
+    unsigned int num_macroblocks,
+    unsigned int first_macroblock,
+    XvMCMacroBlockArray *macroblock_array,
+    XvMCBlockArray *blocks
+);
+
+    This function renders the macroblocks passed to it.  It will not
+    return until it has read all of the macroblocks, however, rendering 
+    will usually not be completed by that time.  The return of this
+    function means it is safe to touch the blocks and macroblock_array.
+    To synchronize rendering see the section on sychronization below.
+
+    display - The connection to the server.
+
+    context - The context used to render.
+
+    target_surface -
+    past_surface -
+    furture_surface -
+
+        The target_surface is required.  If the future and past 
+      surfaces are NULL, the target_surface is an "Intra" frame.
+
+      	If the past surface is provided but not the future surface,
+      the target_surface is a "Predicted Inter" frame.
+
+	If both past and future surfaces are provided, the
+      target_surface is a "Bidirectionally-predicted Inter" frame.
+
+        Specifying a future surface without a past surface results
+      in a BadMatch.
+
+      All surfaces must belong to the same context.
+
+    picture_structure - XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or
+                        XVMC_FRAME_PICTURE.
+
+
+    flags -  Flags may include:
+
+            XVMC_SECOND_FIELD - For field pictures this indicates whether
+                                the current field (top or bottom) is first 
+                                or second in the sequence.
+
+    num_macroblocks -  The number of XvMCMacroBlock structures to execute in
+                       the macroblock_array.
+
+    first_macroblock - The index of the first XvMCMacroBlock to process in the
+                       macroblock_array.
+
+    blocks - The array of XvMCBlocks to be referenced by the XvMCMacroBlocks.
+             The data in the individual blocks are in raster scan order and
+             should be clamped to the limits specific to the acceleration
+             level.  For motion compensation level acceleration this is 8
+             bits for Intra and 9 bits for non-Intra data.  At the IDCT level
+             this is 12 bits.
+
+  Errors:
+
+        XvMCBadContext - The context is not valid.
+    
+        XvMCBadSurface - Any of the surfaces are not valid. 
+
+	BadMatch - Any of the surfaces do not belong to the specified
+                   context or a future surface was specified without
+                   a past surface.
+
+        BadValue - Unrecognized data for the picture_structure.
+
+
+/***********************************************************************/
+
+     DISPLAYING THE SURFACE
+
+/***********************************************************************/
+
+
+Status
+XvMCPutSurface(
+  Display *display,
+  XvMCSurface *surface,
+  Drawable draw,
+  short srcx, 
+  short srcy, 
+  unsigned short srcw, 
+  unsigned short srch,
+  short destx,
+  short desty,
+  unsigned short destw,
+  unsigned short desth,
+  int flags
+);
+
+   Display the rectangle from the source defined by srcx/y/w/h scaled
+ to destw by desth and placed at (destx, desty) on the given drawable.
+ This function is not guaranteed to be pipelined with previous rendering 
+ commands and may display the surface immediately.  Therefore, the client
+ must query that the surface has finished rendering before calling this
+ function.
+
+    display - The connection to the server.
+
+    surface - The surface to copy/overlay from.
+
+    draw - The drawable to copy/overlay the video on. 
+
+    srcx -
+    srcy -
+    srcw -
+    srch -  The rectangle in the source area from the surface that is
+            to be displayed.
+
+    destx -
+    desty -
+    destw -
+    desth -  The rectangle in the destination drawable where the scaled 
+             source rectangle should be displayed. 
+
+    flags - this indicates the field to be displayed and can be XVMC_TOP_FIELD,
+            XVMC_BOTTOM_FIELD or XVMC_FRAME_PICTURE.  XVMC_FRAME_PICTURE
+            displays both fields (weave).
+
+   Errors:
+
+       XvMCBadSurface - The surface is not valid.
+
+       BadDrawable -  The drawable does not exist.
+
+
+Status XvMCHideSurface(Display *display, XvMCSurface *surface)
+
+   Stops display of a surface.  This is only needed if the surface is an
+   overlaid surface as indicated in the XvMCSurfaceInfo - it is a no-op
+   otherwise.  
+
+     display - The connection to the server.
+ 
+     surface - The surface to be hidden.
+  
+      Errors:
+	
+	  XvMCBadSurface - The surface is not valid.
+
+
+/***********************************************************************/
+
+     COMPOSITING THE SUBPICTURE
+
+/***********************************************************************/
+
+
+XvImageFormatValues * XvMCListSubpictureTypes (
+  Display * display,
+  XvPortID port,
+  int surface_type_id,
+  int *count_return
+)
+
+  Returns an array of XvImageFormatValues supported by the surface_type_id
+  describing the surface. The surface_type_id is acquired from the
+  XvMCSurfaceInfo.  This list should be freed with XFree().
+
+   display - Specifies the connection to the X-server.
+
+   port - Specifies the port we are interested in.
+   
+   surface_type_id - Specifies the surface type for which we want to 
+                     query the supported subpicture types. 
+                    
+   count_return - the size of the returned array.
+
+   Errors:
+
+      BadPort -  The port doesn't exist.
+  
+      BadAlloc - There are insufficient resources to complete this request.
+ 
+      BadMatch - The surface type is not supported on that port. 
+  
+
+typedef struct {
+  XID subpicture_id;
+  XID context_id;
+  int xvimage_id;
+  unsigned short width;
+  unsigned short height;
+  int num_palette_entries;
+  int entry_bytes;
+  char component_order[4];
+  void *privData;    /* private to the library */
+} XvMCSubpicture;
+
+   
+   subpicture_id - An XID associated with this subpicture.
+
+   context_id - The XID of the context this subpicture was created for.
+
+   xvimage_id - The id descriptor of the XvImage format that may be used
+                with this subpicture.
+
+   width -
+   height - The dimensions of the subpicture.
+
+   num_palette_entries - For paletted formats only.  This is the number
+                         of palette entries.  It is zero for XvImages
+                         without palettes.
+  
+   entry_bytes -  Each component is one byte and entry_bytes indicates
+                  the number of components in each entry (eg. 3 for
+                  YUV palette entries).  This field is zero when 
+                  palettes are not used. 
+
+   component_order - Is an array of ascii characters describing the order
+                     of the components within the bytes.  Only entry_bytes
+                     characters of the string are used. 
+
+Status
+XvMCCreateSubpicture (
+   Display *display, 
+   XvMCContext *context,
+   XvMCSubpicture *subpicture, 
+   unsigned short width,
+   unsigned short height,
+   int xvimage_id
+)
+
+   This creates a subpicture by filling out the XvMCSubpicture structure
+   passed to it and returning Success.
+
+    display -  Specifies the connection to the X-Server.
+  
+    context -  The context to create the subpicture for.
+
+    subpicture - Pre-allocated XvMCSubpicture structure to be filled 
+                 out by this function.
+
+    width -
+    height -  The dimensions of the subpicture.
+    
+    xvimage_id - The id describing the XvImage format.
+
+
+    Errors:
+
+      BadAlloc - There are insufficient resources to complete this request.
+
+      XvMCBadContext - The specified context does not exist.
+
+      BadMatch - The XvImage format id specified is not supported by
+                 the context. 
+
+      BadValue - If the size requested is larger than the max size reported
+                 in the XvMCSurfaceInfo.
+
+
+Status
+XvMCClearSubpicture (
+  Display *display,
+  XvMCSubpicture *subpicture,
+  short x,
+  short y,
+  unsigned short width,
+  unsigned short height,
+  unsigned int color
+)
+
+    Clear the area of the given subpicture to "color".
+
+    display - The connection to the server.
+
+    subpicture - The subpicture to clear.
+
+    x -
+    y -
+    width -
+    height -  The rectangle in the subpicture to be cleared.
+
+    color -  The data to fill the rectangle with. 
+
+    Errors:
+
+       XvMCBadSubpicture - The subpicture is invalid.
+
+Status
+XvMCCompositeSubpicture (
+   Display *display,
+   XvMCSubpicture *subpicture,
+   XvImage *image,
+   short srcx,
+   short srcy,
+   unsigned short width,
+   unsigned short height,
+   short dstx,
+   short dsty
+)
+
+    Copies the XvImage to the XvMCSubpicture.  
+
+    display -  The connection to the server.
+
+    subpicture -  The subpicture used as the destination of the copy. 
+
+    image -  The XvImage to be used as the source of the copy. 
+             XvImages should be of the shared memory variety for 
+             indirect contexts.
+
+    srcx -
+    srcy -
+    width -
+    height -  The rectangle from the image to be composited.
+
+    dstx -
+    dsty -  The location in the subpicture where the source rectangle
+            should be composited. 
+
+    Errors:
+
+       XvMCBadSubpicture - The subpicture is invalid.
+
+       BadMatch -  The subpicture does not support the type of XvImage
+                   passed to this function.
+
+Status
+XvMCDestroySubpicture (Display *display, XvMCSubpicture *subpicture)
+
+   Destroys the specified subpicture.
+
+   display - Specifies the connection to the X-server.
+
+   subpicture - The subpicture to be destroyed.
+
+   Errors:
+   
+      XvMCBadSubpicture -  The subpicture specified does not exist.
+
+
+Status
+XvMCSetSubpicturePalette (
+  Display *display, 
+  XvMCSubpicture *subpicture, 
+  unsigned char *palette
+)
+
+   Set the subpicture's palette.  This applies to paletted subpictures
+   only. 
+
+    display -  The connection to the server.
+
+    subpicture - The subpicture on which to change the palette.
+
+    palette -  A pointer to an array holding the palette data.  The
+               size of this array is 
+
+                   num_palette_entries * entry_bytes
+
+               in size.  The order of the components in the palette
+	       is described by the component_order in the XvMCSubpicture
+               structure. 
+
+    Errors:
+
+      XvMCBadSubpicture -  The subpicture specified does not exist.
+  
+      BadMatch -  The specified subpicture does not use palettes.
+
+
+Status
+XvMCBlendSubpicture (
+   Display *display,
+   XvMCSurface *target_surface,
+   XvMCSubpicture *subpicture,
+   short subx,
+   short suby,
+   unsigned short subw,
+   unsigned short subh,
+   short surfx,
+   short surfy,
+   unsigned short surfw,
+   unsigned short surfh
+)
+
+Status
+XvMCBlendSubpicture2 (
+   Display *display,
+   XvMCSurface *source_surface,
+   XvMCSurface *target_surface,
+   XvMCSubpicture *subpicture,
+   short subx,
+   short suby,
+   unsigned short subw,
+   unsigned short subh,
+   short surfx,
+   short surfy,
+   unsigned short surfw,
+   unsigned short surfh
+)
+
+   The behavior of these two functions is different depending on whether
+or not the XVMC_BACKEND_SUBPICTURE flag is set in the XvMCSurfaceInfo.
+
+ XVMC_BACKEND_SUBPICTURE set:
+
+    XvMCBlendSubpicture associates the subpicture with the target_surface.
+  Both will be displayed at the next call to XvMCPutSurface.  Additional
+  blends before the call to XvMCPutSurface simply overrides the association.
+  Both the target_surface and subpicture will query XVMC_DISPLAYING from
+  the call to XvMCPutSurface until they are no longer displaying.  It is
+  safe to associate the subpicture and target_surface before rendering has
+  completed (while they still query XVMC_RENDERING) but it is not safe to
+  call XvMCPutSurface at that time. 
+
+    XvMCBlendSubpicture2 copies the source_surface to the target_surface
+  and associates the subpicture with the target_surface.  This essentially
+  calls XvMCBlendSubpicture on the target_surface after the copy.  Both
+  the subpicture and target_surface will query XVMC_DISPLAYING from the
+  call to XvMCPutSurface until they are no longer displaying.  The
+  source_surface will not query XVMC_DISPLAYING as a result of this function.
+  The copy is pipelined with the rendering and will cause XVMC_RENDERING
+  to be queried until the copy is done.
+
+
+ XVMC_BACKEND_SUBPICTURE not set ("frontend" behavior):
+
+    XvMCBlendSubpicture is a no-op in this case.
+
+    XvMCBlendSubpicture2 blends the source_surface and subpicture and
+  puts it in the target_surface.  This does not effect the status of
+  the source surface but will cause the target_surface to query
+  XVMC_RENDERING until the blend is completed.
+
+
+  display - The connection to the server.
+
+  subpicture - The subpicture to be blended into the video.
+
+  target_surface - The surface to be displayed with the blended subpicture.
+
+  source_surface - Source surface prior to blending.
+
+  subx -
+  suby -
+  subw -
+  subh -  The rectangle from the subpicture to be blended.
+
+  surfx -
+  surfy -
+  surfw -
+  surfh - The rectangle in the XvMCSurface to blend the subpicture rectangle
+          into.  If XVMC_SUBPICTURE_INDEPENDENT_SCALING is not set in the
+          XvMCSurfaceInfo subw must be equal to surfw and subh must be 
+          equal to surfh height or else a BadValue error occurs. 
+
+   Errors:
+
+    XvMCBadSurface - Any of the surfaces are invalid.
+
+    XvMCBadSubpicture - The subpicture is invalid.
+
+    BadMatch - The subpicture or any of the surfaces do not belong to the
+               same context.
+
+    BadValue - XVMC_SUBPICTURE_INDEPENDENT_SCALING is set and the source
+               and destination rectangles are different sizes.
+
+
+/***********************************************************************/
+
+     SURFACE SYNCHRONIZATION
+
+/***********************************************************************/
+
+
+#define XVMC_RENDERING		0x00000001
+#define XVMC_DISPLAYING		0x00000002
+
+Status
+XvMCSyncSurface (Display *display, XvMCSurface *surface)
+
+   This function blocks until all rendering requests on the surface
+  have been completed. 
+
+     display - The connection to the server.
+
+     surface - The surface to synchronize.
+
+     Errors:
+
+         XvMCBadSurface - The surface is not valid.
+
+
+Status
+XvMCFlushSurface (Display *display, XvMCSurface *surface)
+   
+   This function commits pending rendering requests to ensure that
+  they will be completed in a finite amount of time. 
+
+    display -  The connnection to the server.
+
+    surface -  The surface whos rendering requests should be flushed.
+
+     Errors:
+
+         XvMCBadSurface - The surface is not valid.
+
+
+Status
+XvMCGetSurfaceStatus (Display *display, XvMCSurface *surface, int *stat)
+
+   display -  The connection to the server.
+  
+   surface -  The surface whos status is being queried.
+
+   stat -  May be any of the following OR'd together:
+
+   XVMC_RENDERING - The last XvMCRenderSurface request has not completed
+                    yet.
+
+   XVMC_DISPLAYING - The surface is currently being displayed or a
+                     display is pending (ie. it is not safe to render
+                     to it).
+
+    Errors:
+
+         XvMCBadSurface - The surface is not valid.
+
+
+/***********************************************************************/
+
+     SUBPICTURE SYNCHRONIZATION
+
+/***********************************************************************/
+
+
+
+Status
+XvMCSyncSubpicture (Display *display, XvMCSubpicture *subpicture)
+   
+   This function blocks until all composite/clear requests on the supicture
+  have been completed.
+
+     display - The connection to the server.
+
+     subpicture -  The subpicture to synchronize.
+
+     Errors:
+
+         XvMCBadSubpicture - The subpicture is not valid.
+
+
+Status
+XvMCFlushSubpicture (Display *display, XvMCSubpicture *subpicture)
+   
+   This function commits pending composite/clear requests to ensure that
+  they will be completed in a finite amount of time.  
+
+    display - The connection to the server.
+
+    subpicture - The subpicture whos compositing should be flushed.
+
+     Errors:
+
+         XvMCBadSubpicture - The surface is not valid.
+
+
+Status
+XvMCGetSubpictureStatus (Display *display, XvMCSubpicture *subpic, int *stat)
+
+    display - The connection to the server.
+
+    subpic - The subpicture whos status is being queried. 
+
+    stat - may be any of the following OR'd together:
+
+   XVMC_RENDERING - The last XvMCCompositeSubpicture or XvMCClearSubpicture 
+                    request has not completed yet.
+
+   XVMC_DISPLAYING - The subpicture is currently being displayed or a
+                     display is pending (ie. it is not safe to render
+                     to it).
+
+     Errors:
+
+         XvMCBadSubpicture - The surface is not valid.
+
+/********************************************************************/
+
+     ATTRIBUTES
+
+/********************************************************************/
+
+   Context specific attribute functions are provided.  These are
+similar to their Xv Counterparts XvQueryPortAttributes, XvSetPortAttribute 
+and XvGetPortAttribute but their state is specific to the context.
+
+XvAttribute *
+XvMCQueryAttributes (
+    Display *display,
+    XvMCContext *context,
+    int *number
+)
+
+    An array of XvAttributes of size "number" is returned by this function.
+  If there are no attributes, NULL is returned and number is set to 0.
+  The array may be freed with XFree().
+
+    display - The connection to the server.
+
+    context - The context whos attributes we are querying.
+
+    number - The returned number of recognized atoms.
+
+    Errors:
+
+	XvMCBadContext - The context is invalid.
+
+Status
+XvMCSetAttribute (
+    Display *display,
+    XvMCContext *context, 
+    Atom attribute, 
+    int value
+)
+
+    This function sets a context-specific attribute and returns Success
+  if no error has occurred.
+
+    display - The connection to the server.
+
+    context - The context for which the attribute change is to go into effect.
+
+    attribute - The X Atom of the attribute to be changed.
+
+    value -  The new value of the attribute.
+
+    Errors:
+
+	XvMCBadContext - The context is not valid.
+
+	BadValue - An invalid value was specified.
+
+	BadMatch - This attribute is not defined for this context.
+
+Status
+XvMCGetAttribute (
+    Display *display,
+    XvMCContext *context, 
+    Atom attribute, 
+    int *value
+)
+
+    This function queries a context-specific attribute and return
+  Success and the value if no error has occurred.
+
+    display - The connection to the server.
+
+    context - The context whos attribute we are querying. 
+
+    attribute - The X Atom of the attribute to be retrieved.
+
+    value -  The returned attribute value. 
+
+    Errors:
+
+        XvMCBadContext - The context is not valid.
+
+        BadMatch - This attribute is not defined for this context.
+
diff --git a/specs/saver/saver.ms b/specs/saver/saver.ms
new file mode 100644
index 0000000..d92ebe4
--- /dev/null
+++ b/specs/saver/saver.ms
@@ -0,0 +1,881 @@
+.\" Use tbl, -ms
+.\" $XConsortium: saver.ms,v 1.5 92/02/11 17:05:26 keith Exp $
+.\" $NCDId: @(#)screensaver.ms,v 1.24 1992/02/22 14:00:00 jim Exp jim $
+.EH ''''
+.OH ''''
+.EF ''''
+.OF ''''
+.\" Change the contents of the following of Pp to PP to have it indent
+.de Pp
+.LP
+..
+.de PN
+\\fB\\^\\$1\^\\fR\\$2
+..
+.de Pn
+\\$1\\fB\\^\\$2\^\\fR\\$3
+..
+.de Rq
+.sp
+.LP
+.\" .in +.50i
+.PN \\$1
+.in +.33i
+.sp .5v
+.\".LP
+..
+.de Sm
+.\".in -.50i
+.in -.33i
+.Pp
+..
+.de Ar
+.br
+\\fI\\$1\\fP\\^: \\$2
+..
+.de Rp
+.in -.2i
+.br
+.sp .5v
+\(->
+.br
+.sp .5v
+.in +.2i
+..
+.de Rv
+.br
+\\$1: \\$2
+..
+.ps 11
+.nr PS 11
+.nr PD 1v
+\&
+.sp 8
+.ce 1
+\s+2\fBX11 SCREEN SAVER EXTENSION\fP\s-2
+.sp 3
+.ce 3
+Version 1.0
+MIT X Consortium Proposed Standard
+X Version 11, Release 5
+.sp 6
+.ce 4
+\s-1Jim Fulton
+.sp 6p
+Network Computing Devices, Inc.\s+1
+.sp 3
+.ce 4
+\s-1Keith Packard
+.sp 6p
+X Consortium
+Laboratory for Computer Science
+Massachusetts Institute of Technology\s+1
+.ps 9
+.nr PS 9
+.sp 8
+.LP
+Copyright \(co 1992 by the Massachusetts Institute of Technology and 
+Network Computing Devices, Inc.
+.LP
+Permission to use, copy, modify, and distribute this documentation for any
+purpose and without fee is hereby granted, provided that the above copyright
+notice and this permission notice appear in all copies.  MIT and
+Network Computing Devices, Inc. make no
+representations about the suitability for any purpose of the information in
+this document.  This documentation is provided ``as is'' without express or
+implied warranty.
+.ps 11
+.nr PS 11
+.bp 1
+.EH ''\s10X11 Screen Saver Extension\s0''
+.OH ''\s10X11 Screen Saver Extension\s0''
+.EF ''\s10\fB % \fP\s0''
+.OF ''\s10\fB % \fP\s0''
+.NH 1
+Introduction
+.Pp
+The X Window System provides support for changing the image on a display screen
+after a user-settable period of inactivity to avoid burning the cathode ray
+tube phosphors.  However, no interfaces are provided for the user to control
+the image that is drawn.  This extension allows an external ``screen saver''
+client to detect when the alternate image is to be displayed and to provide the
+graphics.
+.Pp
+Current X server implementations typically provide at least one form of
+``screen saver'' image.  Historically, this has been a copy of the X logo
+drawn against the root background pattern.  However, many users have asked
+for the mechanism to allow them to write screen saver programs that provide
+capabilities similar to those provided by other window systems.  In
+particular, such users often wish to be able to display corporate logos,
+instructions on how to reactivate the screen, and automatic screen-locking
+utilities.  This extension provides a means for writing such clients.
+.NH 1
+Assumptions
+.Pp
+This extension exports the notion of a special screen saver window that is
+mapped above all other windows on a display.  This window has the
+\fIoverride-redirect\fP attribute set so that it is not subject to manipulation by
+the window manager.  Furthermore, the X identifier for the window is never
+returned by \fBQueryTree\fP requests on the root window, so it is typically
+not visible to other clients.  
+.NH 1
+Overview
+.Pp
+The core
+.PN SetScreenSaver
+request can be used to set the length of time without
+activity on any input devices after which the screen saver should ``activate''
+and alter the image on the screen.  This image periodically ``cycles'' to 
+reduce
+the length of time that any particular pixel is illuminated.  Finally, the
+screen saver is ``deactivated'' in response to activity on any of the input 
+devices
+or particular X requests.
+.Pp
+Screen saving is typically done by disabling video output to the display tube
+or by drawing a changing pattern onto the display.  If the server chooses the
+latter approach, a window with a special identifier is created and mapped at
+the top of the stacking order where it remains until the screen saver
+deactivates.  At this time, the window is unmapped and is not accessible to any
+client requests.
+.Pp
+The server's default mechanism is refered to as the \fIinternal\fP screen 
+saver.  An \fIexternal\fP
+screen saver client requires a means of determining the window
+id for the screen saver window and setting the attributes (e.g. size,
+location, visual, colormap) to be used when the window is mapped.  These
+requirements form the basis of this extension.
+.NH 1
+Issues
+.Pp
+This extension raises several interesting issues.  First is the question of
+what should be done if some other client has the server grabbed when the screen
+saver is supposed to activate?  This commonly occurs with window managers that
+automatically ask the user to position a window when it is first mapped by
+grabbing the server and drawing XORed lines on the root window.
+.Pp
+Second, a screen saver program must control the actual RGB values sent to the
+display tube to ensure that the values change periodically to avoid phosphor
+burn in.  Thus, the client must have a known colormap installed whenever the
+screen saver window is displayed.  To prevent screen flashing, the visual type
+of the screen saver window should also be controlable.
+.Pp
+Third, some implementations may wish to destroy the screen saver window when
+it is not mapped so that it need not be avoided during event delivery.  Thus,
+screen saver clients may find that the requests that reference the screen 
+saver window may fail when the window is not displayed.
+.NH 1
+Protocol
+.Pp
+The Screen Saver extension is as follows:
+.NH 2
+Types
+.Pp
+In adition to the comon types described in the core protocol, the following
+type is used in the request and event definitions in subsequent sections.
+.Pp
+.TS
+lw(2i) lw(3.75i).
+_
+.sp 6p
+.B
+Name	Value
+.sp 6p
+_
+.sp 6p
+.R
+SCREENSAVEREVENT	T{
+.Pn { ScreenSaverNotify ,
+.PN ScreenSaverCycle }
+T}
+.TE
+.NH 2
+Errors
+.Pp
+The Screen Saver extension adds no errors beyond the core protocol.
+.NH 2
+Requests
+.Pp
+The Screen Saver extension adds the following requests:
+.Rq ScreenSaverQueryVersion
+.Ar client-major-version CARD8
+.Ar client-minor-version CARD8
+.Rp
+.Rv server-major-version CARD8
+.Rv server-minor-version CARD8
+.Sm
+This request allows the client and server to determine which version of
+the protocol should be used.  The client sends the version that it
+prefers; if the server understands that
+version, it returns the same values and interprets subsequent requests
+for this extension according to the specified version.  Otherwise,
+the server returns the closest version of the protocol that it can
+support and interprets subsequent requests according to that version.
+This document describes major version 1, minor version 0; the major
+and minor revision numbers should only be incremented in response to
+incompatible and compatible changes, respectively.
+.Rq ScreenSaverQueryInfo
+.Ar drawable DRAWABLE
+.Rp
+.Rv saver-window WINDOW
+.Rv state 
+.Pn { Disabled ,
+.PN Off ,
+.PN On }
+.Rv kind
+.Pn { Blanked ,
+.PN Internal ,
+.PN External }
+.Rv til-or-since CARD32
+.Rv idle CARD32
+.Rv event-mask SETofSCREENSAVEREVENT
+.LP
+.Rv Errors
+.PN Drawable
+.Sm
+This request returns information about the state of the screen
+saver on the screen associated with \fIdrawable\fP.  The \fIsaver-window\fP 
+is the XID that is associated with the screen saver window.  This
+window is not guaranteed to exist
+except when external screen saver is active.  Although it is a 
+child of the root, this window is not returned by
+.PN QueryTree
+requests on the root.  Whenever this window is mapped, it is always above
+any of its siblings in the stacking order.  XXX - TranslateCoords?
+.Pp
+The \fIstate\fP field specifies whether or not the screen saver is currently
+active and how the \fItil-or-since\fP value should be interpretted:
+.in +.5i
+.TS
+lw(1.5i) lw(3.5i).
+T{
+.PN Off
+T}	T{
+The screen is not currently being saved; \fItil-or-since\fP
+specifies the number of milliseconds until the screen saver is expected to
+activate.
+T}
+.sp
+T{
+.PN On
+T}	T{
+The screen is currently being saved; \fItil-or-since\fP specifies
+the number of milliseconds since the screen saver activated.
+T}
+.sp
+T{
+.PN Disabled
+T}	T{
+The screen saver is currently disabled; \fItil-or-since\fP is zero.
+T}
+.TE
+.in -.5i
+.Pp
+The \fIkind\fP field specifies the mechanism that either is currently being
+used or would have been were the screen being saved:
+.in +.5i
+.TS
+lw(1.5i) lw(3.5i).
+T{
+.PN Blanked
+T}	T{
+The video signal to the display monitor was disabled.
+T}
+.sp
+T{
+.PN Internal
+T}	T{
+A server-dependent, built-in screen saver image was displayed; either no
+client had set the screen saver window attributes or a different client 
+had the server grabbed when the screen saver activated.
+T}
+.sp
+T{
+.PN External
+T}	T{
+The screen saver window was mapped with attributes set by a
+client using the \fBScreenSaverSetAttributes\fP request.
+T}
+.TE
+.in -.5i
+.Pp
+The \fIidle\fP field specifies the number of milliseconds since the last
+input was received from the user on any of the input devices.
+.Pp
+The \fIevent-mask\fP field specifies which, if any, screen saver
+events this client has requested using \fBScreenSaverSelectInput\fP.
+.Pp
+If \fIdrawable\fP is not a valid drawable identifier, a Drawable
+error is returned and the request is ignored.
+.Rq ScreenSaverSelectInput
+.Ar drawable DRAWABLE
+.Ar event-mask SETofSCREENSAVEREVENT
+.LP
+Errors:
+.PN Drawable ,
+.PN Match
+.Sm
+This request specifies which Screen Saver extension events on the screen 
+associated with \fIdrawable\fP should be generated for this client.  If
+no bits are set in \fIevent-mask\fP, then no events will be generated.
+Otherwise, any combination of the following bits may be set:
+.in +.5i
+.TS
+lw(1.5i) lw(3.5i).
+T{
+.PN ScreenSaverNotify
+T}	T{
+If this bit is set, \fBScreenSaverNotify\fP events are generated whenever
+the screen saver is activated or deactivated.
+T}
+.sp
+T{
+.PN ScreenSaverCycle
+T}	T{
+If this bit is set, \fBScreenSaverNotify\fP events are generated whenever
+the screen saver cycle interval passes.
+T}
+.TE
+.in -.5i
+.Pp
+If \fIdrawable\fP is not a valid drawable identifier, a Drawable
+error is returned.  If any undefined bits are set in \fIevent-mask\fP,
+a Value error is returned.  If an error is returned,
+the request is ignored.
+.Rq ScreenSaverSetAttributes
+.Ar drawable DRAWABLE
+.Ar class 
+.Pn { InputOutput , 
+.PN InputOnly , 
+.PN CopyFromParent }
+.Ar depth CARD8
+.Ar visual "VISUALID or"
+.PN CopyFromParent
+.Ar "x, y" INT16
+.Ar "width, height, border-width" CARD16
+.Ar value-mask BITMASK
+.Ar value-list LISTofVALUE
+.LP
+.Rv Errors
+.PN Access ,
+.PN Window ,
+.PN Pixmap ,
+.PN Colormap ,
+.PN Cursor ,
+.PN Match ,
+.PN Value ,
+.PN Alloc
+.Sm
+This request sets the attributes that this client would like to see
+used in creating the screen saver window on the screen associated
+with \fIdrawable\fP.  If another client currently has the attributes set,
+an Access error is generated and the request is ignored.
+.Pp
+Otherwise, the specified window attributes are checked as if
+they were used in a core \fBCreateWindow\fP request whose
+parent is the root.  The \fIoverride-redirect\fP field is ignored as
+it is implicitly set to True.  If the window attributes result in an
+error according to the rules for \fBCreateWindow\fP, the request is
+ignored.
+.Pp
+Otherwise, the attributes are stored and will take effect on the next 
+activation that occurs when the server is not grabbed by another client.
+Any resources specified for the
+\fIbackground-pixmap\fP or \fIcursor\fP attributes may be
+freed immediately.  The server is free to copy the \fIbackground-pixmap\fP
+or \fIcursor\fP resources or to use them in place; therefore, the effect of
+changing the contents of those resources is undefined.  If the 
+specified \fIcolormap\fP no longer exists when the screen saver activates,
+the parent's colormap is used instead.  If no errors are generated by this
+request, any previous
+screen saver window attributes set by this client are released.
+.Pp
+When the screen saver next activates and the server is not grabbed by 
+another client, the screen saver window is 
+created, if necessary, and set to the specified attributes and events
+are generated as usual.  The colormap
+associated with the screen saver window is 
+installed.  Finally, the screen saver window is mapped.
+.Pp
+The window remains mapped and at the top of the stacking order
+until the screen saver is deactivated in response to activity on
+any of the user input devices, a \fBForceScreenSaver\fP request with
+a value of Reset, or any request that would cause the window to be
+unmapped.
+.Pp
+If the screen saver activates while the server is grabbed by another
+client, the internal saver mechanism is used.  The \fBForceScreenSaver\fP 
+request may be used with a value of Active to 
+deactivate the internal saver and activate the external saver.
+.Pp
+If the screen saver client's connection to the server is broken
+while the screen saver is activated and the client's close down mode has not
+been RetainPermanent or RetainTemporary, the current screen saver
+is deactivated and the internal screen saver is immediately activated.
+.Pp
+When the screen saver deactivates, the screen saver window's colormap
+is uninstalled and the window is unmapped (except as described below).
+The screen saver XID is disassociated
+with the window and the server may, but is not required to,
+destroy the window along with any children.
+.Pp
+When the screen saver is being deactivated and then immediately
+reactivated (such as when switching screen savers), the server
+may leave the screen saver window mapped (typically to avoid 
+generating exposures).
+.Rq ScreenSaverUnsetAttributes
+.Ar drawble DRAWABLE
+.LP
+.Rv Errors
+.PN Drawable
+.Sm
+This request notifies the server that this client no longer
+wishes to control the screen saver window.  Any screen saver
+attributes set by this client and any descendents of the screen
+saver window created by this client should be released
+immediately if the screen saver is not active, else upon
+deactivation.
+.Pp
+This request is ignored if the client has not previously set the screen saver
+window attributes.
+.NH 2
+Events
+.Pp
+The Screen Saver extension adds one event:
+.Rq ScreenSaverNotify
+.Ar root WINDOW
+.Ar window WINDOW
+.Ar state
+.Pn { Off ,
+.PN On ,
+.PN Cycle }
+.Ar kind 
+.Pn { Blanked ,
+.PN Internal ,
+.PN External }
+.Ar forced BOOL
+.Ar time TIMESTAMP
+.Sm
+This event is delivered to clients that have requested
+ScreenSaverNotify events using the \fBScreenSaverSelectInput\fP request
+whenever the screen saver activates or deactivates.
+.Pp
+The \fIroot\fP field specifies root window of the screen for
+which the event was generated.  The \fIwindow\fP field specifies
+the value that is returned by \fBScreenSaverQueryInfo\fP as
+the identifier for the screen saver window.  This window is not
+required to exist if the external screen saver is not active.
+.Pp
+The \fIstate\fP field specifies the cause of the event:
+.in +.5i
+.TS
+lw(1.5i) lw(3.5i).
+T{
+.PN Off
+T}	T{
+The screen saver deactivated; this event is sent if the client has set the
+ScreenSaverNotify bit in its event mask.
+T}
+.sp
+T{
+.PN On
+T}	T{
+The screen saver activated.  This event is sent if the client has set the
+ScreenSaverNotify bit in its event mask.
+T}
+.sp
+T{
+.PN Cycle
+T}	T{
+The cycle interval passed and the client is expected to change the image on
+the screen.  This event is sent if the client has set the
+ScreenSaverCycle bit in its event mask.
+T}
+.TE
+.in -.5i
+.LP
+If \fIstate\fP is set to 
+.PN On 
+or
+.PN Off
+then \fIforced\fP indicates whether or not activation or
+deactivation was caused by a core
+.PN ForceScreenSaver
+request; otherwise, \fIforced\fP is set to False.
+.Pp
+The \fIkind\fP field specifies mechanism that was used to save the screen
+when the screen saver was activated, as described in 
+\fBScreenSaverQueryInfo\fP.
+.Pp
+The \fItime\fP field indicates the server time when the 
+event was generated.
+.NH 1
+Encoding
+.Pp
+Please refer to the X11 Protocol Encoding document as this document uses
+conventions established there.
+.Pp
+The name of this extension is ``SCREEN-SAVER''.
+.LP
+.NH 2
+Common Types
+.LP
+.TA .75i 1.75i
+.ta .75i 1.75i
+.nf
+.R
+SETofSCREENSAVEREVENT
+	#x00000001	ScreenSaverNotifyMask
+	#x00000002	ScreenSaverCycleMask
+.fi
+.NH 2
+Requests
+.de En
+.LP
+.PN \\$1
+.TA .5i 1.5i 2.5i
+.ta .5i 1.5i 2.5i
+.in +.33i
+.nf
+..
+.de Ee
+.in -.33i
+.fi
+..
+.En ScreenSaverQueryVersion
+1	CARD8		screen saver opcode
+1	0		minor opcode
+2   	2		request length
+1	CARD8		client major version
+1	CARD8		client minor version
+2			unused
+.Rp
+1	1		Reply
+1			unused
+2	CARD16		sequence number
+4	0		reply length
+1	CARD8		server major version
+1	CARD8		server minor version
+22			unused
+.Ee
+.En ScreenSaverQueryInfo
+1	CARD8		screen saver opcode
+1	1		minor opcode
+2	2		request length
+4	DRAWABLE		drawable associated with screen
+.Rp
+1	1		Reply
+1	CARD8		state
+	0	Off
+	1	On
+	3	Disabled
+2	CARD16		sequence number
+4	0		reply length
+4	WINDOW		saver window
+4	CARD32		milliseconds until saver or since saver
+4	CARD32		milliseconds since last user device input
+4	SETofSCREENSAVEREVENT		event mask
+1	CARD8		kind
+	0	Blanked
+	1	Internal
+	2	External
+10			unused
+.Ee
+.En ScreenSaverSelectInput
+1	CARD8		screen saver opcode
+1	2		minor opcode
+2	3		request length
+4	DRAWABLE		drawable associated with screen
+4	SETofSCREENSAVEREVENT		event mask
+.Ee
+.En ScreenSaverSetAttributes
+1	CARD8		screen saver opcode
+1	3		minor opcode
+2	6+n		request length
+4	DRAWABLE		drawable associated with screen
+2	INT16		x
+2	INT16		y
+2	CARD16		width
+2	CARD16		height
+2	CARD16		border-width
+1			class
+	0	CopyFromParent
+	1	InputOutput
+	2	InputOnly
+1	CARD8		depth
+4	VISUALID		visual
+	0	CopyFromParent
+4	BITMASK			value-mask (has n bits set to 1)
+	encodings are the same as for core CreateWindow
+4n	LISTofVALUE		value-list
+	encodings are the same as for core CreateWindow
+.Ee
+.En ScreenSaverUnsetAttributes
+1	CARD8		screen saver opcode
+1	4		minor opcode
+2	3		request length
+4	DRAWABLE		drawable associated with screen
+.Ee
+.NH 2
+Events
+.En ScreenSaverNotify
+1	CARD8		code assigned by core
+1	CARD8		state
+	0	Off
+	1	On
+	2	Cycle
+2	CARD16		sequence number
+4	TIMESTAMP		time
+4	WINDOW		root
+4	WINDOW		screen saver window
+1	CARD8		kind
+	0	Blanked
+	1	Internal
+	2	External
+1	BOOL		forced
+14			unused
+.Ee
+.NH 1
+Inter-Client Communications Conventions
+.Pp
+Screen saver clients should create at least one resource value whose
+identifier can be stored in a property named
+.PN _SCREEN_SAVER_ID
+on the root of each screen it is managing.
+This property should have one 32-bit value corresponding to the resource
+identifier; the type of the property should indicate the type of the
+resource and should be one of the following: 
+.PN WINDOW ,
+.PN PIXMAP ,
+.PN CURSOR ,
+.PN FONT , or
+.PN COLORMAP .
+.NH 1
+C language binding
+.Pp
+The C binding for this extension simply provide access to the protocol; they
+add no semantics beyond what is described above.
+.Pp
+The include file for this extension is
+.Pn < X11/extensions/scrnsaver.h >.
+.LP
+Bool
+.br
+XScreenSaverQueryExtension (display, event_base, error_base)
+.RS
+Display *display;
+.br
+int *event_base; /* RETURN */
+.br
+int *error_base; /* RETURN */
+.RE
+.IP
+This routine returns
+.PN True
+if the specified \fIdisplay\fP supports the SCREEN-SAVER extension; 
+otherwise it returns
+.PN False .
+If the extension is supported, the event number for 
+.PN ScreenSaverNotify
+events is returned in the value pointed to by \fIevent_base\fP.  Since
+no additional errors are defined by this extension, the results
+of \fIerror_base\fP are not defined.
+.LP
+Status
+.br
+XScreenSaverQueryVersion (display, major, minor)
+.RS
+Display *display;
+.br
+int *major; /* RETURN */
+.br
+int *minor; /* RETURN */
+.RE
+.IP
+If the specified \fIdisplay\fP supports the extension,
+the version numbers of the protocol
+expected by the server are returned in \fImajor\fP and \fIminor\fP and
+a non-zero value is returned.  Otherwise, the arguments are not 
+set and 0 is returned.
+.LP
+XScreenSaverInfo *
+.br
+XScreenSaverAllocInfo ()
+.IP
+This routine allocates and returns an \fBXScreenSaverInfo\fP structure
+for use in calls to \fBXScreenSaverQueryInfo\fP.  All fields in the
+structure are initialized to zero.  If insufficient memory is available,
+NULL is returned.  The results of this routine can be released
+using \fIXFree\fP.
+.LP
+Status
+.br
+XScreenSaverQueryInfo (display, drawable, saver_info)
+.RS
+Display *display;
+.br
+Drawable drawable;
+.br
+XScreenSaverInfo *saver_info; /* RETURN */
+.RE
+.IP
+If the specified \fIdisplay\fP supports the extension,
+information about the current state of the
+screen server is returned in \fIsaver_info\fP and a non-zero value is
+returned.  The \fBXScreenSaverInfo\fP structure is defined as follows:
+.sp
+.in +.5i
+.TA 4i
+.ta 4i
+typedef struct {
+    Window window;                /* screen saver window */
+    int state;                    /* ScreenSaver{Off,On,Disabled} */
+    int kind;                     /* ScreenSaver{Blanked,Internal,External} */
+    unsigned long til_or_since;   /* milliseconds */
+    unsigned long idle;           /* milliseconds */
+    unsigned long event_mask;     /* events */
+.br
+} XScreenSaverInfo;
+.in -.5i
+.sp
+See the \fBScreenSaverQueryInfo\fP request for a description of the fields.
+If the extension is not supported, \fIsaver_info\fP is not changed and 0
+is returned.
+.LP
+void
+.br
+XScreenSaverSelectInput (display, drawable, event_mask)
+.RS
+Display *display;
+.br
+Drawable drawable;
+.br
+unsigned long event_mask;
+.RE
+.IP
+If the specified \fIdisplay\fP supports the extension,
+this routine asks that events related to 
+the screen saver be generated for this client.
+The format of the events generated is:
+.sp
+.in +.5i
+.TA 4i
+.ta 4i
+typedef struct {
+    int type;               /* of event */
+    unsigned long serial;   /* # of last request processed by server */
+    Bool send_event;        /* true if this came frome a SendEvent request */
+    Display *display;       /* Display the event was read from */
+    Window window;          /* screen saver window */
+    Window root;            /* root window of event screen */
+    int state;              /* ScreenSaver{Off,On,Cycle} */
+    int kind;               /* ScreenSaver{Blanked,Internal,External} */
+    Bool forced;            /* extents of new region */
+    Time time;              /* event timestamp */
+.br
+} XScreenSaverNotifyEvent;
+.in -.5i
+.sp
+See the
+definition of the \fBScreenSaverSelectInput\fP request for descriptions
+of the allowed event masks.  
+.LP
+void
+.br
+XScreenSaverSetAttributes (display, drawable, x, y, width, height, border_width, depth, class, visual, valuemask, attributes)
+.RS
+Display *dpy;
+.br
+Drawable drawable;
+.br
+int x;
+.br
+int y;
+.br
+unsigned int width;
+.br
+unsigned int height;
+.br
+unsigned int border_width;
+.br
+int depth;
+.br
+unsigned int class;
+.br
+Visual *visual;
+.br
+unsigned long valuemask;
+.br
+XSetWindowAttributes *attributes;
+.RE
+.IP
+If the specified \fIdisplay\fP supports the extension,
+this routine sets the attributes to be used
+the next time the external screen saver is activated.  See the definition
+of the \fBScreenSaverSetAttributes\fP request for a description of each of
+the arguments.
+.LP
+void
+.br
+XScreenSaverUnsetAttributes (display, drawable)
+.RS
+Display *display;
+.br
+Drawable drawable;
+.RE
+.IP
+If the specified \fIdisplay\fP supports the extension,
+this routine instructs the server to discard
+any previous screen saver window attributes set by this client.
+.LP
+Status
+.br
+XScreenSaverRegister (display, screen, xid, type)
+.RS
+Display *display;
+.br
+int screen;
+.br
+XID xid;
+.br
+Atom type;
+.RE
+.IP
+This routine stores the given \fIXID\fP in the \fB_SCREEN_SAVER_ID\fP 
+property (of the given \fItype\fP) on the
+root window of the specified \fIscreen\fP.  It returns zero if an error
+is encountered and the property is not changed, otherwise it returns 
+non-zero.
+.LP
+Status
+.br
+XScreenSaverUnregister (display, screen)
+.RS
+Display *display;
+.br
+int screen;
+.RE
+.IP
+This routine removes any \fB_SCREEN_SAVER_ID\fP from the 
+root window of the specified \fIscreen\fP.  It returns zero if an error
+is encountered and the property is changed, otherwise it returns 
+non-zero.
+.LP
+Status
+.br
+XScreenSaverGetRegistered (display, screen, xid, type)
+.RS
+Display *display;
+.br
+int screen;
+.br
+XID *xid; /* RETURN */
+.br
+Atom *type; /* RETURN */
+.RE
+.IP
+This routine returns the \fIXID\fP and \fItype\fP stored in
+the \fB_SCREEN_SAVER_ID\fP property on the
+root window of the specified \fIscreen\fP.  It returns zero if an error
+is encountered or if the property does not exist or is not of the correct
+format; otherwise it returns non-zero.
author	Kaleb Keithley <kaleb@freedesktop.org>	2003-11-14 16:48:55 +0000
committer	Kaleb Keithley <kaleb@freedesktop.org>	2003-11-14 16:48:55 +0000
commit	67f7a131c3e3616149d4775546dba04857607f96 (patch)
tree	b065dbbe61c34e5a49f8343a39a99a5bafb397aa
parent	3e77e75b5a28b1b5a258396f4f15a61c9f3dc87c (diff)