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

1 files changed, 307 insertions, 0 deletions

diff --git a/mesalib/docs/relnotes/4.1 b/mesalib/docs/relnotes/4.1
new file mode 100644
index 000000000..24e9299eb
--- /dev/null
+++ b/mesalib/docs/relnotes/4.1
@@ -0,0 +1,307 @@
+
+                            Mesa 4.1 release notes
+
+                               October 29, 2002
+
+                                PLEASE READ!!!!
+
+
+
+Introduction
+------------
+
+Mesa uses an even/odd version number scheme like the Linux kernel.
+Even numbered versions (such as 4.0) designate stable releases.
+Odd numbered versions (such as 4.1) designate new developmental releases.
+
+
+New Features in Mesa 4.1
+------------------------
+
+New extensions.  Docs at http://oss.sgi.com/projects/ogl-sample/registry/
+
+GL_NV_vertex_program
+
+    NVIDIA's vertex programming extension
+
+GL_NV_vertex_program1_1
+
+    A few features built on top of GL_NV_vertex_program
+
+GL_ARB_window_pos
+
+    This is the ARB-approved version of GL_MESA_window_pos
+
+GL_ARB_depth_texture
+
+    This is the ARB-approved version of GL_SGIX_depth_texture.
+    It allows depth (Z buffer) data to be stored in textures.
+    This is used by GL_ARB_shadow
+
+GL_ARB_shadow
+
+    Shadow mapping with depth textures.
+    This is the ARB-approved version of GL_SGIX_shadow.
+
+GL_ARB_shadow_ambient
+
+    Allows one to specify the luminance of shadowed pixels.
+    This is the ARB-approved version of GL_SGIX_shadow_ambient.
+
+GL_EXT_shadow_funcs
+
+    Extends the set of GL_ARB_shadow texture comparision functions to
+    include all eight of standard OpenGL dept-test functions.
+
+GL_ARB_point_parameters
+
+    This is basically the same as GL_EXT_point_parameters.
+
+GL_ARB_texture_env_crossbar
+
+    Allows any texture combine stage to reference any texture source unit.
+
+GL_NV_point_sprite
+
+    For rendering points as textured quads.  Useful for particle effects.
+
+GL_NV_texture_rectangle  (new in 4.0.4 actually)
+
+    Allows one to use textures with sizes that are not powers of two.
+    Note that mipmapping and several texture wrap modes are not allowed.
+
+GL_EXT_multi_draw_arrays
+
+    Allows arrays of vertex arrays to be rendered with one call.
+
+GL_EXT_stencil_two_side
+
+   Separate stencil modes for front and back-facing polygons.
+
+GLX_SGIX_fbconfig & GLX_SGIX_pbuffer
+
+   Off-screen rendering support.
+
+GL_ATI_texture_mirror_once
+
+   Adds two new texture wrap modes: GL_MIRROR_CLAMP_ATI and
+   GL_MIRROR_CLAMP_TO_EDGE_ATI.
+
+
+
+Device Driver Status
+--------------------
+
+A number of Mesa's software drivers haven't been actively maintained for
+some time.  We rely on volunteers to maintain many of these drivers.
+Here's the current status of all included drivers:
+
+
+Driver			Status
+----------------------	---------------------
+XMesa (Xlib)		implements OpenGL 1.3
+OSMesa (off-screen)	implements OpenGL 1.3
+FX (3dfx Voodoo1/2)	implements OpenGL 1.3
+SVGA			implements OpenGL 1.3
+Wind River UGL		implements OpenGL 1.3
+Windows/Win32		implements OpenGL 1.3
+DOS/DJGPP		implements OpenGL 1.3
+GGI			implements OpenGL 1.3
+BeOS			needs updating (underway)
+Allegro			needs updating
+D3D			needs updating
+DOS			needs updating
+
+
+
+New features in GLUT
+--------------------
+
+1. Frames per second printing
+
+   GLUT now looks for an environment variable called "GLUT_FPS".  If it's
+   set, GLUT will print out a frames/second statistic to stderr when
+   glutSwapBuffers() is called.  By default, frames/second is computed
+   and displayed once every 5 seconds.  You can specify a different
+   interval (in milliseconds) when you set the env var.  For example
+   'export GLUT_FPS=1000' or 'setenv GLUT_FPS 1000' will set the interval
+   to one second.
+
+   NOTE: the demo or application must call the glutInit() function for
+   this to work.  Otherwise, the env var will be ignored.
+
+   Finally, this feature may not be reliable in multi-window programs.
+
+
+2. glutGetProcAddress() function
+
+   The new function:
+
+        void *glutGetProcAddress(const char *procName)
+
+   is a wrapper for glXGetProcAddressARB() and wglGetProcAddress().  It
+   lets you dynamically get the address of an OpenGL function at runtime.
+   The GLUT_API_VERSION has been bumped to 5, but I haven't bumped the
+   GLUT version number from 3.7 since that's probably Mark Kilgard's role.
+
+   This function should probably also be able to return the address of
+   GLUT functions themselves, but it doesn't do that yet.
+
+
+
+XXX Things To Do Yet XXXX
+-------------------------
+
+isosurf with vertex program exhibits some missing triangles (probably
+when recycling the vertex buffer for long prims).
+
+
+
+Porting Info
+------------
+
+If you're porting a DRI or other driver from Mesa 4.0.x to Mesa 4.1 here
+are some things to change:
+
+1. ctx->Texture._ReallyEnabled is obsolete.
+
+   Since there are now 5 texture targets (1D, 2D, 3D, cube and rect) that
+   left room for only 6 units (6*5 < 32) in this field.
+   This field is being replaced by ctx->Texture._EnabledUnits which has one
+   bit per texture unit.  If the bit k of _EnabledUnits is set, that means
+   ctx->Texture.Unit[k]._ReallyEnabled is non-zero.  You'll have to look at
+   ctx->Texture.Unit[k]._ReallyEnabled to learn if the 1D, 2D, 3D, cube or
+   rect texture is enabled for unit k.
+
+   This also means that the constants TEXTURE1_*, TEXTURE2_*, etc are
+   obsolete.
+
+   The tokens TEXTURE0_* have been replaced as well (since there's no
+   significance to the "0" part:
+
+   old token           new token
+   TEXTURE0_1D         TEXTURE_1D_BIT
+   TEXTURE0_2D         TEXTURE_2D_BIT
+   TEXTURE0_3D         TEXTURE_3D_BIT
+   TEXTURE0_CUBE       TEXTURE_CUBE_BIT
+   <none>              TEXTURE_RECT_BIT
+
+   These tokens are only used for the ctx->Texture.Unit[i].Enabled and
+   ctx->Texture.Unit[i]._ReallyEnabled fields.  Exactly 0 or 1 bits will
+   be set in _ReallyEnabled at any time!
+
+   Q: "What's the purpose of Unit[i].Enabled vs Unit[i]._ReallyEnabled?"
+   A: The user can enable GL_TEXTURE_1D, GL_TEXTURE_2D, etc for any
+      texure unit all at once (an unusual thing to do).
+      OpenGL defines priorities that basically say GL_TEXTURE_2D has
+      higher priority than GL_TEXTURE_1D, etc.  Also, just because a
+      texture target is enabled by the user doesn't mean we'll actually
+      use that texture!  If a texture object is incomplete (missing mip-
+      map levels, etc) it's as if texturing is disabled for that target.
+      The _ReallyEnabled field will have a bit set ONLY if the texture
+      target is enabled and complete.  This spares the driver writer from
+      examining a _lot_ of GL state to determine which texture target is
+      to be used.
+
+
+2. Tnl tokens changes
+
+   During the implementation of GL_NV_vertex_program some of the vertex
+   buffer code was changed.  Specifically, the VERT_* bits defined in
+   tnl/t_context.h have been renamed to better match the conventions of
+   GL_NV_vertex_program.  The old names are still present but obsolete.
+   Drivers should use the newer names.
+
+   For example:  VERT_RGBA is now VERT_BIT_COLOR0 and
+   VERT_SPEC_RGB is now VERT_BIT_COLOR1.
+
+
+
+3. Read/Draw Buffer changes
+
+   The business of setting the current read/draw buffers in Mesa 4.0.x
+   was complicated.  It's much simpler now in Mesa 4.1.
+
+   Here are the changes:
+
+   - Renamed ctx->Color.DrawDestMask to ctx->Color._DrawDestMask
+   - Removed ctx->Color.DriverDrawBuffer
+   - Removed ctx->Pixel.DriverReadBuffer
+   - Removed ctx->Color.MultiDrawBuffer
+   - Removed ctx->Driver.SetDrawBuffer()
+   - Removed swrast->Driver.SetReadBuffer().
+   - Added ctx->Color._DrawDestMask - a bitmask of FRONT/BACK_LEFT/RIGHT_BIT
+     values to indicate the current draw buffers.
+   - Added ctx->Pixel._ReadSrcMask to indicate the source for pixel reading.
+     The value is _one_ of the FRONT/BACK_LEFT/RIGHT_BIT values.
+   - Added ctx->Driver.DrawBuffer() and ctx->Driver.ReadBuffer().
+     These functions exactly correspond to glDrawBuffer and glReadBuffer calls.
+     Many drivers will set ctx->Driver.DrawBuffer = _swrast_DrawBuffer and
+     leave ctx->Draw.ReadBuffer NULL.
+     DRI drivers should implement their own function for ctx->Driver.DrawBuffer
+     and use it to set the current hardware drawing buffer.  You'll probably
+     also want to check for GL_FRONT_AND_BACK mode and fall back to software.
+     Call _swrast_DrawBuffer() too, to update the swrast state.
+   - Added swrast->Driver.SetBuffer().
+     This function should be implemented by all device drivers that use swrast.
+     Mesa will call it to specify the buffer to use for span reading AND
+     writing and point/line/triangle rendering.
+     There should be no confusion between current read or draw buffer anymore.
+   - Added swrast->CurrentBuffer to indicate which color buffer to read/draw.
+     Will be FRONT_LEFT_BIT, BACK_LEFT_BIT, FRONT_RIGHT_BIT or BACK_RIGHT_BIT.
+     This value is usually passed to swrast->Driver.SetBuffer().
+
+
+4. _mesa_create_context() changes.  This function now takes a pointer to
+   a __GLimports object.  The __GLimports structure contains function
+   pointers to system functions like fprintf(), malloc(), etc.
+   The _mesa_init_default_imports() function can be used to initialize
+   a __GLimports object.  Most device drivers (like the DRI drivers)
+   should use this.
+
+
+5. In tnl's struct vertex_buffer, the field "ProjectedClipCoords"
+   has been replaced by "NdcPtr" to better match the OpenGL spec's
+   terminology.
+
+
+6. Since GL_EXT_stencil_two_side has been implemented, many of the
+   ctx->Stencil fields are now 2-element arrays.  For example,
+   "GLenum Ref" is now "GLenum Ref[2]"  The [0] elements are the front-face
+   values and the [1] elements are the back-face values.
+   ctx->Stencil.ActiveFace is 0 or 1 to indicate the current face for
+   the glStencilOp/Func/Mask() functions.
+   ctx->Stencil.TestTwoSide controls whether or not 1 or 2-sided stenciling
+   is enabled.
+
+
+7. Removed ctx->Polygon._OffsetAny.  Removed ctx->Polygon.OffsetMRD.
+
+
+8. GLfloat / GLchan changes:
+
+   - Changed ctx->Driver.ClearColor() to take GLfloat[4] instead of GLchan[4].
+     ctx->Color.ClearColor is now GLfloat[4] too.
+   - Changed ctx->Driver.AlphaRef() to take GLfloat instead of GLchan.
+   - ctx->Color.AlphaRef is now GLfloat.
+   - texObj->BorderColor is now GLfloat[4].  texObj->_BorderChan is GLchan[4].
+
+   This is part of an effort to remove all GLchan types from core Mesa so
+   that someday we can support 8, 16 and 32-bit color channels dynamically
+   at runtime, instead of at compile-time.
+
+
+9. GLboolean ctx->Tranform.ClipEnabled[MAX_CLIP_PLANES] has been replaced
+   by GLuint ctx->Transform.ClipPlanesEnabled.  The later is a bitfield.
+
+
+10. There's a new matrix_stack type in mtypes.h used for the Modelview,
+   Projection, Color and Texcoord matrix stacks.
+
+
+11. The ctx->Current.* fields have changed a lot.  Now, there's a
+   ctx->Current.Attrib[] array for all vertex attributes which matches
+   the NV vertex program conventions.
+
+
+----------------------------------------------------------------------