Merge remote-tracking branch 'origin/released'

* origin/released:
  libX11 mesa git update 18 Mar 2013
  fontconfig libX11 mesa pixman xserver xkeyboard-config git update 11 Mar 2013

3 files changed, 54 insertions, 42 deletions

diff --git a/mesalib/docs/devinfo.html b/mesalib/docs/devinfo.html
index d64171aee..c89bfc02e 100644
--- a/mesalib/docs/devinfo.html
+++ b/mesalib/docs/devinfo.html
@@ -200,8 +200,6 @@ branch is relevant.
   <dd>PACKAGE_VERSION</dd>
   <dt>configure.ac</dt>
   <dd>AC_INIT</dd>
-  <dt>src/mesa/main/version.h</dt>
-  <dd>MESA_MAJOR, MESA_MINOR, MESA_PATCH and MESA_VERSION_STRING</dd>
 </dl>
 
 <p>
diff --git a/mesalib/docs/osmesa.html b/mesalib/docs/osmesa.html
index b0609cf88..848754570 100644
--- a/mesalib/docs/osmesa.html
+++ b/mesalib/docs/osmesa.html
@@ -18,77 +18,62 @@
 
 
 <p>
-Mesa's off-screen rendering interface is used for rendering into
-user-allocated blocks of memory.
+Mesa's off-screen interface is used for rendering into user-allocated memory
+without any sort of window system or operating system dependencies.
 That is, the GL_FRONT colorbuffer is actually a buffer in main memory,
 rather than a window on your display.
-There are no window system or operating system dependencies.
-One potential application is to use Mesa as an off-line, batch-style renderer.
 </p>
 
 <p>
-The <b>OSMesa</b> API provides three basic functions for making off-screen
+The OSMesa API provides three basic functions for making off-screen
 renderings: OSMesaCreateContext(), OSMesaMakeCurrent(), and
 OSMesaDestroyContext().  See the Mesa/include/GL/osmesa.h header for
 more information about the API functions.
 </p>
 
 <p>
-There are several examples of OSMesa in the mesa/demos repository.
+The OSMesa interface may be used with any of three software renderers:
 </p>
+<ol>
+<li>llvmpipe - this is the high-performance Gallium LLVM driver
+<li>softpipe - this it the reference Gallium software driver
+<li>swrast - this is the legacy Mesa software rasterizer
+</ol>
 
 
-<h2>Deep color channels</h2>
-
 <p>
-For some applications 8-bit color channels don't have sufficient
-precision.
-OSMesa supports 16-bit and 32-bit color channels through the OSMesa interface.
-When using 16-bit channels, channels are GLushorts and RGBA pixels occupy
-8 bytes.
-When using 32-bit channels, channels are GLfloats and RGBA pixels occupy
-16 bytes.
+There are several examples of OSMesa in the mesa/demos repository.
 </p>
 
-<p>
-Before version 6.5.1, Mesa had to be recompiled to support exactly
-one of 8, 16 or 32-bit channels.
-With Mesa 6.5.1, Mesa can be compiled for either 8, 16 or 32-bit channels
-and render into any of the smaller size channels.
-For example, if Mesa's compiled for 32-bit channels, you can also render
-16 and 8-bit channel images.
-</p>
+<h1>Building OSMesa</h1>
 
 <p>
-To build Mesa/OSMesa for 16 and 8-bit color channel support:
+Configure and build Mesa with something like:
+
 <pre>
-      make realclean
-      make linux-osmesa16
+configure --enable-osmesa --disable-driglx-direct --disable-dri --with-gallium-drivers=swrast
+make
 </pre>
 
 <p>
-To build Mesa/OSMesa for 32, 16 and 8-bit color channel support:
-<pre>
-      make realclean
-      make linux-osmesa32
-</pre>
+Make sure you have LLVM installed first if you want to use the llvmpipe driver.
+</p>
 
 <p>
-You'll wind up with a library named libOSMesa16.so or libOSMesa32.so.
-Otherwise, most Mesa configurations build an 8-bit/channel libOSMesa.so library
-by default.
+When the build is complete you should find:
 </p>
+<pre>
+lib/libOSMesa.so  (swrast-based OSMesa)
+lib/gallium/libOSMsea.so  (gallium-based OSMesa)
+</pre>
 
 <p>
-If performance is important, compile Mesa for the channel size you're
-most interested in.
+Set your LD_LIBRARY_PATH to point to one directory or the other to select
+the library you want to use.
 </p>
 
 <p>
-If you need to compile on a non-Linux platform, copy Mesa/configs/linux-osmesa16
-to a new config file and edit it as needed.  Then, add the new config name to
-the top-level Makefile.  Send a patch to the Mesa developers too, if you're
-inclined.
+When you link your application, link with -lOSMesa
 </p>
 
 </div>
diff --git a/mesalib/docs/viewperf.html b/mesalib/docs/viewperf.html
index ab2fd67ef..3bbe1978a 100644
--- a/mesalib/docs/viewperf.html
+++ b/mesalib/docs/viewperf.html
@@ -203,6 +203,35 @@ This causes the object in question to be drawn in a strange orientation
 and with a semi-random color (between white and black) since GL_FOG is enabled.
 </p>
 
+
+<h2>Proe-05 test 1</h2>
+
+<p>
+This uses depth testing but there's two problems:
+<ol>
+<li>The glXChooseFBConfig() call doesn't request a depth buffer
+<li>The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer
+</ol>
+<p>
+If the chosen visual does not have a depth buffer, you'll see the wireframe
+car model but it won't be rendered correctly.
+</p>
+If (by luck) the chosen visual has a depth buffer, its initial contents
+will be undefined so you may or may not see parts of the model.
+<p>
+Interestingly, with NVIDIA's driver most visuals happen to have a depth buffer
+and apparently the contents are initialized to 1.0 by default so this test
+just happens to work with their drivers.
+</p>
+
+<p>
+Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT)
+calls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
+the problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when
+glClear is called so clearing the depth buffer would be a no-op anyway.
+</p>
+
+
 </div>
 </body>
 </html>