xwininfo fontconfig libX11 libXau libXdmcp libXext mesa libXinerama libxcb libxcb/xcb-proto libfontenc pixman xkbcomp mkfontscale xkeyboard-config git update 4 Jun 2013

xserver          commit c21344add2fc589df83b29be5831c36a372201bd
libxcb           commit 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12
libxcb/xcb-proto commit bdfedfa57a13ff805580cfacafc70f9cc55df363
xkeyboard-config commit dad9ade4e83d1ef5a517fcc4cc9ad3a79b47acce
libX11           commit 8496122eb00ce6cd5d2308ee54f64b68c378e455
libXdmcp         commit 0b443c1b769b9c9a3b45b4252afe07e18b709ff4
libXext          commit d8366afbb0d2e4fbb1e419b1187f490522270bea
libfontenc       commit 3acba630d8b57084f7e92c15732408711ed5137a
libXinerama      commit 6e1d1dc328ba8162bba2f4694e7f3c706a1491ff
libXau           commit 899790011304c4029e15abf410e49ce7cec17e0a
xkbcomp          commit ed582f4fccd4e23abcfba8b3b03649fea6414f44
pixman           commit 2acfac5f8e097ee2ae225d986f981b55d65dd152
mkfontscale      commit 19e2cb7c6a3ec2c5b1bc0d24866fa685eef0ee13
xwininfo         commit ba0d1b0da21d2dbdd81098ed5778f3792b472e13
fontconfig       commit cd9b1033a68816a7acfbba1718ba0aa5888f6ec7
mesa             commit 7bafd88c153e395274b632e7eae4bc9fc3aec1d2

18 files changed, 3155 insertions, 0 deletions

diff --git a/mesalib/docs/specs/MESA_agp_offset.spec b/mesalib/docs/specs/MESA_agp_offset.spec
new file mode 100644
index 000000000..06e1d902e
--- /dev/null
+++ b/mesalib/docs/specs/MESA_agp_offset.spec
@@ -0,0 +1,95 @@
+Name
+
+    MESA_agp_offset
+
+Name Strings
+
+    GLX_MESA_agp_offset
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (Mesa 4.0.4 and later.  Only implemented in particular
+    XFree86/DRI drivers.)
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    GLX_NV_vertex_array_range is required.
+    This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+    This extensions provides a way to convert pointers in an AGP memory
+    region into byte offsets into the AGP aperture.
+    Note, this extension depends on GLX_NV_vertex_array_range, for which
+    no real specification exists.  See GL_NV_vertex_array_range for more
+    information.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    unsigned int glXGetAGPOffsetMESA( const void *pointer )
+
+New Tokens
+
+    None
+
+Additions to the OpenGL 1.4 Specification
+
+    None
+
+Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
+
+    Add a new section, 3.6 as follows:
+
+    3.6 AGP Memory Access
+
+    On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV
+    and freed with glXFreeMemoryNV.  Sometimes it's useful to know where a
+    block of AGP memory is located with respect to the start of the AGP
+    aperture.  The function
+
+        GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
+
+    Returns the offset of the given memory block from the start of AGP
+    memory in basic machine units (i.e. bytes).  If pointer is invalid
+    the value ~0 will be returned.
+
+GLX Protocol
+
+    None.  This is a client side-only extension.
+
+Errors
+
+    glXGetAGPOffsetMESA will return ~0 if the pointer does not point to
+    an AGP memory region.
+
+New State
+
+    None
+
+Revision History
+
+    20 September 2002 - Initial draft
+    2 October 2002 - finished GLX chapter 3 additions
+    27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid
diff --git a/mesalib/docs/specs/MESA_copy_sub_buffer.spec b/mesalib/docs/specs/MESA_copy_sub_buffer.spec
new file mode 100644
index 000000000..752a014b3
--- /dev/null
+++ b/mesalib/docs/specs/MESA_copy_sub_buffer.spec
@@ -0,0 +1,96 @@
+Name
+
+    MESA_copy_sub_buffer
+
+Name Strings
+
+    GLX_MESA_copy_sub_buffer
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 2.6 in February, 1998.
+
+Version
+
+    Last Modified Date:  12 January 2009
+
+Number
+
+    215
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    The glxCopySubBufferMESA() function copies a rectangular region
+    of the back color buffer to the front color buffer.  This can be
+    used to quickly repaint 3D windows in response to expose events
+    when the back color buffer cannot be damaged by other windows.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+			       int x, int y, int width, int height );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Add to section 3.3.10 Double Buffering:
+
+    The function
+
+	 void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+				    int x, int y, int width, int height );
+
+    may be used to copy a rectangular region of the back color buffer to
+    the front color buffer.  This can be used to quickly repaint 3D windows
+    in response to expose events when the back color buffer cannot be
+    damaged by other windows.
+
+    <x> and <y> indicates the lower-left corner of the region to copy and
+    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
+    corresponds to the lower-left pixel of the window, like glReadPixels.
+
+    If dpy and drawable are the display and drawable for the calling
+    thread's current context, glXCopySubBufferMESA performs an
+    implicit glFlush before it returns.  Subsequent OpenGL commands
+    may be issued immediately after calling glXCopySubBufferMESA, but
+    are not executed until the copy is completed. 
+
+GLX Protocol
+
+    None at this time.  The extension is implemented in terms of ordinary
+    Xlib protocol inside of Mesa.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    12 January 2009 Ian Romanick - Added language about implicit flush
+                                   and command completion.
+    8 June 2000     Brian Paul   - initial specification
+
diff --git a/mesalib/docs/specs/MESA_drm_image.spec b/mesalib/docs/specs/MESA_drm_image.spec
new file mode 100644
index 000000000..1150a4c43
--- /dev/null
+++ b/mesalib/docs/specs/MESA_drm_image.spec
@@ -0,0 +1,153 @@
+Name
+
+    MESA_drm_image
+
+Name Strings
+
+    EGL_MESA_drm_image
+
+Contact
+
+    Kristian Høgsberg <krh@bitplanet.net>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 2, August 25, 2010
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Requires EGL 1.4 or later.  This extension is written against the
+    wording of the EGL 1.4 specification.
+
+    EGL_KHR_base_image is required.
+
+Overview
+
+    This extension provides entry points for integrating EGLImage with the
+    Linux DRM mode setting and memory management drivers.  The extension
+    lets applications create EGLImages without a client API resource and
+    lets the application get the DRM buffer handles.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
+                                      const EGLint *attrib_list);
+
+    EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
+                                     EGLImageKHR image,
+                                     EGLint *name,
+				     EGLint *handle,
+				     EGLint *stride);
+
+New Tokens
+
+    Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA:
+
+        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
+        EGL_DRM_BUFFER_USE_MESA			0x31D1
+
+    Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
+
+        EGL_DRM_BUFFER_FORMAT_ARGB32_MESA	0x31D2
+
+    Bits accepted in EGL_DRM_BUFFER_USE_MESA:
+
+        EGL_DRM_BUFFER_USE_SCANOUT_MESA		0x0001
+        EGL_DRM_BUFFER_USE_SHARE_MESA		0x0002
+        EGL_DRM_BUFFER_USE_CURSOR_MESA		0x0004
+
+    Accepted in the <target> parameter of eglCreateImageKHR:
+
+        EGL_DRM_BUFFER_MESA			0x31D3
+
+    Use when importing drm buffer:
+
+        EGL_DRM_BUFFER_STRIDE_MESA		0x31D4
+        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
+
+Additions to the EGL 1.4 Specification:
+
+    To create a DRM EGLImage, call
+
+        EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
+                                          const EGLint *attrib_list);
+
+    In the attribute list, pass EGL_WIDTH, EGL_HEIGHT and format and
+    use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and
+    EGL_DRM_BUFFER_USE_MESA.  The only format specified by this
+    extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel
+    is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits,
+    then red, then green, then blue.  The bit values accepted by
+    EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA,
+    EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_MESA.
+    EGL_DRM_BUFFER_USE_SCANOUT_MESA requests that the created EGLImage
+    should be usable as a scanout buffer with the DRM kernel
+    modesetting API.  EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
+    EGLImage can be shared with other processes by passing the
+    underlying DRM buffer name.  EGL_DRM_BUFFER_USE_CURSOR_MESA
+    requests that the image must be usable as a cursor with KMS.  When
+    EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
+    be 64.
+
+    To create a process local handle or a global DRM name for a
+    buffer, call
+
+        EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
+                                         EGLImageKHR image,
+                                         EGLint *name,
+                                         EGLint *handle,
+                                         EGLint *stride);
+
+    If <name> is non-NULL, a global name is assigned to the image and
+    written to <name>, the handle (local to the DRM file descriptor,
+    for use with DRM kernel modesetting API) is written to <handle> if
+    non-NULL and the stride (in bytes) is written to <stride>, if
+    non-NULL.
+
+    Import a shared buffer by calling eglCreateImageKHR with
+    EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT,
+    EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA
+    in the attrib list.
+
+Issues
+
+    1.  Why don't we use eglCreateImageKHR with a target that
+        indicates that we want to create an EGLImage from scratch?
+
+        RESOLVED: The eglCreateImageKHR entry point is reserved for
+        creating an EGLImage from an already existing client API
+        resource.  This is fine when we're creating the EGLImage from
+        an existing DRM buffer name, it doesn't seem right to overload
+        the function to also allocate the underlying resource.
+
+    2.  Why don't we use an eglQueryImageMESA type functions for
+        querying the DRM EGLImage attributes (name, handle, and stride)?
+
+        RESOLVED: The eglQueryImage function has been proposed often,
+        but it goes against the EGLImage design.  EGLImages are opaque
+        handles to a 2D array of pixels, which can be passed between
+        client APIs.  By referencing an EGLImage in a client API, the
+        EGLImage target (a texture, a renderbuffer or such) can be
+        used to query the attributes of the EGLImage.  We don't have a
+        full client API for creating and querying DRM buffers, though,
+        so we use a new EGL extension entry point instead.
+
+Revision History
+
+    Version 1, June 3, 2010
+        Initial draft (Kristian Høgsberg)
+    Version 2, August 25, 2010
+        Flesh out the extension a bit, add final EGL tokens, capture
+        some of the original discussion in the issues section.
diff --git a/mesalib/docs/specs/MESA_multithread_makecurrent.spec b/mesalib/docs/specs/MESA_multithread_makecurrent.spec
new file mode 100644
index 000000000..5065c2fc0
--- /dev/null
+++ b/mesalib/docs/specs/MESA_multithread_makecurrent.spec
@@ -0,0 +1,158 @@
+Name
+
+    MESA_multithread_makecurrent
+
+Name Strings
+
+    GLX_MESA_multithread_makecurrent
+
+Contact
+
+    Eric Anholt (eric@anholt.net)
+
+Status
+
+    Not shipping.
+
+Version
+
+    Last Modified Date:  21 February 2011
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.3 or later is required.
+
+Overview
+
+    The GLX context setup encourages multithreaded applications to
+    create a context per thread which each operate on their own
+    objects in parallel, and leaves synchronization for write access
+    to shared objects up to the application.
+
+    For some applications, maintaining per-thread contexts and
+    ensuring that the glFlush happens in one thread before another
+    thread starts working on that object is difficult.  For them,
+    using the same context across multiple threads and protecting its
+    usage with a mutex is both higher performance and easier to
+    implement.  This extension gives those applications that option by
+    relaxing the context binding requirements.
+
+    This new behavior matches the requirements of AGL, while providing
+    a feature not specified in WGL.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    None.
+
+Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
+
+    Replace the following sentence from section 2.2 Rendering Contexts:
+	In addition, a rendering context can be current for only one
+	thread at a time.
+    with:
+	In addition, an indirect rendering context can be current for
+	only one thread at a time.  A direct rendering context may be
+	current to multiple threads, with synchronization of access to
+	the context thruogh the GL managed by the application through
+	mutexes.
+
+Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Replace the following sentence from section 3.3.7 Rendering Contexts:
+	If ctx is current to some other thread, then
+	glXMakeContextCurrent will generate a BadAccess error.
+    with:
+	If ctx is an indirect context current to some other thread,
+	then glXMakeContextCurrent will generate a BadAccess error.
+
+    Replace the following sentence from section 3.5 Rendering Contexts:
+	If ctx is current to some other thread, then
+	glXMakeCurrent will generate a BadAccess error.
+    with:
+	If ctx is an indirect context current to some other thread,
+	then glXMakeCurrent will generate a BadAccess error.
+
+GLX Protocol
+
+    None.  The GLX extension only extends to direct rendering contexts.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Issues
+
+    (1) What happens if the app binds a context/drawable in multiple
+	threads, then binds a different context/thread in one of them?
+
+    As with binding a new context from the current thread, the old
+    context's refcount is reduced and the new context's refcount is
+    increased.
+
+    (2) What happens if the app binds a context/drawable in multiple
+	threads, then binds None/None in one of them?
+
+    The GLX context is unreferenced from that thread, and the other
+    threads retain their GLX context binding.
+
+    (3) What happens if the app binds a context/drawable in 7 threads,
+	then destroys the context in one of them?
+
+    As with GLX context destruction previously, the XID is destroyed
+    but the context remains usable by threads that have the context
+    current.
+
+    (4) What happens if the app binds a new drawable/readable with
+        glXMakeCurrent() when it is already bound to another thread?
+
+    The context becomes bound to the new drawable/readable, and
+    further rendering in either thread will use the new
+    drawable/readable.
+
+    (5) What requirements should be placed on the user managing contexts
+        from multiple threads?
+
+    The intention is to allow multithreaded access to the GL at the
+    minimal performance cost, so requiring that the GL do general
+    synchronization (beyond that already required by context sharing)
+    is not an option, and synchronizing of GL's access to the GL
+    context between multiple threads is left to the application to do
+    across GL calls.  However, it would be unfortunate for a library
+    doing multithread_makecurrent to require that other libraries
+    share in synchronization for binding of their own contexts, so the
+    refcounting of the contexts is required to be threadsafe.
+
+    (6) Does this apply to indirect contexts?
+
+    This was ignored in the initial revision of the spec.  Behavior
+    for indirect contexts is left as-is.
+
+Revision History
+
+    20 November 2009 Eric Anholt - initial specification
+    22 November 2009 Eric Anholt - added issues from Ian Romanick.
+    3 February 2011 Eric Anholt - updated with resolution to issues 1-3
+    3 February 2011 Eric Anholt - added issue 4, 5
+    21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
+    along with glXMakeContextCurrent() for removal.
diff --git a/mesalib/docs/specs/MESA_pack_invert.spec b/mesalib/docs/specs/MESA_pack_invert.spec
new file mode 100644
index 000000000..33fb3c7bf
--- /dev/null
+++ b/mesalib/docs/specs/MESA_pack_invert.spec
@@ -0,0 +1,138 @@
+Name
+
+    MESA_pack_invert
+
+Name Strings
+
+    GL_MESA_pack_invert
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (Mesa 4.0.4 and later)
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+    This extension adds a new pixel storage parameter to indicate that
+    images are to be packed in top-to-bottom order instead of OpenGL's
+    conventional bottom-to-top order.  Only pixel packing can be
+    inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
+    etc).
+
+    Almost all known image file formats store images in top-to-bottom
+    order.  As it is, OpenGL reads images from the frame buffer in
+    bottom-to-top order.  Thus, images usually have to be inverted before
+    writing them to a file with image I/O libraries.  This extension
+    allows images to be read such that inverting isn't needed.
+
+IP Status
+
+    None
+
+Issues
+
+    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
+
+    Resolved:  No, we're only concerned with pixel packing.  There are other
+    solutions for inverting images when using glDrawPixels (negative Y pixel
+    zoom) or glTexImage (invert the vertex T coordinates).  It would be easy
+    enough to define a complementary extension for pixel packing in the
+    future if needed.
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted by the <pname> parameter of PixelStorei and PixelStoref
+    and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
+    and GetBooleanv:
+
+        PACK_INVERT_MESA                   0x8758
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    Add the following entry to table 4.4 (PixelStore parameters) on page 182:
+
+    Parameter Name       Type    Initial Value    Valid Range
+    ---------------------------------------------------------
+    PACK_INVERT_MESA     boolean     FALSE        TRUE/FALSE
+
+    In the section labeled "Placement in Client Memory" on page 184
+    insert the following text into the paragraph before the sentence
+    that starts with "If the format is RED, GREEN, BLUE...":
+
+    "The parameter PACK_INVERT_MESA controls whether the image is packed
+     in bottom-to-top order (the default) or top-to-bottom order.  Equation
+     3.8 is modified as follows:
+
+     ... the first element of the Nth row is indicated by
+
+         p + Nk,                if PACK_INVERT_MESA is false
+         p + k * (H - 1) - Nk,  if PACK_INVERT_MESA is true, where H is the
+                                image height
+    "
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    None
+
+New State
+
+    Add the following entry to table 6.20 (Pixels) on page 235:
+
+    Get Value         Type     Get Cmd    Initial Value  Description                Sec    Attribute
+    --------------------------------------------------------------------------------------------------
+    PACK_INVERT_MESA  boolean  GetBoolean  FALSE         Value of PACK_INVERT_MESA  4.3.2  pixel-store
+
+Revision History
+
+    21 September 2002 - Initial draft
diff --git a/mesalib/docs/specs/MESA_pixmap_colormap.spec b/mesalib/docs/specs/MESA_pixmap_colormap.spec
new file mode 100644
index 000000000..fb0b441cc
--- /dev/null
+++ b/mesalib/docs/specs/MESA_pixmap_colormap.spec
@@ -0,0 +1,90 @@
+Name
+
+    MESA_pixmap_colormap
+
+Name Strings
+
+    GLX_MESA_pixmap_colormap
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 1.2.8 in May, 1996.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    216
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    Since Mesa allows RGB rendering into drawables with PseudoColor,
+    StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
+    in order to compute pixel values during rendering.
+
+    The colormap associated with a window can be queried with normal
+    Xlib functions but there is no colormap associated with pixmaps.
+
+    The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
+    which allows specification of a colormap.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+				      Pixmap pixmap, Colormap cmap );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Add to section 3.4.2 Off Screen Rendering
+
+    The Mesa implementation of GLX allows RGB rendering into X windows and
+    pixmaps of any visual class, not just TrueColor or DirectColor.  In order
+    to compute pixel values from RGB values Mesa requires a colormap.
+
+    The function
+
+	GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+					  Pixmap pixmap, Colormap cmap );
+
+    allows one to create a GLXPixmap with a specific colormap.  The image
+    rendered into the pixmap may then be copied to a window (which uses the
+    same colormap and visual) with the expected results.
+
+GLX Protocol
+
+    None since this is a client-side extension.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/mesalib/docs/specs/MESA_release_buffers.spec b/mesalib/docs/specs/MESA_release_buffers.spec
new file mode 100644
index 000000000..52d1e5a9c
--- /dev/null
+++ b/mesalib/docs/specs/MESA_release_buffers.spec
@@ -0,0 +1,85 @@
+Name
+
+    MESA_release_buffers
+
+Name Strings
+
+    GLX_MESA_release_buffers
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 2.0 in October, 1996.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    217
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    Mesa's implementation of GLX is entirely implemented on the client side.
+    Therefore, Mesa cannot immediately detect when an X window or pixmap is
+    destroyed in order to free any ancillary data associated with the window
+    or pixmap.
+
+    The glxMesaReleaseBuffers() function can be used to explicitly indicate
+    when the back color buffer, depth buffer, stencil buffer, and/or accumu-
+    lation buffer associated with a drawable can be freed.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    The function
+
+	Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+    causes all software ancillary buffers (back buffer, depth, stencil,
+    accum, etc) associated with the named drawable to be immediately
+    deallocated.  True is returned if <d> is a valid Mesa GLX drawable,
+    else False is returned.  After calling glXReleaseBuffersMESA, the
+    drawable should no longer be used for GL rendering.  Results of
+    attempting to do so are undefined.
+
+
+GLX Protocol
+
+    None, since this is a client-side operation.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/mesalib/docs/specs/MESA_resize_buffers.spec b/mesalib/docs/specs/MESA_resize_buffers.spec
new file mode 100644
index 000000000..dabc7c421
--- /dev/null
+++ b/mesalib/docs/specs/MESA_resize_buffers.spec
@@ -0,0 +1,81 @@
+Name
+
+    MESA_resize_buffers
+
+Name Strings
+
+    GL_MESA_resize_buffers
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (since Mesa version 2.2)
+
+Version
+
+
+Number
+
+    196
+
+Dependencies
+
+    Mesa 2.2 or later is required.
+
+Overview
+
+    Mesa is often used as a client library with no integration with
+    the computer's window system (an X server, for example).  And since
+    Mesa does not have an event loop nor window system callbacks, it
+    cannot properly respond to window system events.  In particular,
+    Mesa cannot automatically detect when a window has been resized.
+
+    Mesa's glViewport command queries the current window size and updates
+    its internal data structors accordingly.  This normally works fine
+    since most applications call glViewport in response to window size
+    changes.
+
+    In some situations, however, the application may not call glViewport
+    when a window size changes but would still like Mesa to adjust to
+    the new window size.  This extension exports a new function to solve
+    this problem.
+
+New Procedures and Functions
+
+    void glResizeBuffersMESA( void )
+
+New Tokens
+
+    none
+
+Additions to the OpenGL Specification (no particular section)
+
+    The glResizeBuffersMESA command may be called when the client
+    determines that a window has been resized.  Calling
+    glResizeBuffersMESA causes Mesa to query the current window size
+    and adjust its internal data structures.  This may include
+    reallocating depth, stencil, alpha and accumulation buffers.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+Errors
+
+    INVALID_OPERATION is generated if glResizeBuffersMESA is called between
+    Begin and End.
+
+New State
+
+    None.
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+  * Revision 1.0 - Initial specification
diff --git a/mesalib/docs/specs/MESA_set_3dfx_mode.spec b/mesalib/docs/specs/MESA_set_3dfx_mode.spec
new file mode 100644
index 000000000..06d97ca02
--- /dev/null
+++ b/mesalib/docs/specs/MESA_set_3dfx_mode.spec
@@ -0,0 +1,85 @@
+Name
+
+    MESA_set_3dfx_mode
+
+Name Strings
+
+    GLX_MESA_set_3dfx_mode
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 2.6 in February, 1998.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    218
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    The Mesa Glide driver allows full-screen rendering or rendering into
+    an X window.  The glXSet3DfxModeMESA() function allows an application
+    to switch between full-screen and windowed rendering.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    GLboolean glXSet3DfxModeMESA( GLint mode );
+
+New Tokens
+
+    GLX_3DFX_WINDOW_MODE_MESA	    0x1
+    GLX_3DFX_FULLSCREEN_MODE_MESA   0x2
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    The Mesa Glide device driver allows either rendering in full-screen
+    mode or rendering into an X window.  An application can switch between
+    full-screen and window rendering with the command:
+
+	GLboolean glXSet3DfxModeMESA( GLint mode );
+
+    <mode> may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window
+    rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode.
+
+    GL_TRUE is returned if <mode> is valid and the operation completed
+    normally.  GL_FALSE is returned if <mode> is invalid or if the Glide
+    driver is not being used.
+
+    Note that only one drawable and context can be created at any given
+    time with the Mesa Glide driver.
+
+GLX Protocol
+
+    None since this is a client-side extension.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/mesalib/docs/specs/MESA_shader_debug.spec b/mesalib/docs/specs/MESA_shader_debug.spec
new file mode 100644
index 000000000..fab92abc7
--- /dev/null
+++ b/mesalib/docs/specs/MESA_shader_debug.spec
@@ -0,0 +1,264 @@
+Name
+
+    MESA_shader_debug
+
+Name Strings
+
+    GL_MESA_shader_debug
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Michal Krol (mjkrol 'at' gmail.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+    Last Modified Date: July 30, 2006
+    Author Revision: 0.2
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 is required.
+
+    The ARB_shader_objects extension is required.
+
+    The ARB_shading_language_100 extension is required.
+
+    The extension is written against the OpenGL 1.5 specification.
+
+    The extension is written against the OpenGL Shading Language 1.10
+    Specification.
+
+Overview
+
+    This extension introduces a debug object that can be attached to
+    a program object to enable debugging. Vertex and/or fragment shader,
+    during execution, issue diagnostic function calls that are logged
+    to the debug object's log. A separate debug log for each shader type
+    is maintained. A debug object can be attached, detached and queried
+    at any time outside the Begin/End pair. Multiple debug objects can
+    be attached to a single program object.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    handleARB CreateDebugObjectMESA(void)
+    void ClearDebugLogMESA(handleARB obj, enum logType, enum shaderType)
+    void GetDebugLogMESA(handleARB obj, enum logType, enum shaderType,
+                         sizei maxLength, sizei *length,
+                         charARB *debugLog)
+    sizei GetDebugLogLengthMESA(handleARB obj, enum logType,
+                                enum shaderType)
+
+New Types
+
+    None
+
+New Tokens
+
+    Returned by the <params> parameter of GetObjectParameter{fi}vARB:
+
+        DEBUG_OBJECT_MESA                               0x8759
+
+    Accepted by the <logType> argument of ClearDebugLogMESA,
+    GetDebugLogLengthMESA and GetDebugLogMESA:
+
+        DEBUG_PRINT_MESA                                0x875A
+        DEBUG_ASSERT_MESA                               0x875B
+
+Additions to Chapter 2 of the OpenGL 1.5 Specification
+(OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    None
+
+Additions to Chapter 5 of the OpenGL 1.5 Specification
+(Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
+Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
+
+    None
+
+Additions to Chapter 1 of the OpenGL Shading Language 1.10 Specification
+(Introduction)
+
+    None
+
+Additions to Chapter 2 of the OpenGL Shading Language 1.10 Specification
+(Overview of OpenGL Shading)
+
+    None
+
+Additions to Chapter 3 of the OpenGL Shading Language 1.10 Specification
+(Basics)
+
+    None
+
+Additions to Chapter 4 of the OpenGL Shading Language 1.10 Specification
+(Variables and Types)
+
+    None
+
+Additions to Chapter 5 of the OpenGL Shading Language 1.10 Specification
+(Operators and Expressions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL Shading Language 1.10 Specification
+(Statements and Structure)
+
+    None
+
+Additions to Chapter 7 of the OpenGL Shading Language 1.10 Specification
+(Built-in Variables)
+
+    None
+
+Additions to Chapter 8 of the OpenGL Shading Language 1.10 Specification
+(Built-in Functions)
+
+    Add a new section 8.10 "Debug Functions":
+
+    Debug functions are available to both fragment and vertex shaders.
+    They are used to track the execution of a shader by logging
+    passed-in arguments to the debug object's log. Those values can be
+    retrieved by the application for inspection after shader execution
+    is complete.
+
+    The text, if any, produced by any of these functions is appended
+    to each debug object that is attached to the program object.
+    There are different debug log types
+
+    Add a new section 8.10.1 "Print Function":
+
+    The following printMESA prototypes are available.
+
+        void printMESA(const float value)
+        void printMESA(const int value)
+        void printMESA(const bool value)
+        void printMESA(const vec2 value)
+        void printMESA(const vec3 value)
+        void printMESA(const vec4 value)
+        void printMESA(const ivec2 value)
+        void printMESA(const ivec3 value)
+        void printMESA(const ivec4 value)
+        void printMESA(const bvec2 value)
+        void printMESA(const bvec3 value)
+        void printMESA(const bvec4 value)
+        void printMESA(const mat2 value)
+        void printMESA(const mat3 value)
+        void printMESA(const mat4 value)
+        void printMESA(const sampler1D value)
+        void printMESA(const sampler2D value)
+        void printMESA(const sampler3D value)
+        void printMESA(const samplerCube value)
+        void printMESA(const sampler1DShadow value)
+        void printMESA(const sampler2DShadow value)
+
+    The printMESA function writes the argument <value> to the "debug
+    print log" (XXX DEBUG_PRINT_MESA?). Each component is written in
+    text format (XXX format!) and is delimited by a white space (XXX 1
+    or more?).
+
+    Add a new section 8.10.2 "Assert Function":
+
+    The following assertMESA prototypes are available.
+
+        void assertMESA(const bool condition)
+        void assertMESA(const bool condition, const int cookie)
+        void assertMESA(const bool condition, const int cookie,
+                        const int file, const int line)
+
+    The assertMESA function checks if the argument <condition> is
+    true or false. If it is true, nothing happens. If it is false,
+    a diagnostic message is written to the "debug assert log".
+    The message contains the argument <file>, <line>, <cookie> and
+    implementation dependent double-quoted string, each of this
+    delimited by a white space. If the argument <cookie> is not present,
+    it is meant as if it was of value 0. If the arguments <file> and
+    <line> are not present, they are meant as if they were of values
+    __FILE__ and __LINE__, respectively. The following three calls
+    produce the same output, assuming they were issued from the same
+    file and line.
+
+        assertMESA (false);
+        assertMESA (false, 0);
+        assertMESA (false, 0, __FILE__, __LINE__);
+
+    The diagnostic message examples follow.
+
+        1 89 0 ""
+        1 45 333 "all (lessThanEqual (fragColor, vec4 (1.0)))"
+        1 66 1 "assertion failed in file 1, line 66, cookie 1"
+
+Additions to Chapter 9 of the OpenGL Shading Language 1.10 Specification
+(Shading Language Grammar)
+
+    None
+
+Additions to Chapter 10 of the OpenGL Shading Language 1.10
+Specification (Issues)
+
+    None
+
+Additions to the AGL/EGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    TBD
+
+New State
+
+    TBD
+
+New Implementation Dependent State
+
+    TBD
+
+Sample Code
+
+    TBD
+
+Revision History
+
+    29 May 2006
+        Initial draft. (Michal Krol)
+    30 July 2006
+        Add Overview, New Procedures and Functions, New Tokens sections.
+        Add sections 8.10.1, 8.10.2 to GLSL spec.
diff --git a/mesalib/docs/specs/MESA_swap_control.spec b/mesalib/docs/specs/MESA_swap_control.spec
new file mode 100644
index 000000000..a002563c9
--- /dev/null
+++ b/mesalib/docs/specs/MESA_swap_control.spec
@@ -0,0 +1,129 @@
+Name
+
+    MESA_swap_control
+
+Name Strings
+
+    GLX_MESA_swap_control
+
+Contact
+
+    Ian Romanick, IBM, idr at us.ibm.com
+
+Status
+
+    Deployed in DRI drivers post-XFree86 4.3.
+
+Version
+
+    Date: 5/1/2003   Revision: 1.1
+
+Number
+
+    ???
+
+Dependencies
+
+    None
+
+    Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
+    version 1.5.
+
+Overview
+
+    This extension allows an application to specify a minimum periodicity
+    of color buffer swaps, measured in video frame periods.
+
+Issues
+
+    * Should implementations that export GLX_MESA_swap_control also export
+      GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
+
+    UNRESOLVED.
+
+New Procedures and Functions
+
+    int glXSwapIntervalMESA(unsigned int interval)
+    int glXGetSwapIntervalMESA(void)
+
+New Tokens
+
+    None
+
+Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+    None
+
+Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
+
+    None
+
+Additions to the GLX 1.3 Specification
+
+    [Add the following to Section 3.3.10 of the GLX Specification (Double
+     Buffering)]
+
+    glXSwapIntervalMESA specifies the minimum number of video frame periods
+    per buffer swap.  (e.g. a value of two means that the color buffers
+    will be swapped at most every other video frame.)  A return value
+    of zero indicates success; otherwise an error occurred.  The interval
+    takes effect when glXSwapBuffers is first called subsequent to the
+    glXSwapIntervalMESA call.
+
+    A video frame period is the time required by the monitor to display a 
+    full frame of video data.  In the case of an interlaced monitor,
+    this is typically the time required to display both the even and odd 
+    fields of a frame of video data.
+
+    If <interval> is set to a value of 0, buffer swaps are not synchro-
+    nized to a video frame.  The <interval> value is silently clamped to
+    the maximum implementation-dependent value supported before being
+    stored.
+
+    The swap interval is not part of the render context state.  It cannot
+    be pushed or popped.  The current swap interval for the window
+    associated with the current context can be obtained by calling
+    glXGetSwapIntervalMESA.  The default swap interval is 0.
+
+    On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
+    the swap interval to 1.
+
+Errors
+
+    glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
+    GLXContext or if the current context is not a direct rendering context.
+
+GLX Protocol
+
+    None.  This extension only extends to direct rendering contexts.
+
+New State
+
+    Get Value		Get Command	Type	    Initial Value
+    ---------		-----------	----	    -------------
+    [swap interval]	GetSwapInterval	Z+	    0
+
+New Implementation Dependent State
+
+    None
+
+
+Revision History
+
+    1.1,  5/1/03   Added the issues section and contact information.
+    	  	   Changed the default swap interval to 0.
+    1.0,  3/17/03  Initial version based on GLX_SGI_swap_control and
+                   WGL_EXT_swap_control.
diff --git a/mesalib/docs/specs/MESA_swap_frame_usage.spec b/mesalib/docs/specs/MESA_swap_frame_usage.spec
new file mode 100644
index 000000000..5023eadd8
--- /dev/null
+++ b/mesalib/docs/specs/MESA_swap_frame_usage.spec
@@ -0,0 +1,201 @@
+Name
+
+    MESA_swap_frame_usage
+
+Name Strings
+
+    GLX_MESA_swap_frame_usage
+
+Contact
+
+    Ian Romanick, IBM, idr at us.ibm.com
+
+Status
+
+    Deployed in DRI drivers post-XFree86 4.3.
+
+Version
+
+    Date: 5/1/2003   Revision: 1.1
+
+Number
+
+    ???
+
+Dependencies
+
+    GLX_SGI_swap_control affects the definition of this extension.
+    GLX_MESA_swap_control affects the definition of this extension.
+    GLX_OML_sync_control affects the definition of this extension.
+
+    Based on WGL_I3D_swap_frame_usage version 1.3.
+
+Overview
+
+    This extension allows an application to determine what portion of the
+    swap period has elapsed since the last swap operation completed.  The
+    "usage" value is a floating point value on the range [0,max] which is
+    calculated as follows:
+
+                              td
+                   percent = ----
+                              tf
+
+    where td is the time measured from the last completed buffer swap (or
+    call to enable the statistic) to when the next buffer swap completes, tf
+    is the entire time for a frame which may be multiple screen refreshes
+    depending on the swap interval as set by the GLX_SGI_swap_control or
+    GLX_OML_sync_control extensions. 
+
+    The value, percent, indicates the amount of time spent between the
+    completion of the two swaps.  If the value is in the range [0,1], the
+    buffer swap occurred within the time period required to maintain a
+    constant frame rate.  If the value is in the range (1,max], a constant
+    frame rate was not achieved.  The value indicates the number of frames
+    required to draw.
+
+    This definition of "percent" differs slightly from
+    WGL_I3D_swap_frame_usage.  In WGL_I3D_swap_frame_usage, the measurement
+    is taken from the completion of one swap to the issuance of the next.
+    This representation may not be as useful as measuring between
+    completions, as a significant amount of time may pass between the
+    issuance of a swap and the swap actually occurring.
+
+    There is also a mechanism to determine whether a frame swap was
+    missed.
+
+New Procedures and Functions
+
+    int glXGetFrameUsageMESA(Display *dpy,
+                             GLXDrawable drawable,
+    	                     float *usage)
+
+    int glXBeginFrameTrackingMESA(Display *dpy,
+                                  GLXDrawable drawable)
+
+    int glXEndFrameTrackingMESA(Display *dpy,
+                                GLXDrawable drawable)
+
+    int glXQueryFrameTrackingMESA(Display *dpy,
+                                  GLXDrawable drawable,
+				  int64_t *swapCount,
+                                  int64_t *missedFrames,
+                                  float *lastMissedUsage)
+
+New Tokens
+
+    None
+
+Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+    None
+
+Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
+
+    None
+
+Additions to the GLX 1.3 Specification
+
+    The frame usage is measured as the percentage of the swap period elapsed
+    between two buffer-swap operations being committed.  In unextended GLX the
+    swap period is the vertical refresh time.  If SGI_swap_control or
+    MESA_swap_control are supported, the swap period is the vertical refresh
+    time multiplied by the swap interval (or one if the swap interval is set
+    to zero).
+    
+    If OML_sync_control is supported, the swap period is the vertical
+    refresh time multiplied by the divisor parameter to
+    glXSwapBuffersMscOML.  The frame usage in this case is less than 1.0 if
+    the swap is committed before target_msc, and is greater than or equal to
+    1.0 otherwise.  The actual usage value is based on the divisor and is
+    never less than 0.0.
+
+       int glXBeginFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable,
+				     float *usage)
+
+    glXGetFrameUsageMESA returns a floating-point value in <usage>
+    that represents the current swap usage, as defined above.
+
+    Missed frame swaps can be tracked by calling the following function:
+
+       int glXBeginFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable)
+
+    glXBeginFrameTrackingMESA resets a "missed frame" count and
+    synchronizes with the next frame vertical sync before it returns.
+    If a swap is missed based in the rate control specified by the
+    <interval> set by glXSwapIntervalSGI or the default swap of once
+    per frame, the missed frame count is incremented.
+
+    The current missed frame count and total number of swaps since
+    the last call to glXBeginFrameTrackingMESA can be obtained by
+    calling the following function:
+
+       int glXQueryFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable,
+				     int64_t *swapCount,
+                                     int64_t *missedFrames,
+                                     float *lastMissedUsage)
+
+    The location pointed to by <swapCount> will be updated with the
+    number of swaps that have been committed.  This value may not match the
+    number of swaps that have been requested since swaps may be
+    queued by the implementation.  This function can be called at any
+    time and does not synchronize to vertical blank.
+
+    The location pointed to by <missedFrames> will contain the number
+    swaps that missed the specified frame.  The frame usage for the
+    last missed frame is returned in the location pointed to by
+    <lastMissedUsage>.
+
+    Frame tracking is disabled by calling the function
+
+       int glXEndFrameTrackingMESA(Display *dpy,
+                                   GLXDrawable drawable)
+
+    This function will not return until all swaps have occurred.  The
+    application can call glXQueryFrameTrackingMESA for a final swap and
+    missed frame count.
+
+    If these functions are successful, zero is returned.  If the context
+    associated with dpy and drawable is not a direct context,
+    GLX_BAD_CONTEXT is returned.
+
+Errors
+
+    If the function succeeds, zero is returned.  If the function
+    fails, one of the following error codes is returned:
+
+       GLX_BAD_CONTEXT         The current rendering context is not a direct
+       			       context.
+
+GLX Protocol
+
+    None.  This extension only extends to direct rendering contexts.
+
+New State
+
+    None
+
+New Implementation Dependent State
+
+    None
+
+Revision History
+
+    1.1,  5/1/03   Added contact information.
+    1.0,  3/17/03  Initial version based on WGL_I3D_swap_frame_usage.
diff --git a/mesalib/docs/specs/MESA_texture_array.spec b/mesalib/docs/specs/MESA_texture_array.spec
new file mode 100644
index 000000000..b146821f7
--- /dev/null
+++ b/mesalib/docs/specs/MESA_texture_array.spec
@@ -0,0 +1,804 @@
+Name
+
+    MESA_texture_array
+
+Name Strings
+
+    GL_MESA_texture_array
+
+Contact
+
+    Ian Romanick, IBM (idr 'at' us.ibm.com)
+
+IP Status
+
+    No known IP issues.
+
+Status
+
+    Shipping in Mesa 7.1
+
+Version
+
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.2 or GL_EXT_texture3D is required.
+
+    Support for ARB_fragment_program is assumed, but not required.
+
+    Support for ARB_fragment_program_shadow is assumed, but not required.
+
+    Support for EXT_framebuffer_object is assumed, but not required.
+
+    Written based on the wording of the OpenGL 2.0 specification and
+    ARB_fragment_program_shadow but not dependent on them.
+
+Overview
+
+    There are a number of circumstances where an application may wish to
+    blend two textures out of a larger set of textures.  Moreover, in some
+    cases the selected textures may vary on a per-fragment basis within
+    a polygon.  Several examples include:
+
+       1. High dynamic range textures.  The application stores several
+       different "exposures" of an image as different textures.  On a
+       per-fragment basis, the application selects which exposures are
+       used.
+
+       2. A terrain engine where the altitude of a point determines the
+       texture applied to it.  If the transition is from beach sand to
+       grass to rocks to snow, the application will store each texture
+       in a different texture map, and dynamically select which two
+       textures to blend at run-time.
+
+       3. Storing short video clips in textures.  Each depth slice is a
+       single frame of video.
+
+    Several solutions to this problem have been proposed, but they either
+    involve using a separate texture unit for each texture map or using 3D
+    textures without mipmaps.  Both of these options have major drawbacks.
+
+    This extension provides a third alternative that eliminates the major
+    drawbacks of both previous methods.  A new texture target,
+    TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
+    all aspects except the sizes of the non-base level images.  In
+    traditional 3D texturing, the size of the N+1 LOD is half the size
+    of the N LOD in all three dimensions.  For the TEXTURE_2D_ARRAY target,
+    the height and width of the N+1 LOD is halved, but the depth is the
+    same for all levels of detail. The texture then becomes an array of
+    2D textures.  The per-fragment texel is selected by the R texture
+    coordinate.
+
+    References:
+
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
+        http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
+
+New Procedures and Functions
+
+    All functions come directly from EXT_texture_array.
+
+    void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                    uint texture, int level, int layer);
+
+New Tokens
+
+    All token names and values come directly from EXT_texture_array.
+
+    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
+    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
+    GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
+    GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
+    GetTexParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT                            0x8C18
+        TEXTURE_2D_ARRAY_EXT                            0x8C1A
+
+    Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
+    CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
+    CompressedTexSubImage2D, GetTexLevelParameteriv, and 
+    GetTexLevelParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT
+        PROXY_TEXTURE_1D_ARRAY_EXT                      0x8C19
+
+    Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
+    CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
+    GetTexLevelParameteriv, and GetTexLevelParameterfv:
+
+        TEXTURE_2D_ARRAY_EXT
+        PROXY_TEXTURE_2D_ARRAY_EXT                      0x8C1B
+
+    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+    GetFloatv, and GetDoublev
+
+        TEXTURE_BINDING_1D_ARRAY_EXT                    0x8C1C
+        TEXTURE_BINDING_2D_ARRAY_EXT                    0x8C1D
+        MAX_ARRAY_TEXTURE_LAYERS_EXT                    0x88FF
+
+    Accepted by the <param> parameter of TexParameterf, TexParameteri,
+    TexParameterfv, and TexParameteriv when the <pname> parameter is
+    TEXTURE_COMPARE_MODE_ARB:
+
+        COMPARE_REF_DEPTH_TO_TEXTURE_EXT                0x884E
+
+    (Note:  COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
+    existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
+    reflects the fact that the R coordinate is not always used.)
+
+    Accepted by the <internalformat> parameter of TexImage3D and
+    CompressedTexImage3D, and by the <format> parameter of
+    CompressedTexSubImage3D:
+
+        COMPRESSED_RGB_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT3_EXT
+        COMPRESSED_RGBA_S3TC_DXT5_EXT
+
+    Accepted by the <pname> parameter of
+    GetFramebufferAttachmentParameterivEXT:
+
+        FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT          0x8CD4
+
+    (Note:  FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
+    FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
+    EXT_framebuffer_object.  This extension generalizes the notion of
+    "<zoffset>" to include layers of an array texture.)
+
+Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
+
+    -- Section 3.8.1 "Texture Image Specification"
+
+       Change the first paragraph (page 150) to say (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void TexImage3D(enum target, int level, int internalformat,
+                         sizei width, sizei height, sizei depth, int border,
+                         enum format, enum type, void *data);
+
+       is used to specify a three-dimensional texture image. target must be one
+       one of TEXTURE_3D for a three-dimensional texture or
+       TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
+       Additionally, target may be either PROXY_TEXTURE_3D for a
+       three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
+       two-dimensional proxy array texture."
+
+       Change the fourth paragraph on page 151 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Textures with a base internal format of DEPTH_COMPONENT are supported
+       by texture image specification commands only if target is TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
+       PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
+       PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
+       other target will result in an INVALID_OPERATION error."
+
+
+       Change the fourth paragraph on page 156 to say (spec changes identical
+       to EXT_texture_array):
+       
+       "The command
+
+         void TexImage2D(enum target, int level,
+                         int internalformat, sizei width, sizei height,
+                         int border, enum format, enum type, void *data);
+
+       is used to specify a two-dimensional texture image. target must be one
+       of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
+       one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
+       target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
+       texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
+       texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
+       special case discussed in section 3.8.11.  The other parameters match
+       the corresponding parameters of TexImage3D.
+
+       For the purposes of decoding the texture image, TexImage2D is
+       equivalent to calling TexImage3D with corresponding arguments and depth
+       of 1, except that
+
+         * The border depth, d_b, is zero, and the depth of the image is
+           always 1 regardless of the value of border. 
+
+         * The border height, h_b, is zero if <target> is
+           TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
+
+         * Convolution will be performed on the image (possibly changing its
+           width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
+
+         * UNPACK SKIP IMAGES is ignored."
+
+    -- Section 3.8.2 "Alternate Texture Image Specification Commands"
+
+       Change the second paragraph (page 159) (spec changes identical
+       to EXT_texture_array):
+
+       "The command
+
+         void CopyTexImage2D(enum target, int level,
+                             enum internalformat, int x, int y, sizei width,
+                             sizei height, int border);
+
+       defines a two-dimensional texture image in exactly the manner of
+       TexImage2D, except that the image data are taken from the framebuffer
+       rather than from client memory. Currently, target must be one of
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z.
+
+
+       Change the last paragraph on page 160 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
+       must be TEXTURE_1D, the target arguments of TexSubImage2D and
+       CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
+       TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
+       TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
+       TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
+       target arguments of TexSubImage3D and CopyTexSubImage3D must be
+       TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
+
+
+    -- Section 3.8.4 "Texture Parameters"
+
+       Change the first paragraph (page 166) to say:
+
+       "Various parameters control how the texel array is treated when
+       specified or changed, and when applied to a fragment. Each parameter is
+       set by calling
+
+         void TexParameter{if}(enum target, enum pname, T param); 
+         void TexParameter{if}v(enum target, enum pname, T params);
+
+       target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
+
+
+    -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
+
+       Change the first paragraph (page 172) to say:
+
+       "Let s(x,y) be the function that associates an s texture coordinate
+       with each set of window coordinates (x,y) that lie within a primitive;
+       define t(x,y) and r(x,y) analogously.  Let u(x,y) = w_t * s(x,y),
+       v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
+       and d_t are as defined by equations 3.15, 3.16, and 3.17 with
+       w_s, h_s, and d_s equal to the width, height, and depth of the
+       image array whose level is level_base.  For a one-dimensional
+       texture or a one-dimensional array texture, define v(x,y) = 0 and
+       w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
+       texture, define w(x,y) = 0..."
+
+    -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
+
+       Change the third paragraph (page 174) to say:
+       
+       "For a two-dimensional texture, two-dimensional array texture, or
+       cube map texture,"
+
+       Change the fourth paragraph (page 174) to say:
+
+       "And for a one-dimensional texture or a one-dimensional array texture,"
+
+       After the first paragraph (page 175) add:
+
+       "For one-dimensional array textures, h_b and d_b are treated as 1,
+       regardless of the actual values, when performing mipmap calculations.
+       For two-dimensional array textures, d_b is always treated as one,
+       regardless of the actual value, when performing mipmap calculations."
+
+    -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
+
+       Change the third paragraph (page 176) to say (spec changes identical
+       to EXT_texture_array):
+
+       "The contents of the derived arrays are computed by repeated, filtered
+       reduction of the level_base array.  For one- and two-dimensional array
+       textures, each layer is filtered independently.  ..."
+
+    -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
+
+       Change first paragraph to say (spec changes identical to
+       EXT_texture_array):
+
+       "Mipmaps can be generated manually with the command
+
+         void GenerateMipmapEXT(enum target);
+
+       where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
+       TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY.  Mipmap generation
+       affects the texture image attached to <target>.  ..."
+
+    -- Section 3.8.10 "Texture Completeness"
+
+       Change the second paragraph (page 177) to say (spec changes identical
+       to EXT_texture_array):
+
+       "For one-, two-, or three-dimensional textures and one- or
+       two-dimensional array textures, a texture is complete if the following
+       conditions all hold true:"
+
+    -- Section 3.8.11 "Texture State and Proxy State"
+
+       Change the second and third paragraphs (page 179) to say (spec changes
+       identical to EXT_texture_array):
+
+       "In addition to image arrays for one-, two-, and three-dimensional
+       textures, one- and two-dimensional array textures, and the six image
+       arrays for the cube map texture, partially instantiated image arrays
+       are maintained for one-, two-, and three-dimensional textures and one-
+       and two-dimensional array textures.  Additionally, a single proxy image
+       array is maintained for the cube map texture.  Each proxy image array
+       includes width, height, depth, border width, and internal format state
+       values, as well as state for the red, green, blue, alpha, luminance,
+       and intensity component resolutions. Proxy image arrays do not include
+       image data, nor do they include texture properties. When TexImage3D is
+       executed with target specified as PROXY_TEXTURE_3D, the
+       three-dimensional proxy state values of the specified level-of-detail
+       are recomputed and updated. If the image array would not be supported
+       by TexImage3D called with target set to TEXTURE 3D, no error is
+       generated, but the proxy width, height, depth, border width, and
+       component resolutions are set to zero. If the image array would be
+       supported by such a call to TexImage3D, the proxy state values are set
+       exactly as though the actual image array were being specified. No pixel
+       data are transferred or processed in either case.
+
+       Proxy arrays for one- and two-dimensional textures and one- and
+       two-dimensional array textures are operated on in the same way when
+       TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
+       TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
+       PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
+       specified as PROXY_TETXURE_2D_ARRAY_EXT."
+
+    -- Section 3.8.12 "Texture Objects"
+
+       Change section (page 180) to say (spec changes identical to 
+       EXT_texture_array):
+
+       "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
+       TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
+       named one-, two-, and three-dimensional, cube map, and one- and
+       two-dimensional array texture objects can be created and operated upon.
+       The name space for texture objects is the unsigned integers, with zero
+       reserved by the GL.
+
+       A texture object is created by binding an unused name to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
+
+         void BindTexture(enum target, uint texture);
+
+       with <target> set to the desired texture target and <texture> set to
+       the unused name.  The resulting texture object is a new state vector,
+       comprising all the state values listed in section 3.8.11, set to the
+       same initial values. If the new texture object is bound to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
+       three-dimensional, cube map, one- or two-dimensional array texture
+       respectively until it is deleted.
+
+       BindTexture may also be used to bind an existing texture object to
+       either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
+       INVALID_OPERATION is generated if an attempt is made to bind a texture
+       object of different dimensionality than the specified target. If the
+       bind is successful no change is made to the state of the bound texture
+       object, and any previous binding to target is broken.
+
+       While a texture object is bound, GL operations on the target to which
+       it is bound affect the bound object, and queries of the target to which
+       it is bound return state from the bound object. If texture mapping of
+       the dimensionality of the target to which a texture object is bound is
+       enabled, the state of the bound texture object directs the texturing
+       operation.
+
+       In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
+       one-, two-, three-dimensional, cube map, and one- and two-dimensional
+       array texture state vectors respectively associated with them. In order
+       that access to these initial textures not be lost, they are treated as
+       texture objects all of whose names are 0. The initial one-, two-,
+       three-dimensional, cube map, one- and two-dimensional array textures
+       are therefore operated upon, queried, and applied as TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
+       TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
+       targets.
+
+       Change second paragraph on page 181 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "...  If a texture that is currently bound to one of the targets
+       TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
+       though BindTexture had been executed with the same target and texture
+       zero. ..."
+
+       Change second paragraph on page 182 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "The texture object name space, including the initial one-, two-, and
+       three dimensional, cube map, and one- and two-dimensional array texture
+       objects, is shared among all texture units. ..."
+
+
+    -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
+
+       Change second through fourth paragraphs (page 188) to say:
+
+       "Let D_t be the depth texture value, in the range [0, 1].  For
+       texture lookups from one- and two-dimensional, rectangle, and
+       one-dimensional array targets, let R be the interpolated <r>
+       texture coordinate, clamped to the range [0, 1].  For texture lookups
+       from two-dimensional array texture targets, let R be the interpolated
+       <q> texture coordinate, clamped to the range [0, 1].  Then the
+       effective texture value L_t, I_t, or A_t is computed as follows:
+
+       If the value of TEXTURE_COMPARE_MODE is NONE, then
+
+          r = Dt
+
+       If the value of TEXTURE_COMPARE_MODE is
+       COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
+       comparison function as shown in table 3.27."
+
+    -- Section 3.8.15 "Texture Application"
+
+       Change the first paragraph (page 189) to say:
+
+       "Texturing is enabled or disabled using the generic Enable and Disable
+       commands, respectively, with the symbolic constants TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
+       map, one-dimensional array, or two-dimensional array texture,
+       respectively.  If both two- and one-dimensional textures are enabled,
+       the two-dimensional texture is used.  If the three-dimensional and
+       either of the two- or one-dimensional textures is enabled, the
+       three-dimensional texture is used.  If the cube map texture and any of
+       the three-, two-, or one-dimensional textures is enabled, then cube map
+       texturing is used.  If one-dimensional array texture is enabled and any
+       of cube map, three-, two-, or one-dimensional textures is enabled, 
+       one-dimensional array texturing is used.  If two-dimensional array
+       texture is enabled and any of cube map, three-, two-, one-dimensional
+       textures or one-dimensional array texture is enabled, two-dimensional
+       array texturing is used..."
+
+    -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
+
+       (mostly add to existing grammar rules)
+
+       <optionName>           ::= "MESA_texture_array"
+
+       <texTarget>            ::= "1D"
+                               | "2D"
+                               | "3D"
+                               | "CUBE"
+                               | "RECT"
+                               | <arrayTarget> (if program option is present)
+                               | <shadowTarget> (if program option is present)
+
+       <arrayTarget>          ::= "ARRAY1D"
+                               | "ARRAY2D"
+
+       <shadowTarget>         ::= "SHADOW1D"
+                               | "SHADOW2D"
+                               | "SHADOWRECT"
+                               | <shadowArrayTarget> (if program option is present)
+
+       <shadowArrayTarget>    ::= "SHADOWARRAY1D"
+                               | "SHADOWARRAY2D"
+
+
+    -- Add Section 3.11.4.5.4 "Texture Stack Option"
+
+       "If a fragment program specifies the "MESA_texture_array" program
+       option, the <texTarget> rule is modified to add the texture targets
+       ARRAY1D and ARRAY2D (See Section 3.11.2)."
+
+    -- Section 3.11.6 "Fragment Program Texture Instruction Set"
+
+       (replace 1st and 2nd paragraphs with the following paragraphs)
+
+       "The first three texture instructions described below specify the
+       mapping of 4-tuple input vectors to 4-tuple output vectors.
+       The sampling of the texture works as described in section 3.8,
+       except that texture environments and texture functions are not
+       applicable, and the texture enables hierarchy is replaced by explicit
+       references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
+       rectangle, ARRAY1D, ARRAY2D).  These texture instructions specify
+       how the 4-tuple is mapped into the coordinates used for sampling.  The
+       following function is used to describe the texture sampling in the
+       descriptions below: 
+
+         vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
+                            enum texTarget);
+
+       Note that not all four components of the texture coordinates <coord>
+       are used by all texture targets.  Component usage for each <texTarget>
+       is defined in table X.
+
+                                                        coordinates used
+         texTarget          Texture Type               s t r  layer  shadow
+         ----------------   ---------------------      -----  -----  ------
+         1D                 TEXTURE_1D                 x - -    -      -
+         2D                 TEXTURE_2D                 x y -    -      -
+         3D                 TEXTURE_3D                 x y z    -      -
+         CUBE               TEXTURE_CUBE_MAP           x y z    -      -
+         RECT               TEXTURE_RECTANGLE_ARB      x y -    -      -
+         ARRAY1D            TEXTURE_1D_ARRAY_EXT       x - -    y      -
+         ARRAY2D            TEXTURE_2D_ARRAY_EXT       x y -    z      -
+         SHADOW1D           TEXTURE_1D                 x - -    -      z
+         SHADOW2D           TEXTURE_2D                 x y -    -      z
+         SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    -      z
+         SHADOWARRAY1D      TEXTURE_1D_ARRAY_EXT       x - -    y      z
+         SHADOWARRAY2D      TEXTURE_2D_ARRAY_EXT       x y -    z      w
+
+         Table X:  Texture types accessed for each of the <texTarget>, and
+         coordinate mappings.  The "coordinates used" column indicate the
+         input values used for each coordinate of the texture lookup, the
+         layer selector for array textures, and the reference value for
+         texture comparisons."
+
+    -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
+    
+       Add to the end of the section:
+       
+       "A program will fail to load if the TXP instruction is used in
+       conjunction with the SHADOWARRAY2D target."
+
+Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
+
+    -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
+
+       Add to the end of the section (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                         uint texture, int level, int layer);
+
+       operates identically to FramebufferTexture3DEXT, except that it
+       attaches a single layer of a three-dimensional texture or a one- or
+       two-dimensional array texture.  <layer> is an integer indicating the
+       layer number, and is treated identically to the <zoffset> parameter in
+       FramebufferTexture3DEXT.  The error INVALID_VALUE is generated if
+       <layer> is negative.  The error INVALID_OPERATION is generated if
+       <texture> is non-zero and is not the name of a three dimensional
+       texture or one- or two-dimensional array texture.  Unlike
+       FramebufferTexture3D, no <textarget> parameter is accepted.
+
+       If <texture> is non-zero and the command does not result in an error,
+       the framebuffer attachment state corresponding to <attachment> is
+       updated as in the other FramebufferTexture commands, except that
+       FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
+
+    -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
+
+      Add to the end of the list of completeness rules (spec changes
+      identical to EXT_texture_array):
+
+        "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
+           FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or 
+           two-dimensional array texture, then
+           FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
+           number of layers in the texture."
+
+Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
+
+    -- Section 5.4 "Display Lists"
+
+       Change the first paragraph on page 242 to say (spec changes
+       identical to EXT_texture_array):
+
+       "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
+       executed immediately when called with the corresponding proxy arguments
+       PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
+       PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
+       PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
+       PROXY_POST_CONVOLUTION_COLOR_TABLE, or
+       PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
+
+Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
+
+    -- Section 6.1.3 "Enumerated Queries"
+
+       Add after the line beginning "If the value of
+       FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
+       identical to EXT_texture_array):
+
+       "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
+       texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
+       three-dimensional texture or a one- or two-dimensional array texture,
+       then <params> will contain the number of texture layer attached to the
+       attachment point.  Otherwise, <params> will contain the value zero."
+
+    -- Section 6.1.4 "Texture Queries"
+    
+       Change the first three paragraphs (page 248) to say (spec changes
+       identical to EXT_texture_array):
+
+       "The command
+
+         void GetTexImage(enum tex, int lod, enum format,
+                          enum type, void *img);
+
+       is used to obtain texture images. It is somewhat different from the
+       other get commands; tex is a symbolic value indicating which texture
+       (or texture face in the case of a cube map texture target name) is to
+       be obtained.  TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
+       and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
+       texture, or one- or two-dimensional array texture, respectively.
+       TEXTURE_CUBE_MAP_POSITIVE_X, ...
+
+       GetTexImage obtains... from the first image to the last for
+       three-dimensional textures.  One- and two-dimensional array textures
+       are treated as two- and three-dimensional images, respectively, where
+       the layers are treated as rows or images.  These groups are then...
+
+       For three-dimensional and two-dimensional array textures, pixel storage
+       operations are applied as if the image were two-dimensional, except
+       that the additional pixel storage state values PACK_IMAGE_HEIGHT and
+       PACK_SKIP_IMAGES are applied. ..."
+
+Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Dependencies on ARB_fragment_program
+
+    If ARB_fragment_program is not supported, the changes to section 3.11
+    should be ignored.
+
+Dependencies on EXT_framebuffer_object
+
+    If EXT_framebuffer_object is not supported, the changes to section
+    3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
+
+Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
+
+    (Identical dependency as EXT_texture_array.)
+
+    S3TC texture compression is supported for two-dimensional array textures.
+    When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
+    as a compressed two-dimensional textures.  When specifying or querying
+    compressed images using one of the S3TC formats, the images are provided
+    and/or returned as a series of two-dimensional textures stored
+    consecutively in memory, with the layer closest to zero specified first.
+    For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
+    the three-dimensional compression format provided in the
+    EXT_texture_compression_vtc extension.  Pixel store parameters, including
+    those specific to three-dimensional images, are ignored when compressed
+    image data are provided or returned, as in the
+    EXT_texture_compression_s3tc extension.
+
+    S3TC compression is not supported for one-dimensional texture targets in
+    EXT_texture_compression_s3tc, and is not supported for one-dimensional
+    array textures in this extension.  If compressed one-dimensional arrays
+    are needed, use a two-dimensional texture with a height of one.
+
+    This extension allows the use of the four S3TC internal format types in
+    TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
+
+Errors
+
+    None
+
+New State
+
+    (add to table 6.15, p. 276)
+
+                                                     Initial
+    Get Value                     Type   Get Command  Value Description           Sec.    Attribute
+    ----------------------------  -----  -----------  ----- --------------------  ------  ---------
+    TEXTURE_BINDING_1D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_1D_ARRAY
+    TEXTURE_BINDING_2D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_2D_ARRAY
+
+
+New Implementation Dependent State
+
+    (add to Table 6.32, p. 293)
+
+                                                    Minimum
+    Get Value                     Type  Get Command  Value  Description         Sec.  Attribute
+    ----------------------------  ----  ----------- ------- ------------------  ----- ---------
+    MAX_TEXTURE_ARRAY_LAYERS_EXT   Z+   GetIntegerv   64    maximum number of   3.8.1     -
+                                                            layers for texture
+                                                            arrays
+
+Issues
+
+    (1) Is "texture stack" a good name for this functionality?
+
+        NO.  The name is changed to "array texture" to match the
+        nomenclature used by GL_EXT_texture_array.
+
+    (2) Should the R texture coordinate be treated as normalized or
+    un-normalized?  If it were un-normalized, floor(R) could be thought
+    of as a direct index into the array texture.  This may be more
+    convenient for applications.
+
+        RESOLVED.  All texture coordinates are normalized.  The issue of
+        un-normalized texture coordinates has been discussed in the ARB
+        before and should be left for a layered extension.
+
+        RE-RESOLVED.  The R coordinate is un-normalized.  Accessing an array
+        using [0, layers-1] coordinates is much more natural.
+
+    (3) How does LOD selection work for stacked textures?
+
+        RESOLVED.  For 2D array textures the R coordinate is ignored, and
+        the LOD selection equations for 2D textures are used.  For 1D
+        array textures the T coordinate is ignored, and the LOD selection
+        equations for 1D textures are used.  The expected usage is in a
+        fragment program with an explicit LOD selection.
+
+    (4) What is the maximum size of a 2D array texture?  Is it the same
+    as for a 3D texture, or should a new query be added?  How about for 1D
+    array textures?
+
+        RESOLVED.  A new query is added.
+
+    (5) How are array textures exposed in GLSL?
+    
+        RESOLVED.  Use GL_EXT_texture_array.
+        
+    (6) Should a 1D array texture also be exposed?
+
+        RESOLVED.  For orthogonality, yes.
+
+    (7) How are stacked textures attached to framebuffer objects?
+
+        RESOLVED.  Layers of both one- and two-dimensional array textures
+        are attached using FreambufferTextureLayerEXT.  Once attached, the
+        array texture layer behaves exactly as either a one- or
+        two-dimensional texture.
+
+    (8) How is this extension related to GL_EXT_texture_array?
+    
+        This extension adapats GL_MESAX_texture_stack to the notation,
+        indexing, and FBO access of GL_EXT_texture_array.  This extension
+        replaces the GLSL support of GL_EXT_texture_array with
+        GL_ARB_fragment_program support.
+
+        Assembly program support is also provided by GL_NV_gpu_program4.
+        GL_NV_gpu_program4 also adds support for other features that are
+        specific to Nvidia hardware, while this extension adds only support
+        for array textures.
+
+        Much of text of this extension that has changed since
+        GL_MESAX_texture_stack comes directly from either
+        GL_EXT_texture_array or GL_NV_gpu_program4.
+
+Revision History
+
+    ||2005/11/15||0.1||idr||Initial draft MESAX version.||
+    ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
+    ||2005/12/12||0.3||idr||Updated fragment program interactions.||
+    ||2007/05/16||0.4||idr||Converted to MESA_texture_array.  Brought in line with EXT_texture_array and NV_gpu_program4.||
diff --git a/mesalib/docs/specs/MESA_texture_signed_rgba.spec b/mesalib/docs/specs/MESA_texture_signed_rgba.spec
new file mode 100644
index 000000000..e3a6b59af
--- /dev/null
+++ b/mesalib/docs/specs/MESA_texture_signed_rgba.spec
@@ -0,0 +1,214 @@
+Name
+
+    MESA_texture_signed_rgba
+
+Name Strings
+
+    GL_MESA_texture_signed_rgba
+
+Contact
+
+
+
+Notice
+
+
+
+IP Status
+
+    No known IP issues
+
+Status
+
+
+
+Version
+
+    0.3, 2009-03-24
+
+Number
+
+    Not assigned ?
+
+Dependencies
+
+    Written based on the wording of the OpenGL 2.0 specification.
+
+    This extension trivially interacts with ARB_texture_float.
+    This extension shares some language with ARB_texture_compression_rgtc
+    but does not depend on it.
+
+Overview
+
+    OpenGL prior to 3.1 does not support any signed texture formats.
+    ARB_texture_compression_rgtc introduces some compressed red and
+    red_green signed formats but no uncompressed ones, which might
+    still be useful. NV_texture_shader adds signed texture formats,
+    but also a lot of functionality which has been superseded by fragment
+    shaders.
+    It is usually possible to get the same functionality
+    using a unsigned format by doing scale and bias in a shader, but this
+    is undesirable since modern hardware has direct support for this.
+    This extension adds a signed 4-channel texture format by backporting
+    the relevant features from OpenGL 3.1, as a means to support this in
+    OpenGL implementations only supporting older versions.
+
+Issues
+
+    1) What should this extension be called?
+
+       RESOLVED: MESA_texture_signed_rgba seems reasonable.
+       The rgba part is there because only 4 channel format is supported.
+
+
+    2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
+       be supported?
+
+       RESOLVED: NO. To keep this extension simple, only add the most
+       universal format, rgba. alpha/luminance can't be trivially supported
+       since OpenGL 3.1 does not support them any longer, and there is some
+       implied dependency on ARB_texture_rg for red/red_green formats so
+       avoid all this. Likewise, only 8 bits per channel is supported.
+
+
+    3) Should this extension use new enums for the texture formats?
+
+       RESOLVED: NO. Same enums as those used in OpenGL 3.1.
+
+
+    4) How are signed integer values mapped to floating-point values?
+
+       RESOLVED: Same as described in issue 5) of
+       ARB_texture_compression_rgtc (quote):
+       A signed 8-bit two's complement value X is computed to
+       a floating-point value Xf with the formula:
+
+                { X / 127.0, X > -128
+           Xf = {
+                { -1.0,      X == -128
+
+       This conversion means -1, 0, and +1 are all exactly representable,
+       however -128 and -127 both map to -1.0.  Mapping -128 to -1.0
+       avoids the numerical awkwardness of have a representable value
+       slightly more negative than -1.0.
+
+       This conversion is intentionally NOT the "byte" conversion listed
+       in Table 2.9 for component conversions.  That conversion says:
+
+           Xf = (2*X + 1) / 255.0
+
+       The Table 2.9 conversion is incapable of exactly representing
+       zero.
+
+       (Difference to ARB_texture_compression_rgtc):
+       This is the same mapping as OpenGL 3.1 uses.
+       This is also different to what NV_texture_shader used.
+       The above mapping should be considered the reference, but there
+       is some leeway so other mappings are allowed for implementations which
+       cannot do this. Particularly the mapping given in NV_texture_shader or
+       the standard OpenGL byte/float mapping is considered acceptable too, as
+       might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
+       127 (that is, uses different scale factors for negative and positive
+       numbers).
+       Also, it is ok to store incoming GL_BYTE user data as-is, without
+       converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
+       and converting back (using the mapping described here).
+       Other than those subtle issues there are no other non-standard
+       conversions used, so when using for instance CopyTexImage2D with
+       a framebuffer clamped to [0,1] all converted numbers will be in the range
+       [0, 127] (and not scaled and biased).
+
+
+    5) How will signed components resulting from RGBA8_SNORM texture
+       fetches interact with fragment coloring?
+
+       RESOLVED: Same as described in issue 6) of
+       ARB_texture_compression_rgtc (quote):
+       The specification language for this extension is silent
+       about clamping behavior leaving this to the core specification
+       and other extensions.  The clamping or lack of clamping is left
+       to the core specification and other extensions.
+
+       For assembly program extensions supporting texture fetches
+       (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
+       etc.) or the OpenGL Shading Language, these signed formats will
+       appear as expected with unclamped signed components as a result
+       of a texture fetch instruction.
+
+       If ARB_color_buffer_float is supported, its clamping controls
+       will apply.
+
+       NV_texture_shader extension, if supported, adds support for
+       fixed-point textures with signed components and relaxed the
+       fixed-function texture environment clamping appropriately.  If the
+       NV_texture_shader extension is supported, its specified behavior
+       for the texture environment applies where intermediate values
+       are clamped to [-1,1] unless stated otherwise as in the case
+       of explicitly clamped to [0,1] for GL_COMBINE.  or clamping the
+       linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
+
+       Otherwise, the conventional core texture environment clamps
+       incoming, intermediate, and output color components to [0,1].
+
+       This implies that the conventional texture environment
+       functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
+       using GLSL (and with none of the extensions referred to above)
+       is unable to make proper use of the signed texture formats added
+       by this extension because the conventional texture environment
+       requires texture source colors to be clamped to [0,1].  Texture
+       filtering of these signed formats would be still signed, but
+       negative values generated post-filtering would be clamped to
+       zero by the core texture environment functionality.  The
+       expectation is clearly that this extension would be co-implemented
+       with one of the previously referred to extensions or used with
+       GLSL for the new signed formats to be useful.
+
+
+    6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
+       functions?
+
+       RESOLVED: YES.
+
+
+    7) What to do with GetTexParameter if ARB_texture_float is supported,
+       in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
+       TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
+
+       RESOLVED: ARB_texture_float states type is either NONE,
+       UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
+       SIGNED_NORMALIZED, which will be returned accordingly. This is the
+       same behaviour as in OpenGL 3.1.
+
+
+New Tokens
+
+
+    Accepted by the <internalformat> parameter of
+    TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
+
+        RGBA_SNORM                                0x8F93
+        RGBA8_SNORM                               0x8F97
+
+    Returned by the <params> parameter of GetTexLevelParameter:
+
+        SIGNED_NORMALIZED                         0x8F9C
+
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
+
+ -- Section 3.8.1, Texture Image Specification
+
+    Add to Table 3.16 (page 154): Sized internal formats
+
+    Sized             Base             R    G    B    A    L    I    D
+    Internal Format   Internal Format bits bits bits bits bits bits bits
+    ---------------   --------------- ---- ---- ---- ---- ---- ---- ----
+    RGBA8_SNORM       RGBA             8    8    8    8    0    0    0
+
+
+Dependencies on ARB_texture_float extension:
+
+    If ARB_texture_float is supported, GetTexParameter queries with <value>
+    of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
+    TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
+    the base internal format is RGBA_SNORM.
diff --git a/mesalib/docs/specs/MESA_window_pos.spec b/mesalib/docs/specs/MESA_window_pos.spec
new file mode 100644
index 000000000..9e81e9c4d
--- /dev/null
+++ b/mesalib/docs/specs/MESA_window_pos.spec
@@ -0,0 +1,126 @@
+Name
+
+    MESA_window_pos
+
+Name Strings
+
+    GL_MESA_window_pos
+
+Contact
+
+    Brian Paul, brian.paul 'at' tungstengraphics.com
+
+Status
+
+    Shipping (since Mesa version 1.2.8)
+
+Version
+
+
+Number
+
+    197
+
+Dependencies
+
+    OpenGL 1.0 is required.
+    The extension is written against the OpenGL 1.2 Specification
+
+Overview
+
+    In order to set the current raster position to a specific window
+    coordinate with the RasterPos command, the modelview matrix, projection
+    matrix and viewport must be set very carefully.  Furthermore, if the
+    desired window coordinate is outside of the window's bounds one must
+    rely on a subtle side-effect of the Bitmap command in order to circumvent
+    frustum clipping.
+
+    This extension provides a set of functions to directly set the
+    current raster position, bypassing the modelview matrix, the
+    projection matrix and the viewport to window mapping.  Furthermore,
+    clip testing is not performed.
+
+    This greatly simplifies the process of setting the current raster
+    position to a specific window coordinate prior to calling DrawPixels,
+    CopyPixels or Bitmap.
+
+New Procedures and Functions
+
+    void WindowPos2dMESA(double x, double y)
+    void WindowPos2fMESA(float x, float y)
+    void WindowPos2iMESA(int x, int y)
+    void WindowPos2sMESA(short x, short y)
+    void WindowPos2ivMESA(const int *p)
+    void WindowPos2svMESA(const short *p)
+    void WindowPos2fvMESA(const float *p)
+    void WindowPos2dvMESA(const double *p)
+    void WindowPos3iMESA(int x, int y, int z)
+    void WindowPos3sMESA(short x, short y, short z)
+    void WindowPos3fMESA(float x, float y, float z)
+    void WindowPos3dMESA(double x, double y, double z)
+    void WindowPos3ivMESA(const int *p)
+    void WindowPos3svMESA(const short *p)
+    void WindowPos3fvMESA(const float *p)
+    void WindowPos3dvMESA(const double *p)
+    void WindowPos4iMESA(int x, int y, int z, int w)
+    void WindowPos4sMESA(short x, short y, short z, short w)
+    void WindowPos4fMESA(float x, float y, float z, float w)
+    void WindowPos4dMESA(double x, double y, double z, double )
+    void WindowPos4ivMESA(const int *p)
+    void WindowPos4svMESA(const short *p)
+    void WindowPos4fvMESA(const float *p)
+    void WindowPos4dvMESA(const double *p)
+
+New Tokens
+
+    none
+
+Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
+
+  - (2.12, p. 41) Insert after third paragraph:
+
+      Alternately, the current raster position may be set by one of the
+      WindowPosMESA commands:
+
+         void WindowPos{234}{sidf}MESA( T coords );
+         void WindowPos{234}{sidf}vMESA( T coords );
+
+      WindosPos4MESA takes four values indicating x, y, z, and w.
+      WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
+      x, y, and z with w implicitly set to 1 (or only x and y with z
+      implicitly set to 0 and w implicitly set to 1).
+
+      WindowPosMESA operates like RasterPos except that the current modelview
+      matrix, projection matrix and viewport parameters are ignored and the
+      clip test operation always passes.  The current raster position values
+      are directly set to the parameters passed to WindowPosMESA.  The current
+      color, color index and texture coordinate update the current raster
+      position's associated data.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    Not specified at this time.  However, a protocol message very similar
+    to that of RasterPos is expected.
+
+Errors
+
+    INVALID_OPERATION is generated if WindowPosMESA is called between
+    Begin and End.
+
+New State
+
+    None.
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+  * Revision 1.0 - Initial specification
+  * Revision 1.1 - Minor clean-up  (7 Jan 2000, Brian Paul)
+
diff --git a/mesalib/docs/specs/MESA_ycbcr_texture.spec b/mesalib/docs/specs/MESA_ycbcr_texture.spec
new file mode 100644
index 000000000..6a730e81c
--- /dev/null
+++ b/mesalib/docs/specs/MESA_ycbcr_texture.spec
@@ -0,0 +1,204 @@
+Name
+
+    MESA_ycbcr_texture
+
+Name Strings
+
+    GL_MESA_ycbcr_texture
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (Mesa 4.0.4 and later)
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    This extension is written against the OpenGL 1.4 Specification.
+    NV_texture_rectangle effects the definition of this extension.
+
+Overview
+
+    This extension supports texture images stored in the YCbCr format.
+    There is no support for converting YCbCr images to RGB or vice versa
+    during pixel transfer.  The texture's YCbCr colors are converted to
+    RGB during texture sampling, after-which, all the usual per-fragment
+    operations take place.  Only 2D texture images are supported (not
+    glDrawPixels, glReadPixels, etc).
+
+    A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
+    The first component is luminance (Y).  For pixels in even-numbered
+    image columns, the second component is Cb.  For pixels in odd-numbered
+    image columns, the second component is Cr.  If one were to convert the
+    data to RGB one would need to examine two pixels from columns N and N+1
+    (where N is even) to deduce the RGB color.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted by the <internalFormat> and <format> parameters of
+    TexImage2D and TexSubImage2D:
+
+        YCBCR_MESA                   0x8757
+
+    Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
+
+        UNSIGNED_SHORT_8_8_MESA      0x85BA /* same as Apple's */
+        UNSIGNED_SHORT_8_8_REV_MESA  0x85BB /* same as Apple's */
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
+    add the following to Table 3.8 (Packed pixel formats):
+    
+    type Parameter                GL Data   Number of        Matching
+     Token Name                    Type     Components     Pixel Formats
+    --------------                -------   ----------     -------------
+    UNSIGNED_SHORT_8_8_MESA       ushort         2         YCBCR_MESA
+    UNSIGNED_SHORT_8_8_REV_MESA   ushort         2         YCBCR_MESA
+
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
+    add the following to Table 3.10 (UNSIGNED_SHORT formats):
+
+    UNSIGNED_SHORT_8_8_MESA:
+
+      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+    +-------------------------------+-------------------------------+
+    |              1st              |              2nd              |
+    +-------------------------------+-------------------------------+
+                        
+    UNSIGNED_SHORT_8_8_REV_MESA:
+
+      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+    +-------------------------------+-------------------------------+
+    |              2nd              |              1st              |
+    +-------------------------------+-------------------------------+
+
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
+    add the following to Table 3.12 (Packed pixel field assignments):
+
+                       First       Second     Third      Fourth
+    Format             Element     Element    Element    Element
+    ------             -------     -------    -------    -------
+    YCBCR_MESA         luminance   chroma
+
+
+    In section 3.8.1, Texture Image Specification, on page 125, add
+    another item to the list of TexImage2D and TexImage3D equivalence
+    exceptions:
+
+    * The value of internalformat and format may be YCBCR_MESA to
+      indicate that the image data is in YCbCr format.  type must
+      be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
+      as seen in tables 3.8 and 3.10.  Table 3.12 describes the mapping
+      between Y and Cb/Cr to the components.
+      If NV_texture_rectangle is supported target may also be
+      TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
+      All pixel transfer operations are bypassed.  The texture is stored as
+      YCbCr, not RGB.  Queries of the texture's red, green and blue component
+      sizes will return zero.  The YCbCr colors are converted to RGB during
+      texture sampling using an implementation dependent conversion.
+
+
+    In section 3.8.1, Texture Image Specification, on page 126, add
+    another item to the list of TexImage1D and TexImage2D equivalence
+    exceptions:
+
+    * The value of internalformat and format can not be YCBCR_MESA.
+
+
+    In section 3.8.2, Alternate Texture Image Specification Commands, on
+    page 129, insert this paragraph after the first full paragraph on the
+    page:
+
+         "If the internal storage format of the image being updated by
+    TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
+    The error INVALID_OPERATION will be generated otherwise."
+
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    None
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    INVALID_ENUM is generated by TexImage2D if <internalFormat> is
+    MESA_YCBCR but <format> is not MESA_YCBCR.
+
+    INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
+    <internalFormat> is not MESA_YCBCR.
+
+    INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
+    <internalFormat> is MESA_YCBCR and <border> is not zero.
+
+    INVALID_OPERATION is generated by TexSubImage2D if the internal image
+    format is YCBCR_MESA and <format> is not YCBCR_MESA.
+
+    INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
+    image is YCBCR_MESA.
+    
+New State
+
+    Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
+    from n x Z42 to n x Z43 to indicate that internal format may also be
+    YCBCR_MESA.
+
+Revision History
+
+    20 September 2002 - Initial draft
+    29 April 2003 - minor updates
+     3 September 2003 - further clarify when YCbCr->RGB conversion takes place
+    19 September 2003 - a few more updates prior to submitting to extension
+                        registry.
+     3 April 2004 - fix assorted inaccuracies
diff --git a/mesalib/docs/specs/WL_bind_wayland_display.spec b/mesalib/docs/specs/WL_bind_wayland_display.spec
new file mode 100644
index 000000000..02bd6ea21
--- /dev/null
+++ b/mesalib/docs/specs/WL_bind_wayland_display.spec
@@ -0,0 +1,175 @@
+Name
+
+    WL_bind_wayland_display
+
+Name Strings
+
+    EGL_WL_bind_wayland_display
+
+Contact
+
+    Kristian Høgsberg <krh@bitplanet.net>
+    Benjamin Franzke <benjaminfranzke@googlemail.com>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 1, March 1, 2011
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Requires EGL 1.4 or later.  This extension is written against the
+    wording of the EGL 1.4 specification.
+
+    EGL_KHR_base_image is required.
+
+Overview
+
+    This extension provides entry points for binding and unbinding the
+    wl_display of a Wayland compositor to an EGLDisplay.  Binding a
+    wl_display means that the EGL implementation should provide one or
+    more interfaces in the Wayland protocol to allow clients to create
+    wl_buffer objects.  On the server side, this extension also
+    provides a new target for eglCreateImageKHR, to create an EGLImage
+    from a wl_buffer
+
+    Adding an implementation specific wayland interface, allows the
+    EGL implementation to define specific wayland requests and events,
+    needed for buffer sharing in an EGL wayland platform.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+                                       struct wl_display *display);
+
+    EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+                                         struct wl_display *display);
+
+    EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
+                                       struct wl_buffer *buffer,
+                                       EGLint attribute, EGLint *value);
+
+New Tokens
+
+    Accepted as <target> in eglCreateImageKHR
+
+        EGL_WAYLAND_BUFFER_WL                   0x31D5
+
+    Accepted in the <attrib_list> parameter of eglCreateImageKHR:
+
+        EGL_WAYLAND_PLANE_WL                    0x31D6
+
+    Possible values for EGL_TEXTURE_FORMAT:
+
+        EGL_TEXTURE_Y_U_V_WL                    0x31D7
+        EGL_TEXTURE_Y_UV_WL                     0x31D8
+        EGL_TEXTURE_Y_XUXV_WL                   0x31D9
+
+
+Additions to the EGL 1.4 Specification:
+
+    To bind a server side wl_display to an EGLDisplay, call
+
+        EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+                                           struct wl_display *display);
+
+    To unbind a server side wl_display from an EGLDisplay, call
+    
+        EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+                                             struct wl_display *display);
+
+    eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
+    wl_display bound to EGLDisplay otherwise EGL_TRUE.
+
+    eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
+    wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
+
+    A wl_buffer can have several planes, typically in case of planar
+    YUV formats.  Depending on the exact YUV format in use, the
+    compositor will have to create one or more EGLImages for the
+    various planes.  The eglQueryWaylandBufferWL function should be
+    used to first query the wl_buffer texture format using
+    EGL_TEXTURE_FORMAT as the attribute.  If the wl_buffer object is
+    not an EGL wl_buffer (wl_shm and other wayland extensions can
+    create wl_buffer objects of different types), this query will
+    return EGL_FALSE.  In that case the wl_buffer can not be used with
+    EGL and the compositor should have another way to get the buffer
+    contents.
+
+    If eglQueryWaylandBufferWL succeeds, the returned value will be
+    one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
+    EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL.  The value returned
+    describes how many EGLImages must be used, which components will
+    be sampled from each EGLImage and how they map to rgba components
+    in the shader.  The naming conventions separates planes by _ and
+    within each plane, the order or R, G, B, A, Y, U, and V indicates
+    how those components map to the rgba value returned by the
+    sampler.  X indicates that the corresponding component in the rgba
+    value isn't used.
+
+    RGB and RGBA buffer types:
+
+        EGL_TEXTURE_RGB
+                One plane, samples RGB from the texture to rgb in the
+                shader.  Alpha channel is not valid.
+
+        EGL_TEXTURE_RGBA
+                One plane, samples RGBA from the texture to rgba in the
+                shader.
+
+    YUV buffer types:
+
+        EGL_TEXTURE_Y_U_V_WL
+                Three planes, samples Y from the first plane to r in
+                the shader, U from the second plane to r, and V from
+                the third plane to r.
+
+        EGL_TEXTURE_Y_UV_WL
+                Two planes, samples Y from the first plane to r in
+                the shader, U and V from the second plane to rg.
+
+        EGL_TEXTURE_Y_XUXV_WL
+                Two planes, samples Y from the first plane to r in
+                the shader, U and V from the second plane to g and a.
+
+    After querying the wl_buffer layout, create EGLImages for the
+    planes by calling eglCreateImageKHR with wl_buffer as
+    EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
+    context.  If no attributes are given, an EGLImage will be created
+    for the first plane.  For multi-planar buffers, specify the plane
+    to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
+    attribute.  The value of the attribute is the index of the plane,
+    as defined by the buffer format.  Writing to an EGLImage created
+    from a wl_buffer in any way (such as glTexImage2D, binding the
+    EGLImage as a renderbuffer etc) will result in undefined behavior.
+
+    Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
+    EGL_HEIGHT to query the width and height of the wl_buffer.
+
+Issues
+
+Revision History
+
+    Version 1, March 1, 2011
+        Initial draft (Benjamin Franzke)
+    Version 2, July 5, 2012
+        Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
+        for different planes of planar buffer. (Kristian Høgsberg)
+    Version 3, July 10, 2012
+        Add eglQueryWaylandBufferWL and the various buffer
+        formats. (Kristian Høgsberg)
+    Version 4, July 19, 2012
+        Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
+        and just define the new YUV texture formats.  Add support for
+        EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
diff --git a/mesalib/docs/specs/enums.txt b/mesalib/docs/specs/enums.txt
new file mode 100644
index 000000000..b37768e20
--- /dev/null
+++ b/mesalib/docs/specs/enums.txt
@@ -0,0 +1,57 @@
+
+See the OpenGL ARB enum registry at http://www.opengl.org/registry/api/enum.spec
+
+Blocks allocated to Mesa:
+       0x8750-0x875F
+       0x8BB0-0x8BBF
+
+
+GL_MESA_packed_depth_stencil
+	GL_DEPTH_STENCIL_MESA            0x8750
+	GL_UNSIGNED_INT_24_8_MESA        0x8751
+	GL_UNSIGNED_INT_8_24_REV_MESA    0x8752
+	GL_UNSIGNED_SHORT_15_1_MESA      0x8753
+	GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
+
+GL_MESA_trace.spec:
+	GL_TRACE_ALL_BITS_MESA           0xFFFF
+	GL_TRACE_OPERATIONS_BIT_MESA     0x0001
+	GL_TRACE_PRIMITIVES_BIT_MESA     0x0002
+	GL_TRACE_ARRAYS_BIT_MESA         0x0004
+	GL_TRACE_TEXTURES_BIT_MESA       0x0008
+	GL_TRACE_PIXELS_BIT_MESA         0x0010
+	GL_TRACE_ERRORS_BIT_MESA         0x0020
+	GL_TRACE_MASK_MESA               0x8755
+	GL_TRACE_NAME_MESA               0x8756
+
+MESA_ycbcr_texture.spec:
+	GL_YCBCR_MESA                    0x8757
+	GL_UNSIGNED_SHORT_8_8_MESA       0x85BA /* same as Apple's */
+	GL_UNSIGNED_SHORT_8_8_REV_MESA   0x85BB /* same as Apple's */
+
+GL_MESA_pack_invert.spec
+	GL_PACK_INVERT_MESA              0x8758
+
+GL_MESA_shader_debug.spec: (obsolete)
+        GL_DEBUG_OBJECT_MESA             0x8759
+        GL_DEBUG_PRINT_MESA              0x875A
+        GL_DEBUG_ASSERT_MESA             0x875B
+
+GL_MESA_program_debug.spec: (obsolete)
+	GL_FRAGMENT_PROGRAM_CALLBACK_MESA      0x????
+	GL_VERTEX_PROGRAM_CALLBACK_MESA        0x????
+	GL_FRAGMENT_PROGRAM_POSITION_MESA      0x????
+	GL_VERTEX_PROGRAM_POSITION_MESA        0x????
+	GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x????
+	GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x????
+	GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA   0x????
+	GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA   0x????
+
+GL_MESAX_texture_stack:
+	GL_TEXTURE_1D_STACK_MESAX            0x8759
+	GL_TEXTURE_2D_STACK_MESAX            0x875A
+	GL_PROXY_TEXTURE_1D_STACK_MESAX      0x875B
+	GL_PROXY_TEXTURE_2D_STACK_MESAX      0x875C
+	GL_TEXTURE_1D_STACK_BINDING_MESAX    0x875D
+	GL_TEXTURE_2D_STACK_BINDING_MESAX    0x875E
+