Initial revision

7 files changed, 5287 insertions, 0 deletions

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.