Merge head into branch

broken?

.dir-locals.el

@@ -1,11 +0,0 @@
-((nil
-  (indent-tabs-mode . nil)
-  (tab-width . 8)
-  (c-basic-offset . 3)
-  (c-file-style . "stroustrup")
-  (fill-column . 78)
-  (eval . (progn
-	    (c-set-offset 'innamespace '0)
-	    (c-set-offset 'inline-open '0)))
-  )
- )

.gitattributes

@@ -1,4 +0,0 @@
-*.dsp -crlf
-*.dsw -crlf
-*.sln -crlf
-*.vcproj -crlf

.gitignore

@@ -1,43 +0,0 @@
-*.a
-*.dll
-*.exe
-*.ilk
-*.la
-*.lo
-*.o
-*.obj
-*.os
-*.pc
-*.pdb
-*.pyc
-*.pyo
-*.so
-*.so.*
-*.sw[a-z]
-*.tar
-*.tar.bz2
-*.tar.gz
-*.zip
-*~
-depend
-depend.bak
-bin/ltmain.sh
-lib
-lib64
-configure
-configure.lineno
-autom4te.cache
-aclocal.m4
-config.log
-config.status
-cscope*
-.scon*
-config.py
-build
-libtool
-manifest.txt
-Makefile.in
-.dir-locals.el
-.deps/
-.libs/
-/Makefile

Android.common.mk

@@ -1,65 +0,0 @@
-# Mesa 3-D graphics library
-#
-# Copyright (C) 2010-2011 Chia-I Wu <olvaffe@gmail.com>
-# Copyright (C) 2010-2011 LunarG Inc.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included
-# in all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-# use c99 compiler by default
-ifeq ($(LOCAL_CC),)
-ifeq ($(LOCAL_IS_HOST_MODULE),true)
-LOCAL_CC := $(HOST_CC) -std=c99
-else
-LOCAL_CC := $(TARGET_CC) -std=c99
-endif
-endif
-
-LOCAL_C_INCLUDES += \
-	$(MESA_TOP)/include
-
-# define ANDROID_VERSION (e.g., 4.0.x => 0x0400)
-major := $(word 1, $(subst ., , $(PLATFORM_VERSION)))
-minor := $(word 2, $(subst ., , $(PLATFORM_VERSION)))
-LOCAL_CFLAGS += \
-	-DANDROID_VERSION=0x0$(major)0$(minor)
-
-LOCAL_CFLAGS += \
-	-DHAVE_PTHREAD=1 \
-	-fvisibility=hidden \
-	-Wno-sign-compare
-
-ifeq ($(strip $(MESA_ENABLE_ASM)),true)
-ifeq ($(TARGET_ARCH),x86)
-LOCAL_CFLAGS += \
-	-DUSE_X86_ASM \
-	-DHAVE_DLOPEN \
-
-endif
-endif
-
-LOCAL_CPPFLAGS += \
-	-Wno-error=non-virtual-dtor \
-	-Wno-non-virtual-dtor
-
-# uncomment to keep the debug symbols
-#LOCAL_STRIP_MODULE := false
-
-ifeq ($(strip $(LOCAL_MODULE_TAGS)),)
-LOCAL_MODULE_TAGS := optional
-endif

Android.mk

@@ -1,94 +0,0 @@
-# Mesa 3-D graphics library
-#
-# Copyright (C) 2010-2011 Chia-I Wu <olvaffe@gmail.com>
-# Copyright (C) 2010-2011 LunarG Inc.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included
-# in all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-# BOARD_GPU_DRIVERS should be defined.  The valid values are
-#
-#   classic drivers: i915 i965
-#   gallium drivers: swrast i915g nouveau r300g r600g radeonsi vmwgfx
-#
-# The main target is libGLES_mesa.  For each classic driver enabled, a DRI
-# module will also be built.  DRI modules will be loaded by libGLES_mesa.
-
-MESA_TOP := $(call my-dir)
-MESA_COMMON_MK := $(MESA_TOP)/Android.common.mk
-MESA_PYTHON2 := python
-
-DRM_TOP := external/drm
-DRM_GRALLOC_TOP := hardware/drm_gralloc
-
-classic_drivers := i915 i965
-gallium_drivers := swrast i915g nouveau r300g r600g radeonsi vmwgfx
-
-MESA_GPU_DRIVERS := $(strip $(BOARD_GPU_DRIVERS))
-
-# warn about invalid drivers
-invalid_drivers := $(filter-out \
-	$(classic_drivers) $(gallium_drivers), $(MESA_GPU_DRIVERS))
-ifneq ($(invalid_drivers),)
-$(warning invalid GPU drivers: $(invalid_drivers))
-# tidy up
-MESA_GPU_DRIVERS := $(filter-out $(invalid_drivers), $(MESA_GPU_DRIVERS))
-endif
-
-# host and target must be the same arch to generate matypes.h
-ifeq ($(TARGET_ARCH),$(HOST_ARCH))
-MESA_ENABLE_ASM := true
-else
-MESA_ENABLE_ASM := false
-endif
-
-ifneq ($(filter $(classic_drivers), $(MESA_GPU_DRIVERS)),)
-MESA_BUILD_CLASSIC := true
-else
-MESA_BUILD_CLASSIC := false
-endif
-
-ifneq ($(filter $(gallium_drivers), $(MESA_GPU_DRIVERS)),)
-MESA_BUILD_GALLIUM := true
-else
-MESA_BUILD_GALLIUM := false
-endif
-
-# add subdirectories
-ifneq ($(strip $(MESA_GPU_DRIVERS)),)
-
-SUBDIRS := \
-	src/mapi \
-	src/glsl \
-	src/mesa \
-	src/egl/main
-
-ifeq ($(strip $(MESA_BUILD_CLASSIC)),true)
-SUBDIRS += \
-	src/egl/drivers/dri2 \
-	src/mesa/drivers/dri
-endif
-
-ifeq ($(strip $(MESA_BUILD_GALLIUM)),true)
-SUBDIRS += src/gallium
-endif
-
-mkfiles := $(patsubst %,$(MESA_TOP)/%/Android.mk,$(SUBDIRS))
-include $(mkfiles)
-
-endif

Makefile.DJ

@@ -0,0 +1,108 @@
+# Mesa 3-D graphics library
+# Version:  4.0
+# 
+# Copyright (C) 1999  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+# DOS/DJGPP makefile v1.4 for Mesa
+#
+#  Copyright (C) 2002 - Borca Daniel
+#  Email : dborca@users.sourceforge.net
+#  Web   : http://www.geocities.com/dborca
+
+
+#
+#  Available options:
+#
+#    Environment variables:
+#	CPU		optimize for the given processor.
+#			default = pentium
+#	GLU=[mesa|sgi]	specify GLU directory; can be `sgi' (requires GNU/C++)
+#			or `mesa'.
+#			default = mesa
+#	GLIDE		path to Glide3 SDK; used with FX.
+#			default = $(TOP)/glide3
+#	FX=1		build for 3dfx Glide3. Note that this disables
+#			compilation of most DMesa code and requires fxMesa.
+#			As a consequence, you'll need the DJGPP Glide3
+#			library to build any application.
+#			default = no
+#	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.
+#			This is experimental and not intensively tested.
+#			default = no
+#	HAVE_X86=1	optimize for i386.
+#			default = no
+#	HAVE_MMX=1	allow MMX specializations, provided your assembler
+#			supports MMX instruction set. However, the true CPU
+#			capabilities are checked at run-time to avoid crashes.
+#			default = no
+#	HAVE_SSE=1	(see HAVE_MMX)
+#			default = no
+#	HAVE_3DNOW=1	(see HAVE_MMX)
+#			default = no
+#
+#    Targets:
+#	all:		build everything
+#	libgl:		build GL
+#	libglu:		build GLU
+#	libglut:	build GLUT
+#	clean:		remove object files
+#	realclean:	remove all generated files
+#
+
+
+
+.PHONY : all libgl libglu libglut clean realclean
+
+CPU ?= pentium
+
+GLU ?= mesa
+
+CFLAGS = -Wall -W -pedantic
+CFLAGS += -O2 -ffast-math -mcpu=$(CPU)
+
+export CFLAGS
+
+ifeq ($(wildcard $(addsuffix /rm.exe,$(subst ;, ,$(PATH)))),)
+UNLINK = del $(subst /,\,$(1))
+else
+UNLINK = $(RM) $(1)
+endif
+
+all: libgl libglu libglut
+
+libgl: lib
+	$(MAKE) -f Makefile.DJ -C src/mesa
+libglu: lib
+	$(MAKE) -f Makefile.DJ -C src/glu/$(GLU)
+libglut: lib
+	$(MAKE) -f Makefile.DJ -C src/glut/dos
+
+lib:
+	mkdir lib
+
+clean:
+	$(MAKE) -f Makefile.DJ clean -C src/mesa
+	$(MAKE) -f Makefile.DJ clean -C src/glu/mesa
+	$(MAKE) -f Makefile.DJ clean -C src/glu/sgi
+	$(MAKE) -f Makefile.DJ clean -C src/glut/dos
+
+realclean: clean
+	-$(call UNLINK,lib/*.a)
+	-$(call UNLINK,lib/*.dxe)

Makefile.X11

@@ -0,0 +1,622 @@
+# $Id: Makefile.X11,v 1.89.2.1 2003/11/24 12:01:39 keithw Exp $
+
+# Mesa 3-D graphics library
+# Version:  5.1
+# 
+# Copyright (C) 1999-2003  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+
+# Top-level makefile for Mesa
+# To add a new configuration for your system add it to the list below
+# then update the Make-config file.
+
+SHELL = /bin/sh
+
+
+
+default:
+	@echo "Type one of the following:"
+	@echo "  make aix                   for IBM RS/6000 with AIX"
+	@echo "  make aix-sl                for IBM RS/6000, make shared libs"
+	@echo "  make beos-r4               for BeOS R4"
+	@echo "  make cygnus                for Win95/NT using Cygnus-Win32"
+	@echo "  make cygnus-linux          for Win95/NT using Cygnus-Win32 under Linux"
+	@echo "  make darwin                for Darwin - Mac OS X"
+	@echo "  make freebsd               for FreeBSD systems with GCC"
+	@echo "  make freebsd-386           for FreeBSD systems with GCC, w/ Intel assembly"
+	@echo "  make gcc-sl                for a generic system with GCC for shared libs"
+	@echo "  make hpux9                 for HP systems with HPUX 9.x"
+	@echo "  make hpux9-sl              for HP systems with HPUX 9.x, make shared libs"
+	@echo "  make hpux9-gcc             for HP systems with HPUX 9.x using GCC"
+	@echo "  make hpux9-gcc-sl          for HP systems with HPUX 9.x, GCC, make shared libs"
+	@echo "  make hpux10                for HP systems with HPUX 10.x and 11.x"
+	@echo "  make hpux10-sl             for HP systems with HPUX 10.x and 11.x, shared libs"
+	@echo "  make hpux10-gcc            for HP systems with HPUX 10.x w/ GCC"
+	@echo "  make hpux10-gcc-sl         for HP systems with HPUX 10.x w/ GCC, shared libs"
+	@echo "  make irix6-o32             for SGI systems with IRIX 6.x, make o32-bit libs"
+	@echo "  make irix6-o32-dso         for SGI systems with IRIX 6.x, make o32-bit DSOs"
+	@echo "  make irix6-n32             for SGI systems with IRIX 6.x, make n32-bit libs"
+	@echo "  make irix6-n32-dso         for SGI systems with IRIX 6.x, make n32-bit DSOs"
+	@echo "  make irix6-gcc-n32-sl      for SGI systems with IRIX 6.x, GCC, make n32 DSOs"
+	@echo "  make irix6-64              for SGI systems with IRIX 6.x, make 64-bit libs"
+	@echo "  make irix6-64-dso          for SGI systems with IRIX 6.x, make 64-bit DSOs"
+
+	@echo "  make linux                 for Linux"
+	@echo "  make linux-x86             for Linux with x86 optimizations"
+	@echo "  make linux-ggi             for Linux with libggi driver"
+	@echo "  make linux-x86-ggi         for Linux with libggi driver and x86 optimizations"
+	@echo "  make linux-glide           for Linux with 3Dfx Glide driver"
+	@echo "  make linux-x86-glide       for Linux with 3Dfx Glide driver and x86 opts"
+	@echo "  make linux-alpha           for Linux with Alpha optimizations"
+	@echo "  make linux-alpha-static    for Linux with Alpha opts, make static libs"
+	@echo "  make linux-ppc             for Linux with PowerPC opts"
+	@echo "  make linux-ppc-static      for Linux with PowerPC opts, make static libs"
+	@echo "  make linux-sparc           for Linux with Sparc optimzations"
+	@echo "  make linux-sparc5          for Linux with Sparc5 optimizations"
+	@echo "  make linux-sparc-ultra     for Linux with UltraSparc optimizations"
+	@echo "  make linux-osmesa16        for 16-bit/channel OSMesa"
+	@echo "  make linux-osmesa16-static for 16-bit/channel OSMesa, make static libs"
+	@echo "  make linux-osmesa32        for 32-bit/channel OSMesa"
+	@echo "  make linux-solo            for Linux standalone with dri drivers"
+	@echo "  make linux-icc             for Linux with the Intel C/C++ compiler"
+	@echo "  make lynxos                for LynxOS systems with GCC"
+	@echo "  make mklinux               for Linux on Power Macintosh"
+	@echo "  make netbsd                for NetBSD 1.0 systems with GCC"
+	@echo "  make openbsd               for OpenBSD systems"
+	@echo "  make openstep              for OpenStep/MacOSX Server systems"
+	@echo "  make osf1                  for DEC Alpha systems with OSF/1"
+	@echo "  make qnx                   for QNX V4 systems with Watcom compiler"
+	@echo "  make solaris-x86           for PCs with Solaris"
+	@echo "  make solaris-x86-gcc       for PCs with Solaris using GCC"
+	@echo "  make sunos4                for Suns with SunOS 4.x"
+	@echo "  make sunos4-sl             for Suns with SunOS 4.x, make shared libs"
+	@echo "  make sunos4-gcc            for Suns with SunOS 4.x and GCC"
+	@echo "  make sunos4-gcc-sl         for Suns with SunOS 4.x, GCC, make shared libs"
+	@echo "  make sunos5                for Suns with SunOS 5.x"
+	@echo "  make sunos5-smp            for Suns with SunOS 5.x, SMP optimization"
+	@echo "  make sunos5-gcc            for Suns with SunOS 5.x and GCC"
+	@echo "  make ultrix-gcc            for DEC systems with Ultrix and GCC"
+	@echo "  make unixware              for PCs running UnixWare"
+	@echo "  make unixware-shared       for PCs running UnixWare, shared libs"
+	@echo "  make clean                 remove .o files"
+	@echo "  make realclean             remove .o, library and executable files"
+
+
+
+# XXX we may have to split up this group of targets into those that
+# have a C++ compiler and those that don't for the SI-GLU library.
+
+aix aix-sl darwin freebsd freebsd-386 gcc-sl \
+hpux9 hpux9-sl hpux9-gcc hpux9-gcc-sl \
+hpux10 hpux10-sl hpux10-gcc hpux10-gcc-sl \
+linux linux-debug \
+linux-x86 linux-x86-sse linux-icc linux-x86-static linux-x86-debug \
+linux-glide linux-x86-glide linux-glide-debug \
+linux-alpha-static linux-alpha \
+linux-ppc-static linux-ppc \
+linux-sparc linux-sparc5 linux-sparc-ultra \
+mklinux netbsd osf1 openbsd qnx \
+solaris-x86 solaris-x86-gcc \
+sunos4 sunos4-sl sunos4-gcc sunos4-gcc-sl sunos4-gcc-x11r6-sl \
+sunos5 sunos5-smp sunos5-gcc \
+ultrix-gcc unixware:
+	-mkdir lib
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glu/sgi  ] ; then touch src/glu/sgi/depend  ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw      ] ; then touch src/glw/depend      ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx  ] ; then cd src/glut/glx  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw       ] ; then cd src/glw       ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+gcc-mesa-sl:
+	if [ -d src ] ; then cd src  ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+irix6-o32 irix6-o32-dso irix6-n32 irix6-n32-dso irix6-gcc-n32-sl:
+	-mkdir lib32
+	if [ -d src/mesa      ] ; then touch src/mesa/depend      ; fi
+	if [ -d src/glu/sgi   ] ; then touch src/glu/sgi/depend   ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw ] ; then touch src/glw/depend ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx ] ; then cd src/glut/glx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos    ] ; then cd progs/demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos   ] ; then cd progs/xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples  ] ; then cd progs/samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook     ] ; then cd progs/redbook     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(MAKE) -f Makefile.X11 $@ ; fi
+
+irix6-64 irix6-64-dso:
+	-mkdir lib64
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glu/sgi  ] ; then touch src/glu/sgi/depend  ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw      ] ; then touch src/glw/depend      ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx  ] ; then cd src/glut/glx  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(MAKE) -f Makefile.X11 $@ ; fi
+
+
+beos-r4:
+	-mkdir lib
+	-rm src/mesa/depend
+	touch src/mesa/depend
+	-rm src/glu/sgi/depend
+	touch src/glu/sgi/depend
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glut/beos ] ; then cd src/glut/beos ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glut/beos ] ; then cp src/glut/beos/obj*/libglut.so lib  ; fi
+	if [ -d progs/beos    ] ; then cd progs/beos    ; $(MAKE)                        ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+
+cygnus cygnus-linux:
+	-mkdir lib
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src/mesa     ] ; then cd src/mesa     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi  ] ; then cd src/glu/sgi  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx ] ; then cd src/glut/glx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos  ] ; then cd progs/demos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos ] ; then cd progs/xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw      ] ; then cd src/glw      ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+openstep:
+	-mkdir lib
+	cd src/mesa    ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+	cd src/glu/sgi ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+
+linux-ggi linux-x86-ggi:
+	-mkdir lib
+	touch src/depend
+	touch src/glu/sgi/depend
+	if [ -d src/glut/glx    ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw         ] ; then touch src/glw/depend ; fi
+	if [ -d src/mesa        ] ; then cd src            ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi     ] ; then cd src/glu/sgi    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx    ] ; then cd src/glut/glx   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d ggi/demos       ] ; then cd ggi/demos      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos     ] ; then cd progs/demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos    ] ; then cd progs/xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples   ] ; then cd progs/samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook   ] ; then cd progs/redbook  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(MAKE) -f Makefile.X11 $@ ; fi
+
+# if you change GGI_DEST please change it in ggimesa.conf, too.
+DESTDIR=/usr/local
+GGI_DEST=lib/ggi/mesa
+
+linux-ggi-install linux-x86-ggi-install:
+	install -d $(DESTDIR)/$(GGI_DEST)/default $(DESTDIR)/$(GGI_DEST)/display $(DESTDIR)/etc/ggi
+	install -m 0755 src/GGI/default/*.so $(DESTDIR)/$(GGI_DEST)/default
+	install -m 0755 src/GGI/display/*.so $(DESTDIR)/$(GGI_DEST)/display
+	install -m 0644 src/GGI/ggimesa.conf $(DESTDIR)/etc/ggi
+#	if [ -z "`grep ggimesa $(DESTDIR)/etc/ggi/libggi.conf`" ]; then \
+#	echo ".include $(DESTDIR)/etc/ggi/ggimesa.conf" >> $(DESTDIR)/etc/ggi/libggi.conf ; \
+#	fi
+
+linux-osmesa16 linux-osmesa16-static linux-osmesa32:
+	-mkdir lib
+	if [ -d src/mesa ] ; then touch src/mesa/depend ; fi
+	if [ -d src/mesa ] ; then cd src/mesa ; $(MAKE) -f Makefile.OSMesa16 $@ ; fi
+
+linux-solo:
+	-mkdir lib
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glx/mini ] ; then touch src/glx/mini/depend  ; fi
+	if [ -d src/glu/mini ] ; then touch src/glu/mini/depend  ; fi
+	if [ -d src/glut/mini ] ; then touch src/glut/mini/depend  ; fi
+	if [ -d src/mesa/drivers/dri/r200 ] ; then touch src/mesa/drivers/dri/r200/depend ; fi
+	if [ -d src/mesa/drivers/dri/r128 ] ; then touch src/mesa/drivers/dri/r128/depend ; fi
+	if [ -d src/mesa/drivers/dri/radeon ] ; then touch src/mesa/drivers/dri/radeon/depend ; fi
+	if [ -d src/mesa/drivers/dri/mga ] ; then touch src/mesa/drivers/dri/mga/depend ; fi
+	if [ -d src/mesa/drivers/dri/i810 ] ; then touch src/mesa/drivers/dri/i810/depend ; fi
+	if [ -d src/mesa/drivers/dri/i830 ] ; then touch src/mesa/drivers/dri/i830/depend ; fi
+	if [ -d src/mesa/drivers/dri/sis ] ; then touch src/mesa/drivers/dri/sis/depend ; fi
+	if [ -d src/mesa/drivers/dri/gamma ] ; then touch src/mesa/drivers/dri/gamma/depend ; fi
+	if [ -d src/mesa/drivers/dri/fb ] ; then touch src/mesa/drivers/dri/fb/depend ; fi
+	if [ -d src/glut/mini ] ; then touch src/glut/mini/depend ; fi
+	if [ -d progs/miniglx ] ; then touch progs/miniglx/depend ; fi
+	if [ -d progs/tests ] ; then touch progs/tests/depend ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/r200 ] ; then cd src/mesa/drivers/dri/r200     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/r128 ] ; then cd src/mesa/drivers/dri/r128     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/radeon ] ; then cd src/mesa/drivers/dri/radeon ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/mga ] ; then cd src/mesa/drivers/dri/mga       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/i810 ] ; then cd src/mesa/drivers/dri/i810       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/i830 ] ; then cd src/mesa/drivers/dri/i830       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/sis ] ; then cd src/mesa/drivers/dri/sis       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/gamma ] ; then cd src/mesa/drivers/dri/gamma       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/fb ] ; then cd src/mesa/drivers/dri/fb         ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glx/mini  ] ; then cd src/glx/mini  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/mini  ] ; then cd src/glu/mini  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/mini ] ; then cd src/glut/mini ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/miniglx ] ; then cd progs/miniglx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/tests   ] ; then cd progs/tests   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+# Remove .o files, emacs backup files, etc.
+clean:
+	if ! [ -f src/mesa/depend      ] ; then touch src/mesa/depend      ; fi
+	if ! [ -f src/mesa/drivers/dri/r200/depend ];   then touch src/mesa/drivers/dri/r200/depend;   fi
+	if ! [ -f src/mesa/drivers/dri/r128/depend ];   then touch src/mesa/drivers/dri/r128/depend;   fi
+	if ! [ -f src/mesa/drivers/dri/radeon/depend ]; then touch src/mesa/drivers/dri/radeon/depend; fi
+	if ! [ -f src/mesa/drivers/dri/mga/depend ];    then touch src/mesa/drivers/dri/mga/depend;    fi
+	if ! [ -f src/mesa/drivers/dri/fb/depend ];     then touch src/mesa/drivers/dri/fb/depend;     fi
+	if ! [ -f src/glu/mesa/depend  ] ; then touch src/glu/mesa/depend  ; fi
+	if ! [ -f src/glu/sgi/depend   ] ; then touch src/glu/sgi/depend   ; fi
+	if ! [ -f src/glu/mini/depend  ] ; then touch src/glu/mini/depend  ; fi
+	if ! [ -f src/glut/glx/depend  ] ; then touch src/glut/glx/depend  ; fi
+	if ! [ -f src/glut/mini/depend ] ; then touch src/glut/mini/depend ; fi
+	if ! [ -f src/glx/mini/depend  ] ; then touch src/glx/mini/depend  ; fi
+	if ! [ -f progs/tests/depend   ] ; then touch progs/tests/depend   ; fi
+	if ! [ -f progs/miniglx/depend ] ; then touch progs/miniglx/depend ; fi
+	-rm -f include/GL/*~
+	cd src/mesa          && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/r200   && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/r128   && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/radeon && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/mga    && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/fb     && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/mesa      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/sgi       && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/mini      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glut/glx      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glut/mini     && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glw           && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glx/mini      && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/demos       && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/redbook     && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/xdemos      && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/samples     && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/tests       && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/miniglx     && $(MAKE) -f Makefile.X11 $@ || true
+	if [ -f src/mesa/depend      ] ; then rm src/mesa/depend      ; fi
+	if [ -f src/mesa/drivers/dri/r200/depend ];   then rm -f src/mesa/drivers/dri/r200/depend;   fi
+	if [ -f src/mesa/drivers/dri/r128/depend ];   then rm -f src/mesa/drivers/dri/r128/depend;   fi
+	if [ -f src/mesa/drivers/dri/radeon/depend ]; then rm -f src/mesa/drivers/dri/radeon/depend; fi
+	if [ -f src/mesa/drivers/dri/mga/depend ];    then rm -f src/mesa/drivers/dri/mga/depend;    fi
+	if [ -f src/mesa/drivers/dri/fb/depend ];     then rm -f src/mesa/drivers/dri/fb/depend;     fi
+	if [ -f src/glu/mesa/depend  ] ; then rm -f src/glu/mesa/depend  ; fi
+	if [ -f src/glu/sgi/depend   ] ; then rm -f src/glu/sgi/depend   ; fi
+	if [ -f src/glu/mini/depend  ] ; then rm -f src/glu/mini/depend  ; fi
+	if [ -f src/glut/glx/depend  ] ; then rm -f src/glut/glx/depend  ; fi
+	if [ -f src/glut/mini/depend ] ; then rm -f src/glut/mini/depend ; fi
+	if [ -f src/glx/mini/depend  ] ; then rm -f src/glx/mini/depend  ; fi
+	if [ -f progs/tests/depend   ] ; then rm -f progs/tests/depend   ; fi
+	if [ -f progs/miniglx/depend ] ; then rm -f progs/miniglx/depend ; fi
+
+# Remove everything that can be remade
+realclean: clean
+	-rm -fr lib lib32 lib64
+	cd progs/demos       && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/xdemos      && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/redbook     && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/samples     && $(MAKE) -f Makefile.X11 realclean || true
+
+# Remove everything not in CVS
+cvsclean: realclean
+	-rm -f acinclude.m4 aclocal.m4
+	-rm -f conf.h conf.h.in config.guess config.log config.status
+	-rm -f config.sub configure
+	-rm -f install-sh libtool ltmain.sh Makefile.in
+	-rm -f missing mkinstalldirs stamp-h stamp-h.in
+
+
+
+
+DIRECTORY = Mesa-5.1
+LIB_NAME = MesaLib-5.1
+DEMO_NAME = MesaDemos-5.1
+GLU_NAME = MesaGLU-5.1
+GLUT_NAME = GLUT-3.7
+
+
+LIB_FILES =	\
+	$(DIRECTORY)/Makefile*						\
+	$(DIRECTORY)/Make-config					\
+	$(DIRECTORY)/descrip.mms					\
+	$(DIRECTORY)/mms-config.					\
+	$(DIRECTORY)/Mesa.dsw						\
+	$(DIRECTORY)/bin/mklib*						\
+	$(DIRECTORY)/docs/*.html					\
+	$(DIRECTORY)/docs/COPYING					\
+	$(DIRECTORY)/docs/INSTALL.GNU					\
+	$(DIRECTORY)/docs/README.*					\
+	$(DIRECTORY)/docs/RELNOTES*					\
+	$(DIRECTORY)/docs/VERSIONS					\
+	$(DIRECTORY)/docs/*.spec					\
+	$(DIRECTORY)/include/GL/internal/glcore.h			\
+	$(DIRECTORY)/include/GL/dmesa.h					\
+	$(DIRECTORY)/include/GL/amesa.h					\
+	$(DIRECTORY)/include/GL/fxmesa.h				\
+	$(DIRECTORY)/include/GL/ggimesa.h				\
+	$(DIRECTORY)/include/GL/gl.h					\
+	$(DIRECTORY)/include/GL/glext.h					\
+	$(DIRECTORY)/include/GL/gl_mangle.h				\
+	$(DIRECTORY)/include/GL/glu.h					\
+	$(DIRECTORY)/include/GL/glu_mangle.h				\
+	$(DIRECTORY)/include/GL/glx.h					\
+	$(DIRECTORY)/include/GL/glxext.h				\
+	$(DIRECTORY)/include/GL/glx_mangle.h				\
+	$(DIRECTORY)/include/GL/mesa_wgl.h				\
+	$(DIRECTORY)/include/GL/mglmesa.h				\
+	$(DIRECTORY)/include/GL/osmesa.h				\
+	$(DIRECTORY)/include/GL/svgamesa.h				\
+	$(DIRECTORY)/include/GL/ugl*.h					\
+	$(DIRECTORY)/include/GL/vms_x_fix.h				\
+	$(DIRECTORY)/include/GL/wmesa.h					\
+	$(DIRECTORY)/include/GL/xmesa.h					\
+	$(DIRECTORY)/include/GL/xmesa_x.h				\
+	$(DIRECTORY)/include/GL/xmesa_xf86.h				\
+	$(DIRECTORY)/src/mesa/Makefile*					\
+	$(DIRECTORY)/src/mesa/descrip.mms				\
+	$(DIRECTORY)/src/mesa/depend					\
+	$(DIRECTORY)/src/mesa/main/*.[chS]				\
+	$(DIRECTORY)/src/mesa/main/main.dsp				\
+	$(DIRECTORY)/src/mesa/glapi/*.[chS]				\
+	$(DIRECTORY)/src/mesa/glapi/glapi.dsp				\
+	$(DIRECTORY)/src/mesa/array_cache/*.[ch]			\
+	$(DIRECTORY)/src/mesa/array_cache/array_cache.dsp		\
+	$(DIRECTORY)/src/mesa/math/*.[ch]				\
+	$(DIRECTORY)/src/mesa/math/math.dsp				\
+	$(DIRECTORY)/src/mesa/swrast/*.[ch]				\
+	$(DIRECTORY)/src/mesa/swrast/swrast.dsp				\
+	$(DIRECTORY)/src/mesa/swrast_setup/*.[ch]			\
+	$(DIRECTORY)/src/mesa/swrast_setup/swrast_setup.dsp		\
+	$(DIRECTORY)/src/mesa/tnl/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl/tnl.dsp				\
+	$(DIRECTORY)/src/mesa/tnl_dd/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl_dd/imm/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl_dd/imm/NOTES.imm			\
+	$(DIRECTORY)/src/mesa/drivers/common/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/dos/*.[chS]			\
+	$(DIRECTORY)/src/mesa/drivers/dos/mga/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/beos/*.cpp			\
+	$(DIRECTORY)/src/mesa/drivers/glide/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/glide/*.def			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/ggimesa.conf.in		\
+	$(DIRECTORY)/src/mesa/drivers/ggi/default/*.c			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/default/genkgi.conf.in	\
+	$(DIRECTORY)/src/mesa/drivers/ggi/display/*.c			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/display/fbdev.conf.in		\
+	$(DIRECTORY)/src/mesa/drivers/ggi/include/ggi/mesa/*.h		\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/Makefile.win		\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.def			\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.dsp			\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/svga/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.def			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.dsp			\
+	$(DIRECTORY)/src/mesa/drivers/x11/*.[ch]			\
+	$(DIRECTORY)/src/mesa/sparc/*.[chS]				\
+	$(DIRECTORY)/src/mesa/x86/*.[ch]				\
+	$(DIRECTORY)/src/mesa/x86/*.S					\
+	$(DIRECTORY)/src/glu/sgi/Makefile.X11				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.win				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.DJ				\
+	$(DIRECTORY)/src/glu/sgi/cc*.txt				\
+	$(DIRECTORY)/src/glu/sgi/glu.def				\
+	$(DIRECTORY)/src/glu/sgi/glu.dsp				\
+	$(DIRECTORY)/src/glu/sgi/dummy.cc				\
+	$(DIRECTORY)/src/glu/sgi/descrip.mms				\
+	$(DIRECTORY)/src/glu/sgi/mesaglu.opt				\
+	$(DIRECTORY)/src/glu/sgi/include/gluos.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.cc		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.cc		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbtess/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbtess/*.cc			\
+	$(DIRECTORY)/src/glu/sgi/libtess/README				\
+	$(DIRECTORY)/src/glu/sgi/libtess/alg-outline			\
+	$(DIRECTORY)/src/glu/sgi/libtess/*.[ch]				\
+	$(DIRECTORY)/src/glu/sgi/libutil/*.[ch]				\
+	$(DIRECTORY)/src/glu/mesa/README[12]				\
+	$(DIRECTORY)/src/glu/mesa/Makefile*				\
+	$(DIRECTORY)/src/glu/mesa/descrip.mms				\
+	$(DIRECTORY)/src/glu/mesa/mms_depend				\
+	$(DIRECTORY)/src/glu/mesa/*.def					\
+	$(DIRECTORY)/src/glu/mesa/depend				\
+	$(DIRECTORY)/src/glu/mesa/*.[ch]				\
+	$(DIRECTORY)/src/glw/*.[ch]					\
+	$(DIRECTORY)/src/glw/Makefile*					\
+	$(DIRECTORY)/src/glw/README					\
+	$(DIRECTORY)/progs/util/README					\
+	$(DIRECTORY)/progs/util/*.[ch]					\
+	$(DIRECTORY)/progs/util/sampleMakefile				\
+	$(DIRECTORY)/vms/analyze_map.com				\
+	$(DIRECTORY)/vms/xlib.opt					\
+	$(DIRECTORY)/vms/xlib_share.opt
+
+
+DEMO_FILES =	\
+	$(DIRECTORY)/include/GL/glut.h			\
+	$(DIRECTORY)/include/GL/glutf90.h		\
+	$(DIRECTORY)/src/glut/glx/Makefile*		\
+	$(DIRECTORY)/src/glut/glx/depend		\
+	$(DIRECTORY)/src/glut/glx/*def			\
+	$(DIRECTORY)/src/glut/glx/descrip.mms		\
+	$(DIRECTORY)/src/glut/glx/mms_depend		\
+	$(DIRECTORY)/src/glut/glx/glut.dsp		\
+	$(DIRECTORY)/src/glut/glx/*.[ch]		\
+	$(DIRECTORY)/src/glut/dos/*.[ch]		\
+	$(DIRECTORY)/src/glut/dos/Makefile.DJ		\
+	$(DIRECTORY)/src/glut/dos/PC_HW/*.[chS]		\
+	$(DIRECTORY)/progs/images/*			\
+	$(DIRECTORY)/progs/demos/Makefile*		\
+	$(DIRECTORY)/progs/demos/descrip.mms		\
+	$(DIRECTORY)/progs/demos/*.[ch]			\
+	$(DIRECTORY)/progs/demos/*.cxx			\
+	$(DIRECTORY)/progs/demos/*.dat			\
+	$(DIRECTORY)/progs/demos/README			\
+	$(DIRECTORY)/progs/demos/Windows/*		\
+	$(DIRECTORY)/progs/xdemos/Makefile*		\
+	$(DIRECTORY)/progs/xdemos/descrip.mms		\
+	$(DIRECTORY)/progs/xdemos/*.[chf]		\
+	$(DIRECTORY)/progs/redbook/Makefile*		\
+	$(DIRECTORY)/progs/redbook/README		\
+	$(DIRECTORY)/progs/redbook/*.[ch]		\
+	$(DIRECTORY)/progs/samples/Makefile*		\
+	$(DIRECTORY)/progs/samples/README		\
+	$(DIRECTORY)/progs/samples/*.c			\
+	$(DIRECTORY)/progs/windml/Makefile.ugl		\
+	$(DIRECTORY)/progs/windml/*.c			\
+	$(DIRECTORY)/progs/windml/*.bmp			\
+	$(DIRECTORY)/progs/ggi/*.c
+
+SI_GLU_FILES = \
+	$(DIRECTORY)/Makefile*					\
+	$(DIRECTORY)/Make-config				\
+	$(DIRECTORY)/bin/mklib*					\
+	$(DIRECTORY)/include/GL/glu.h				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.X11			\
+	$(DIRECTORY)/src/glu/sgi/include/gluos.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbstess/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbstess/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libtess/README			\
+	$(DIRECTORY)/src/glu/sgi/libtess/alg-outline		\
+	$(DIRECTORY)/src/glu/sgi/libtess/*.[ch]			\
+	$(DIRECTORY)/src/glu/sgi/libutil/*.[ch]
+
+GLU_FILES = \
+	$(DIRECTORY)/Makefile*			\
+	$(DIRECTORY)/Make-config		\
+	$(DIRECTORY)/bin/mklib*			\
+	$(DIRECTORY)/include/GL/gl.h		\
+	$(DIRECTORY)/include/GL/gl_mangle.h	\
+	$(DIRECTORY)/include/GL/glext.h		\
+	$(DIRECTORY)/include/GL/glu.h		\
+	$(DIRECTORY)/include/GL/glu_mangle.h	\
+	$(DIRECTORY)/src/glu/mesa/README[12]	\
+	$(DIRECTORY)/src/glu/mesa/Makefile*	\
+	$(DIRECTORY)/src/glu/mesa/descrip.mms	\
+	$(DIRECTORY)/src/glu/mesa/mms_depend	\
+	$(DIRECTORY)/src/glu/mesa/*.def		\
+	$(DIRECTORY)/src/glu/mesa/depend	\
+	$(DIRECTORY)/src/glu/mesa/*.[ch]
+
+GLUT_FILES = \
+	$(DIRECTORY)/Makefile*			\
+	$(DIRECTORY)/Make-config		\
+	$(DIRECTORY)/bin/mklib*			\
+	$(DIRECTORY)/include/GL/gl.h		\
+	$(DIRECTORY)/include/GL/gl_mangle.h	\
+	$(DIRECTORY)/include/GL/glext.h		\
+	$(DIRECTORY)/include/GL/glu.h		\
+	$(DIRECTORY)/include/GL/glu_mangle.h	\
+	$(DIRECTORY)/include/GL/glut.h		\
+	$(DIRECTORY)/include/GL/glutf90.h	\
+	$(DIRECTORY)/src/glut/glx/Makefile*	\
+	$(DIRECTORY)/src/glut/glx/depend	\
+	$(DIRECTORY)/src/glut/glx/*def		\
+	$(DIRECTORY)/src/glut/glx/descrip.mms	\
+	$(DIRECTORY)/src/glut/glx/mms_depend	\
+	$(DIRECTORY)/src/glut/glx/*.[ch]
+
+
+
+lib_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
+	gzip $(LIB_NAME).tar ; \
+	mv $(LIB_NAME).tar.gz $(DIRECTORY)
+
+demo_gz:
+	cd .. ; \
+	tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
+	gzip $(DEMO_NAME).tar ; \
+	mv $(DEMO_NAME).tar.gz $(DIRECTORY)
+
+lib_bz2:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
+	bzip2 $(LIB_NAME).tar ; \
+	mv $(LIB_NAME).tar.bz2 $(DIRECTORY)
+
+demo_bz2:
+	cd .. ; \
+	tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
+	bzip2 $(DEMO_NAME).tar ; \
+	mv $(DEMO_NAME).tar.bz2 $(DIRECTORY)
+
+lib_zip:
+	-rm $(LIB_NAME).zip ; \
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	zip -r $(LIB_NAME).zip $(LIB_FILES) ; \
+	mv $(LIB_NAME).zip $(DIRECTORY)
+
+demo_zip:
+	-rm $(DEMO_NAME).zip ; \
+	cd .. ; \
+	zip -r $(DEMO_NAME).zip $(DEMO_FILES) ; \
+	mv $(DEMO_NAME).zip $(DIRECTORY)
+
+md5:
+	@-md5sum $(LIB_NAME).tar.gz
+	@-md5sum $(LIB_NAME).tar.bz2
+	@-md5sum $(LIB_NAME).zip
+	@-md5sum $(DEMO_NAME).tar.gz
+	@-md5sum $(DEMO_NAME).tar.bz2
+	@-md5sum $(DEMO_NAME).zip
+
+# Everything for new Mesa release:
+tarballs: lib_gz demo_gz lib_bz2 demo_bz2 lib_zip demo_zip md5
+
+
+# not used
+glu_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLU_NAME).tar $(GLU_FILES) ; \
+	gzip $(GLU_NAME).tar ; \
+	mv $(GLU_NAME).tar.gz $(DIRECTORY)
+
+glut_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLUT_NAME).tar $(GLUT_FILES) ; \
+	gzip $(GLUT_NAME).tar ; \
+	mv $(GLUT_NAME).tar.gz $(DIRECTORY)

Makefile.am

@@ -1,185 +0,0 @@
-# Copyright © 2012 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-
-SUBDIRS = src
-
-ACLOCAL_AMFLAGS = -I m4
-
-doxygen:
-	cd doxygen && $(MAKE)
-
-check-local:
-	$(MAKE) -C src/mapi/glapi/tests check
-	$(MAKE) -C src/mapi/shared-glapi/tests check
-	$(MAKE) -C src/mesa/main/tests check
-	$(MAKE) -C src/glsl/tests check
-	$(MAKE) -C src/glx/tests check
-
-clean-local:
-	-@touch $(top_builddir)/configs/current
-	-@for dir in $(SUBDIRS) ; do \
-		if [ -d $$dir ] ; then \
-			(cd $$dir && $(MAKE) clean) ; \
-		fi \
-	done
-	-@test -s $(top_builddir)/configs/current || rm -f $(top_builddir)/configs/current
-
-
-
-distclean-local:
-	-rm -rf lib*
-	-rm -f $(top_builddir)/configs/current
-	-find . '(' -name '*.o' -o -name '*.a' -o -name '*.so' -o \
-	  -name depend -o -name depend.bak ')' -exec rm -f '{}' ';'
-
-.PHONY: doxygen
-
-# Rules for making release tarballs
-
-PACKAGE_VERSION=9.0.1
-PACKAGE_DIR = Mesa-$(PACKAGE_VERSION)
-PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
-
-EXTRA_FILES = \
-	aclocal.m4					\
-	configure					\
-	bin/ar-lib					\
-	bin/compile					\
-	bin/config.sub					\
-	bin/config.guess				\
-	bin/depcomp					\
-	bin/install-sh					\
-	bin/ltmain.sh					\
-	bin/missing					\
-	bin/ylwrap					\
-	src/glsl/glsl_parser.cc				\
-	src/glsl/glsl_parser.h				\
-	src/glsl/glsl_lexer.cc				\
-	src/glsl/glcpp/glcpp-lex.c			\
-	src/glsl/glcpp/glcpp-parse.c			\
-	src/glsl/glcpp/glcpp-parse.h			\
-	src/mesa/main/api_exec_es1.c			\
-	src/mesa/main/api_exec_es1_dispatch.h		\
-	src/mesa/main/api_exec_es1_remap_helper.h	\
-	src/mesa/main/api_exec_es2.c			\
-	src/mesa/main/api_exec_es2_dispatch.h		\
-	src/mesa/main/api_exec_es2_remap_helper.h	\
-	src/mesa/program/lex.yy.c			\
-	src/mesa/program/program_parse.tab.c		\
-	src/mesa/program/program_parse.tab.h		\
-	src/gallium/drivers/r600/Makefile.in		\
-	src/gallium/drivers/r300/Makefile.in		\
-	src/gallium/drivers/Makefile.in			\
-	src/gallium/Makefile.in				\
-	src/gallium/auxiliary/pipe-loader/Makefile.in	\
-	src/gallium/targets/opencl/Makefile.in		\
-	src/gallium/state_trackers/clover/Makefile.in	\
-	src/mapi/glapi/tests/Makefile.in		\
-	src/mapi/glapi/Makefile.in			\
-	src/mapi/glapi/gen/Makefile.in			\
-	src/mapi/es1api/Makefile.in			\
-	src/mapi/shared-glapi/tests/Makefile.in		\
-	src/mapi/shared-glapi/Makefile.in		\
-	src/mapi/vgapi/Makefile.in			\
-	src/mapi/es2api/Makefile.in			\
-	src/glsl/tests/Makefile.in			\
-	src/glsl/glcpp/Makefile.in			\
-	src/glsl/Makefile.in				\
-	src/gtest/Makefile.in				\
-	src/egl/drivers/Makefile.in			\
-	src/egl/drivers/glx/Makefile.in			\
-	src/egl/drivers/dri2/Makefile.in		\
-	src/egl/Makefile.in				\
-	src/egl/main/Makefile.in			\
-	src/egl/wayland/Makefile.in			\
-	src/egl/wayland/wayland-drm/Makefile.in		\
-	src/egl/wayland/wayland-egl/Makefile.in		\
-	src/Makefile.in					\
-	src/glx/tests/Makefile.in			\
-	src/glx/Makefile.in				\
-	src/gbm/Makefile.in				\
-	src/mesa/drivers/Makefile.in			\
-	src/mesa/drivers/dri/common/Makefile.in		\
-	src/mesa/drivers/dri/i965/Makefile.in		\
-	src/mesa/drivers/dri/r200/Makefile.in		\
-	src/mesa/drivers/dri/Makefile.in		\
-	src/mesa/drivers/dri/radeon/Makefile.in		\
-	src/mesa/drivers/dri/swrast/Makefile.in		\
-	src/mesa/drivers/dri/nouveau/Makefile.in	\
-	src/mesa/drivers/dri/i915/Makefile.in		\
-	src/mesa/drivers/osmesa/Makefile.in		\
-	src/mesa/drivers/x11/Makefile.in		\
-	src/mesa/Makefile.in				\
-	src/mesa/libdricore/Makefile.in			\
-	src/mesa/x86-64/Makefile.in			\
-	src/mesa/main/tests/Makefile.in			\
-	src/mesa/x86/Makefile.in			\
-	Makefile.in
-
-
-IGNORE_FILES = \
-	-x autogen.sh
-
-
-parsers: configure
-	-@touch $(top_builddir)/configs/current
-	$(MAKE) -C src/glsl glsl_parser.cc glsl_parser.h glsl_lexer.cc
-	$(MAKE) -C src/glsl/glcpp glcpp-lex.c glcpp-parse.c glcpp-parse.h
-	$(MAKE) -C src/mesa program/lex.yy.c program/program_parse.tab.c program/program_parse.tab.h
-
-# Everything for new a Mesa release:
-ARCHIVES = $(PACKAGE_NAME).tar.gz \
-	$(PACKAGE_NAME).tar.bz2 \
-	$(PACKAGE_NAME).zip
-
-tarballs: md5
-	rm -f ../$(PACKAGE_DIR) $(PACKAGE_NAME).tar
-
-manifest.txt: .git
-	( \
-		ls -1 $(EXTRA_FILES) ; \
-		git ls-files $(IGNORE_FILES) \
-	) | sed -e '/^\(.*\/\)\?\./d' -e "s@^@$(PACKAGE_DIR)/@" > $@
-
-../$(PACKAGE_DIR):
-	ln -s $(PWD) $@
-
-$(PACKAGE_NAME).tar: parsers ../$(PACKAGE_DIR) manifest.txt
-	cd .. ; tar -cf $(PACKAGE_DIR)/$(PACKAGE_NAME).tar -T $(PACKAGE_DIR)/manifest.txt
-
-$(PACKAGE_NAME).tar.gz: $(PACKAGE_NAME).tar ../$(PACKAGE_DIR)
-	gzip --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.gz
-
-$(PACKAGE_NAME).tar.bz2: $(PACKAGE_NAME).tar
-	bzip2 --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.bz2
-
-$(PACKAGE_NAME).zip: parsers ../$(PACKAGE_DIR) manifest.txt
-	rm -f $(PACKAGE_NAME).zip ; \
-	cd .. ; \
-	zip -q -@ $(PACKAGE_NAME).zip < $(PACKAGE_DIR)/manifest.txt ; \
-	mv $(PACKAGE_NAME).zip $(PACKAGE_DIR)
-
-md5: $(ARCHIVES)
-	@-md5sum $(PACKAGE_NAME).tar.gz
-	@-md5sum $(PACKAGE_NAME).tar.bz2
-	@-md5sum $(PACKAGE_NAME).zip
-
-.PHONY: tarballs md5

Makefile.mgw

@@ -0,0 +1,91 @@
+# Mesa 3-D graphics library
+# Version:  4.0
+# 
+# Copyright (C) 1999  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+# MinGW makefile v1.0 for Mesa
+#
+#  Copyright (C) 2002 - Borca Daniel
+#  Email : dborca@users.sourceforge.net
+#  Web   : http://www.geocities.com/dborca
+
+
+#
+#  Available options:
+#
+#    Environment variables:
+#	CPU		optimize for the given processor.
+#			default = pentium
+#	GLIDE		path to Glide3 SDK; used with FX.
+#			default = $(TOP)/glide3
+#	FX=1		build for 3dfx Glide3. Note that this disables
+#			compilation of most WMesa code and requires fxMesa.
+#			As a consequence, you'll need the Win32 Glide3
+#			library to build any application.
+#			default = no
+#	HAVE_X86=1	optimize for i386.
+#			default = no
+#	HAVE_MMX=1	allow MMX specializations, provided your assembler
+#			supports MMX instruction set. However, the true CPU
+#			capabilities are checked at run-time to avoid crashes.
+#			default = no
+#	HAVE_SSE=1	(see HAVE_MMX)
+#			default = no
+#	HAVE_3DNOW=1	(see HAVE_MMX)
+#			default = no
+#
+#    Targets:
+#	all:		build everything
+#	libgl:		build GL
+#	clean:		remove object files
+#	realclean:	remove all generated files
+#
+
+
+
+.PHONY : all libgl clean realclean
+
+CPU ?= pentium
+
+CFLAGS = -Wall -W -pedantic
+CFLAGS += -O2 -ffast-math -mcpu=$(CPU)
+
+export CFLAGS
+
+ifeq ($(wildcard $(addsuffix /rm.exe,$(subst ;, ,$(PATH)))),)
+UNLINK = del $(subst /,\,$(1))
+else
+UNLINK = $(RM) $(1)
+endif
+
+all: libgl
+
+libgl: lib
+	$(MAKE) -f Makefile.mgw -C src/mesa
+
+lib:
+	mkdir lib
+
+clean:
+	$(MAKE) -f Makefile.mgw clean -C src/mesa
+
+realclean: clean
+	-$(call UNLINK,lib/*.a)
+	-$(call UNLINK,lib/*.dll)

Makefile.wfx

@@ -0,0 +1,87 @@
+# Mesa 3-D graphics library
+# Version:  5.1
+#
+# Copyright (C) 1999-2003  Brian Paul   All Rights Reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+# Win32/FX makefile for Mesa
+#
+#  Copyright (c) 2003 - Hiroshi Morii
+#  Email : koolsmoky@users.sourceforge.net
+#  URL   : http://www.3dfxzone.it/koolsmoky
+
+# Debug build                : nmake -f Makefile.wfx debug
+# Optimized build            : nmake -f Makefile.wfx
+# Remove objects             : nmake -f Makefile.wfx clean
+# Remove files in bin, lib   : nmake -f Makefile.wfx clobber
+# Remove all generated files : nmake -f Makefile.wfx realclean
+
+# Build the libs
+SUBDIRS	  = src\mesa.dir
+DBGBUILD  = $(SUBDIRS:.dir=.debug)
+CLEAN	  = $(SUBDIRS:.dir=.clean)
+CLOBBER	  = $(SUBDIRS:.dir=.clobber)
+REALCLEAN = $(SUBDIRS:.dir=.realclean)
+LIBDIR    = lib
+
+# default rule
+default	  : $(LIBDIR) $(SUBDIRS)
+
+# debug build rules
+debug     : $(LIBDIR) $(DBGBUILD)
+
+# cleanup rules
+clean	  : $(CLEAN)
+clobber	  : $(CLOBBER)
+realclean : $(REALCLEAN)
+
+# inference rules
+$(LIBDIR):
+	@echo.
+	@mkdir $(LIBDIR)
+
+$(SUBDIRS):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx
+	@cd ..
+
+$(DBGBUILD):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx DEBUG=1
+	@cd ..
+
+$(CLEAN):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx clean
+	@cd ..
+
+$(CLOBBER):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx clobber
+	@cd ..
+
+$(REALCLEAN):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx realclean
+	@cd ..

Mesa.dsw

@@ -0,0 +1,179 @@
+Microsoft Developer Studio Workspace File, Format Version 6.00
+# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
+
+###############################################################################
+
+Project: "array_cache"=".\SRC\MESA\array_cache\array_cache.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "gdi"=".\src\mesa\drivers\windows\gdi\gdi.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name array_cache
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name main
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name math
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name swrast_setup
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name swrast
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name tnl
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name glapi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "glapi"=".\SRC\MESA\glapi\glapi.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "glu"=".\src\glu\sgi\glu.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name gdi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "glut"=".\src\glut\glx\glut.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name glu
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "main"=".\SRC\MESA\main\main.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "math"=".\SRC\MESA\math\math.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "osmesa"=".\SRC\MESA\DRIVERS\osmesa\osmesa.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name gdi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "swrast"=".\SRC\MESA\swrast\swrast.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "swrast_setup"=".\SRC\MESA\swrast_setup\swrast_setup.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "tnl"=".\SRC\MESA\tnl\tnl.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Global:
+
+Package=<5>
+{{{
+}}}
+
+Package=<3>
+{{{
+}}}
+
+###############################################################################
+

SConstruct

@@ -1,161 +0,0 @@
-#######################################################################
-# Top-level SConstruct
-#
-# For example, invoke scons as 
-#
-#   scons build=debug llvm=yes machine=x86
-#
-# to set configuration variables. Or you can write those options to a file
-# named config.py:
-#
-#   # config.py
-#   build='debug'
-#   llvm=True
-#   machine='x86'
-# 
-# Invoke
-#
-#   scons -h
-#
-# to get the full list of options. See scons manpage for more info.
-#  
-
-import os
-import os.path
-import sys
-import SCons.Util
-
-import common
-
-#######################################################################
-# Configuration options
-
-opts = Variables('config.py')
-common.AddOptions(opts)
-
-env = Environment(
-	options = opts,
-	tools = ['gallium'],
-	toolpath = ['#scons'],	
-	ENV = os.environ,
-)
-
-# XXX: This creates a many problems as it saves...
-#opts.Save('config.py', env)
-
-# Backwards compatability with old target configuration variable
-try:
-    targets = ARGUMENTS['targets']
-except KeyError:
-    pass
-else:
-    targets = targets.split(',')
-    print 'scons: warning: targets option is deprecated; pass the targets on their own such as'
-    print
-    print '  scons %s' % ' '.join(targets)
-    print 
-    COMMAND_LINE_TARGETS.append(targets)
-
-
-Help(opts.GenerateHelpText(env))
-
-# fail early for a common error on windows
-if env['gles']:
-    try:
-        import libxml2
-    except ImportError:
-        raise SCons.Errors.UserError, "GLES requires libxml2-python to build"
-
-#######################################################################
-# Environment setup
-
-# Includes
-env.Prepend(CPPPATH = [
-	'#/include',
-])
-env.Append(CPPPATH = [
-	'#/src/gallium/include',
-	'#/src/gallium/auxiliary',
-	'#/src/gallium/drivers',
-	'#/src/gallium/winsys',
-])
-
-if env['msvc']:
-    env.Append(CPPPATH = ['#include/c99'])
-
-# for debugging
-#print env.Dump()
-
-
-#######################################################################
-# Invoke host SConscripts 
-# 
-# For things that are meant to be run on the native host build machine, instead
-# of the target machine.
-#
-
-# Create host environent
-if env['crosscompile'] and not env['embedded']:
-    host_env = Environment(
-        options = opts,
-        # no tool used
-        tools = [],
-        toolpath = ['#scons'],
-        ENV = os.environ,
-    )
-
-    # Override options
-    host_env['platform'] = common.host_platform
-    host_env['machine'] = common.host_machine
-    host_env['toolchain'] = 'default'
-    host_env['llvm'] = False
-
-    host_env.Tool('gallium')
-
-    host_env['hostonly'] = True
-    assert host_env['crosscompile'] == False
-
-    if host_env['msvc']:
-        host_env.Append(CPPPATH = ['#include/c99'])
-
-    target_env = env
-    env = host_env
-    Export('env')
-
-    SConscript(
-        'src/SConscript',
-        variant_dir = host_env['build_dir'],
-        duplicate = 0, # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
-    )
-
-    env = target_env
-
-Export('env')
-
-#######################################################################
-# Invoke SConscripts
-
-# TODO: Build several variants at the same time?
-# http://www.scons.org/wiki/SimultaneousVariantBuilds
-
-SConscript(
-	'src/SConscript',
-	variant_dir = env['build_dir'],
-	duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
-)
-
-
-########################################################################
-# List all aliases
-
-try:
-    from SCons.Node.Alias import default_ans
-except ImportError:
-    pass
-else:
-    aliases = default_ans.keys()
-    aliases.sort()
-    env.Help('\n')
-    env.Help('Recognized targets:\n')
-    for alias in aliases:
-        env.Help('    %s\n' % alias)

acinclude.m4

@@ -1,119 +0,0 @@
-# A few convenience macros for Mesa, mostly to keep all the platform
-# specifics out of configure.ac.
-
-# MESA_PIC_FLAGS()
-#
-# Find out whether to build PIC code using the option --enable-pic and
-# the configure enable_static/enable_shared settings. If PIC is needed,
-# figure out the necessary flags for the platform and compiler.
-#
-# The platform checks have been shamelessly taken from libtool and
-# stripped down to just what's needed for Mesa. See _LT_COMPILER_PIC in
-# /usr/share/aclocal/libtool.m4 or
-# http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=blob;f=libltdl/m4/libtool.m4;hb=HEAD
-#
-AC_DEFUN([MESA_PIC_FLAGS],
-[AC_REQUIRE([AC_PROG_CC])dnl
-AC_ARG_VAR([PIC_FLAGS], [compiler flags for PIC code])
-AC_ARG_ENABLE([pic],
-    [AS_HELP_STRING([--disable-pic],
-        [compile PIC objects @<:@default=enabled for shared builds
-        on supported platforms@:>@])],
-    [enable_pic="$enableval"
-    test "x$enable_pic" = x && enable_pic=auto],
-    [enable_pic=auto])
-# disable PIC by default for static builds
-if test "$enable_pic" = auto && test "$enable_static" = yes; then
-    enable_pic=no
-fi
-# if PIC hasn't been explicitly disabled, try to figure out the flags
-if test "$enable_pic" != no; then
-    AC_MSG_CHECKING([for $CC option to produce PIC])
-    # allow the user's flags to override
-    if test "x$PIC_FLAGS" = x; then
-        # see if we're using GCC
-        if test "x$GCC" = xyes; then
-            case "$host_os" in
-            aix*|beos*|cygwin*|irix5*|irix6*|osf3*|osf4*|osf5*)
-                # PIC is the default for these OSes.
-                ;;
-            mingw*|os2*|pw32*)
-                # This hack is so that the source file can tell whether
-                # it is being built for inclusion in a dll (and should
-                # export symbols for example).
-                PIC_FLAGS="-DDLL_EXPORT"
-                ;;
-            darwin*|rhapsody*)
-                # PIC is the default on this platform
-                # Common symbols not allowed in MH_DYLIB files
-                PIC_FLAGS="-fno-common"
-                ;;
-            hpux*)
-                # PIC is the default for IA64 HP-UX and 64-bit HP-UX,
-                # but not for PA HP-UX.
-                case $host_cpu in
-                hppa*64*|ia64*)
-                    ;;
-                *)
-                    PIC_FLAGS="-fPIC"
-                    ;;
-                esac
-                ;;
-            *)
-                # Everyone else on GCC uses -fPIC
-                PIC_FLAGS="-fPIC"
-                ;;
-            esac
-        else # !GCC
-            case "$host_os" in
-            hpux9*|hpux10*|hpux11*)
-                # PIC is the default for IA64 HP-UX and 64-bit HP-UX,
-                # but not for PA HP-UX.
-                case "$host_cpu" in
-                hppa*64*|ia64*)
-                    # +Z the default
-                    ;;
-                *)
-                    PIC_FLAGS="+Z"
-                    ;;
-                esac
-                ;;
-            linux*|k*bsd*-gnu)
-                case `basename "$CC"` in
-                icc*|ecc*|ifort*)
-                    PIC_FLAGS="-KPIC"
-                    ;;
-                pgcc*|pgf77*|pgf90*|pgf95*)
-                    # Portland Group compilers (*not* the Pentium gcc
-                    # compiler, which looks to be a dead project)
-                    PIC_FLAGS="-fpic"
-                    ;;
-                ccc*)
-                    # All Alpha code is PIC.
-                    ;;
-                xl*)
-                    # IBM XL C 8.0/Fortran 10.1 on PPC
-                    PIC_FLAGS="-qpic"
-                    ;;
-                *)
-                    case `$CC -V 2>&1 | sed 5q` in
-                    *Sun\ C*|*Sun\ F*)
-                        # Sun C 5.9 or Sun Fortran
-                        PIC_FLAGS="-KPIC"
-                        ;;
-                    esac
-                esac
-                ;;
-            solaris*)
-                PIC_FLAGS="-KPIC"
-                ;;
-            sunos4*)
-                PIC_FLAGS="-PIC"
-                ;;
-            esac
-        fi # GCC
-    fi # PIC_FLAGS
-    AC_MSG_RESULT([$PIC_FLAGS])
-fi
-AC_SUBST([PIC_FLAGS])
-])# MESA_PIC_FLAGS

autogen.sh

@@ -1,14 +0,0 @@
-#! /bin/sh
-
-srcdir=`dirname "$0"`
-test -z "$srcdir" && srcdir=.
-
-ORIGDIR=`pwd`
-cd "$srcdir"
-
-autoreconf -v --install || exit 1
-cd $ORIGDIR || exit $?
-
-if test -z "$NOCONFIGURE"; then
-    "$srcdir"/configure "$@"
-fi

bin/.cherry-ignore

@@ -1,10 +0,0 @@
-# These commits were cherry picked without using -x.
-# TBD
-
-# Causes too many regressions...
-413c4914129cd26ca87960852d8c0264c0fb29e7 intel: Improve teximage perf for Google Chrome paint rects (v3)
-b1d0fe022dc4826dadce014ab8fe062a82f75a16 intel: Fix segfault in intel_texsubimage_tiled_memcpy
-b5891286202987dfc2606ac716050c0ee426de11 intel: Fix yet-another-bug in intel_texsubimage_tiled_memcpy
-
-# Introduces performance regressions for other games... don't cherry-pick for now
-fa58644855e44830e0b91dc627703c236fa6712a r600g: fix abysmal performance in Reaction Quake

bin/.gitignore

@@ -1,8 +0,0 @@
-config.guess
-config.sub
-install-sh
-/depcomp
-/missing
-ylwrap
-compile
-ar-lib

bin/get-pick-list.sh

@@ -1,29 +0,0 @@
-#!/bin/sh
-
-# Script for generating a list of candidates for cherry-picking to a stable branch
-
-# Grep for commits with "cherry picked from commit" in the commit message.
-git log --reverse --grep="cherry picked from commit" origin/master..HEAD |\
-	grep "cherry picked from commit" |\
-	sed -e 's/^[[:space:]]*(cherry picked from commit[[:space:]]*//' -e 's/)//' > already_picked
-
-# Grep for commits that were marked as a candidate for the stable tree.
-git log --reverse --pretty=%H -i --grep='^[[:space:]]*NOTE: This is a candidate' HEAD..origin/master |\
-while read sha
-do
-	# Check to see whether the patch is on the ignore list.
-	if [ -f bin/.cherry-ignore ] ; then
-		if grep -q ^$sha bin/.cherry-ignore ; then
-			continue
-		fi
-	fi
-
-	# Check to see if it has already been picked over.
-	if grep -q ^$sha already_picked ; then
-		continue
-	fi
-
-	git log -n1 --pretty=oneline $sha | cat
-done
-
-rm -f already_picked

bin/installmesa

@@ -1,74 +0,0 @@
-#!/bin/sh
-
-#
-# Simple shell script for installing Mesa's header and library files.
-# If the copy commands below don't work on a particular system (i.e. the
-# -f or -d flags), we may need to branch on `uname` to do the right thing.
-#
-
-
-TOP=.
-
-INCLUDE_DIR="/usr/local/include"
-LIB_DIR="/usr/local/lib"
-
-if [ "x$#" = "x0" ] ; then
-echo
-echo "***** Mesa installation - You may need root privileges to do this *****"
-echo
-echo "Default directory for header files is:" ${INCLUDE_DIR}
-echo "Enter new directory or press <Enter> to accept this default."
-
-read INPUT
-if [ "x${INPUT}" != "x" ] ; then
-	INCLUDE_DIR=${INPUT}
-fi
-
-echo
-echo "Default directory for library files is:" ${LIB_DIR}
-echo "Enter new directory or press <Enter> to accept this default."
-
-read INPUT
-if [ "x${INPUT}" != "x" ] ; then
-	LIB_DIR=${INPUT}
-fi
-
-echo
-echo "About to install Mesa header files (GL/*.h) in: " ${INCLUDE_DIR}/GL
-echo "and Mesa library files (libGL.*, etc) in: " ${LIB_DIR}
-echo "Press <Enter> to continue, or <ctrl>-C to abort."
-
-read INPUT
-
-else
-INCLUDE_DIR=$1/include
-LIB_DIR=$1/lib
-fi
-
-# flags:
-#  -f = force
-#  -d = preserve symlinks (does not work on BSD)
-
-if [ `uname` = "FreeBSD" ] ; then
-	CP_FLAGS="-f"
-elif [ `uname` = "Darwin" ] ; then
-	CP_FLAGS="-f"
-elif [ `uname` = "AIX" ] ; then
-	CP_FLAGS="-fh"
-else
-	CP_FLAGS="-fd"
-fi
-
-
-set -v
-
-mkdir -p ${INCLUDE_DIR}
-mkdir -p ${INCLUDE_DIR}/GL
-# NOT YET: mkdir -p ${INCLUDE_DIR}/GLES
-mkdir -p ${LIB_DIR}
-cp -f ${TOP}/include/GL/*.h ${INCLUDE_DIR}/GL
-cp -f ${TOP}/src/glw/*.h ${INCLUDE_DIR}/GL
-# NOT YET: cp -f ${TOP}/include/GLES/*.h ${INCLUDE_DIR}/GLES
-cp ${CP_FLAGS} ${TOP}/lib*/lib* ${LIB_DIR}
-
-echo "Done."

bin/minstall

@@ -1,112 +0,0 @@
-#!/bin/sh
-
-
-# A minimal replacement for 'install' that supports installing symbolic links.
-# Only a limited number of options are supported:
-# -d dir          Create a directory
-# -m mode         Sets a file's mode when installing
-
-
-# If these commands aren't portable, we'll need some "if (arch)" type stuff
-SYMLINK="ln -s"
-MKDIR="mkdir -p"
-RM="rm -f"
-
-MODE=""
-
-if [ "$1" = "-d" ] ; then
-	# make a directory path
-	$MKDIR "$2"
-	exit 0
-fi
-
-if [ "$1" = "-m" ] ; then
-	# set file mode
-	MODE=$2
-	shift 2
-fi
-
-# install file(s) into destination
-if [ $# -ge 2 ] ; then
-
-	# Last cmd line arg is the dest dir
-	for FILE in $@ ; do
-		DESTDIR="$FILE"
-	done
-
-	# Loop over args, moving them to DEST directory
-	I=1
-	for FILE in $@ ; do
-		if [ $I = $# ] ; then
-			# stop, don't want to install $DEST into $DEST
-			exit 0
-		fi
-
-                DEST=$DESTDIR
-
-                # On CYGWIN, because DLLs are loaded by the native Win32 loader,
-                # they are installed in the executable path.  Stub libraries used
-                # only for linking are installed in the library path
-                case `uname` in
-                    CYGWIN*)
-                        case $FILE in
-                            *.dll)
-                                DEST="$DEST/../bin"
-                                ;;
-                            *)
-                                ;;
-                        esac
-	                ;;
-                    *)
-                        ;;
-                esac
-
-		PWDSAVE=`pwd`
-
-		# determine file's type
-		if [ -h "$FILE" ] ; then
-			#echo $FILE is a symlink
-			# Unfortunately, cp -d isn't universal so we have to
-			# use a work-around.
-
-			# Use ls -l to find the target that the link points to
-			LL=`ls -l "$FILE"`
-			for L in $LL ; do
-				TARGET=$L
-			done
-			#echo $FILE is a symlink pointing to $TARGET
-
-			FILE=`basename "$FILE"`
-			# Go to $DEST and make the link
-			cd "$DEST"        # pushd
-				$RM "$FILE"
-				$SYMLINK "$TARGET" "$FILE"
-			cd "$PWDSAVE"     # popd
-
-		elif [ -f "$FILE" ] ; then
-			#echo "$FILE" is a regular file
-			# Only copy if the files differ
-			if ! cmp -s $FILE $DEST/`basename $FILE`; then
-				$RM "$DEST/`basename $FILE`"
-				cp "$FILE" "$DEST"
-			fi
-			if [ $MODE ] ; then
-				FILE=`basename "$FILE"`
-				chmod $MODE "$DEST/$FILE"
-			fi
-		else
-			echo "Unknown type of argument: " "$FILE"
-			exit 1
-		fi
-
-		I=`expr $I + 1`
-	done
-
-	exit 0
-fi
-
-# If we get here, we didn't find anything to do
-echo "Usage:"
-echo "  install -d dir                      Create named directory"
-echo "  install [-m mode] file [...] dest   Install files in destination"
-

bin/mklib.aix

@@ -0,0 +1,153 @@
+#!/bin/ksh
+
+# Make an AIX shared library (tricky!!!)
+# Based on a script from Athanasios G. Gaitatzes (gaitat@vnet.ibm.com)
+# Improved by Greg Thompson <gregt@visix.com> -gt
+
+#--identification------------------------------------------------------
+
+# $Id: mklib.aix,v 1.2 1999/09/15 15:10:20 brianp Exp $
+
+# $Log: mklib.aix,v $
+# Revision 1.2  1999/09/15 15:10:20  brianp
+# added third, tiny version number to arguments
+#
+# Revision 1.1  1999/08/19 13:52:56  brianp
+# initial check-in (post-crash)
+#
+
+
+#--common--------------------------------------------------------------
+
+LIBRARY=$1
+shift 1
+
+MAJOR=$1
+shift 1
+
+MINOR=$1
+shift 1
+
+TINY=$1
+shift 1
+
+OBJECTS=$*
+
+#--platform------------------------------------------------------------
+
+# BASENAME = LIBRARY without .a suffix
+BASENAME=`echo ${LIBRARY} | sed "s/\.a//g"`
+
+# Name of exports file
+EXPFILE=${BASENAME}.exp
+
+# Name of temporary shared lib file
+OFILE=shr.o
+####OFILE=${BASENAME}.o
+
+
+# Remove any old files from previous make
+rm -f ${LIBRARY} ${EXPFILE} ${OFILE}
+
+# Pick a way to use nm -gt
+NM=${NM-/bin/nm -eC}
+
+# Determine which version of AIX this is
+AIXVERSION=`uname -v`
+
+# Pick a way to tell the linker there's no entrypoint -gt
+case ${AIXVERSION}
+{
+	3*)
+		ENTRY='-e _nostart'
+		;;
+	4*)
+		ENTRY=-bnoentry
+		;;
+	*)
+		echo "Error in mklib.aix!"
+		exit 1
+		;;
+}
+
+
+# Other libraries which we may be dependent on.  Since we make the libraries
+# in the order libGL.a, libaGLU.a, libglut.a just depends on its predecessor.
+# modified to make otherlibs in the form of -lfoo -gt
+OTHERLIBS=`ls ../lib/*.a | sed "s/..\/lib\/lib/-l/g" | sed "s/\.a//g"`
+
+##echo OTHERLIBS are ${OTHERLIBS}
+
+
+# Make exports (.exp) file header
+echo "#! ${LIBRARY}" > ${EXPFILE}
+
+# Append list of exported symbols to exports file -gt
+case ${AIXVERSION}
+{
+    3*)
+	${NM} ${OBJECTS} | awk -F'|' '{
+	    if ($3 != "extern" || substr($7,1,1) == " ") continue
+	    sub ("  *", "", $1); sub ("  *", "", $7)
+	    if ( (($7 == ".text") || ($7 == ".data") || ($7 == ".bss"))  \
+		    && ( substr($1,1,1) != ".")) {
+		if (substr ($1, 1, 7) != "__sinit" &&
+			substr ($1, 1, 7) != "__sterm") {
+		    if (substr ($1, 1, 5) == "__tf1")
+			print (substr ($1, 7))
+		    else if (substr ($1, 1, 5) == "__tf9")
+			print (substr ($1, 15))
+		    else
+			print $1
+		}
+	    }
+	}' | sort -u >> ${EXPFILE}
+	;;
+
+    4*)
+	${NM} ${OBJECTS} | awk '{
+	    if ((($2 == "T") || ($2 == "D") || ($2 == "B")) \
+		    && ( substr($1,1,1) != ".")) {
+		if (substr ($1, 1, 7) != "__sinit" &&
+			substr ($1, 1, 7) != "__sterm") {
+		    if (substr ($1, 1, 5) == "__tf1")
+			print (substr ($1, 7))
+		    else if (substr ($1, 1, 5) == "__tf9")
+			print (substr ($1, 15))
+		    else
+			print $1
+		}
+	    }
+	}' | sort -u >> ${EXPFILE}
+	;;
+}
+
+
+# This next line is a hack to allow full compatibility with IBM's OpenGL
+# libraries.  IBM mistakenly exports glLoadIdentity from the libGLU.a
+# library.  We have to do the same thing.  Problem reported by Yemi Adesanya
+# (adesanya@afsmail.cern.ch) and Patrick Brown (pbrown@austin.ibm.com)
+if [ "${BASENAME}" = libGLU ] ; then
+    echo "glLoadIdentity" >> ${EXPFILE}
+fi
+
+
+# Make the shared lib file
+cc -o ${OFILE} ${OBJECTS} -L../lib ${OTHERLIBS} -lX11 -lXext -lXmu -lXi -lm -lc -bE:${EXPFILE} -bM:SRE ${ENTRY}
+
+
+# Make the .a file
+ar ruv ${LIBRARY} ${OFILE}
+
+# Put exports file in Mesa lib directory
+mv ${EXPFILE} ../lib
+
+# Remove OFILE
+rm -f ${OFILE}
+
+
+#NOTES
+# AIX 4.x /usr/bin/nm -B patch from ssclift@mach.me.queensu.ca (Simon Clift)
+# Robustified symbol extraction for AIX 3 and 4
+#   Greg Thompson <gregt@visix.com>
+

bin/mklib.ar-ruv

@@ -0,0 +1,38 @@
+#!/bin/sh
+
+# Make a standard Unix .a library file with 'ar ruv'
+
+#--identification------------------------------------------------------
+
+# $Id: mklib.ar-ruv,v 1.2 1999/09/15 15:10:20 brianp Exp $
+
+# $Log: mklib.ar-ruv,v $
+# Revision 1.2  1999/09/15 15:10:20  brianp
+# added third, tiny version number to arguments
+#
+# Revision 1.1  1999/08/19 13:52:57  brianp
+# initial check-in (post-crash)
+#
+
+
+#--common--------------------------------------------------------------
+
+LIBRARY=$1
+shift 1
+
+MAJOR=$1
+shift 1
+
+MINOR=$1
+shift 1
+
+TINY=$1
+shift 1
+
+OBJECTS=$*
+
+#--platform-------------------------------------------------------------
+
+#ar ruv $LIBRARY $OBJECTS
+ar ru $LIBRARY $OBJECTS
+

bin/shortlog_mesa.sh

@@ -1,23 +0,0 @@
-#!/bin/bash
-
-# This script is used to generate the list of changes that
-# appears in the release notes files, with HTML formatting.
-
-
-typeset -i in_log=0
-
-git shortlog $* | while read l
-do
-    if [ $in_log -eq 0 ]; then
-	echo '<p>'$l'</p>'
-	echo '<ul>'
-	in_log=1
-    elif echo "$l" | egrep -q '^$' ; then
-	echo '</ul>'
-	echo
-	in_log=0
-    else
-        mesg=$(echo $l | sed 's/ (cherry picked from commit [0-9a-f]\+)//;s/\&/&amp;/g;s/</\&lt;/g;s/>/\&gt;/g')
-	echo '  <li>'${mesg}'</li>'
-    fi
-done

common.py

@@ -1,103 +0,0 @@
-#######################################################################
-# Common SCons code
-
-import os
-import os.path
-import re
-import subprocess
-import sys
-import platform as _platform
-
-import SCons.Script.SConscript
-
-
-#######################################################################
-# Defaults
-
-host_platform = _platform.system().lower()
-if host_platform.startswith('cygwin'):
-    host_platform = 'cygwin'
-
-# Search sys.argv[] for a "platform=foo" argument since we don't have
-# an 'env' variable at this point.
-if 'platform' in SCons.Script.ARGUMENTS:
-    target_platform = SCons.Script.ARGUMENTS['platform']
-else:
-    target_platform = host_platform
-
-_machine_map = {
-	'x86': 'x86',
-	'i386': 'x86',
-	'i486': 'x86',
-	'i586': 'x86',
-	'i686': 'x86',
-	'BePC': 'x86',
-	'Intel': 'x86',
-	'ppc' : 'ppc',
-	'BeBox': 'ppc',
-	'BeMac': 'ppc',
-	'AMD64': 'x86_64',
-	'x86_64': 'x86_64',
-	'sparc': 'sparc',
-	'sun4u': 'sparc',
-}
-
-
-# find host_machine value
-if 'PROCESSOR_ARCHITECTURE' in os.environ:
-	host_machine = os.environ['PROCESSOR_ARCHITECTURE']
-else:
-	host_machine = _platform.machine()
-host_machine = _machine_map.get(host_machine, 'generic')
-
-default_machine = host_machine
-default_toolchain = 'default'
-
-if target_platform == 'windows' and host_platform != 'windows':
-    default_machine = 'x86'
-    default_toolchain = 'crossmingw'
-
-
-# find default_llvm value
-if 'LLVM' in os.environ:
-    default_llvm = 'yes'
-else:
-    default_llvm = 'no'
-    try:
-        if target_platform != 'windows' and \
-           subprocess.call(['llvm-config', '--version'], stdout=subprocess.PIPE) == 0:
-            default_llvm = 'yes'
-    except:
-        pass
-
-
-#######################################################################
-# Common options
-
-def AddOptions(opts):
-	try:
-		from SCons.Variables.BoolVariable import BoolVariable as BoolOption
-	except ImportError:
-		from SCons.Options.BoolOption import BoolOption
-	try:
-		from SCons.Variables.EnumVariable import EnumVariable as EnumOption
-	except ImportError:
-		from SCons.Options.EnumOption import EnumOption
-	opts.Add(EnumOption('build', 'build type', 'debug',
-	                  allowed_values=('debug', 'checked', 'profile', 'release')))
-	opts.Add(BoolOption('verbose', 'verbose output', 'no'))
-	opts.Add(EnumOption('machine', 'use machine-specific assembly code', default_machine,
-											 allowed_values=('generic', 'ppc', 'x86', 'x86_64')))
-	opts.Add(EnumOption('platform', 'target platform', host_platform,
-											 allowed_values=('cygwin', 'darwin', 'freebsd', 'haiku', 'linux', 'sunos', 'windows')))
-	opts.Add(BoolOption('embedded', 'embedded build', 'no'))
-	opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-	opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', 'no'))
-	opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
-	opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp (swrast)', 'no'))
-	opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes'))
-	opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no'))
-	opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
-	opts.Add(BoolOption('texture_float', 'enable floating-point textures and renderbuffers', 'no'))
-	if host_platform == 'windows':
-		opts.Add(EnumOption('MSVS_VERSION', 'MS Visual C++ version', None, allowed_values=('7.1', '8.0', '9.0')))

configs/.gitignore

@@ -1,2 +0,0 @@
-current
-autoconf

configs/current.in

@@ -1,221 +0,0 @@
-# Autoconf configuration
-
-# Pull in the defaults
-include $(TOP)/configs/default
-
-# This is generated by configure
-CONFIG_NAME = autoconf
-
-# Compiler and flags
-CC = @CC@
-CXX = @CXX@
-PIC_FLAGS = @PIC_FLAGS@
-DEFINES = @DEFINES@
-API_DEFINES = @API_DEFINES@
-SHARED_GLAPI = @SHARED_GLAPI@
-CFLAGS_NOVISIBILITY = @CPPFLAGS@ @CFLAGS@ \
-	$(PIC_FLAGS) $(DEFINES)
-CXXFLAGS_NOVISIBILITY = @CPPFLAGS@ @CXXFLAGS@ \
-	$(PIC_FLAGS) $(DEFINES)
-CFLAGS = $(CFLAGS_NOVISIBILITY) @VISIBILITY_CFLAGS@
-CXXFLAGS = $(CXXFLAGS_NOVISIBILITY) @VISIBILITY_CXXFLAGS@
-LDFLAGS = @LDFLAGS@
-RADEON_CFLAGS = @RADEON_CFLAGS@
-RADEON_LIBS = @RADEON_LIBS@
-NOUVEAU_CFLAGS = @NOUVEAU_CFLAGS@
-NOUVEAU_LIBS = @NOUVEAU_LIBS@
-INTEL_LIBS = @INTEL_LIBS@
-INTEL_CFLAGS = @INTEL_CFLAGS@
-X11_LIBS = @X11_LIBS@
-X11_CFLAGS = @X11_CFLAGS@
-LLVM_BINDIR = @LLVM_BINDIR@
-LLVM_CFLAGS = @LLVM_CFLAGS@
-LLVM_CPPFLAGS = @LLVM_CPPFLAGS@
-LLVM_CXXFLAGS = @LLVM_CXXFLAGS@
-LLVM_LDFLAGS = @LLVM_LDFLAGS@
-LLVM_LIBDIR = @LLVM_LIBDIR@
-LLVM_LIBS = @LLVM_LIBS@
-LLVM_INCLUDEDIR = @LLVM_INCLUDEDIR@
-GLW_CFLAGS = @GLW_CFLAGS@
-GLX_TLS = @GLX_TLS@
-
-# dlopen
-DLOPEN_LIBS = @DLOPEN_LIBS@
-
-# Source selection
-MESA_ASM_FILES = @MESA_ASM_FILES@
-
-# Misc tools and flags
-MAKE = @MAKE@
-SHELL = @SHELL@
-MKLIB_OPTIONS = @MKLIB_OPTIONS@
-MKDEP = @MKDEP@
-MKDEP_OPTIONS = @MKDEP_OPTIONS@
-INSTALL = @INSTALL@
-AWK = @AWK@
-GREP = @GREP@
-NM = @NM@
-
-# Perl
-PERL = @PERL@
-
-# Indent (used for generating dispatch tables)
-INDENT = @INDENT@
-INDENT_FLAGS = @INDENT_FLAGS@
-
-# Python and flags (generally only needed by the developers)
-PYTHON2 = @PYTHON2@
-PYTHON_FLAGS = -t -O -O
-
-# Flex and Bison for GLSL compiler
-FLEX = @LEX@
-BISON = @YACC@
-
-# Library names (base name)
-GL_LIB = @GL_LIB@
-GLU_LIB = @GLU_LIB@
-GLW_LIB = GLw
-OSMESA_LIB = @OSMESA_LIB@
-GLESv1_CM_LIB = GLESv1_CM
-GLESv2_LIB = GLESv2
-VG_LIB = OpenVG
-GLAPI_LIB = glapi
-
-# Library names (actual file names)
-GL_LIB_NAME = @GL_LIB_NAME@
-GLU_LIB_NAME = @GLU_LIB_NAME@
-GLW_LIB_NAME = @GLW_LIB_NAME@
-OSMESA_LIB_NAME = @OSMESA_LIB_NAME@
-EGL_LIB_NAME = @EGL_LIB_NAME@
-GLESv1_CM_LIB_NAME = @GLESv1_CM_LIB_NAME@
-GLESv2_LIB_NAME = @GLESv2_LIB_NAME@
-VG_LIB_NAME = @VG_LIB_NAME@
-GLAPI_LIB_NAME = @GLAPI_LIB_NAME@
-
-# Globs used to install the lib and all symlinks
-GL_LIB_GLOB = @GL_LIB_GLOB@
-GLU_LIB_GLOB = @GLU_LIB_GLOB@
-GLW_LIB_GLOB = @GLW_LIB_GLOB@
-EGL_LIB_GLOB = @EGL_LIB_GLOB@
-GLESv1_CM_LIB_GLOB = @GLESv1_CM_LIB_GLOB@
-GLESv2_LIB_GLOB = @GLESv2_LIB_GLOB@
-VG_LIB_GLOB = @VG_LIB_GLOB@
-GLAPI_LIB_GLOB = @GLAPI_LIB_GLOB@
-
-# Directories to build
-LIB_DIR = @LIB_DIR@
-SRC_DIRS = @SRC_DIRS@
-DRIVER_DIRS = @DRIVER_DIRS@
-GALLIUM_DIRS = @GALLIUM_DIRS@
-GALLIUM_DRIVERS_DIRS = @GALLIUM_DRIVERS_DIRS@
-GALLIUM_WINSYS_DIRS = @GALLIUM_WINSYS_DIRS@
-GALLIUM_TARGET_DIRS = @GALLIUM_TARGET_DIRS@
-GALLIUM_STATE_TRACKERS_DIRS = @GALLIUM_STATE_TRACKERS_DIRS@
-GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a
-GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a)
-
-# Driver specific build vars
-DRI_DIRS = @DRI_DIRS@
-EGL_PLATFORMS = @EGL_PLATFORMS@
-EGL_CLIENT_APIS = @EGL_CLIENT_APIS@
-
-# Dependencies
-X11_INCLUDES = @X11_INCLUDES@
-
-# GLw motif setup
-GLW_SOURCES = @GLW_SOURCES@
-MOTIF_CFLAGS = @MOTIF_CFLAGS@
-
-# Library/program dependencies
-GL_LIB_DEPS = @GL_LIB_DEPS@
-OSMESA_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @OSMESA_MESA_DEPS@ \
-	@OSMESA_LIB_DEPS@
-EGL_LIB_DEPS = @EGL_LIB_DEPS@
-GLU_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @GLU_MESA_DEPS@ \
-	@GLU_LIB_DEPS@
-GLW_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @GLW_MESA_DEPS@ \
-	@GLW_LIB_DEPS@
-GLESv1_CM_LIB_DEPS = @GLESv1_CM_LIB_DEPS@
-GLESv2_LIB_DEPS = @GLESv2_LIB_DEPS@
-VG_LIB_DEPS = @VG_LIB_DEPS@
-GLAPI_LIB_DEPS = @GLAPI_LIB_DEPS@
-
-# DRI dependencies
-DRI_LIB_DEPS = @DRI_LIB_DEPS@
-GALLIUM_DRI_LIB_DEPS = @GALLIUM_DRI_LIB_DEPS@
-LIBDRM_CFLAGS = @LIBDRM_CFLAGS@
-LIBDRM_LIB = @LIBDRM_LIBS@
-DRI2PROTO_CFLAGS = @DRI2PROTO_CFLAGS@
-GLPROTO_CFLAGS = @GLPROTO_CFLAGS@
-EXPAT_INCLUDES = @EXPAT_INCLUDES@
-
-# Autoconf directories
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-includedir = @includedir@
-
-# Installation directories (for make install)
-INSTALL_DIR = $(prefix)
-INSTALL_LIB_DIR = $(libdir)
-INSTALL_INC_DIR = $(includedir)
-
-# DRI installation directories
-DRI_DRIVER_INSTALL_DIR = @DRI_DRIVER_INSTALL_DIR@
-
-# Where libGL will look for DRI hardware drivers
-DRI_DRIVER_SEARCH_DIR = @DRI_DRIVER_SEARCH_DIR@
-
-# EGL driver install directory
-EGL_DRIVER_INSTALL_DIR = @EGL_DRIVER_INSTALL_DIR@
-
-# XVMC library install directory
-XVMC_LIB_INSTALL_DIR=@XVMC_LIB_INSTALL_DIR@
-
-# VDPAU library install directory
-VDPAU_LIB_INSTALL_DIR=@VDPAU_LIB_INSTALL_DIR@
-
-# VA library install directory
-VA_LIB_INSTALL_DIR=@VA_LIB_INSTALL_DIR@
-
-# Xorg driver install directory (for xorg state-tracker)
-XORG_DRIVER_INSTALL_DIR = @XORG_DRIVER_INSTALL_DIR@
-
-# Path to OpenCL C library libclc
-LIBCLC_PATH = @LIBCLC_PATH@
-
-# pkg-config substitutions
-GL_PC_REQ_PRIV = @GL_PC_REQ_PRIV@
-GL_PC_LIB_PRIV = @GL_PC_LIB_PRIV@
-GL_PC_CFLAGS = @GL_PC_CFLAGS@
-DRI_PC_REQ_PRIV = @DRI_PC_REQ_PRIV@
-GLU_PC_REQ = @GLU_PC_REQ@
-GLU_PC_REQ_PRIV = @GLU_PC_REQ_PRIV@
-GLU_PC_LIB_PRIV = @GLU_PC_LIB_PRIV@
-GLU_PC_CFLAGS = @GLU_PC_CFLAGS@
-GLW_PC_REQ_PRIV = @GLW_PC_REQ_PRIV@
-GLW_PC_LIB_PRIV = @GLW_PC_LIB_PRIV@
-GLW_PC_CFLAGS = @GLW_PC_CFLAGS@
-OSMESA_PC_REQ = @OSMESA_PC_REQ@
-OSMESA_PC_LIB_PRIV = @OSMESA_PC_LIB_PRIV@
-GLESv1_CM_PC_LIB_PRIV = @GLESv1_CM_PC_LIB_PRIV@
-GLESv2_PC_LIB_PRIV = @GLESv2_PC_LIB_PRIV@
-EGL_PC_REQ_PRIV = @GL_PC_REQ_PRIV@
-EGL_PC_LIB_PRIV = @GL_PC_LIB_PRIV@
-EGL_PC_CFLAGS = @GL_PC_CFLAGS@
-
-XCB_DRI2_CFLAGS = @XCB_DRI2_CFLAGS@
-XCB_DRI2_LIBS = @XCB_DRI2_LIBS@
-LIBUDEV_CFLAGS = @LIBUDEV_CFLAGS@
-LIBUDEV_LIBS = @LIBUDEV_LIBS@
-WAYLAND_CFLAGS = @WAYLAND_CFLAGS@
-WAYLAND_LIBS = @WAYLAND_LIBS@
-
-MESA_LLVM = @MESA_LLVM@
-
-LLVM_VERSION = @LLVM_VERSION@
-
-HAVE_XF86VIDMODE = @HAVE_XF86VIDMODE@
-
-GALLIUM_PIPE_LOADER_DEFINES = @GALLIUM_PIPE_LOADER_DEFINES@
-GALLIUM_PIPE_LOADER_LIBS = @GALLIUM_PIPE_LOADER_LIBS@

configs/default

@@ -1,180 +0,0 @@
-# Default/template configuration
-
-# This is included by other config files which may override some
-# of these variables.
-# Think of this as a base class from which configs are derived.
-
-
-CONFIG_NAME = default
-
-# Version info
-MESA_MAJOR=9
-MESA_MINOR=0
-MESA_TINY=1
-MESA_VERSION = $(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY)
-
-# external projects.  This should be useless now that we use libdrm.
-DRM_SOURCE_PATH=$(TOP)/../drm
-
-# Compiler and flags
-CC = cc
-CXX = CC
-CFLAGS = -O
-CXXFLAGS = -O
-LDFLAGS =
-GLU_CFLAGS = 
-GLX_TLS = no
-
-# Compiler for building demos/tests/etc
-APP_CC = $(CC)
-APP_CXX = $(CXX)
-
-# Misc tools and flags
-SHELL = /bin/sh
-MKLIB = $(SHELL) $(TOP)/bin/mklib
-MKLIB_OPTIONS = 
-MKDEP = makedepend
-MKDEP_OPTIONS = -fdepend
-MAKE = make
-FLEX = flex
-BISON = bison
-PKG_CONFIG = pkg-config
-
-# Use MINSTALL for installing libraries, INSTALL for everything else
-MINSTALL = $(SHELL) $(TOP)/bin/minstall
-INSTALL = $(MINSTALL)
-
-# Tools for regenerating glapi (generally only needed by the developers)
-PYTHON2 = python
-PYTHON_FLAGS = -t -O -O
-INDENT = indent
-INDENT_FLAGS = -i4 -nut -br -brs -npcs -ce -T GLubyte -T GLbyte -T Bool
-
-# Library names (base name)
-GL_LIB = GL
-GLU_LIB = GLU
-GLW_LIB = GLw
-OSMESA_LIB = OSMesa
-EGL_LIB = EGL
-GLESv1_CM_LIB = GLESv1_CM
-GLESv2_LIB = GLESv2
-VG_LIB = OpenVG
-GLAPI_LIB = glapi
-
-# Library names (actual file names)
-GL_LIB_NAME = lib$(GL_LIB).so
-GLU_LIB_NAME = lib$(GLU_LIB).so
-GLW_LIB_NAME = lib$(GLW_LIB).so
-OSMESA_LIB_NAME = lib$(OSMESA_LIB).so
-EGL_LIB_NAME = lib$(EGL_LIB).so
-GLESv1_CM_LIB_NAME = lib$(GLESv1_CM_LIB).so
-GLESv2_LIB_NAME = lib$(GLESv2_LIB).so
-VG_LIB_NAME = lib$(VG_LIB).so
-GLAPI_LIB_NAME = lib$(GLAPI_LIB).so
-
-# globs used to install the lib and all symlinks
-GL_LIB_GLOB = $(GL_LIB_NAME)*
-GLU_LIB_GLOB = $(GLU_LIB_NAME)*
-GLW_LIB_GLOB = $(GLW_LIB_NAME)*
-EGL_LIB_GLOB = $(EGL_LIB_NAME)*
-GLESv1_CM_LIB_GLOB = $(GLESv1_CM_LIB_NAME)*
-GLESv2_LIB_GLOB = $(GLESv2_LIB_NAME)*
-VG_LIB_GLOB = $(VG_LIB_NAME)*
-GLAPI_LIB_GLOB = $(GLAPI_LIB_NAME)*
-
-# Optional assembly language optimization files for libGL
-MESA_ASM_FILES =
-
-# GLw widget sources (Append "GLwMDrawA.c" here and add -lXm to GLW_LIB_DEPS in
-# order to build the Motif widget too)
-GLW_SOURCES = GLwDrawA.c
-MOTIF_CFLAGS = -I/usr/include/Motif1.2
-
-
-# Directories to build
-LIB_DIR = lib
-SRC_DIRS = glsl mapi/glapi mapi/vgapi mesa \
-	gallium egl gallium/winsys gallium/targets
-DRIVER_DIRS = x11 osmesa
-
-# Gallium directories and
-GALLIUM_DIRS = auxiliary drivers state_trackers
-GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a
-GALLIUM_DRIVERS_DIRS = softpipe trace rbug noop identity galahad i915 svga r300 nvfx nv50
-GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a)
-GALLIUM_WINSYS_DIRS = sw sw/xlib
-GALLIUM_TARGET_DIRS = libgl-xlib
-GALLIUM_STATE_TRACKERS_DIRS = glx vega
-
-# native platforms EGL should support
-EGL_PLATFORMS = x11
-EGL_CLIENT_APIS = $(GL_LIB)
-
-# Library dependencies
-#EXTRA_LIB_PATH ?=
-GL_LIB_DEPS     = -lX11 -lXext -lm -lpthread
-EGL_LIB_DEPS    = -ldl -lpthread
-OSMESA_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB)
-GLU_LIB_DEPS    = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -lm
-GLW_LIB_DEPS    = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -lXt -lX11
-GLESv1_CM_LIB_DEPS = -lpthread
-GLESv2_LIB_DEPS = -lpthread
-VG_LIB_DEPS    = -lpthread
-GLAPI_LIB_DEPS = -lpthread
-
-# Program dependencies - specific GL libraries added in Makefiles
-X11_LIBS = -lX11
-
-DLOPEN_LIBS = -ldl
-
-# Installation directories (for make install)
-INSTALL_DIR = /usr/local
-INSTALL_LIB_DIR = $(INSTALL_DIR)/$(LIB_DIR)
-INSTALL_INC_DIR = $(INSTALL_DIR)/include
-DRI_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/dri
-
-# Where libGL will look for DRI hardware drivers
-DRI_DRIVER_SEARCH_DIR = $(DRI_DRIVER_INSTALL_DIR)
-
-# EGL driver install directory
-EGL_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/egl
-
-# Xorg driver install directory (for xorg state-tracker)
-XORG_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/xorg/modules/drivers
-
-# pkg-config substitutions
-GL_PC_REQ_PRIV =
-GL_PC_LIB_PRIV =
-GL_PC_CFLAGS =
-DRI_PC_REQ_PRIV =
-GLU_PC_REQ = gl
-GLU_PC_REQ_PRIV =
-GLU_PC_LIB_PRIV =
-GLU_PC_CFLAGS =
-GLW_PC_REQ_PRIV =
-GLW_PC_LIB_PRIV =
-GLW_PC_CFLAGS =
-OSMESA_PC_REQ =
-OSMESA_PC_LIB_PRIV =
-GLESv1_CM_PC_REQ_PRIV =
-GLESv1_CM_PC_LIB_PRIV =
-GLESv1_CM_PC_CFLAGS =
-GLESv2_PC_REQ_PRIV =
-GLESv2_PC_LIB_PRIV =
-GLESv2_PC_CFLAGS =
-VG_PC_REQ_PRIV =
-VG_PC_LIB_PRIV =
-VG_PC_CFLAGS =
-
-# default targets
-# this helps reduce the mismatch between our automake Makefiles and the old
-# custom Makefiles while we transition.
-
-all: default
-
-am--refresh:
-
-distclean: clean
-
-check:
-test:

descrip.mms

@@ -0,0 +1,21 @@
+# Makefile for Mesa for VMS
+# contributed by Jouk Jansen  joukj@hrem.stm.tudelft.nl
+
+macro : 
+        @ macro=""
+.ifdef NOSHARE
+.else
+	@ if f$getsyi("HW_MODEL") .ge. 1024 then macro= "/MACRO=(SHARE=1)"
+.endif
+	$(MMS)$(MMSQUALIFIERS)'macro' all
+
+all :
+	if f$search("lib.dir") .eqs. "" then create/directory [.lib]
+	set default [.src]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.progs.demos]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.xdemos]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.tests]
+	$(MMS)$(MMSQUALIFIERS)

docs/ARB_color_buffer_float.txt

@@ -1,4 +0,0 @@
-Known issues in the ARB_color_buffer_float implementation:
-- Rendering to multiple render targets, some fixed-point, some floating-point, with FIXED_ONLY fragment clamping and polygon smooth enabled may write incorrect values to the fixed point buffers (depends on spec interpretation)
-- For fragment programs with ARB_fog_* options, colors are clamped before fog application regardless of the fragment clamping setting (this depends on spec interpretation)
-

docs/GL3.txt

@@ -1,164 +0,0 @@
-
-Status of OpenGL 3.x features in Mesa
-
-
-Note: when an item is marked as "DONE" it means all the core Mesa
-infrastructure is complete but it may be the case that few (if any) drivers
-implement the features.
-
-
-Feature                                               Status
------------------------------------------------------ ------------------------
-
-GL 3.0:
-
-GLSL 1.30                                             DONE
-glBindFragDataLocation, glGetFragDataLocation         DONE
-Conditional rendering (GL_NV_conditional_render)      DONE (i965, r300, r600, swrast)
-Map buffer subranges (GL_ARB_map_buffer_range)        DONE (i965, r300, r600, swrast)
-Clamping controls (GL_ARB_color_buffer_float)         DONE (i965, r300, r600)
-Float textures, renderbuffers (GL_ARB_texture_float)  DONE (i965, r300, r600)
-GL_EXT_packed_float                                   DONE (i965, r600)
-GL_EXT_texture_shared_exponent                        DONE (i965, r600, swrast)
-Float depth buffers (GL_ARB_depth_buffer_float)       DONE (i965, r600)
-Framebuffer objects (GL_ARB_framebuffer_object)       DONE (i965, r300, r600, swrast)
-Half-float                                            DONE
-Non-normalized Integer texture/framebuffer formats    DONE (i965)
-1D/2D Texture arrays                                  DONE
-Per-buffer blend and masks (GL_EXT_draw_buffers2)     DONE (i965, r600, swrast)
-GL_EXT_texture_compression_rgtc                       DONE (i965, r300, r600, swrast)
-Red and red/green texture formats                     DONE (i965, swrast, gallium)
-Transform feedback (GL_EXT_transform_feedback)        DONE (i965)
-Vertex array objects (GL_APPLE_vertex_array_object)   DONE (i965, r300, r600, swrast)
-sRGB framebuffer format (GL_EXT_framebuffer_sRGB)     DONE (i965, r600)
-glClearBuffer commands                                DONE
-glGetStringi command                                  DONE
-glTexParameterI, glGetTexParameterI commands          DONE
-glVertexAttribI commands                              ~50% done (converts int
-                                                                 values to floats)
-Depth format cube textures                            DONE
-GLX_ARB_create_context (GLX 1.4 is required)          DONE
-
-
-GL 3.1:
-
-GLSL 1.40                                             DONE (i965)
-Forward compatibile context support/deprecations      DONE (i965)
-Instanced drawing (GL_ARB_draw_instanced)             DONE (i965, gallium, swrast)
-Buffer copying (GL_ARB_copy_buffer)                   DONE (i965, r300, r600, swrast)
-Primitive restart (GL_NV_primitive_restart)           DONE (i965, r600)
-16 vertex texture image units                         DONE
-Texture buffer objs (GL_ARB_texture_buffer_object)    DONE for OpenGL 3.1 contexts (i965)
-Rectangular textures (GL_ARB_texture_rectangle)       DONE (i965, r300, r600, swrast)
-Uniform buffer objs (GL_ARB_uniform_buffer_object)    DONE (i965)
-Signed normalized textures (GL_EXT_texture_snorm)     DONE (i965, r300, r600)
-
-
-GL 3.2:
-
-Core/compatibility profiles                           DONE
-GLSL 1.50                                             not started
-Geometry shaders (GL_ARB_geometry_shader4)            partially done (Zack)
-BGRA vertex order (GL_ARB_vertex_array_bgra)          DONE (i965, r300, r600, swrast)
-Base vertex offset(GL_ARB_draw_elements_base_vertex)  DONE (i965, r300, r600, swrast)
-Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (i965, r300, r600, swrast)
-Provoking vertex (GL_ARB_provoking_vertex)            DONE (i965, r300, r600, swrast)
-Seamless cubemaps (GL_ARB_seamless_cube_map)          DONE (i965, r600)
-Multisample textures (GL_ARB_texture_multisample)     not started
-Frag depth clamp (GL_ARB_depth_clamp)                 DONE (i965, r600, swrast)
-Fence objects (GL_ARB_sync)                           DONE (i965, r300, r600, swrast)
-GLX_ARB_create_context_profile                        DONE
-
-
-GL 3.3:
-
-GLSL 3.30                                             new features in this version pretty much done
-GL_ARB_blend_func_extended                            DONE (i965, r600, softpipe)
-GL_ARB_explicit_attrib_location                       DONE (i915, i965, r300, r600, swrast)
-GL_ARB_occlusion_query2                               DONE (i965, r300, r600, swrast)
-GL_ARB_sampler_objects                                DONE (i965, r300, r600)
-GL_ARB_shader_bit_encoding                            DONE
-GL_ARB_texture_rgb10_a2ui                             DONE (i965, r600)
-GL_ARB_texture_swizzle                                DONE (same as EXT version) (i965, r300, r600, swrast)
-GL_ARB_timer_query                                    DONE (i965)
-GL_ARB_instanced_arrays                               DONE (i965, r300, r600)
-GL_ARB_vertex_type_2_10_10_10_rev                     DONE (r600)
-
-
-GL 4.0:
-
-GLSL 4.0                                             not started
-GL_ARB_texture_query_lod                             not started
-GL_ARB_draw_buffers_blend                            DONE (i965, r600, softpipe)
-GL_ARB_draw_indirect                                 not started
-GL_ARB_gpu_shader5                                   not started
-GL_ARB_gpu_shader_fp64                               not started
-GL_ARB_sample_shading                                not started
-GL_ARB_shader_subroutine                             not started
-GL_ARB_tessellation_shader                           not started
-GL_ARB_texture_buffer_object_rgb32                   not started
-GL_ARB_texture_cube_map_array                        not started
-GL_ARB_texture_gather                                not started
-GL_ARB_transform_feedback2                           DONE
-GL_ARB_transform_feedback3                           DONE
-
-
-GL 4.1:
-
-GLSL 4.1                                             not started
-GL_ARB_ES2_compatibility                             DONE (i965, r300, r600)
-GL_ARB_get_program_binary                            not started
-GL_ARB_separate_shader_objects                       some infrastructure done
-GL_ARB_shader_precision                              not started
-GL_ARB_vertex_attrib_64bit                           not started
-GL_ARB_viewport_array                                not started
-
-
-GL 4.2:
-
-GLSL 4.2                                             not started
-GL_ARB_texture_compression_bptc                      not started
-GL_ARB_compressed_texture_pixel_storage              not started
-GL_ARB_shader_atomic_counters                        not started
-GL_ARB_texture_storage                               DONE (r300, r600, swrast)
-GL_ARB_transform_feedback_instanced                  DONE
-GL_ARB_base_instance                                 DONE (nv50, nvc0, r600, radeonsi)
-GL_ARB_shader_image_load_store                       not started
-GL_ARB_conservative_depth                            DONE (softpipe)
-GL_ARB_shading_language_420pack                      not started
-GL_ARB_internalformat_query                          not started
-GL_ARB_map_buffer_alignment                          not started
-
-
-GL 4.3:
-
-GLSL 4.3                                             not started
-ARB_arrays_of_arrays                                 not started
-ARB_ES3_compatibility                                not started
-ARB_clear_buffer_object                              not started
-ARB_compute_shader                                   started (gallium)
-ARB_copy_image                                       not started
-ARB_debug_group                                      not started
-ARB_debug_label                                      not started
-ARB_debug_output                                     DONE
-ARB_debug_output2                                    not started
-ARB_explicit_uniform_location                        not started
-ARB_fragment_layer_viewport                          not started
-ARB_framebuffer_no_attachments                       not started
-ARB_internalformat_query2                            not started
-ARB_invalidate_subdata                               not started
-ARB_multi_draw_indirect                              not started
-ARB_program_interface_query                          not started
-ARB_robust_buffer_access_behavior                    not started
-ARB_shader_image_size                                not started
-ARB_shader_storage_buffer_object                     not started
-ARB_stencil_texturing                                not started
-ARB_texture_buffer_range                             not started
-ARB_texture_query_levels                             not started
-ARB_texture_storage_multisample                      not started
-ARB_texture_view                                     not started
-ARB_vertex_attrib_binding                            not started
-
-
-More info about these features and the work involved can be found at
-http://dri.freedesktop.org/wiki/MissingFunctionality

docs/INSTALL.GNU

@@ -0,0 +1,182 @@
+Basic Installation
+==================
+
+   These are generic installation instructions.
+
+   The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation.  It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions.  Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, a file
+`config.cache' that saves the results of its tests to speed up
+reconfiguring, and a file `config.log' containing compiler output
+(useful mainly for debugging `configure').
+
+   If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release.  If at some point `config.cache'
+contains results you don't want to keep, you may remove or edit it.
+
+   The file `configure.in' is used to create `configure' by a program
+called `autoconf'.  You only need `configure.in' if you want to change
+it or regenerate `configure' using a newer version of `autoconf'.
+
+The simplest way to compile this package is:
+
+  1. `cd' to the directory containing the package's source code and type
+     `./configure' to configure the package for your system.  If you're
+     using `csh' on an old version of System V, you might need to type
+     `sh ./configure' instead to prevent `csh' from trying to execute
+     `configure' itself.
+
+     Running `configure' takes awhile.  While running, it prints some
+     messages telling which features it is checking for.
+
+  2. Type `make' to compile the package.
+
+  3. Optionally, type `make check' to run any self-tests that come with
+     the package.
+
+  4. Type `make install' to install the programs and any data files and
+     documentation.
+
+  5. You can remove the program binaries and object files from the
+     source code directory by typing `make clean'.  To also remove the
+     files that `configure' created (so you can compile the package for
+     a different kind of computer), type `make distclean'.  There is
+     also a `make maintainer-clean' target, but that is intended mainly
+     for the package's developers.  If you use it, you may have to get
+     all sorts of other programs in order to regenerate files that came
+     with the distribution.
+
+Compilers and Options
+=====================
+
+   Some systems require unusual options for compilation or linking that
+the `configure' script does not know about.  You can give `configure'
+initial values for variables by setting them in the environment.  Using
+a Bourne-compatible shell, you can do that on the command line like
+this:
+     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+
+Or on systems that have the `env' program, you can do it like this:
+     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+
+Compiling For Multiple Architectures
+====================================
+
+   You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory.  To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'.  `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script.  `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+   If you have to use a `make' that does not supports the `VPATH'
+variable, you have to compile the package for one architecture at a time
+in the source code directory.  After you have installed the package for
+one architecture, use `make distclean' before reconfiguring for another
+architecture.
+
+Installation Names
+==================
+
+   By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc.  You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PATH'.
+
+   You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files.  If you
+give `configure' the option `--exec-prefix=PATH', the package will use
+PATH as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+   In addition, if you use an unusual directory layout you can give
+options like `--bindir=PATH' to specify different values for particular
+kinds of files.  Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+   If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+   Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System).  The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+   For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+   There may be some features `configure' can not figure out
+automatically, but needs to determine by the type of host the package
+will run on.  Usually `configure' can figure that out, but if it prints
+a message saying it can not guess the host type, give it the
+`--host=TYPE' option.  TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name with three fields:
+     CPU-COMPANY-SYSTEM
+
+See the file `config.sub' for the possible values of each field.  If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the host type.
+
+   If you are building compiler tools for cross-compiling, you can also
+use the `--target=TYPE' option to select the type of system they will
+produce code for and the `--build=TYPE' option to select the type of
+system on which you are compiling the package.
+
+Sharing Defaults
+================
+
+   If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists.  Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Operation Controls
+==================
+
+   `configure' recognizes the following options to control how it
+operates.
+
+`--cache-file=FILE'
+     Use and save the results of the tests in FILE instead of
+     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
+     debugging `configure'.
+
+`--help'
+     Print a summary of the options to `configure', and exit.
+
+`--quiet'
+`--silent'
+`-q'
+     Do not print messages saying which checks are being made.  To
+     suppress all normal output, redirect it to `/dev/null' (any error
+     messages will still be shown).
+
+`--srcdir=DIR'
+     Look for the package's source code in directory DIR.  Usually
+     `configure' can determine that directory automatically.
+
+`--version'
+     Print the version of Autoconf used to generate the `configure'
+     script, and exit.
+
+`configure' also accepts some other, not widely useful, options.

docs/MESA_agp_offset.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -48,7 +48,7 @@ Issues
 
 New Procedures and Functions
 
-    unsigned int glXGetAGPOffsetMESA( const void *pointer )
+    GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
 
 New Tokens
 
@@ -67,7 +67,7 @@ Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
     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
+    aperature.  The function
 
         GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
 
@@ -92,4 +92,3 @@ 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

docs/MESA_copy_sub_buffer.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 
@@ -16,7 +16,7 @@ Status
 
 Version
 
-    Last Modified Date:  12 January 2009
+    Last Modified Date:  8 June 2000
 
 Number
 
@@ -69,12 +69,6 @@ Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
     <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
@@ -90,7 +84,5 @@ New State
 
 Revision History
 
-    12 January 2009 Ian Romanick - Added language about implicit flush
-                                   and command completion.
-    8 June 2000     Brian Paul   - initial specification
+    8 June 2000 - initial specification
 

docs/MESA_drm_image.spec

@@ -1,153 +0,0 @@
-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.

docs/MESA_multithread_makecurrent.spec

@@ -1,158 +0,0 @@
-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.

docs/MESA_pack_invert.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -48,7 +48,7 @@ IP Status
 
 Issues
 
-    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
+    1. Should we also defined 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

docs/MESA_packed_depth_stencil.spec

@@ -17,6 +17,7 @@ Status
 
 Version
 
+    $Id: MESA_packed_depth_stencil.spec,v 1.2 2003/09/19 14:58:21 brianp Exp $
 
 Number
 

docs/MESA_pixmap_colormap.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 

docs/MESA_program_debug.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian @ tungstengraphics.com)
 
 Status
 
@@ -18,6 +18,7 @@ Version
 
     Last Modified Date: July 20, 2003
     Author Revision: 1.0
+    $Date: 2003/09/23 14:46:11 $ $Revision: 1.3 $
 
 Number
 

docs/MESA_release_buffers.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 
@@ -31,12 +31,12 @@ 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
+    destroyed in order to free any ancilliary 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.
+    when the back color buffer, depth buffer, stencil buffer, and/or accum-
+    ulation buffer associated with a drawable can be freed.
 
 IP Status
 
@@ -60,7 +60,7 @@ Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
 
 	Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
 
-    causes all software ancillary buffers (back buffer, depth, stencil,
+    causes all software ancilliary 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

docs/MESA_resize_buffers.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, brianp 'at' mesa3d.org
 
 Status
 
@@ -16,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_resize_buffers.spec,v 1.2 2000/04/04 23:29:32 brianp Exp $
 
 Number
 
@@ -35,7 +36,7 @@ Overview
 
     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
+    since most applications call glViewport in responce to window size
     changes.
 
     In some situations, however, the application may not call glViewport
@@ -65,7 +66,7 @@ Additions to the AGL/GLX/WGL Specifications
 
 Errors
 
-    INVALID_OPERATION is generated if glResizeBuffersMESA is called between
+    INVALID_OPERATION is generated if ResizeBuffersMESA is called betweeen
     Begin and End.
 
 New State

docs/MESA_set_3dfx_mode.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 

docs/MESA_shader_debug.spec

@@ -1,264 +0,0 @@
-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.

docs/MESA_sprite_point.spec

@@ -16,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_sprite_point.spec,v 1.2 2003/09/19 14:58:21 brianp Exp $
 
 Number
 

docs/MESA_swap_control.spec

@@ -43,7 +43,7 @@ Issues
 
 New Procedures and Functions
 
-    int glXSwapIntervalMESA(unsigned int interval)
+    int glXSwapIntervalMESA(int interval)
     int glXGetSwapIntervalMESA(void)
 
 New Tokens
@@ -88,8 +88,8 @@ Additions to the GLX 1.3 Specification
     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
+    If <interval> is set to a value of 0, buffer swaps are not synchron-
+    ized to a video frame.  The <interval> value is silently clamped to
     the maximum implementation-dependent value supported before being
     stored.
 
@@ -103,8 +103,11 @@ Additions to the GLX 1.3 Specification
 
 Errors
 
+    glXSwapIntervalMESA returns GLX_BAD_VALUE if parameter <interval> is
+    less than zero.
+
     glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
-    GLXContext or if the current context is not a direct rendering context.
+    GLXContext.
 
 GLX Protocol
 

docs/MESA_swap_frame_usage.spec

@@ -32,7 +32,7 @@ Dependencies
 
 Overview
 
-    This extension allows an application to determine what portion of the
+    This extension allows an application to deterine 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:
@@ -59,7 +59,7 @@ Overview
     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.
+    issuance of a swap and the swap actually occuring.
 
     There is also a mechanism to determine whether a frame swap was
     missed.
@@ -110,7 +110,7 @@ Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
 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
+    between two buffer-swap operations being commited.  In unextened 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
@@ -119,7 +119,7 @@ Additions to the GLX 1.3 Specification
     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
+    the swap is commited 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.
 
@@ -143,7 +143,7 @@ Additions to the GLX 1.3 Specification
 
     The current missed frame count and total number of swaps since
     the last call to glXBeginFrameTrackingMESA can be obtained by
-    calling the following function:
+    callling the following function:
 
        int glXQueryFrameTrackingMESA(Display *dpy,
                                      GLXDrawable drawable,
@@ -152,7 +152,7 @@ Additions to the GLX 1.3 Specification
                                      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 commited.  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.
@@ -171,7 +171,7 @@ Additions to the GLX 1.3 Specification
     application can call glXQueryFrameTrackingMESA for a final swap and
     missed frame count.
 
-    If these functions are successful, zero is returned.  If the context
+    If these functions are succesful, zero is returned.  If the context
     associated with dpy and drawable is not a direct context,
     GLX_BAD_CONTEXT is returned.
 

docs/MESA_texture_array.spec

@@ -1,804 +0,0 @@
-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.||

docs/MESA_texture_signed_rgba.spec

@@ -1,214 +0,0 @@
-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.

docs/MESA_trace.spec

@@ -4,7 +4,7 @@ Name
 
 Name Strings
 
-     GL_MESA_trace
+     GL_MESA_TRACE
 
 Contact
     
@@ -17,6 +17,7 @@ Status
 
 Version
 
+    $Id: MESA_trace.spec,v 1.3 2003/09/19 14:58:21 brianp Exp $
 
 Number
 

docs/MESA_window_pos.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, brian.paul 'at' tungstengraphics.com
+    Brian Paul, brianp 'at' mesa3d.org
 
 Status
 
@@ -16,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_window_pos.spec,v 1.3 2000/04/04 23:29:32 brianp Exp $
 
 Number
 
@@ -88,7 +89,7 @@ Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
       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).
+      implicititly 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
@@ -108,7 +109,7 @@ GLX Protocol
 
 Errors
 
-    INVALID_OPERATION is generated if WindowPosMESA is called between
+    INVALID_OPERATION is generated if WindowPosMESA is called betweeen
     Begin and End.
 
 New State

docs/MESA_ycbcr_texture.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -26,7 +26,7 @@ Number
 Dependencies
 
     OpenGL 1.0 or later is required
-    This extension is written against the OpenGL 1.4 Specification.
+    This extensions is written against the OpenGL 1.4 Specification.
     NV_texture_rectangle effects the definition of this extension.
 
 Overview
@@ -75,14 +75,14 @@ Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
 
 Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
 
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
     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
+    UNSIGNED_SHORT_8_8_MESA       ushort         3         YCBCR_422_MESA
+    UNSIGNED_SHORT_8_8_REV_MESA   ushort         3         YCBCR_422_MESA
 
 
     In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
@@ -103,13 +103,13 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
     +-------------------------------+-------------------------------+
 
 
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
-    add the following to Table 3.12 (Packed pixel field assignments):
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
+    add the following to Table 3.12 (Packed pixel fiedl assignments):
 
                        First       Second     Third      Fourth
     Format             Element     Element    Element    Element
     ------             -------     -------    -------    -------
-    YCBCR_MESA         luminance   chroma
+    YCBCR_422_MESA     luminance   chroma
 
 
     In section 3.8.1, Texture Image Specification, on page 125, add
@@ -201,4 +201,3 @@ Revision History
      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

docs/MiniGLX.html

@@ -0,0 +1,547 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Mini GLX Specification</title>
+</head>
+<body>
+<h1>
+<center>Mini GLX Specification</center>
+</h1>
+<h2>
+<center>Tungsten Graphics, Inc.<br>
+<br>
+January 20, 2003<br>
+<br>
+</center>
+</h2>
+<p> Copyright &copy; 2002-2003 by Tungsten Graphics, Inc., Cedar Park,
+Texas. All Rights Reserved. <br>
+<br>
+Permission is granted to make and distribute verbatim copies of this
+document provided the copyright notice and this permission notice are
+preserved on all copies.<br>
+<br>
+</p>
+<h1>1. Introduction</h1>
+<p>The Mini GLX interface facilitates OpenGL rendering on embedded
+devices. The interface is a subset of the GLX interface, plus a minimal
+set of Xlib-like functions.</p>
+<p>Programs written to the Mini GLX specification should run unchanged
+on systems with the X Window System and the GLX extension. The intention
+is to allow flexibility for prototyping and testing.</p>
+<p>This document serves as both the reference guide and programming
+guide for Mini GLX.<br>
+<br>
+</p>
+<h1>2. Mini GLX Concepts</h1>
+<p>The OpenGL specification does not describe how OpenGL rendering
+contexts and drawing surfaces (i.e. the frame buffer) are created and
+managed. Rather, this is handled by an OpenGL window system interface,
+such as Mini GLX.</p>
+<p>There are three main datatypes or resources managed by Mini GLX. The
+resources and their corresponding GLX or Xlib data types are:</p>
+<table cellspacing="10" align="center">
+  <tbody>
+    <tr>
+      <td><u>Resource</u></td>
+      <td><u>Data type</u></td>
+    </tr>
+    <tr>
+      <td>pixel formats</td>
+      <td>X Visual and XVisualInfo</td>
+    </tr>
+    <tr>
+      <td>drawing surfaces</td>
+      <td>X Window or GLXDrawable</td>
+    </tr>
+    <tr>
+      <td>rendering contexts</td>
+      <td>GLXContext</td>
+    </tr>
+  </tbody>
+</table>
+<p>Pixel formats or X Visuals describe the per-pixel attributes of the
+frame buffer.  For example, bits per color component, Z buffer size,
+stencil size, TrueColor vs PseudoColor, etc.</p>
+<p>Drawing surfaces or X Windows typically describe a spatial
+allocation of the frame buffer (i.e. the position and size of a
+rectangular region of pixels).  Since MiniGLX doesn't really support a
+window system, the window is effectively the entire frame buffer.</p>
+<p>A rendering context represents the current OpenGL state such as
+current drawing color, line width, blending mode, texture parameters,
+etc. Several rendering contexts can be created but only one can be in
+use at any given time.</p>
+<p>The Mini GLX interface provides all the functions needed for
+choosing pixel formats, create drawing surfaces, creating rendering
+contexts and binding rendering contexts to drawing surfaces.<br>
+<br>
+</p>
+<h1>3. Using Mini GLX</h1>
+<p>To use the Mini GLX interface in your application, include the
+GL/miniglx.h header file at compile time:</p>
+<blockquote><code>	#include &lt;GL/miniglx.h&gt;<br>
+  </code></blockquote>
+<code></code>Applications should link with libGL.so (i.e. <code>gcc
+myprogram.o -lGL -o myprogram</code>). &nbsp;libGL.so implements the
+MiniGLX API functions and, in turn, loads a hardware-specific device
+driver (such as <code>radeon_dri.so</code>) at runtime. &nbsp;The
+environment variable <code>LIBGL_DRIVERS_PATH</code> should name the
+directory where these modules are located.<br>
+<br>
+Prior to running a MiniGXL application, the following kernel modules
+must be installed:<br>
+<br>
+<div style="margin-left: 40px;"> agpgart.o<br>
+radeonfb.o &nbsp;(assuming Radeon hardware)<br>
+radeon.o &nbsp;(assuming Radeon hardware)<br>
+</div>
+<code></code> <br>
+Finally, MiniGLX reads a configuration file (by default,<code>
+/etc/miniglx.conf</code>) to determine basic configuration information.
+&nbsp;The configuration file may also be located in the directory
+specified by the <code>MINIGLX_CONF</code> environment variable).<br>
+<br>
+The remainder of this section describes the MiniGLX API functions.<br>
+<br>
+<h2>3.1 Initialization</h2>
+<p>The XOpenDisplay function is used to initialize the graphics system:</p>
+<blockquote>
+  <pre>Display *XOpenDisplay(const char *displayname)<br></pre>
+</blockquote>
+<p>The <code>displayName</code> parameter is currently ignored in Mini
+GLX. It is recommended that <code>NULL</code> be passed as the<code>displayName</code>
+parameter.</p>
+<p>If XOpenDisplay is able to initialize the graphics system a pointer
+to a Display will be returned.  Otherwise, NULL will be returned.</p>
+<h2>3.2 Choosing a Visual</h2>
+<p>A visual (i.e. pixel format) must be chosen before a drawing surface
+or rendering context can be created.  This is done with the
+glXChooseVisual function:</p>
+<blockquote>
+  <pre>XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)<br></pre>
+</blockquote>
+<p><code>dpy</code> is a pointer to the display returned by
+XOpenDisplay. </p>
+<p><code>screen</code> is currently ignored by Mini GLX and should be
+zero. </p>
+<p><code>attribList</code> is a list of GLX attributes which describe
+the desired pixel format.  It is terminated by the token <code>None</code>.
+The attributes are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>GLX_USE_GL</code></dt>
+    <dd>This attribute should always be present in order to maintain
+compatibility with GLX.</dd>
+    <dt><code>GLX_RGBA</code></dt>
+    <dd>If present, only RGBA pixel formats will be considered.
+Otherwise, only color index formats are considered.</dd>
+    <dt><code>GLX_DOUBLEBUFFER</code></dt>
+    <dd>if present, only double-buffered pixel formats will	be chosen.</dd>
+    <dt><code>GLX_RED_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per red pixel component that is acceptable.</dd>
+    <dt><code>GLX_GREEN_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per green pixel component that is acceptable.</dd>
+    <dt><code>GLX_BLUE_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per blue pixel component that is acceptable.</dd>
+    <dt><code>GLX_ALPHA_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per alpha pixel component that is acceptable.</dd>
+    <dt><code>GLX_STENCIL_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per stencil value that is acceptable.</dd>
+    <dt><code>None</code></dt>
+    <dd>This token is used to terminate the attribute list.</dd>
+  </dl>
+</blockquote>
+<p>glXChooseVisual will return a pointer to an XVisualInfo object which
+most closely matches the requirements of the attribute list.  If there
+is no visual which matches the request, NULL will be returned.</p>
+<p>Note that visuals with accumulation buffers and depth buffers are
+not available.<br>
+<br>
+</p>
+<h2>3.3 Creating a Drawing Surface</h2>
+<p>Drawing surfaces are created as X windows. &nbsp;For Mini GLX,
+windows are <i>full-screen</i>; they cover the entire frame buffer.
+&nbsp;Also, Mini GLX imposes a limit of one window.  A second window
+cannot be created until the first one is destroyed.</p>
+<h3>3.3.1 Window Creation</h3>
+<p>The XCreateWindow function is used to create a drawing surface:</p>
+<blockquote>
+  <pre>Window XCreateWindow( Display *display,<br>                      Window parent,<br>                      int x, int y,<br>                      unsigned int width, unsigned int height,<br>                      unsigned int borderWidth,<br>                      int depth,<br>                      unsigned int class,<br>                      Visual *visual,<br>                      unsigned long valuemask,<br>                      XSetWindowAttributes *attributes )<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>display</code></dt>
+    <dd>A Display pointer, as returned by XOpenDisplay.</dd>
+    <dt><code>parent</code></dt>
+    <dd>The parent window for the new window.  For Mini GLX, this
+should be<code>RootWindow(dpy, 0)</code>.</dd>
+    <dt><code>x, y</code></dt>
+    <dd>The position of the window.  For Mini GLX, both values should
+be zero.</dd>
+    <dt><code>width, height</code></dt>
+    <dd>The size of the window.  For Mini GLX, this specifies the
+desired screen size such as 1024, 768 or 1280, 1024.</dd>
+    <dt><code>borderWidth</code></dt>
+    <dd>This parameter should be zero.</dd>
+    <dt><code>depth</code></dt>
+    <dd>The pixel depth for the window.  For Mini GLX this should be
+the depth found in the XVisualInfo object returned by <code>glxChooseVisual</code>.</dd>
+    <dt><code>class</code></dt>
+    <dd>The window class.  For Mini GLX this value should be <code>InputOutput</code>.</dd>
+    <dt><code>visual</code></dt>
+    <dd>This parameter should be the <code>visual</code> field of the <code>XVisualInfo</code>
+object returned by <code>glxChooseVisual</code>.</dd>
+    <dt><code>valuemask</code></dt>
+    <dd>This parameter indicates which fields of the <code>XSetWindowAttributes</code>
+are to be used. For Mini GLX this is typically the bitmask<code>CWBackPixel
+| CWBorderPixel | CWColormap</code>.</dd>
+    <dt><code>attributes</code></dt>
+    <dd>Initial window attributes. Of the fields in the <code>XSetWindowAttributes</code>
+structure, the<code>background_pixel</code>, <code>border_pixel</code>
+and <code>colormap</code> fields should be set. &nbsp;See the discussion
+below regarding colormaps.</dd>
+  </dl>
+</blockquote>
+<p><code>XCreateWindow</code> will return a window handle if it succeeds
+or zero if it fails.</p>
+<h3>3.3.2 Window Mapping</h3>
+<p>To display the window the XMapWindow function must be called:</p>
+<blockquote>
+  <pre>void XMapWindow(Display *dpy, Window w)</pre>
+</blockquote>
+<p>This function does nothing in Mini GLX but is required for Xlib/GLX
+compatibility</p>
+<h3>3.3.3 Colormaps<br>
+</h3>
+<p>Xlib requires specification of a colormap when creating a window.
+&nbsp;For purposes of interoperability, Mini GLX requires this as well,
+though the colormap is not actually used. &nbsp;The XCreateColormap
+function is used to create a colormap:</p>
+<blockquote><code>Colormap XCreateColormap(Display *dpy, Window window,
+Visual *visual, int alloc)</code><br>
+  <code></code></blockquote>
+<p>The parameters are as follows:<br>
+</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle as returned by XOpenDisplay.</dd>
+    <dt><code>window</code></dt>
+    <dd> This parameter is ignored by Mini GLX but should be the value
+returned by the <code>RootWindow(dpy, 0)</code> macro.<br>
+    </dd>
+    <dt><code>visual</code></dt>
+    <dd>This parameter is ignored by Mini GLX but should be the visual
+field of the XVisualInfo object returned by glXChooseVisual. </dd>
+    <dt><code>alloc</code></dt>
+    <dd>This parameter is ignored by Mini GLX but should be set to <code>AllocNone</code>.</dd>
+  </dl>
+</blockquote>
+<br>
+<h2>3.4 Creating a Rendering Context</h2>
+<p>An OpenGL rendering context is created with the <code>glXCreateContext</code>
+function:</p>
+<blockquote>
+  <pre>GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle as returned by XOpenDisplay.</dd>
+    <dt><code>visInfo</code></dt>
+    <dd>The visual as returned by glXChooseVisual.</dd>
+    <dt><code>shareList</code></dt>
+    <dd>If non-zero, texture objects and display lists are shared with
+the named rendering context. If zero, texture objects and display lists
+will (initially) be private to this context. They may be shared when a
+subsequent context is created.</dd>
+    <dt><code>direct</code></dt>
+    <dd>Specifies whether direct or indirect rendering is desired. For
+Mini GLX this value is ignored but it should be set to <code>True</code>.</dd>
+  </dl>
+</blockquote>
+<p><code>glXCreateContext</code> will return a GLXContext handle if it
+succeeds or zero if it fails due to invalid parameter or insufficient
+resources.<br>
+<br>
+</p>
+<h2>3.5 Binding a Rendering Context</h2>
+<p>The final step before beginning OpenGL rendering is to bind (i.e.
+activate) a rendering context and drawing surface with the
+glXMakeCurrent function:</p>
+<blockquote>
+  <pre>Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>drawable</code></dt>
+    <dd>The window or drawable to bind to the rendering context. This
+should be the value returned by XCreateWindow.</dd>
+    <dt><code>ctx</code></dt>
+    <dd>The rendering context to bind, as returned by glXCreateContext.</dd>
+  </dl>
+</blockquote>
+<p>If glXMakeCurrent succeeds True is returned.  Otherwise False is
+returned to indicate an invalid display, window or context parameter.</p>
+<p>After the rendering context has been bound to the drawing surface
+OpenGL rendering can begin.</p>
+<p>The current rendering context may be unbound by calling
+glXMakeCurrent with the window and context parameters set to zero.</p>
+<p>An application may create any number of rendering contexts and bind
+them as needed. Note that binding a rendering context is generally not a
+light-weight operation. &nbsp;Most simple OpenGL applications create
+only one rendering context.<br>
+<br>
+</p>
+<h2>3.6 Color Buffer Swapping</h2>
+<p>A double buffered window has two color buffers: a front buffer and a
+back buffer.  Normally, rendering is directed to the back buffer while
+the front buffer is displayed.  When rendering of a frame is finished
+the front and back buffers are swapped to provide the illusion of
+instanteous screen updates.</p>
+<p>The color buffers for a particular window (i.e. drawable) may be
+swapped with the glXSwapBuffers command:</p>
+<blockquote>
+  <pre>void glXSwapBuffers(Display *dpy, GLXDrawable drawable)<br></pre>
+</blockquote>
+Any pending rendering commands will be completed before the buffer swap
+takes place.<br>
+<br>
+Calling glXSwapBuffers on a window which is single-buffered has no
+effect.<br>
+<br>
+<h2>3.7 Releasing Resources</h2>
+<h3>3.7.1 Releasing Rendering Contexts</h3>
+<p>A rendering context may be destroyed by calling glXDestroyContext:</p>
+<blockquote>
+  <pre>void glXDestroyContext(Display *dpy, GLXContext ctx)<br></pre>
+</blockquote>
+<h3>3.7.2 Releasing Windows</h3>
+<p>A window may be destroyed by calling XDestroyWindow:</p>
+<blockquote>
+  <pre>void XDestroyWindow(Display *dpy, Window window)<br></pre>
+</blockquote>
+<h3>3.7.3 Releasing Visuals</h3>
+<p>An XVisualInfo object may be freed by calling XFree:</p>
+<blockquote>
+  <pre>void XFree(void *data)<br></pre>
+</blockquote>
+<h3>3.7.4 Releasing Colormaps</h3>
+<p>A colormap may be freed by calling XFreeColormap:</p>
+<blockquote>
+  <pre>void XFreeColormap(Display *dpy, Colormap colormap)<br></pre>
+</blockquote>
+<h3>3.7.4 Releasing Display Resources</h3>
+<p>When the application is about to exit, the resources associated with
+the graphics system can be released by calling XCloseDisplay:</p>
+<blockquote>
+  <pre>void XCloseDisplay(Display *dpy)<br></pre>
+</blockquote>
+<p>The display handle becomes invalid at this point.<br>
+<br>
+</p>
+<h2>3.8 Query Functions</h2>
+<h3>3.8.1 Querying Available Visuals</h3>
+A list of all available visuals can be obtained with the XGetVisualInfo
+function:<br>
+<br>
+<div style="margin-left: 40px;"><code>XVisualInfo
+*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo
+*vinfo_template, int *nitems_return)<br>
+</code></div>
+<br>
+The parameters are as follows:<br>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>vinfo_mask</code></dt>
+    <dd>A bitmask indicating which fields of the vinfo_template are to
+be matched. &nbsp;The value must be VisualScreenMask.</dd>
+    <dt><code>vinfo_template</code></dt>
+    <dd>A template whose fields indicate which visual attributes must
+be matched by the results. &nbsp;The screen field of this structure must
+be zero.</dd>
+    <dt><code>nitems_return</code></dt>
+    <dd>Returns the number of visuals returned. </dd>
+  </dl>
+</blockquote>
+The return value is the address of an array of all available visuals.<br>
+<br>
+An example of using XGetVisualInfo to get all available visuals follows:<br>
+<br>
+<div style="margin-left: 40px;"><code>XVisualInfo visTemplate, *results;</code><br>
+<code>int numVisuals;</code><br>
+<code>Display *dpy = XOpenDisplay(NULL);</code><br>
+<code>visTemplate.screen = 0;</code><br>
+<code>results = XGetVisualInfo(dpy, VisualScreenMask, &amp;visTemplate,
+&amp;numVisuals);</code><br>
+<code></code></div>
+<br>
+<h3>3.8.2 Querying Visual Attributes</h3>
+<p>The GLX attributes of an X visual may be queried with the
+glXGetConfig function:</p>
+<blockquote>
+  <pre>int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>vis</code></dt>
+    <dd>The visual, as returned by glXChooseVisual.</dd>
+    <dt><code>attribute</code></dt>
+    <dd>The attribute to query.  The attributes are listed below.</dd>
+    <dt><code>value</code></dt>
+    <dd>Pointer to an integer in which the result of the query will be
+stored. </dd>
+  </dl>
+</blockquote>
+<p>The return value will be zero if no error occurs.<code>
+&nbsp;GLX_INVALID_ATTRIBUTE</code> will be returned if the attribute
+parameter is invalid.<code> &nbsp;GLX_BAD_VISUAL</code> will be returned
+if the XVisualInfo parameter is invalid.</p>
+<p>The following attributes may be queried:</p>
+<blockquote>
+  <dl>
+    <dt><code>GLX_USE_GL</code></dt>
+    <dd>The result will be <code>True</code> or <code>False</code> to
+indicate if OpenGL rendering is supported with the visual.  Mini GLX
+always return <code>True</code>.</dd>
+    <dt><code>GLX_RGBA</code></dt>
+    <dd>The result will be <code>True</code> for RGBA visuals or <code>False</code>
+for color index visuals.</dd>
+    <dt><code>GLX_DOUBLEBUFFER</code></dt>
+    <dd>The result will be <code>True</code> if the visual has two
+color buffers or <code>False</code> if the visual has one color buffer.</dd>
+    <dt><code>GLX_RED_SIZE</code></dt>
+    <dd>The result will be the number of red bits per pixel.</dd>
+    <dt><code>GLX_GREEN_SIZE</code></dt>
+    <dd>The result will be the number of green bits per pixel.</dd>
+    <dt><code>GLX_BLUE_SIZE</code></dt>
+    <dd>The result will be the number of blue bits per pixel.</dd>
+    <dt><code>GLX_ALPHA_SIZE</code></dt>
+    <dd>The result will be the number of alpha bits per pixel.</dd>
+    <dt><code>GLX_DEPTH_SIZE</code></dt>
+    <dd>The result will be the number of bits per Z value.</dd>
+    <dt><code>GLX_STENCIL_SIZE</code></dt>
+    <dd>The result will be the number of bits per stencil value.<br>
+      <br>
+    </dd>
+  </dl>
+</blockquote>
+<h3>3.8.3 Querying the Current Rendering Context</h3>
+<p>The current rendering context can be queried with
+glXGetCurrentContext: </p>
+<blockquote>
+  <pre>GLXContext glXGetCurrentContext(void)<br></pre>
+</blockquote>
+<p>Zero will be returned if no context is currently bound.<br>
+<br>
+</p>
+<h3>3.8.4 Querying the Current Drawable</h3>
+<p>The current drawable (i.e. window or drawing surface) can be queried
+with glXGetCurrentDrawable:</p>
+<blockquote>
+  <pre>GLXDrawable glXGetCurrentDrawable(void)<br></pre>
+</blockquote>
+<p>Zero will be returned if no drawable is currently bound.<br>
+<br>
+</p>
+<h3>3.8.5 Function Address Queries</h3>
+<p>The glXGetProcAddress function will return the address of any
+available OpenGL or Mini GLX function:</p>
+<blockquote>
+  <pre>void *glXGetProcAddress(const GLubyte *procName)<br></pre>
+</blockquote>
+<p>If <code>procName</code> is a valid function name, a pointer to that
+function will be returned. &nbsp;Otherwise, NULL will be returned.</p>
+<p>The purpose of glXGetProcAddress is to facilitate using future
+extensions to OpenGL or Mini GLX.  If a future version of the library
+adds new extension functions they'll be accessible via
+glXGetProcAddress. The alternative is to hard-code calls to the new
+functions in the application but doing so will prevent linking the
+application with older versions of the library.<br>
+<br>
+</p>
+<h2>3.9 Versioning</h2>
+The Mini GLX version can be queried at run time with glXQueryVersion:
+<blockquote>
+  <pre>Bool glXQueryVersion(Display *dpy, int *major, int *minor)<br></pre>
+</blockquote>
+<p><code>major</code> will be set to the major version number and<code>minor</code>
+will be set to the minor version number.<code>True</code> will be
+returned if the function succeeds. <code>False</code> will be returned
+if the function fails due to invalid parameters. The <code>dpy</code>
+argument is currently ignored, but should be the value returned by
+XOpenDisplay.</p>
+<p>At compile time, the Mini GLX interface version can be tested with
+the MINI_GLX_VERSION_1_<i>x</i> preprocessor tokens. For example, if
+version 1.0 of Mini GLX is supported, then<code> MINI_GLX_VERSION_1_0</code>
+will be defined. If version 1.1 of Mini GLX is supported, then<code>
+MINI_GLX_VERSION_1_1</code> will be defined.</p>
+<p>At the time of writing the current Mini GLX version is 1.0.<br>
+<br>
+</p>
+<h1>4.0 Interoperability with GLX and Xlib</h1>
+While Mini GLX strives to be compatible with GLX and Xlib there are
+some unavoidable differences which must be taken into consideration.<br>
+<h2>4.1 Public vs Private Structures</h2>
+The structure of many X data types is public. &nbsp;For example, the <code>Display</code>
+data type is defined as a structure in /usr/include/X11/Xlib.h and
+programmers may access any fields of that structure at will. &nbsp;Mini
+GLX also defines a Display data type but its fields are hidden and not
+visiblein <code>miniglx.h</code>. &nbsp;Duplicating the Xlib
+declaration for the <code>Display</code> data type in minigl.h would
+require defining a large number of other superfluous Xlib datatypes.<br>
+<br>
+Mini GLX users are discouraged from directly accessing the fields of
+Xlib data types to maximize portability - though this is unavoidable to
+some extent. &nbsp;For example, the <code>XVisualInfo</code> and <code>XSetWindowAtttributes</code>
+data types must be completely public.
+<h2>4.2 Macros</h2>
+In some cases, Xlib defines macros which are meant to be used instead
+of direct structure accesses. &nbsp;For example, the <code>RootWindow(dpy,
+screen)</code> macro returns the root window for a given screen on a
+given display. &nbsp;Unfortunately, macros do nothing to aid in ABI
+compatibility since they are resolved at compile time instead of at
+link/run time.<br>
+<br>
+Mini GLX also defines a <code>RootWindow</code> macro since it's
+essential for creating windows. &nbsp;But the implementation of this
+macro by Xlib and Mini GLX is completely different.<br>
+<h2>4.3 Summary</h2>
+Because Xlib and Mini GLX define data types and macros differently,
+Mini GLX applications must be recompiled when retargeting Mini GLX or
+native Xlib/GLX. &nbsp;That is, applications can't simply be re-linked
+because of ABI incompatibilities.<br>
+<br>
+Nevertheless, the fact that Mini GLX programs can be recompiled for
+Xlib and GLX increases portability and flexibility for testing and
+prototyping.<br>
+<br>
+<h1>5.0 Example Program</h1>
+<p>This section shows an example program which uses the Mini GLX
+interface. The program simply draws several frames of a rotating square.<br>
+</p>
+<p>The program may be compiled for use with Xlib/GLX or Mini GLX by
+setting the <code>USE_MINIGLX</code> token to 0 or 1, respectively.
+&nbsp;Note that the only difference is the header files which are
+included.<br>
+</p>
+<p> </p>
+<pre><code><br></code>#define USE_MINIGLX 1  /* 1 = use Mini GLX, 0 = use Xlib/GLX */<br><br>#include &lt;stdio.h&gt;<br>#include &lt;stdlib.h&gt;<br>#include &lt;GL/gl.h&gt;<br><br>#if USE_MINIGLX<br>#include &lt;GL/miniglx.h&gt;<br>#else<br>#include &lt;GL/glx.h&gt;<br>#include &lt;X11/Xlib.h&gt;<br>#endif<br><br><code>/*<br> * Create a simple double-buffered RGBA window.<br> */<br>static Window<br>MakeWindow(Display * dpy, unsigned int width, unsigned int height)<br>{<br>   int visAttributes[] = {<br>      GLX_RGBA,<br>      GLX_RED_SIZE, 1,<br>      GLX_GREEN_SIZE, 1,<br>      GLX_BLUE_SIZE, 1,<br>      GLX_DOUBLEBUFFER,<br>      None<br>   };<br>   XSetWindowAttributes attr;<br>   unsigned long attrMask;<br>   Window root;<br>   Window win;<br>   GLXContext ctx;<br>   XVisualInfo *visinfo;<br><br>   root = RootWindow(dpy, 0);<br><br>   /* Choose GLX visual / pixel format */<br>   visinfo = glXChooseVisual(dpy, 0, visAttributes);<br>   if (!visinfo) {<br>      printf("Error: couldn't get an RGB, Double-buffered visual\n");<br>      exit(1);<br>   }<br><br>   /* Create the window */<br>   attr.background_pixel = 0;<br>   attr.border_pixel = 0;<br>   attr.colormap = XCreateColormap(dpy, root, visinfo-&gt;visual, AllocNone);<br>   attrMask = CWBackPixel | CWBorderPixel | CWColormap;<br>   win = XCreateWindow(dpy, root, 0, 0, width, height,<br>		       0, visinfo-&gt;depth, InputOutput,<br>		       visinfo-&gt;visual, attrMask, &amp;attr);<br>   if (!win) {<br>      printf("Error: XCreateWindow failed\n");<br>      exit(1);<br>   }<br><br>   /* Display the window */<br>   XMapWindow(dpy, win);<br><br>   /* Create GLX rendering context */<br>   ctx = glXCreateContext(dpy, visinfo, NULL, True);<br>   if (!ctx) {<br>      printf("Error: glXCreateContext failed\n");<br>      exit(1);<br>   }<br><br>   /* Bind the rendering context and window */<br>   glXMakeCurrent(dpy, win, ctx);<br><br>   return win;<br>}<br><br><br>/*<br> * Draw a few frames of a rotating square.<br> */<br>static void<br>DrawFrames(Display * dpy, Window win)<br>{<br>   int angle;<br>   glShadeModel(GL_FLAT);<br>   glClearColor(0.5, 0.5, 0.5, 1.0);<br>   for (angle = 0; angle &lt; 360; angle += 10) {<br>      glClear(GL_COLOR_BUFFER_BIT);<br>      glColor3f(1.0, 1.0, 0.0);<br>      glPushMatrix();<br>      glRotatef(angle, 0, 0, 1);<br>      glRectf(-0.8, -0.8, 0.8, 0.8);<br>      glPopMatrix();<br>      glXSwapBuffers(dpy, win);<br>   }<br>}<br><br><br>int<br>main(int argc, char *argv[])<br>{<br>   Display *dpy;<br>   Window win;<br><br>   dpy = XOpenDisplay(NULL);<br>   if (!dpy) {<br>      printf("Error: XOpenDisplay failed\n");<br>      return 1;<br>   }<br><br>   win = MakeWindow(dpy, 300, 300);<br><br>   DrawFrames(dpy, win);<br><br>   return 0;<br>}<br></code></pre>
+<br>
+</body>
+</html>

docs/README.3DFX

@@ -0,0 +1,672 @@
+
+                            3Dfx Glide device driver
+
+
+
+Mesa-5.1 release notes:
+-----------------------
+
+1) Glide2 support has been ceased; in order to keep Voodoo Graphics
+   and Voodoo Rush compatibility, please visit the Glide SourceForge
+   and help us to fix Glide3 for those cards.
+2) The current release is a WIP; among other things, the Linux build works
+   only to some extent. Any help will be appreciated.
+3) Glide3 can be found at http://sourceforge.net/projects/glide/
+
+
+
+Known supported HW/OS:
+----------------------
+
+Voodoo^2, Voodoo Banshee, Voodoo3, Voodoo4, Voodoo5
+DOS (DJGPP), Windows9x/2k (MinGW/MSVC), Linux
+
+
+
+How to compile:
+---------------
+
+DJGPP/MinGW/MSVC:
+   Place the Glide3 SDK in the top Mesa directory:
+	$(MESA)/glide3/include/*.h
+	$(MESA)/glide3/lib/
+   Required headers:
+	3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
+   Required libraries:
+	OS specific
+   Type:
+	make -f Makefile.DJ HAVE_MMX=1 HAVE_3DNOW=1 FX=1
+	or
+	make -f Makefile.mgw HAVE_MMX=1 HAVE_3DNOW=1 FX=1
+	or
+	nmake -f Makefile.wfx
+   Look into the corresponding makefiles for further information.
+
+Linux:
+   Place the Glide3 SDK in /usr/local/glide
+   Type:
+	make linux-glide
+
+
+
+Contact:
+--------
+
+Daniel Borca <dborca@users.sourceforge.net>
+Hiroshi Morii <koolsmoky@users.sourceforge.net>
+
+
+
+The info below this line is outdated. You have been warned...
+*************************************************************
+
+
+
+Info for Mesa 4.1
+-----------------
+
+The 3dfx Glide driver in Mesa is disabled by default.  Not too many people
+use this driver anymore and at some point down the road it will be dropped.
+
+To use/enable the Glide driver either do this:
+
+'./configure --with-glide=DIR'    Where DIR is the location of Glide, like
+                                  /usr/ or /usr/local
+
+OR
+
+'make linux-x86-glide'     If using the old-style Makefile system.
+
+The rest of this file hasn't changed since Mesa 3.3.  Some of it's out of
+date, but some is still valid.
+
+
+
+What do you need ?
+------------------
+
+	- A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board
+	  (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.).
+	  The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+	  under Linux (more information in the "Useful Glide Environment
+	  Variables");
+
+	- The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
+	  The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not
+	  compatible with the Glide 2.x so it doesn't work with the current
+	  version of the driver;
+
+	- A compiler supported by the Glide library (Micro$oft VC++ (tested),
+	  Watcom (tested), GCC for Linux (tested), etc.);
+
+	- It's nice to have two monitors - one for your normal graphics
+	  card and one for your 3Dfx card. If something goes wrong with
+	  an application using the 3Dfx hardware you can still see your
+	  normal screen in order to recover.
+
+
+
+Tested on:
+----------
+	Windows 95 - David Bucciarelli
+	Windows NT - Henri Fousse
+	MS-DOS
+	Linux - Daryll Strauss, Brian Paul, David Bucciarelli
+	FreeBSD
+	BeOS - Duncan Wilcox
+	MacOS - Fazekas Miklos
+
+
+What is able to do ?
+--------------------
+
+	- It is able accelerate points, lines and polygon with flat
+	  shading, gouraud shading, Z-buffer, texture mapping, blending, fog and
+	  antialiasing (when possible). There is also the support for rendering
+	  in a window with a slow trick for the Voodoo Graphics (available only
+	  for Linux) and at full speed with the Voodoo Rush chipset.
+	  Under Linux is also possible to switch on-the-fly between the fullscreen
+	  and in-window rendering hack.
+	  There is also the support for using more than one Voodoo Graphics in the
+	  some application/PC (you can create one context for each board and use
+	  multiple video outputs for driving monitors, videoprojectors or HMDs).
+	  The driver is able to fallback to pure software rendering when afeature
+	  isn't supported by the Voodoo hardware (however software rendering is
+	  very slow compared to hardware supported rendering)
+
+
+
+How to compile:
+---------------
+
+Linux:
+------
+	Here are the basic steps for using the 3Dfx hardware with Mesa
+	on Linux:
+
+	- You'll need the Glide library and headers.  Mesa expects:
+		/usr/local/glide/include/*.h        // all the Glide headers
+		/usr/local/glide/lib/libglide2x.so
+
+	  If your Glide libraries and headers are in a different directory
+	  you'll have to modify the Mesa-config and mklib.glide files.
+
+	- Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives;
+
+	- If you're going to use a newer Mesa/Glide driver than v0.27 then
+          unpack the new driver archive over the Mesa directory.
+
+	- In the Mesa-3.1 directory type "make linux-glide"
+
+	- Compilation _should_ finish without errors;
+
+	- Set your LD_LIBRARY_PATH environment variable so that the
+	  libglide2x.so and Mesa library files can be found.  For example:
+	    setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib"
+
+	- You'll have to run Glide-based programs as root or set the suid
+	  bit on executables;
+
+	- Try a demo:
+	    cd gdemos
+	    su
+	    setenv MESA_GLX_FX f
+	    ./gears     (hit ESC to exit)
+
+	- You can find the demos especially designed for the Voodoo driver in
+	  in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile
+	  everything).
+
+MacOS:
+------
+	Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html
+      
+MS Windows:
+-----------
+
+	For the MSVC++:
+	- The glide2x.lib have to be in the default MSVC++ lib directory;
+
+	- The Glide headers have to be in the default MSVC++ include directory;
+
+	- You must have the vcvars32.bat script in your PATH;
+
+	- Go to the directory Mesa-3.1 and run the mesafx.bat;
+
+	- The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll},
+	  Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and
+          Voodoo demos);
+
+	- At the end, you will be in the Mesa-3.1/3Dfx/demos directory;
+
+	- Try some demo (fire.exe, teapot.exe, etc.) in order to check if
+	  everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between
+	  the Voodoo screen and the windows desktop);
+
+	- Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the
+          some directory were you run your Mesa based applications.
+
+	- I think that you can easy change the Makefile.fx files in order
+	  to work with other kind of compilers;
+
+	- To discover how open the 3Dfx screen, read the sources under
+	  the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or
+          the Diego Picciani's wgl emulator.
+
+	NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the
+	SP3, you could have some problem (you can disable optimization in order
+	solve these kind of problems).
+
+
+Doing more with Mesa & Linux Glide:
+-----------------------------------
+
+	The MESA_GLX_FX environment variable can be used to coax most
+	GLX-based programs into using Glide (and the __GLUT library
+	is GLX-based__).
+
+        Full-screen 3Dfx rendering:
+        ---------------------------
+
+	1. Set the MESA_GLX_FX variable to "fullscreen":
+
+		ksh:
+			export MESA_GLX_FX = "fullscreen"
+		csh:
+			setenv MESA_GLX_FX fullscreen
+
+	2. As root, run a GLX-based program (any GLUT demo on Linux).
+	
+	3. Be careful:  once the 3Dfx screen appears you won't be able
+	to see the GLUT windows on your X display.  This can make using
+	the mouse tricky!  One solution is to hook up your 3Dfx card to
+	a second monitor.  If you can do this then set these env vars
+	first:
+
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN
+	
+	or for the Voodoo2:
+
+		setenv SSTV2_VGA_PASS 1
+		setenv SSTV2_NOSHUTDOWN
+
+        Rendering into an X window with the help of the Voodoo hardware:
+        ----------------------------------------------------------------
+
+	1. Start your X server in 16 bpp mode (XFree86:  startx -- -bpp 16)
+	   in order to have the best performance and the best visual
+	   quality. However you can use any visual depth supported by X.
+
+	2. Set the following environment variables:
+		export MESA_GLX_FX="window"	# to enable window rendering
+		export SST_VGA_PASS=1	# to stop video signal switching
+		export SST_NOSHUTDOWN=1	# to stop video signal switching
+	    OR
+		setenv MESA_GLX_FX window
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN 1
+
+	(the Voodoo2 requires to use "SSTV2_" instead "SST_").
+
+	3. As root, try running a GLX-based program
+
+	How does it work?  We use the 3Dfx hardware to do rendering then
+	copy the image from the 3Dfx frame buffer into an X window when
+	the SwapBuffers() function is called.  The problem with this
+	idea is it's slow.  The image must be copied from the 3Dfx frame
+	buffer to main memory then copied into the X window (and when the X
+	visual depth doesn't match the Voodoo framebufffer bit per pixel, it
+	is required also a pixel format translation).
+
+	NOTE: the in-window rendering feature only works with double-buffering.
+
+
+        On the fly switching between in window rendering and full screen rendering
+	--------------------------------------------------------------------------
+
+	The Mesa 2.6 has introduced the capability of switching
+	on-the-fly between the fullscreen/fullspeed rendering and the in-window
+	hack and vice versa. The on-the-fly switching requires a direct support
+	by the application but it is really easy to add. You have to start
+	your X server in 16 bpp mode and to add the following lines to your
+	application:
+
+		#if defined(FX) && define(XMESA)
+		#include <GL/xmesa.h>
+
+		static int fullscreen=1;
+		#endif
+
+		...
+
+		/* In the GLUT keyboard event callback */
+
+		#if defined(FX) && !define(WIN32)
+		  case ' ':
+		    fullscreen=(!fullscreen);
+		    XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW);
+		    break;
+		#endif
+		...
+
+       	See the 3Dfx/demos/tunnel.c program
+       	for an example.  You have to set the -DXMESA flag in the Makefile's COPTS
+       	to enable it.
+
+  	Rendering into an X window with the X11 software driver:
+        --------------------------------------------------------
+
+	Set the MESA_GLX_FX variable to "disable" your GLX-based program will use
+	the X11 software driver (the 3Dfx hardware isn't used at all).
+
+
+
+Useful Glide Environment Variables:
+-----------------------------------
+
+	- To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable.
+
+	- To disable video signal switching:
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN
+	  or for the Voodoo2:
+		setenv SSTV2_VGA_PASS 1
+		setenv SSTV2_NOSHUTDOWN
+
+        - To set the default screen refresh rate:
+                setenv SST_SCREENREFRESH=75
+
+          the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120.
+
+	- To force the Mesa library to swap buffers as fast as possible,
+	  without any vertical blanking synchronization (useful for benchmarks):
+		setenv FX_GLIDE_SWAPINTERVAL 0
+                setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0
+
+	- You can slight improve the performances of your Voodoo1 board with
+	  the following env. var.:
+		setenv SST_FASTMEM 1
+		setenv SST_PCIRD 1
+		setenv SST_GRXCLK 57
+
+	  (don't use this setting with the Quantum3D 100SB or with any other
+	  SLI configuration: it will hang everything !).
+	  The following setting can be used with the Voodoo2:
+		setenv SSTV2_FASTMEM_RAS_READS=1
+		setenv SSTV2_FASTPCIRD=1
+		setenv SSTV2_GRXCLK=95
+
+	- The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+	  in order to work under Linux:
+
+		export SSTV2_FT_CLKDEL=5
+		export SSTV2_TF0_CLKDEL=7
+		export SSTV2_TF1_CLKDEL=7
+		export SSTV2_TF2_CLKDEL=7
+		export SSTV2_SLIM_VIN_CLKDEL=3
+		export SSTV2_SLIM_VOUT_CLKDEL=2
+		export SSTV2_SLIS_VIN_CLKDEL=3
+		export SSTV2_SLIS_VOUT_CLKDEL=2
+
+	  (Thanks to Phil Ross for this trick).
+
+
+
+
+The Mesa/Voodoo Environment Variables:
+--------------------------------------
+
+	- Only for Windows/Voodoo Rush users, if you define the
+	  env. var. MESA_WGL_FX:
+		export MESA_WGL_FX=fullscreen
+	  you will get fullscreen rendering;
+
+	- Only for Windows/Voodoo Rush users, if you define the
+	  env. var. MESA_WGL_FX:
+		export MESA_WGL_FX=window
+	  you will get window rendering (default value);
+
+	- Only for Linux users, you can find more informations about
+	  the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide"
+	  section;
+
+	- If you define the env. var. MESA_FX_SWAP_PENDING:
+		export MESA_FX_SWAP_PENDING=4
+	  you will able to set the maximum number of swapbuffers
+	  commands in the Voodoo FIFO after a swapbuffer (default value: 2);
+
+        - If you define the env. var. MESA_FX_INFO:
+		export MESA_FX_INFO=1
+          you will get some useful statistic.
+
+        - If you define the env. var. MESA_FX_NO_SIGNALS:
+		export MESA_FX_NO_SIGNALS=1
+          Mesa/FX will not install atexit() or signal() handlers.
+
+
+
+Know BUGS and Problems:
+-----------------------
+
+	- fog doesn't work in the right way when using the glDepthRange() function;
+
+	- Maximum texture size: 256x256 (this is an hardware limit);
+
+	- Texture border aren't yet supported;
+
+	- A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit);
+
+        - Use the glBindTexture extension (standard in OpenGL 1.1) for texture
+	  mapping (the old way: glTexImage inside a display list, download
+	  the texture map each time that you call the display list !!!);
+
+	- Stencil buffer and Accumulation buffer are emulated in software (they are not
+	  directly supported by the Hardware);
+
+	- Color index mode not implemented (this is an hardware limit);
+
+	- Thre is an know bug in the Linux Glide library so the in-window-rendering hack
+	  and any other operations that requires to read the Voodoo frame buffer
+	  (like the accumulation buffer support) doesn't work on Voodoo SLI cards.
+
+	- The driver switch to pure software (_slow_) rendering when:
+
+		- Stencil enabled;
+		- Using the Accumulation buffer;
+		- Blend enabled and blend equation != GL_FUNC_ADD_EXT;
+		- Color logic operation enabled and color logic operation != GL_COPY;
+		- Using GL_SEPARATE_SPECULAR_COLOR;
+		- The four values of glColorMask() aren't the some;
+		- Texture 1D or 3D enabled;
+		- Texture function is GL_BLEND;
+		- Using the Multitexture extension with Voodoo cards with only one TMU;
+		- Using the Multitexture extension with Voodoo cards with more than
+		   one TMU, and texture function isn't GL_MODULATE;
+		- Point size is != 1.0 or point params vector != (1.0,0.0,0.0);
+		- Line width != 1.0 or using stipple lines.
+		- Using polygon offset or stipple polygons;
+
+	NOTE: this is list is not yet complete.
+		
+
+Hints and Special Features:
+---------------------------
+
+	- Under Linux and with a Voodoo Graphics board, you can use
+	  XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to
+	  switch on the fly between fullscreen rendering and the in-window-rendering
+	  hack.
+
+	- The driver is able to use all the texture memory available: 2/4MB on
+	  Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards.
+
+	- Trilinear filtering is fully supported on Voodoo boards with two TMUs
+	  (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is
+	  available the driver fallback to bilinear filter also if you ask
+	  for trilinear filtering.
+
+        - The Voodoo driver support multiple Voodoo Graphics boards in the
+          some PC. Using this feature, you can write applications that use
+          multiple monitors, videoprojectors or HMDs for the output. See
+	  Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one
+          context for each board.
+
+	- The v0.19 introduces a new powerful texture memory manager: the
+	  texture memory is used as a cache of the set of all defined texture
+	  maps. You can now define several MBs of texture maps also with a 2MB
+	  of texture memory (the texture memory manager will do automatically
+	  all the swap out/swap in
+	  texture memory work). The new texture memory manager has also
+	  solved a lot of other bugs/no specs compliance/problems
+	  related to the texture memory usage.
+
+	- Use triangles and quads strip: they are a LOT faster than sparse
+	  triangles and quads.
+
+	- The Voodoo driver supports the GL_EXT_paletted_texture. it works
+	  only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value
+	  is ignored because this is a limitation of the the current Glide
+	  version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for
+	  a demo of this extension.
+
+	- The Voodoo driver directly supports 3Dfx Global Palette extension.
+	  It was written for GLQuake and I think that it isn't a good idea
+	  to use this extension for any other purpose (it is a trick). See
+	  Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension.
+
+	- The Voodoo driver chooses the screen resolution according to the
+	  requested window size. If you open a 640x480 window, you will get
+	  a 640x480 screen resolution, if you open a 800x600 window, you
+	  will get a 800x600 screen resolution, etc.
+	  Most GLUT demos support the '-geometry' option, so you can choose
+	  the screen resolution: 'tunnel -geometry 800x600'.
+	  Clearly, you Voodoo board must have enough framebuffer RAM (otherwise
+	  the window creation will fail).
+
+	- The glGetString(GL_RENDERER) returns more information
+          about the hardware configuration: "Mesa Glide <version>
+          <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/
+          <num> TM/<num> TMU/<NOSLI|SLI>"
+          where: <num> CARD is the card used for the current context,
+          <num> FB is the number of MB for the framebuffer,
+          <num> TM is the number of MB for the texture memory,
+          <num> TMU is the number of TMU. You can try to run
+          Mesa/demos/glinfo in order to have an example of the output.
+
+Did you find a lot BUGs and problems ? Good, send me an email.
+
+
+
+FAQ:
+----
+
+For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO
+available at http://www.gamers.org/dEngine/xf3D (it includes also
+a lot of informations not strictly related to Linux, so it can be
+useful also if you don't use Linux)
+
+1. What is 3Dfx?
+
+3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics
+chipset (and others) used in popular PC cards such as the Diamond Monster 3D
+and the Orchid Righteous 3D (more informations at http://www.3dfx.com).
+
+
+2. What is Glide?
+
+Glide is a "thin" programming interface for the 3Dfx hardware.  It was
+originally written for Windows/Intel but has been ported to Linux/Intel
+by Daryll Strauss.
+
+3Dfx, Inc. should be applauded for allowing the Linux version of Glide
+to be written.
+
+You can directly program with the Glide library if you wish.  You can
+obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com
+There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux
+
+
+3. What is fxmesa?
+
+"fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library.
+It was written by David Bucciarelli and others.  It works on both Linux
+and Windows.  Basically, it allows you to write and run OpenGL-style programs
+on the 3Dfx hardware.
+
+
+4. What is GLQuake?
+
+Quake is a very popular game from id software, Inc.  See www.idsoftware.com
+GLQuake is a version of Quake written for OpenGL.  There is now a Linux
+version of GLQuake with works with the Mesa/3Dfx/Glide combo.
+
+Here's what you need to run GLQuake on Linux:
+   PC with 100MHz Pentium or better
+   a 3Dfx-based card
+   Mesa 3.1 libraries:  libMesaGL.so  libMesaGLU.so
+   Glide 2.4 libraries:  libglide2x.so  libtexus.so
+   GLQuake for Linux.
+
+Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll,
+you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory
+in order to test 'MesaQuake'.
+
+
+5. What is GLUT?
+
+GLUT is Mark Kilgard's OpenGL Utility Toolkit.  It provides an API for
+writing portable OpenGL programs with support for multiple windows, pop-
+up menus, event handling, etc.
+
+Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd).
+
+Every OpenGL programmer should check out GLUT.
+
+GLUT on Linux uses GLX.
+
+
+6. What is GLX?
+
+GLX is the OpenGL extension to the X Window System.  I defines both a
+programming API (glX*() functions) and a network protocol.  Mesa implements
+an emulation of GLX on Linux.  A real GLX implementation would requires
+hooks into the X server.  The 3Dfx hardware can be used with GLX-based
+programs via the MESA_GLX_FX environment variable.
+
+
+7. Is the Voodoo driver able to use the 4Mb texture memory of
+the Pure3D boards ?
+
+Yes, the Voodoo driver v0.20 includes the support for Voodoo
+Graphics boards with more than 2Mb of texture memory.
+
+
+8. Do the Voodoo driver support the Voodoo Rush under Windows ?
+
+Yes, Diego Picciani has developed the support for the Voodoo
+Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul
+has a Monster3D, so the new versions of the Mesa/Voodoo sometime are
+not tested with the Voodoo Rush.
+
+
+9. Do the Voodoo driver support the Voodoo Rush under Linux ?
+
+No because the Linux Glide doesn't (yet) support the Voodoo Rush.
+
+
+10. Can I sell my Mesa/Voodoo based software and include
+a binary copy of the Mesa in order to make the software
+working out of the box ?
+
+Yes.
+
+
+11. Which is the best make target for compiling the Mesa for
+Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ?
+
+'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide'
+for Voodoo2 boards because it doesn't include the '-fPIC'
+option (4-5% faster).
+
+
+12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide'
+for my applications/programs/demos ?
+
+Yes, there is only one constrain: you can't run two Mesa applications
+at the some time. This isn't a big issue with the today Voodoo Graphics.
+
+
+Thanks to:
+----------
+
+Henri Fousse       (he has written several parts of the v0.15 and the old GLUT
+	            emulator for Win);
+
+Diego Picciani     (he has developed all the Voodoo Rush support and the wgl
+	            emulator);
+
+Daryll Strauss     (for the Linux Glide and the first Linux support);
+
+Brian Paul         (of course);
+
+Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports)
+
+Bernd Kreimeier    (for the Linux 3Dfx HOWTO and for pushing companies to offer
+                    a better Linux support)
+
+3Dfx and Quantum3D (for actively supporting Linux)
+
+The most update places where find Mesa VooDoo driver related informations are
+the Mesa mailing list and my driver WEB page
+(http://www-hmw.caribel.pisa.it/fxmesa/index.shtml)
+
+
+David Bucciarelli (davibu@tin.it)
+
+Humanware s.r.l. 
+Via XXIV Maggio 62
+Pisa, Italy
+Tel./Fax +39-50-554108
+email: info.hmw@plus.it
+www: www-hmw.caribel.pisa.it

docs/README.AMIWIN

@@ -0,0 +1,181 @@
+AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION
+========================================================
+Port by Victor Ng-Thow-Hing (victorng@dgp.toronto.edu) 
+Original Author (Brian Paul (brianp@ssec.wisc.edu)
+
+Dec.1 , 1995: Port of release Mesa 1.2.5
+ - Modifications made to minimize changes to Mesa distribution.
+
+Nov.25, 1995: Port of release Mesa 1.2.4
+
+
+HISTORY
+=======
+As a 3D graphics progammer, I was increasingly frustrated to see OpenGL 
+appearing on so many platforms EXCEPT the Amiga. Up to now, the task
+of porting OpenGL directly from native Amiga drawing routines seemed like
+a daunting task. However, two important events made this port possible.
+
+First of all, Brian Paul wrote Mesa, the OpenGL software emulator that 
+can be found on many platforms - except the Amiga and Atari (who cares 
+about the latter!). This was pretty ironic considering that Mesa was 
+originally prototyped on an Amiga! The second great event was when 
+Holger Kruse developed AmiWin, the X11R6 server for the Amiga (definitely 
+register for this great piece of software) and released a development kit
+so one could compile X programs with SAS/C.
+
+Since Mesa had X routines as its primitive drawing operations, this made
+a marriage of Mesa and Amiwin feasible. I copied over the sources from
+an ftp site, played with the code, wrote some Smakefiles, and voila, 
+I had OpenGL programs displaying on my Amiga.
+
+Although the speed is nothing to be impressed about, this port can be
+potentially useful to those who want to quickly test their code in
+wireframe or perhaps learn more about programming with the OpenGL API.
+
+I hope Amiga developers will continue to write excellent software for
+their machine, especially more X clients for Amiwin. If you have any 
+solutions so some of my problems in the porting notes, please send me
+some email!
+
+See you around,
+Vic.
+
+HOW TO CREATE THE LIBRARIES AND SAMPLE CODE
+===========================================
+
+Just run the shell script mklib.amiwin in the mesa directory. This will
+make all the libraries and copy them into the mesa/lib directory. If you
+don't want to compile everything, just go to the desired directory and
+type smake in that directory.
+
+Change any of the variables in the smakefiles as necessary. You will REQUIRE
+the Amiwin development kit to compile these libraries since you need X11.LIB
+and the shareable X libraries. Some examples require the AmiTCP4.0
+net.lib static link library and related header files for unix related
+header files and functions like sleep().
+
+HOW TO USE THE MESA LIBRARIES
+=============================
+
+Study the Smakefiles in the demos, samples and book directories for the
+proper SAS/C options and linkable libraries to use. Basically aux calls
+require Mesaaux.LIB, gl calls require MesaGL.LIB, glu calls MesaGLU.LIB,
+tk calls Mesatk.LIB. There is a preliminary port of MesaGLUT.LIB toolkit
+available in the lib directory with the other Mesa libraries. However, 
+it seems to cause crashes on some of the sample code. Someone else may want
+to attempt a more stable port.
+
+PORTING NOTES TO AMIWIN
+=======================
+
+My strategy of porting was to leave as much of the code untouched as
+possible. I surrounded any amiga specific changes with 
+#ifdef AMIWIN ... #endif or #ifndef AMIWIN ... #endif preprocessor
+symbols. The code  was ported on an Amiga 2000, with Fusion 40 accelerator
+and a Picasso II graphics card. The SAS/C 6.56 compiler was used, with
+the AmiWin 2.16 X development kit.
+
+All compilations were done for a 68040 CPU with 68882 math coprocessor for
+maximum  speed. Please edit the smakefile for other compilers.
+I wrote smakefiles for the directories I ported. I omitted the Windows
+and Widgets directories. The former is for MS Windows and the latter 
+requires Motif, which is not easily available for the Amiga.
+
+Here are the changes I did per directory:
+
+* mesa
+Nov. 25, 1995 v 1.2.4
+  - added a mklib.amiwin shell script that will make all the libraries and
+    sample code for Mesa
+  - created this readme file: readme.AMIGA
+
+* mesa/include
+Dec. 1, 1995 v 1.2.5
+  - added the following to GL/xmesa.h 
+     #ifdef AMIWIN
+     #include <pragmas/xlib_pragmas.h>
+     extern struct Library *XLibBase;
+     #endif
+NET CHANGE: xmesa.h
+
+* mesa/src 
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c 
+    This prevents undefined symbols errors during the linking phase for 
+    X library calls
+  - created smakefile
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, 
+    glx.c since they are now defined in include/GL/xmesa.h
+NET CHANGE: smakefile
+   
+* mesa/src-tk
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    private.h
+  - created smakefile
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN includes from private.h since it is now defined in
+    include/GL/xmesa.h
+NET CHANGE: smakefile
+
+* mesa/src-glu
+Nov. 25, 1995 v 1.2.4
+  - created smakefile
+NET CHANGE: smakefile
+
+* mesa/src-aux
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    glaux.c
+  - created smakefile
+NET CHANGE: glaux.c, smakefile
+
+* mesa/demos
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    xdemo.c, glxdemo.c, offset.c
+  - created smakefile
+  - put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since 
+    they are not part of AmigaDOS.
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since
+    already defined in include/GL/xmesa.h
+  - modified Smakefile to include header and includes from the AmiTCP4.0
+    net.lib linkable library to provide unix-compatible sys/time.h and
+    the sleep() function
+    - removed AMIWIN defines in xdemo.c since sleep() now defined
+NET CHANGE: smakefile
+
+* mesa/samples
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    oglinfo.c
+  - created smakefile
+  - put #ifndef AMIWIN ... #endif around sleep() in blendxor.c
+  - removed olympic from smakefile targets since <sys/time.h> not defined
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN defines from oglinfo.c, since already defined in 
+    include/GL/xmesa.h
+  - modified Smakefile to include header and includes from the AmiTCP4.0
+    net.lib linkable library to provide unix-compatible sys/time.h and
+    the sleep() function
+    - removed AMIWIN defines in blendxor.c for sleep()
+    - added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom()
+      functions are not defined in any libraries
+    - added olympic back into the Smakefile targets
+NET CHANGE: smakefile, olympic.c
+
+* mesa/book
+Nov. 25, 1995 v 1.2.4
+- created smakefile
+- removed accpersp and dof from smakefile targets since the SAS/C compile seems to
+  confuse the near,far variables with near/far memory models.
+NET CHANGE: smakefile
+
+* mesa/windows
+Dec.  1, 1995 v 1.2.5
+- Removed directory to save space since this is only needed for Windows based 
+  machines.

docs/README.BEOS

@@ -0,0 +1,114 @@
+
+                         Mesa / BeOS Information
+
+
+
+* Introduction
+
+Mesa 4.1 features a driver for the BeOS.  The driver implements
+a clone of the BGLView class.  This class, derived from BView, allows
+OpenGL rendering into a BeOS window.
+The 4.1 BeOS driver is an update of Brian Paul's BeOS driver released in Mesa 3.1.
+
+Any application which uses the BGLView should be able to use Mesa
+instead of Be's OpenGL without changing any code.
+
+Since Be's OpenGL implementation (as of R5) is basically just the
+SGI sample implementation, it's pretty slow.  You'll see that Mesa
+is considerably faster.
+
+
+
+* Source Code
+
+The source code for the driver is in Mesa-4.1/src/BeOS/ directory.
+It's not 100% finished at this time but many GLUT-based demos are
+working.  No optimizations have been made at this time.
+
+
+
+* Compiling
+
+Requirements:
+  - gcc version 2.95.3 for BeOS 
+  You can find it here: http://www.bebits.com/app/2157
+
+Move to the Mesa-4.x src sub-directory and then type "make -f Makefile.BeOS-R5".
+When it finishes the Mesa based libGL.so library for
+BeOS will be in the Mesa-4.x/src/obj.{x86|ppc}/ directory.
+
+To install it as Be's default libGL.so replacement, put it in your 
+/boot/home/config/lib/ directory. All your GL/GLUTapps will use 
+the Mesa based then. 
+
+By default, it build a non-debug version library.
+The x86 (MMX, SSE and 3DNOW) optimizations are also supported for x86 target.
+Sorry, Mesa don't have ppc (Altivec) optimizations yet.
+
+
+* Example Programs
+
+Look in the Mesa-4.x/BeOS/ directory for one or two BGLView demo
+programs.  They should have been compiled along with the Mesa
+library.
+
+
+* GLUT
+
+A beta version of GLUT 3.7 port for BeOS can be found at 
+http://anobject.com/jehamby/Code/Glut-3.7-x86.zip.
+ 
+There's is a 2.5 version in src-glut.beos/, too.
+The original distribution can be obtained from
+http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip
+
+They are special version of GLUT adapted for the BeOS.  I don't
+believe Mark Kilgard's normal GLUT distribution includes BeOS
+support.
+
+
+* Special Features
+
+Mesa's implementation of the BGLView class has an extra member
+function:  CopySubBufferMESA().  It basically works like SwapBuffers()
+but it only copies a sub region from the back buffer to the front
+buffer.  This is a useful optimization for some applications.
+If you use this method in your code be sure that you check at runtime
+that you're actually using Mesa (with glGetString) so you don't
+cause a fatal error when running with Be's OpenGL.
+
+
+
+* Work Left To Do
+
+BDirectWindow single buffering support is not implemented yet.
+
+Color index mode is not implemented yet.
+
+Reading pixels from the front buffer not implemented yet.
+
+There is also a BGLScreen class in BeOS for full-screen OpenGL
+rendering.  This should also be implemented for Mesa.
+
+
+
+* Old BeOS Driver
+
+Mesa 2.6 had an earlier BeOS driver.  It was based on Mesa's Off-screen
+rendering interface, not BGLView.  If you're interested in the older
+driver you should get Mesa 2.6.
+
+
+
+* BeOS and Glide
+
+Mesa 3.0 supported the 3Dfx/Glide library on Beos.  Download Mesa 3.0
+if interested.  Ideally, the 3Dfx/Glide support should be updated to
+work with the new Mesa 3.1 BGLView implementation.
+
+The Glide library hasn't been updated for BeOS R4, to my knowledge, as
+of February, 1999.
+
+
+----------------------------------------------------------------------
+$Id: README.BEOS,v 1.7 2002/09/19 16:19:44 brianp Exp $

docs/README.CYGWIN

@@ -1,256 +0,0 @@
-
-                          Mesa Cygwin/X11 Information
-
-
-WARNING
-=======
-
-If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the 
-latest setup.exe from Cygwin the GL (Mesa) libraries and include are already 
-installed in /usr/X11R6. 
-
-The following will explain how to "replace" them.
-
-Installation
-============
-
-How to compile Mesa on Cygwin/X11 systems:
-
-1. Shared libs:
-    type 'make cygwin-sl'.
-
-    When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and 
-    Mesa-x.y/bin directories.
-
-
-2. Static libs:
-    type 'make cygwin-static'.
-    When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
-
-Header and library files:
-   After you've compiled Mesa and tried the demos I recommend the following
-   procedure for "installing" Mesa.
-
-   Copy the Mesa include/GL directory to /usr/X11R6/include:
-	cp -a include/GL /usr/X11R6/include
-
-   Copy the Mesa library files to /usr/X11R6/lib:
-	cp -a lib/* /usr/X11R6ocal/lib
-
-   Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin:
-	cp -a lib/cyg* /usr/X11R6/bin
-
-Xt/Motif widgets:
-   If you want to use Mesa or OpenGL in your Xt/Motif program you can build
-   the widgets found in either the widgets-mesa or widgets-sgi directories.
-   The former were written for Mesa and the later are the original SGI
-   widgets.  Look in those directories for more information.
-   For the Motif widgets you must have downloaded the lesstif package.
-
-
-Using the library
-=================
-
-Configuration options:
-   The file src/mesa/main/config.h has many parameters which you can adjust
-   such as maximum number of lights, clipping planes, maximum texture size,
-   etc.  In particular, you may want to change DEPTH_BITS from 16 to 32
-   if a 16-bit depth buffer isn't precise enough for your application.
-
-
-Shared libraries:
-   If you compile shared libraries (Win32 DLLS) you may have to set an 
-   environment variable to specify where the Mesa libraries are located.  
-   Set the PATH variable to include /your-dir/Mesa-2.6/bin.   
-   Otherwise, when you try to run a demo it may fail with a message saying 
-   that one or more DLL couldn't be found.
-
-
-Xt/Motif Widgets:
-   Two versions of the Xt/Motif OpenGL drawing area widgets are included:
-
-      widgets-sgi/	SGI's stock widgets
-      widgets-mesa/	Mesa-tuned widgets
-
-   Look in those directories for details
-
-
-Togl:
-   Togl is an OpenGL/Mesa widget for Tcl/Tk.
-   See http://togl.sourceforge.net for more information.
-
-
-
-X Display Modes:
-   Mesa supports RGB(A) rendering into almost any X visual type and depth.
-
-   The glXChooseVisual function tries its best to pick an appropriate visual
-   for the given attribute list.  However, if this doesn't suit your needs
-   you can force Mesa to use any X visual you want (any supported by your
-   X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
-   environment variables.  When an RGB visual is requested, glXChooseVisual
-   will first look if the MESA_RGB_VISUAL variable is defined.  If so, it
-   will try to use the specified visual.  Similarly, when a color index
-   visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
-   variable.
-
-   The format of accepted values is:  <visual-class> <depth>
-   Here are some examples:
-
-   using the C-shell:
-	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor
-	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor
-	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor
-
-   using the KornShell:
-	$ export MESA_RGB_VISUAL="TrueColor 8"
-	$ export MESA_CI_VISUAL="PseudoColor 12"
-	$ export MESA_RGB_VISUAL="PseudoColor 8"
-
-
-Double buffering:
-   Mesa can use either an X Pixmap or XImage as the backbuffer when in
-   double buffer mode.  Using GLX, the default is to use an XImage.  The
-   MESA_BACK_BUFFER environment variable can override this.  The valid
-   values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first
-   letter is checked, case doesn't matter).
-
-   A pixmap is faster when drawing simple lines and polygons while an
-   XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you
-   need depth buffering the XImage will almost surely be faster.  Exper-
-   iment with the MESA_BACK_BUFFER variable to see which is faster for
-   your application.  
-
-
-Colormaps:
-   When using Mesa directly or with GLX, it's up to the application writer
-   to create a window with an appropriate colormap.  The aux, tk, and GLUT
-   toolkits try to minimize colormap "flashing" by sharing colormaps when
-   possible.  Specifically, if the visual and depth of the window matches
-   that of the root window, the root window's colormap will be shared by
-   the Mesa window.  Otherwise, a new, private colormap will be allocated.
-
-   When sharing the root colormap, Mesa may be unable to allocate the colors
-   it needs, resulting in poor color quality.  This can happen when a
-   large number of colorcells in the root colormap are already allocated.
-   To prevent colormap sharing in aux, tk and GLUT, define the environment
-   variable MESA_PRIVATE_CMAP.  The value isn't significant.
-
-
-Gamma correction:
-   To compensate for the nonlinear relationship between pixel values
-   and displayed intensities, there is a gamma correction feature in
-   Mesa.  Some systems, such as Silicon Graphics, support gamma
-   correction in hardware (man gamma) so you won't need to use Mesa's
-   gamma facility.  Other systems, however, may need gamma adjustment
-   to produce images which look correct.  If in the past you thought
-   Mesa's images were too dim, read on.
-
-   Gamma correction is controlled with the MESA_GAMMA environment
-   variable.  Its value is of the form "Gr Gg Gb" or just "G" where
-   Gr is the red gamma value, Gg is the green gamma value, Gb is the
-   blue gamma value and G is one gamma value to use for all three
-   channels.  Each value is a positive real number typically in the
-   range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling
-   gamma correction.  Examples using csh:
-
-	% setenv MESA_GAMMA "2.3 2.2 2.4"	// separate R,G,B values
-	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B
-
-   The demos/gamma.c program may help you to determine reasonable gamma
-   value for your display.  With correct gamma values, the color intensities
-   displayed in the top row (drawn by dithering) should nearly match those
-   in the bottom row (drawn as grays).
-
-   Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
-   on HP displays using the HP-ColorRecovery technology.
-
-   Mesa implements gamma correction with a lookup table which translates
-   a "linear" pixel value to a gamma-corrected pixel value.  There is a
-   small performance penalty.  Gamma correction only works in RGB mode.
-   Also be aware that pixel values read back from the frame buffer will
-   not be "un-corrected" so glReadPixels may not return the same data
-   drawn with glDrawPixels.
-
-   For more information about gamma correction see:
-   http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
-
-
-Overlay Planes
-
-   Overlay planes in the frame buffer are supported by Mesa but require
-   hardware and X server support.  To determine if your X server has
-   overlay support you can test for the SERVER_OVERLAY_VISUALS property:
-
-	xprop -root | grep SERVER_OVERLAY_VISUALS
-
-
-HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
-
-   If you set the MESA_HPCR_CLEAR environment variable then dithering
-   will be used when clearing the color buffer.  This is only applicable
-   to HP systems with the HPCR (Color Recovery) system.
-
-
-Extensions
-==========
-   There are three Mesa-specific GLX extensions at this time.
-
-   GLX_MESA_pixmap_colormap 
-
-      This extension adds the GLX function:
-
-         GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-                                           Pixmap pixmap, Colormap cmap )
-
-      It is an alternative to the standard glXCreateGLXPixmap() function.
-      Since Mesa supports RGB rendering into any X visual, not just True-
-      Color or DirectColor, Mesa needs colormap information to convert RGB
-      values into pixel values.  An X window carries this information but a
-      pixmap does not.  This function associates a colormap to a GLX pixmap.
-      See the xdemos/glxpixmap.c file for an example of how to use this
-      extension.
-
-   GLX_MESA_release_buffers
-
-      Mesa associates a set of ancillary (depth, accumulation, stencil and
-      alpha) buffers with each X window it draws into.  These ancillary
-      buffers are allocated for each X window the first time the X window
-      is passed to glXMakeCurrent().  Mesa, however, can't detect when an
-      X window has been destroyed in order to free the ancillary buffers.
-
-      The best it can do is to check for recently destroyed windows whenever
-      the client calls the glXCreateContext() or glXDestroyContext()
-      functions.  This may not be sufficient in all situations though.
-
-      The GLX_MESA_release_buffers extension allows a client to explicitly
-      deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
-      just before an X window is destroyed.  For example:
-
-         #ifdef GLX_MESA_release_buffers
-            glXReleaseBuffersMESA( dpy, window );
-         #endif
-         XDestroyWindow( dpy, window );
-
-      This extension is new in Mesa 2.0.
-
-   GLX_MESA_copy_sub_buffer
-
-      This extension adds the glXCopySubBufferMESA() function.  It works
-      like glXSwapBuffers() but only copies a sub-region of the window
-      instead of the whole window.
-
-      This extension is new in Mesa version 2.6
-
-
-
-Summary of X-related environment variables:
-   MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
-   MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
-   MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
-   MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
-   MESA_GAMMA - gamma correction coefficients (X only)
-
-
-----------------------------------------------------------------------
-README.CYGWIN - lassauge April 2004 - based on README.X11

docs/README.D3D

@@ -0,0 +1,124 @@
+
+                     DirectX 6 Driver for Mesa 3.0
+
+
+This software is distributed under the terms of the GNU Library
+General Public License, see the LICENSE file for details.
+
+
+
+What do you need ?
+------------------
+
+	- A PC with a DirectX 6 video driver installed.
+
+	- Mesa 3.0
+
+	- The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
+	  The Voodoo2 requires the Glide library 2.51. The Glide 3.0 is not
+	  compatible with the Glide 2.x so it doesn't work with the current
+	  version of the driver;
+
+	- Visual C++ 5.0 is only compiler test but others should be ok with
+       changes to the makefiles (CFLAGS/LFLAGS).
+
+	- DirectX 6 SDK (was a MS download but not sure if still available).
+
+	- SoftIce or another debugger that will get DPF's is nice.
+
+
+Tested on:
+----------
+	Windows 95
+  	Windows 98
+	Windows NT 5.0 (beta 2)
+
+
+What is able to do ?
+--------------------
+
+	- the driver will try and use DirectX to rasterize the OpenGL primitives
+	that are sent to the driver.  The driver will fall back to SW  if the rendering 
+	context is too big.  The fallback to SW still uses DirectDraw.  If the driver
+	fails to support and operation (accum, stencil, etc) then it will try and get
+	Mesa to render it in SW.  DirectX 6 features that are unsupported by the 
+	installed DirectX 6 driver will be mapped to some other best fit feature.
+
+
+How to compile:
+---------------
+
+	These instructions assume you have Visual C++ installed.
+
+	  You might need to increase you enviroment space.  You can do this by 
+	adding the following statement to you config.sys.
+
+	shell=C:\COMMAND.COM C:\ /p /e:8198
+
+	  Next setup you compiler enviroment by running vcvars32.bat in the Visual C++
+ 	'bin' directoy.
+
+	c:\DevStudio\VC\bin\vcvars32.bat
+
+	  Modify the D3D makefile to point at your SDK install.  Example has the SDK
+	installed on my 'f' drive in the root.
+
+	file: \Mesa-3.0\src\makefile.d3d
+
+	SDKROOT=f:\mssdk
+
+	  Now you can simply make the project.  If you look in the makefile you can see
+	I have some different targets like 'install'.  
+
+	nmake /f makefile.d3d
+
+
+FAQ:
+----
+
+	1) I don't think the driver is using my DirectX driver.
+
+ 	  This maybe true as the current version will only select the Primary D3D driver
+	installed.  If you 3D card is the secondary (3dfx) then your out of luck for this
+	release.
+
+	2) The driver seems like its not HW accelerated.
+
+	  If you have a video card with limited memory then you might want to try and 
+	change your destop resolution to a low setting (640x480x16) so that the 3D part
+	of the card has more resources.  Remeber the driver can't make the card better...
+
+	3) Nothing works.
+
+	  Make sure you have a DirectX '6' driver installed.  Check you driver docs for this
+	info or use the SDK info utilities.
+	  The final 'dll' is named opengl32.dll and is either in the same directory as the 
+	OpenGL program or in your system directory (x:\windows\system or x:\winnt\system32).
+	  Check your destop resolution.  Most DirectX 6 drivers will only support 16bit and
+	32bit color depth.  To find out for sure you can check the DirectX Info Viewer in
+	the SDK.
+	  
+
+	4) Rendering doesn't look right.
+
+	  Sometimes this is because the card doesn't support a feature that that is required.
+	This is usually due to unsupported alpha functions (test/blend) or texture mapping.
+	Some cards suffer from too small of an alpha channel.  The driver does its best to
+	fallback on unsupported features.  This is not to say the driver may not have a bug(s).
+
+	5) Textures look bad.
+
+	  No mipmapping in this release.
+
+
+Thanks to:
+----------
+
+Brian Paul
+
+
+
+
+Leigh McRae (leigh@altsoftware.com)
+February 9, 1999
+

docs/README.DJ

@@ -0,0 +1,227 @@
+			Mesa 5.1 DOS/DJGPP Port v1.4
+			~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+Description:
+~~~~~~~~~~~~
+
+Well, guess what... this is the DOS port of Mesa 5.1, for DJGPP fans... Whoa!
+The driver has its origins in ddsample.c, written by Brian Paul and found by me
+in Mesa 3.4.2.
+
+
+
+Legal:
+~~~~~~
+
+Mesa copyright applies, provided this package is used within Mesa. For anything
+else, see GPL.
+
+
+
+Installation:
+~~~~~~~~~~~~~
+
+Unzip and type:
+
+	make -f Makefile.DJ [OPTIONS...]
+
+Available options:
+
+     Environment variables:
+	CPU		optimize for the given processor.
+			default = pentium
+	GLU=[mesa|sgi]	specify GLU directory; can be `sgi' (requires GNU/C++)
+			or `mesa'.
+			default = mesa
+	GLIDE		path to Glide3 SDK; used with FX.
+			default = $(TOP)/glide3
+	FX=1		build for 3dfx Glide3. Note that this disables
+			compilation of most DMesa code and requires fxMesa.
+			As a consequence, you'll need the DJGPP Glide3
+			library to build any application.
+			default = no
+	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.
+			This is experimental and not intensively tested.
+			default = no
+	HAVE_X86=1	optimize for i386.
+			default = no
+	HAVE_MMX=1	allow MMX specializations, provided your assembler
+			supports MMX instruction set. However, the true CPU
+			capabilities are checked at run-time to avoid lockups.
+			default = no
+	HAVE_SSE=1	(see HAVE_MMX)
+			default = no
+	HAVE_3DNOW=1	(see HAVE_MMX)
+			default = no
+
+     Targets:
+	all:		build everything
+	libgl:		build GL
+	libglu:		build GLU
+	libglut:	build GLUT
+	clean:		remove object files
+	realclean:	remove all generated files
+
+
+
+Tested on:
+	CPU:		AMD Athlon XP 1800+
+	Mainboard:	EP-8KTA3 w/ 128 MB SDRAM
+	Video card:	Voodoo5 5500 AGP w/ 64 MB SDRAM
+	DJGPP:		djdev 2.04 + gcc v3.2.2 + make v3.80
+	OS:		DOS and Win98SE
+
+
+
+FAQ:
+~~~~
+
+1. Compilation
+
+   Q) `make' barfs and exits because it cannot find some stupid file.
+   A) You need LFN support.
+   A) When compiling for Glide (FX=1), pay attention to Glide path.
+
+   Q) Libraries built OK, but linker complains about `vsnprintf' every time I
+      compile some demo.
+   A) Upgrade to DJGPP 2.04.
+   A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).
+   A) Patch `src/mesa/main/imports.c' with the following line:
+	#define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)
+      This hack should be safe in 90% of the cases, but if anything goes wrong,
+      don't come back to me crying.
+
+   Q) `make' complains about DXE3 or something, yet it builds the libraries.
+   A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest
+      DJGPP distro, or download the separate package from my web page. Read the
+      DXE3 documentation on how to use them.
+   A) When compiling for Glide (FX=1), make sure `glide3x.dxe' can be found in
+      LD_LIBRARY_PATH (or top `lib' directory).
+
+2. Using Mesa for DJGPP
+
+   Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...
+   A) Is that a question? If you have a 3dfx Voodoo Banshee or higher card,
+      you're lucky (check http://sourceforge.net/projects/glide for the DJGPP
+      port). If you have a Matrox Millennium I card, you just MIGHT be lucky...
+      If you haven't, sorry; everything is done in software. Suggestions?
+
+   Q) I tried to set refresh rate w/ DMesa, but without success.
+   A) Refresh rate control works only for VESA 3.0. If you were compiling for
+      Glide, see Glide info. If not, sorry!
+
+   Q) I made a simple application and it does nothing. It exits right away. Not
+      even a blank screen.
+   A) The pure software drivers (VESA/VGA) support only double-buffered modes.
+   A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a
+      lazy programmer and I found that the easiest way to keep buffer handling
+      at peak performance ;-).
+
+   Q) The GLUT is incomplete.
+   A) See below.
+
+
+
+libGLUT (the toolkit):
+~~~~~~~~~~~~~~~~~~~~~~
+
+Well, this "skeletal" GLUT implementation was taken from AllegGL project and
+heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian
+Paul and probably others (or probably not ;-). GLUT functionality will be
+extended only on an "as needed" basis.
+
+GLUT talks to hardware via PC_HW package which was put together from various
+pieces I wrote long time ago. It consists from the keyboard, mouse and timer
+drivers.
+
+My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,
+I borrowed the translation tables (and maybe more) from Allegro -- many thanks
+to Shawn Hargreaves et co. Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users)
+will shut down the GLUT engine unconditionally: it will raise SIGINT, which in
+turn will (hopefully) call the destructors, thus cleaning up your/my mess ;-)
+NB: since the DJGPP guys ensured signal handlers won't go beyond program's
+space (and since dynamic modules shall) the SIGINT can't be hooked (well, it
+can, but it is useless), therefore you must live with the 'Exiting due to
+signal SIGINT' message...
+
+The mouse driver is far from complete (lack of drawing, etc), but is enough to
+make almost all the demos work. Supports the CuteMouse WheelAPI.
+
+The timer is pretty versatile for it supports multiple timers with different
+frequencies. While not being the most accurate timer in the known universe, I
+think it's OK. Take this example: you have timer A with a very high rate, and
+then you have timer B with very low rate compared to A; now, A ticks OK, but
+timer B will probably loose precision!
+
+As an addition, stdout and stderr are redirected and dumped upon exit. This
+means that `printf' can be safely called during graphics. A bit of a hack, I
+know, because all messages come in bulk, but I think it's better than nothing.
+"Borrowed" from LIBRHUTI (Robert Hoehne).
+
+Window creating defaults: (0, 0, 300, 300), 16bpp. However, the video mode is
+chosen in such a way that first window will fit. If you need high resolution
+with small windows, set initial position far to the right (or way down); then
+you can move them back to any position right before the main loop.
+
+The following environment variables can customize GLUT behaviour:
+	GLUT_FPS		- print frames/second statistics to stderr
+	DMESA_GLUT_REFRESH	- set vertical screen refresh rate (VESA3)
+	DMESA_GLUT_BPP		- set default bits per pixel (VGA needs 8)
+	DMESA_GLUT_ALPHA	- set default alpha bits (8)
+	DMESA_GLUT_DEPTH	- set default depth bits (16)
+	DMESA_GLUT_STENCIL	- set default stencil bits (8)
+	DMESA_GLUT_ACCUM	- set default accum bits (16)
+
+
+
+History:
+~~~~~~~~
+
+v1.0 (mar-2002)
+	initial release
+
+v1.1 (sep-2002)
+	+ added 3dfx Glide3 support
+	+ added refresh rate control
+	+ added fonts in GLUT
+	* lots of minor changes
+
+v1.2 (nov-2002)
+	* synced w/ Mesa-4.1
+	- removed dmesadxe.h
+
+v1.3 (mar-2003)
+	+ enabled OpenGL 1.4 support
+	+ added MMX clear/blit routines
+	+ enabled SGI's GLU compilation
+	+ added samples makefile
+	+ added new GLUT functions
+	+ added color-index modes
+	+ added Matrox Millennium MGA2064W driver
+	+ added 8bit FakeColor (thanks to Neil Funk)
+	+ added VGA support (to keep Ben Decker happy)
+	! fixed some compilation errors (reported by Chan Kar Heng)
+	* optimized driver for faster callback access... yeah, right :)
+	* overhauled virtual buffer and internal video drivers
+	* better fxMesa integration
+	* revamped GLUT
+	* switched to DXE3
+
+v1.4 (nov-2003)
+	+ enabled GLUT fonts with DXE
+	+ truly added multi-window support in GLUT (for Adrian Woodward)
+	* accomodated makefiles with the new sourcetree
+	* fixed some ALPHA issues
+	* minor changes to PC_HW/timer interface
+	x hacked and slashed the 3dfx driver (w/ help from Hiroshi Morii)
+
+
+
+Contact:
+~~~~~~~~
+
+Name:   Borca Daniel
+E-mail: dborca@users.sourceforge.net
+WWW:    http://www.geocities.com/dborca/

docs/README.GGI

@@ -0,0 +1,26 @@
+GGIMesa for LibGGI 2.x
+
+Requirements:
+-------------
+LibGGI 2.0 or greater
+
+Installation:
+-------------
+To install GGIMesa, follow the instructions in INSTALL.GNU.  If you 
+wish to install GGIGLUT as well, first install GGIMesa and then run
+
+make
+make install (must be root)
+
+in ggi/ggiglut.
+
+Notes:
+------
+
+* Set the environment variables GGIMESA_DEBUG and/or GGIGLUT_DEBUG 
+to 255 to see lots of debugging output.
+
+* GGIGLUT contains support for all of the GLUT 3.6 API except for the
+high-level primitive drawing functions, but many of the functions (in
+particular the menu drawing functions) are just stubs.
+

docs/README.LYNXOS

@@ -0,0 +1,64 @@
+
+Mesa 3.0 for LynxOS builds in the following way:
+
+make lynxos
+
+This will build all the libraries and demo applications. You should have 
+around 400 megabytes free for everything since everything is done with 
+static
+libraries.
+
+Before using this make file however, you should perform the following 
+actions:
+0) cd to the Mesa-3.0 directory
+1) Copy the GL directory under the include directory to /usr/include.
+2) Copy the files in the lib directory to /lib.
+3) Make links so that the Mesa libraries look like ordinary OpenGL 
+libraries
+in /lib. This is important for compatibility with other OpenGL apps. This
+is done as follows:
+
+cd /lib
+ln -s libMesaGL.a libGL.a
+ln -s libMesaGLU.a libGLU.a
+
+Mesa 3.0 includes the GLUT (GL Utility Toolkit) by default.
+The demo applications are done using this toolkit.
+
+Mesa makefiles for building their apps could be used as well, but the
+following one is much more concise. Note that the order of the X libraries
+is important to the linker so that all symbols get resolved correctly.
+Changing the order may result in having to list a library twice to make
+sure all linkages are made correctly.
+
+----cut here for Makefile -----
+
+FILES = your_app.x
+
+SPECIAL_INCLUDES = -I/usr/include/GL
+
+SPECIAL_CFLAGS = -g  -ansi -pedantic -funroll-loops -ffast-math -DSHM
+
+SPECIAL_LIBS = -lglut -lGLU -lGL -lm -L/usr/X11/lib -lXext -lXmu -lXi \
+-lX11 -lbsd -g
+
+STANDARD_OFILES = $(FILES:.x=.o)
+
+%.o: %.c
+	gcc -c $(SPECIAL_CFLAGS) $(SPECIAL_INCLUDES) $< -o $@
+
+all: $(STANDARD_OFILES)
+	gcc -o your_app $(STANDARD_OFILES) $(SPECIAL_LIBS)
+
+
+----cut here for Makefile-----
+
+I have tested Mesa under LynxOS 3.0 and 3.01. It should build fine under 
+other
+versions as well. Note, however, that LynxOS versions prior to 3.0 are not
+binary compatible, so you will have to rebuild from source.
+
+
+Vik Sohal
+vik@lynx.com
+January 13, 1999

docs/README.MINGW32

@@ -0,0 +1,53 @@
+August 30, 1998 -- Paul Garceau
+Updated January 13, 2000 -- Paul Garceau (pgarceau@teleport.com)
+
+DISCLAIMER:  I make this port of the Mesa 3-D Graphics Library as a service
+to the general public.  I can, in no way support or make any guarantee that the
+build will work for your system.
+
+	The associated packages and batch files I have included as part of the GCC-2.95.2/Mingw32 extension are provided "As-is" with out any guarantee of support or functionality from this author.
+
+	Feel free to modify or change things as you see fit, just remember that
+I can't support any modifications you might want to make to the files which I
+have included OR the lgpl protected Mesa 3-D Graphics Library.
+
+	I recommend using GCC-2.95.2/Mingw32 which is available at Mumit Khans' ftp site:
+
+		(ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/)
+
+	This build has been tested under WinNT4/SP6.  Win9x and WinNT5 remain untested by me.  I have not tested any of the demos included with Mesa3d.
+
+	I recommend using the GCC-2.95.2/Mingw32.
+
+	ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2
+
+	Much thanks to the combined efforts of Mumit Khan, Jan-Jaap Vanderhagen
+and Colin Peters for making it possible for the Mingw32 toolchain to exist.  Also, thanks go out to Stephane Rehel for the work that was completed on the Cygwin build.
+
+Installing GCC-2.95.2/Mingw32 Build:
+
+	a) Open the file archive (either tar.gz or .zip extensions)
+
+	b) Decide the directory you want to move the archived files to.
+
+	d) Extract the files from the archive.
+	
+	e) Edit the mingw32.bat file to accomodate your choice of directory structure.
+
+		%mesaroot%:	This is your root directory (Mesa-3.3)
+		%mesasrc%:	This is the Mesa-3.3 src directory (Mesa-3.3\src)
+		%mesalib%:	This is where the build will put libGL.a and libGLU.a
+
+Running the Build:
+
+	Open your Command Prompt or MS-DOS prompt.
+	Go to your Mesa-3.3 'root' directory
+	At the command line type: mingw32
+
+	That's all there is to it.
+
+	Enjoy!
+
+	Peace,
+
+		Paul G. (pgarceau@teleport.com)

docs/README.NeXT

@@ -0,0 +1,6 @@
+The NeXT support has now been incorporated into the OpenStep support.
+You can build NeXT libraries simply by typing "make next", though before
+linking they will need to be ranlib'd by hand. For more information see
+the README.OpenStep file, together with the README files in OpenStep/Old_Demos.
+
+-Pete French. (pete@ohm.york.ac.uk) 28/5/1998

docs/README.OS2

@@ -0,0 +1,96 @@
+            README for port of Mesa 3.x to XFree86 on OS/2 (X/2)
+                          (as of 19990514)
+
+
+                           Contents:
+
+                           1) Binary release
+                           2) Building from sources
+                           3) History
+                           4) Todo
+                           5) Mesa Home Page
+
+
+1) Binary release
+
+   Though the Mesa sources should build in a quite reasonable time even on
+   a 585 class machine a binary relase is available (check topic 4) for an URL)
+   This package includes:
+
+     - lib/MesaGL.dll,  MesaGL.a
+     - lib/MesaGLU.dll, MesaGLU.a
+     - lib/glut.dll,    glut.a
+     - include/GL/*.h
+
+    Installing this in your XFree86 tree will enable you to build and
+    run all applications compatible with Mesa (and the current DLL
+    interface, of course ;-)
+    As usual the OMF-style libraries can be created using emxomf.
+    (e.g. "emxomf foo.a"  creates the foo.lib omf-style library).
+    The static libraries are rarely used and you have to rebuild
+    Mesa to get them. They're a supported target, so you get
+    them in a straightforward way (see below).
+
+    The testing of these libraries was limited to the supplied
+    demos/examples and a quite small number of third-party apps.
+    No warranty ... as usual ...  ;-)
+
+
+2)  Instructions to build Mesa 3.x for XFree86/OS2 from sources:
+
+    Except the official Mesa source distribution you need:
+      - a recent version of XFree86 (3.3.x or above) including
+        the programming libraries
+      - EMX 0.9c (0.9d might work, never checked)
+      - GNU make
+      - REXX (!)
+
+    The creation of the DLLs as well as of the static libraries
+    (if you want to have them) is handled in "mklib-emx.cmd",
+    a small REXX script. Perhaps not the best idea, but this
+    way it fits best in the scheme used to build libraries
+    on all platforms in Mesa 3.x.
+
+    To actually build the libraries and demos, check mklib-emx.cmd
+    and modify it as desired. Then type
+      make os2-x11
+    and wait for completion ;-)
+
+
+3)  History
+
+    Initially Darren Abbott (abbott@hiwaay.net) ported Mesa versions 2.x
+    to XFree86 OS/2. This port might still be available from 
+       http://fly.HiWAAY.net/~abbott/xfree86-os2/xfree86.html
+
+    The current port picked up things during the beta test for 3.0. 
+    No major changes in the source were done. The build mechanism under OS/2
+    has been made very similar to other platforms (if you treat mklib-emx.cmd
+    as a "black box").
+    Advantage is that X/2 is now a valid target and all files are
+    integrated in the official source distribution.
+    Disadvantage is that this port (i.e. the DLLs' interface itself) is
+    definitly NOT COMPATIBLE to those of version 2.x. 
+    It's uncertain whether this would be at all possible but since there
+    a _very_ few those apps it's not worth to find out anyway.
+    Also some libs (MesaTK, MesaAUX) are withdrawn from the Mesa distribution,
+    and accordingly from the OS/2 port.
+
+4) Todo
+
+    By now binary compatiblity is ensured by using the function names
+    as entry points instead of ordinals. This might cost performance and
+    is subject to change in future. In addition the supplied X86 assembler
+    source is not used yet.
+
+5)  Mesa Home Page
+
+    You can get the source code and more information about Mesa from
+       http://www.mesa3d.org/
+
+    The OS/2 ports should be available from
+       http://r350.ee.ntu.edu.tw/~hcchu/os2/ports 
+
+--
+Alexander Mai
+st002279@hrzpub.tu-darmstadt.de

docs/README.OpenStep

@@ -0,0 +1,35 @@
+This is a port of the GL and GLU libraries to NeXT/Apple object
+orientated systems. As these systems have their own window handling
+systems we simply use the offscreen rendering capability of Mesa
+to generate bitmaps which may then be displayed by the application
+with a View as required. Example pieces of code may be found in the
+OpenStep directory.
+
+Sadly there are now a proliferation of different system that we need to
+support compilation for: The original NextStep system, The OpenStep
+system, the Rhapsody/Mac OS X system and also the windows implementations
+of the latter two systems. This version of the code has been compiled and
+tested under the following architectures:
+
+	NextStep 3.3 
+	OpenStep 4.2
+	Rhapsody DR2
+	WebObjects for NT 3.5
+	WebObjects for NT 4.0
+
+All tests were done with Intel processors. Feedback on other systems would,
+however, be appreciated !
+
+On UNIX systems simply type "make openstep". Under Windows systems
+with WebObjects run the "win32-openstep.sh" script from within the Bourne
+shell provided with the development environment. In both cases this will
+build the libraries and place them into the "lib" directory. Some examples
+may be found in the OpenStep directory showing how to use the code in an
+actual application (MesaView) as well as some command line demos.
+
+The CC variable may be specified on the command line for doing such things
+as building FFAT libraries or using alternative compilers to the standard 'cc'
+e.g.  make CC='cc -arch m68k -arch i386' openstep" will build the libraries
+with both intel and motorola architectures.
+
+-Pete French. (pete@ohm.york.ac.uk) 7/6/1999

docs/README.QUAKE

@@ -205,3 +205,4 @@ http://www.linuxgames.com/quake2/
 
 
 ----------------------------------------------------------------------
+$Id: README.QUAKE,v 1.3 1998/08/23 15:26:26 brianp Exp $

docs/README.VMS

@@ -26,13 +26,3 @@ On Alpha platforms at default a sharable images for the libraries are created.
 To get a static library make it by typing MMS/MACRO=(NOSHARE=1).
 On VAX platforms only static libraries can be build.
 
-23-sep-2005
-changed default compilation to use /float=ieee/ieee=denorm. The reason for 
-this is that it makes Mesa on OpenVMS better compatible with other platforms
-and other packages for VMS that I maintain.
-For more information see
-      http://nchrem.tnw.tudelft.nl/openvms
-      https://bugs.freedesktop.org/show_bug.cgi?id=4270
-You may want to compile Mesa to use VAX-floating point arithmetic, instead
-of IEEE floating point by removing the /float=IEEE/denorm flag from the
-compiler options in the descrip.mms files.

docs/README.WIN32

@@ -1,53 +1,91 @@
 File: docs/README.WIN32
 
-Last updated: 23 April 2011
-
+Last updated: Sep 18, 2003 - Karl Schultz - kschultz@users.sourceforge.net
 
 Quick Start
------ -----
 
-Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
-no longer shipped or supported.
+Unzip both ZIP files (MesaLib and MesaDemos) into the same directory.
+The libs and demos build separately, so if you do not care about the
+demos, you do not have to unzip that zip file.  But if you do, it does
+need to be unzipped into the same directory as the lib zip file because
+the demos depend on the libs.
 
-Run
+The build system has been changed to use Microsoft Visual Studio project
+workspaces and projects.  Makefiles are no longer shipped or supported, but
+can be generated from the projects using Visual Studio.
 
-  scons osmesa mesagdi
+Details and Notes
 
-to build classic mesa Windows GDI drivers; or
+- To build the Mesa libraries, open the Mesa.dsw workspace file
+  in the top directory.  You can build each project one-by-one,
+  or build the glut project to build everything except osmesa,
+  which needs to be built separately.  The build process will
+  create a lib directory in the top directory and will put the
+  following files there:
+	OPENGL32.LIB, GLU32.LIB, GLUT32.LIB, OSMESA32.LIB
+	OPENGL32.DLL, GLU32.DLL, GLUT32.DLL, OSMESA32.DLL
 
-  scons libgl-gdi
+- After building, you can copy the above DLL files to a place in your PATH
+  such as $SystemRoot/SYSTEM32.  If you don't like putting things in a
+  system directory, place them in the same directory as the executable(s).
+  Be careful about accidentially overwriting files of the same name in
+  the SYSTEM32 directory.
 
-to build gallium based GDI driver.
+- Build the demos by opening the appropriate *.dsw file in the
+  progs directory tree.  For example, to build the demos, use
+  progs/demos/Windows/demos.dsw.  The Windows directory contains
+  the workspace and all the projects for each demo program.  Each
+  project places the executable in the same directory as its source
+  code, which is required for some demos.
 
-This will work both with MSVS or Mingw.
+- The demo projects also copy the Mesa library DLL files from the lib
+  directory into the same directory as the demo executables, so that
+  the demos use the Mesa libs you just built.
+
+- The DLL files are built so that the external entry points use the
+  stdcall calling convention.
+
+- Static LIB files are not built.  The LIB files that are built with
+  are the linker import files associated with the DLL files.  
+
+- The si-glu sources are used to build the GLU libs.  This was done
+  mainly to get the better tessellator code.
+
+- The osmesa driver builds and should work on Windows as well as
+  any other platform.
+
+- The Windows driver (in src/Windows) builds and runs at least at
+  a minimal level.  I modified this driver to work with the new
+  Mesa 4.0 code and driver architecture, but I did not do a great
+  deal of optimization and testing.  There are many opportunities
+  for optimization, many of which can be done by coding more specific
+  paths for the rasterizers.  See src/osmesa/osmesa.c for some good
+  examples.
+
+- There is DirectDraw support in the Windows driver, updated by
+  Daniel Slater.  You'll need to uncomment the #define DDRAW line
+  in src/Windows/wmesadef.h and add ddraw.lib to the list of libraries.
+  On some systems, you will acheive significantly higher framerates 
+  with DirectDraw.
+
+- Some of the more specialized code like FX drivers, stereo, and
+  parallel support isn't compiled or tested.  I left much of this
+  code alone, but it may need some work to get it 'turned on' again.
+
+- No assembly code is compiled or assembled.  Again, this may need
+  some work to turn it back on or use it again.
+
+- To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE
+  to the project settings.  You will also need to edit src/mesa.def to change
+  all the gl* symbols to mgl*.  Because this is easy to do with a global
+  replace operation in a text editor, no additional mangled version of mesa.def
+  is maintained or shipped.
+
+If you have a Windows-related build problem or question, it is
+probably better to direct it to me (kschultz@users.sourceforge.net),
+rather than directly to the other Mesa developers.  I will help you
+as much as I can.  I also monitor the Mesa mailing lists and will
+answer questions in this area there as well.
 
 
-Windows Drivers
-------- -------
-
-At this time, only the gallium GDI driver is known to work.
-
-Source code also exists in the tree for other drivers in
-src/mesa/drivers/windows, but the status of this code is unknown.
-
-
-General
--------
-
-After building, you can copy the above DLL files to a place in your
-PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things
-in a system directory, place them in the same directory as the
-executable(s).  Be careful about accidentially overwriting files of
-the same name in the SYSTEM32 directory.
-
-The DLL files are built so that the external entry points use the
-stdcall calling convention.
-
-Static LIB files are not built.  The LIB files that are built with are
-the linker import files associated with the DLL files.
-
-The si-glu sources are used to build the GLU libs.  This was done
-mainly to get the better tessellator code.
-
-If you have a Windows-related build problem or question, please post
-to the mesa-dev or mesa-users list.
+Karl Schultz

docs/README.WINDML

@@ -0,0 +1,146 @@
+
+                        WindML Driver for Mesa 4.0
+
+
+Requirements
+------------
+
+Tornado 2 + WindML, Cumulative Patchs are recommended. 
+  
+I suppose you have a valid WindML installation. Double buffer hardware
+gives better performance than double buffer software so if you can
+compile your WindML driver with this option, just do it. I/O
+redirection is adviced in target server.
+
+
+Tested on
+---------
+
+During the development, my main target was a CoolMonster:
+- Video card: CT69000
+- CPU: PENTIUM 266MHz
+
+and my host a Windows NT + Tornado 2.
+
+
+Installation
+------------
+
+1. Mesa sources must be in root directory (C:\)
+
+2. Add the following line to your torVars.bat:
+set MESA_BASE=C:\Mesa
+
+OR copy the new torVars.bat in your bin path:
+c:/Mesa/src/ugl/tornado/torVars.sample -> 
+/mnt/nt/Tornado/host/x86-win32/bin/torVars (for example)
+
+3. In a command prompt:
+$ torVars
+$ cd c:\Mesa
+$ make -f Makefile.ugl CPU=PENTIUM
+
+Take a long while...
+
+5. Include all the files from ugldemos folder to build some downloadable
+   application modules
+
+4. Download UGL/Mesa object files on target
+
+For example via the WindShell:
+ld < c:\Tornado\target\lib\objMesaGL.o
+ld < c:\Tornado\target\lib\objMesaUGL.o
+ld < c:\Tornado\target\lib\objMesaGLU.o
+ld < c:\Tornado\target\lib\objGLUTshapes.o
+ld < c:\Tornado\target\lib\objMesaOS.o
+
+You can put the previous lines in a file and use:
+< filename
+
+6. Download the application modules.
+
+7. In WindShell, run:
+-> uglalldemos
+
+During the show some messages will appear, it provides some useful
+information on key management.
+
+
+Coding
+------
+
+Sample Usage:
+
+In addition to the usual ugl calls to initialize UGL, (may be find an
+input driver), you must do the following to use the UGL/Mesa interface:
+
+1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context,
+   given the display format.
+
+2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an
+   UGL/Mesa Context and to make the context the current one.
+
+3. Make gl* calls to render your graphics.
+
+4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers.
+
+5. Before the UGL is destroyed, call MesaDestroyContext().
+
+6. Before exiting, call if required uglEventQDestroy and then
+   uglDeinitialize();
+
+Limitations
+-----------
+
+I found the following limitations in my driver :
+ - Color Indexed management is only in 8 bits
+ - It's possible to mix UGL/OpenGL application with a software
+   double buffer
+
+Modifications
+------------
+
+New files in Mesa:
+- Makefile.ugl
+- rules.windmlmesa
+- docs/README.UGL
+- include/GL/uglmesa.h
+- si-glu/Makefile.ugl
+- src/Makefile.ugl
+- src/ugl/torGLUTShapesInit.c
+- src/ugl/torMesaUGLInit.c
+- src/ugl/ugl_api.c
+- src/ugl/ugl_dd.c
+- src/ugl/ugl_glutshapes.c
+- src/ugl/ugl_line.c
+- src/ugl/ugl_span.c
+- src/ugl/ugl_tri.c
+- src/ugl/uglmesaP.h
+- ugldemos/*
+
+Modified files in Tornado 2.0:
+- c:\Tornado\host\x86-win32\bin\torVars.bat
+rem Command line build environments
+set WIND_HOST_TYPE=x86-win32
+set WIND_BASE=C:\Tornado
+set MESA_BASE=C:\Mesa
+set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%
+- c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf
+- c:\Tornado\target\h\GL\*
+
+Todo
+----
+- GCC 2.96, ASM compilation
+
+Thanks to:
+----------
+
+Precision Insight team for their great job around Mesa, XFree, and DRI.
+Wind River Systems to take me as an intern.
+
+
+Stephane Raimbault
+<stephane.raimbault@windriver.com>
+<stephane.raimbault@deesse.univ-lemans.fr>
+
+July 24, 2001

docs/README.X11

@@ -0,0 +1,314 @@
+
+                          Mesa Unix/X11 Information
+
+
+
+Installation
+============
+
+There are two ways to compile Mesa on Unix/X11 systems:
+
+1. The old way:
+    First type 'make' alone to see the list of system
+    configurations currently supported.  If you see your configuration on the
+    list, type 'make <config>'.  Most popular Unix/X workstations are currently
+    supported.
+
+    If your system configuration is not listed by 'make', you'll have to modify
+    the top-level Makefile and Make-config files.  There are instructions in
+    each file.
+
+    When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
+
+
+2. The new way:
+    Type './configure' and then 'make'.  This uses GNU autoconfig.
+    Run 'make check' to build the demos.
+    See docs/INSTALL for more details.
+    When finished, the Mesa libraries will be in the Mesa-x.y/src/.libs/,
+    Mesa-x.y/si-glu/.libs, etc directories.
+
+
+Notes on assembly language optimizations:
+
+   When using the old-style Makefiles, you can specify a configuration
+   that uses X86 assembly language optimizations (linux-3dnow for example).
+
+   The detection of MMX, 3DNow!, PIII/SSE, etc capability is done at
+   runtime.  That means you can compile Mesa for 3DNow! optimizations
+   even if you don't have an AMD CPU.
+
+   However, your Linux binutils and assembler must understand the
+   special instructions in order to compile them.  If you have
+   compilation problems, try upgrading your binutils.
+
+
+Header and library files:
+   After you've compiled Mesa and tried the demos I recommend the following
+   procedure for "installing" Mesa.
+
+   Copy the Mesa include/GL directory to /usr/local/include:
+	cp -r include/GL /usr/local/include
+
+   Copy the Mesa library files to /usr/local/lib:
+	cp lib/* /usr/local/lib
+
+	(actually, use "cp -d" on Linux to preserve symbolic links)
+
+
+Xt/Motif widgets:
+   If you want to use Mesa or OpenGL in your Xt/Motif program you can build
+   the widgets found in either the widgets-mesa or widgets-sgi directories.
+   The former were written for Mesa and the later are the original SGI
+   widgets.  Look in those directories for more information.
+
+
+Notes:
+   HP users:  a Mesa user reports that the HP-UX 10.01 C compiler has
+   a bug which effects glReadPixels.  A patch for the compiler (PHSS_5743) is
+   available.  Otherwise be sure your compiler is version 10.13 or later.
+
+   QNX users:  if you have problems running the demos try setting the
+   stack size to 200K or larger with -N200K, for example.
+
+   SunOS 5.x users:  The X shared memory extension may not work
+   correctly.  If Mesa prints an error message to the effect of "Shared memory
+   error" then you'll have to append the following three lines to the end of
+   your /etc/system file then reboot:
+      set shmsys:shminfo_shmmax = 0x2000000
+      set shmsys:shminfo_shmmni = 0x1000
+      set shmsys:shminfo_shmseg = 0x100
+
+
+
+Using the library
+=================
+
+Configuration options:
+   The file src/config.h has many parameters which you can adjust such
+   as maximum number of lights, clipping planes, maximum texture size,
+   etc.  In particular, you may want to change DEPTH_BITS from 16 to 32
+   if a 16-bit depth buffer isn't precise enough for your application.
+
+
+Shared libraries:
+   If you compile shared libraries you may have to set an environment
+   variable to specify where the Mesa libraries are located.  On Linux and
+   Sun systems for example, set the LD_LIBRARY_PATH variable to include
+   /your-dir/Mesa-2.6/lib.   Otherwise, when you try to run a demo it
+   may fail with a message saying that one or more libraries couldn't be
+   found.
+
+
+Remote display of OpenGL/GLX programs:
+   As of version 1.2.3, Mesa's header files use the same GLenum and GLUenum
+   values as SGI's (and most/all other vendor's) OpenGL headers.  This means
+   you can freely mix object files compiled with OpenGL or Mesa headers.
+   In fact, on systems with dynamic runtime linkers it's possible to dynam-
+   ically link with Mesa or OpenGL shared libraries at runtime, without
+   recompiling or relinking anything!
+
+   Using IRIX 5.x as an example, you can run SGI's OpenGL demos with the
+   Mesa shared libraries as follows.  Let's assume you're installing Mesa
+   in /usr/local/Mesa and using the C-shell:
+       % cd /usr/local/Mesa
+       % make irix5-dso
+       % setenv _RLD_LIST "/usr/local/Mesa/lib/libGL.so:DEFAULT"
+       % /usr/demos/bin/ideas_ogl      // this is a test
+
+   You can now run OpenGL executables on almost any X display!  There may
+   be some problems from the fact that Mesa supports many X visual types
+   that an OpenGL client may not expect (grayscale for example).  In this
+   case the application may abort, print error messages, or just behave
+   strangely.  You may have to experiment with the MESA_RGB_VISUAL envi-
+   ronment variable.
+
+
+Xt/Motif Widgets:
+   Two versions of the Xt/Motif OpenGL drawing area widgets are included:
+
+      widgets-sgi/	SGI's stock widgets
+      widgets-mesa/	Mesa-tuned widgets
+
+   Look in those directories for details
+
+
+Togl:
+   Togl is an OpenGL/Mesa widget for Tcl/Tk.
+   See http://togl.sourceforge.net for more information.
+
+
+
+X Display Modes:
+   Mesa supports RGB(A) rendering into almost any X visual type and depth.
+
+   The glXChooseVisual function tries its best to pick an appropriate visual
+   for the given attribute list.  However, if this doesn't suit your needs
+   you can force Mesa to use any X visual you want (any supported by your
+   X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
+   environment variables.  When an RGB visual is requested, glXChooseVisual
+   will first look if the MESA_RGB_VISUAL variable is defined.  If so, it
+   will try to use the specified visual.  Similarly, when a color index
+   visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
+   variable.
+
+   The format of accepted values is:  <visual-class> <depth>
+   Here are some examples:
+
+   using the C-shell:
+	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor
+	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor
+	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor
+
+   using the KornShell:
+	$ export MESA_RGB_VISUAL="TrueColor 8"
+	$ export MESA_CI_VISUAL="PseudoColor 12"
+	$ export MESA_RGB_VISUAL="PseudoColor 8"
+
+
+Double buffering:
+   Mesa can use either an X Pixmap or XImage as the backbuffer when in
+   double buffer mode.  Using GLX, the default is to use an XImage.  The
+   MESA_BACK_BUFFER environment variable can override this.  The valid
+   values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first
+   letter is checked, case doesn't matter).
+
+   A pixmap is faster when drawing simple lines and polygons while an
+   XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you
+   need depth buffering the XImage will almost surely be faster.  Exper-
+   iment with the MESA_BACK_BUFFER variable to see which is faster for
+   your application.  
+
+
+Colormaps:
+   When using Mesa directly or with GLX, it's up to the application writer
+   to create a window with an appropriate colormap.  The aux, tk, and GLUT
+   toolkits try to minimize colormap "flashing" by sharing colormaps when
+   possible.  Specifically, if the visual and depth of the window matches
+   that of the root window, the root window's colormap will be shared by
+   the Mesa window.  Otherwise, a new, private colormap will be allocated.
+
+   When sharing the root colormap, Mesa may be unable to allocate the colors
+   it needs, resulting in poor color quality.  This can happen when a
+   large number of colorcells in the root colormap are already allocated.
+   To prevent colormap sharing in aux, tk and GLUT, define the environment
+   variable MESA_PRIVATE_CMAP.  The value isn't significant.
+
+
+Gamma correction:
+   To compensate for the nonlinear relationship between pixel values
+   and displayed intensities, there is a gamma correction feature in
+   Mesa.  Some systems, such as Silicon Graphics, support gamma
+   correction in hardware (man gamma) so you won't need to use Mesa's
+   gamma facility.  Other systems, however, may need gamma adjustment
+   to produce images which look correct.  If in the past you thought
+   Mesa's images were too dim, read on.
+
+   Gamma correction is controlled with the MESA_GAMMA environment
+   variable.  Its value is of the form "Gr Gg Gb" or just "G" where
+   Gr is the red gamma value, Gg is the green gamma value, Gb is the
+   blue gamma value and G is one gamma value to use for all three
+   channels.  Each value is a positive real number typically in the
+   range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling
+   gamma correction.  Examples using csh:
+
+	% setenv MESA_GAMMA "2.3 2.2 2.4"	// separate R,G,B values
+	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B
+
+   The demos/gamma.c program may help you to determine reasonable gamma
+   value for your display.  With correct gamma values, the color intensities
+   displayed in the top row (drawn by dithering) should nearly match those
+   in the bottom row (drawn as grays).
+
+   Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
+   on HP displays using the HP-ColorRecovery technology.
+
+   Mesa implements gamma correction with a lookup table which translates
+   a "linear" pixel value to a gamma-corrected pixel value.  There is a
+   small performance penalty.  Gamma correction only works in RGB mode.
+   Also be aware that pixel values read back from the frame buffer will
+   not be "un-corrected" so glReadPixels may not return the same data
+   drawn with glDrawPixels.
+
+   For more information about gamma correction see:
+   http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
+
+
+Overlay Planes
+
+   Overlay planes in the frame buffer are supported by Mesa but require
+   hardware and X server support.  To determine if your X server has
+   overlay support you can test for the SERVER_OVERLAY_VISUALS property:
+
+	xprop -root | grep SERVER_OVERLAY_VISUALS
+
+
+HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
+
+   If you set the MESA_HPCR_CLEAR environment variable then dithering
+   will be used when clearing the color buffer.  This is only applicable
+   to HP systems with the HPCR (Color Recovery) system.
+
+
+Extensions
+==========
+   There are three Mesa-specific GLX extensions at this time.
+
+   GLX_MESA_pixmap_colormap 
+
+      This extension adds the GLX function:
+
+         GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+                                           Pixmap pixmap, Colormap cmap )
+
+      It is an alternative to the standard glXCreateGLXPixmap() function.
+      Since Mesa supports RGB rendering into any X visual, not just True-
+      Color or DirectColor, Mesa needs colormap information to convert RGB
+      values into pixel values.  An X window carries this information but a
+      pixmap does not.  This function associates a colormap to a GLX pixmap.
+      See the xdemos/glxpixmap.c file for an example of how to use this
+      extension.
+
+   GLX_MESA_release_buffers
+
+      Mesa associates a set of ancillary (depth, accumulation, stencil and
+      alpha) buffers with each X window it draws into.  These ancillary
+      buffers are allocated for each X window the first time the X window
+      is passed to glXMakeCurrent().  Mesa, however, can't detect when an
+      X window has been destroyed in order to free the ancillary buffers.
+
+      The best it can do is to check for recently destroyed windows whenever
+      the client calls the glXCreateContext() or glXDestroyContext()
+      functions.  This may not be sufficient in all situations though.
+
+      The GLX_MESA_release_buffers extension allows a client to explicitly
+      deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
+      just before an X window is destroyed.  For example:
+
+         #ifdef GLX_MESA_release_buffers
+            glXReleaseBuffersMESA( dpy, window );
+         #endif
+         XDestroyWindow( dpy, window );
+
+      This extension is new in Mesa 2.0.
+
+   GLX_MESA_copy_sub_buffer
+
+      This extension adds the glXCopySubBufferMESA() function.  It works
+      like glXSwapBuffers() but only copies a sub-region of the window
+      instead of the whole window.
+
+      This extension is new in Mesa version 2.6
+
+
+
+Summary of X-related environment variables:
+   MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
+   MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
+   MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
+   MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
+   MESA_GAMMA - gamma correction coefficients (X only)
+
+
+----------------------------------------------------------------------
+$Id: README.X11,v 3.10 2003/03/08 17:38:57 brianp Exp $

docs/RELNOTES-3.1

@@ -143,3 +143,4 @@ code).  Anyone want to help?
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.1,v 1.2 2000/04/07 17:08:06 brianp Exp $

docs/RELNOTES-3.2

@@ -9,3 +9,4 @@ have been added.  For a list of bug fixes please read the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.2,v 1.2 2000/04/07 17:08:06 brianp Exp $

docs/RELNOTES-3.2.1

@@ -29,3 +29,4 @@ GLU library.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.2.1,v 1.2 2000/07/21 16:32:33 brianp Exp $

docs/RELNOTES-3.3

@@ -268,3 +268,4 @@ image convolution.  This will (hopefully) be done for Mesa 3.5/3.6.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.3,v 1.8 2000/07/21 16:26:41 brianp Exp $

docs/RELNOTES-3.4

@@ -19,3 +19,4 @@ see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4,v 1.2 2002/03/23 02:37:17 brianp Exp $

docs/RELNOTES-3.4.1

@@ -19,3 +19,4 @@ the Mesa 3.4 release.  For details, see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4.1,v 1.2 2001/05/23 14:45:01 brianp Exp $

docs/RELNOTES-3.4.2

@@ -19,3 +19,4 @@ the Mesa 3.4.1 release.  For details, see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4.2,v 1.2 2001/05/23 14:45:01 brianp Exp $

docs/RELNOTES-3.5

@@ -225,3 +225,4 @@ In the future I hope to implement support for 32-bit, floating point
 color channels.
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.5,v 1.14 2001/06/20 19:02:48 brianp Exp $

docs/RELNOTES-4.0

@@ -160,3 +160,4 @@ See the VERSIONS file for more details about bug fixes, etc. in Mesa 4.0.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0,v 3.2 2001/10/17 14:59:21 brianp Exp $

docs/RELNOTES-4.0.1

@@ -19,3 +19,4 @@ Mesa 4.0.1 only contains bug fixes since version 4.0.
 See the docs/VERSIONS file for the list of bug fixes.
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.1,v 1.2 2001/12/18 14:08:23 brianp Exp $

docs/RELNOTES-4.0.2

@@ -47,3 +47,4 @@ D3D			needs updating
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.2,v 1.2 2002/03/23 02:38:39 brianp Exp $

docs/RELNOTES-4.0.3

@@ -49,3 +49,4 @@ D3D			needs updating
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.3,v 1.2 2002/06/26 02:36:34 brianp Exp $

docs/RELNOTES-4.1

@@ -305,3 +305,4 @@ are some things to change:
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.1,v 1.22 2002/10/29 15:06:37 brianp Exp $

docs/RELNOTES-5.0

@@ -82,3 +82,4 @@ driver call the _mesa_enable_1_4_extensions() function.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-5.0,v 3.2 2002/11/13 15:33:51 brianp Exp $

docs/RELNOTES-5.0.1

@@ -43,3 +43,4 @@ driver call the _mesa_enable_1_4_extensions() function.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-5.0.1,v 3.1 2003/03/30 16:17:54 brianp Exp $

docs/RELNOTES-5.0.2

@@ -43,3 +43,4 @@ driver call the _mesa_enable_1_4_extensions() function.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-5.0.2,v 1.1 2003/09/04 23:10:38 brianp Exp $

docs/RELNOTES-5.1

@@ -1,7 +1,7 @@
 
                             Mesa 5.1 release notes
 
-                              December 17, 2003
+                              Month day, 2003
 
                                 PLEASE READ!!!!
 
@@ -24,10 +24,6 @@ See the VERSIONS file for a list of bugs fixed in this release.
 New Features in Mesa 5.1
 ------------------------
 
-GL_ARB_vertex_program / GL_ARB_fragment_program
-   Michal Krol and Karl Rasche implemented these extensions.  Thanks!
-   Be aware that there may be some rough edges and lurking bugs.
-
 GL_ATI_texture_env_combine3 extension
    This adds a few new texture combine modes.
    Contributed by Ian Romanick.
@@ -75,24 +71,6 @@ GL_IBM_multimode_draw_arrays
 GL_SUN_multi_draw_arrays
    An alias for GL_EXT_multi_draw_arrays, standard in OpenGL 1.4.
 
-Faster glDrawPixels / glCopyPixels in X11 driver
-   If your X screen is 32bpp, glDrawPixels to the front color buffer will
-   be accelerated (via XPutImage()) if the image format is GL_BGRA and the
-   type is GL_UNSIGNED_BYTE.  No raster operations, such as depth test,
-   blend, fog, etc. can be enabled.
-
-   If your X screen is 16bpp, glDrawPixels to the front color buffer will
-   be accelerated (via XPutImage()) if the image format is GL_RGB and the
-   type is GL_UNSIGNED_SHORT_5_6_5.  No raster operations, such as depth
-   test, blend, fog, etc. can be enabled.
-
-   glCopyPixels() calls for the front color buffer will be accelerated
-   (via XCopyArea()) if no raster operations, such as depth test, blend,
-   fog, pixel zoom, etc. are enabled.
-
-   The speed-up over typical software rendering is a factor of 10 for
-   glDrawPixels and 100 for glCopyPixels.
-
 
 With the addition of GL_ARB_occlusion_query, GL_ARB_vertex_buffer_object,
 GL_ARB_texture_non_power_of_two and GL_EXT_shadow_funcs, Mesa 5.1 supports
@@ -170,10 +148,6 @@ Old files:
 New files:
 	program.[ch]              - generic ARB/NV program code
 	arbprogram.[ch]           - ARB program API functions
-	arbfragparse.[ch]         - ARB fragment program parsing
-	arbvertparse.[ch]         - ARB vertex program parsing
-	arbparse.[ch]             - ARB vertex/fragment parsing
-	arbparse_syn.h            - vertex/fragment program syntax
 	nvprogram.[ch]            - NV program API functions
 	nvvertprog.h              - NV vertex program definitions
 	nvfragprog.h              - NV fragment program definitions
@@ -182,33 +156,13 @@ New files:
 	nvvertexec.[ch]           - NV vertex program execution
 	swrast/s_nvfragprog.[ch]  - NV fragment program execution
 
-The files related to per-vertex handling have changed.
-Old files:
-	tnl/t_eval_api.c          - old per-vertex code
-	tnl/t_imm_alloc.c         - old per-vertex code
-	tnl/t_imm_api.c           - old per-vertex code
-	tnl/t_imm_debug.c         - old per-vertex code
-	tnl/t_imm_dlist.c         - old per-vertex code
-	tnl/t_imm_elt.c           - old per-vertex code
-	tnl/t_imm_eval.c          - old per-vertex code
-	tnl/t_imm_exec.c          - old per-vertex code
-	tnl/t_imm_fixup.c         - old per-vertex code
-	tnl/t_vtx_sse.c           - old per-vertex code
-	tnl/t_vtx_x86.c           - old per-vertex code
-New files:
-	tnl/t_save_api.c          - new per-vertex code
-	tnl/t_save_loopback.c     - new per-vertex code
-	tnl/t_save_playback.c     - new per-vertex code
-	tnl/t_vtx_eval.c          - old per-vertex code
+Removed files:
+	swrast/s_histogram.[ch] - moved into src/histogram.c
 
-Other new files:
+Other New files:
 	bufferobj.[ch]		- GL_ARB_vertex_buffer_object functions
 	version.h		- defines the Mesa version info
 
-Other removed files:
-	swrast/s_histogram.[ch]   - moved into src/histogram.c
-
-
 
 Other Changes
 -------------
@@ -236,11 +190,6 @@ The ctx->_TriangleCaps field is deprecated.
    While testing _TriangleCaps bits was fast, it was kludgey, and setting
    the bits in the first place could be error prone.
 
-New vertex processing code.
-   The code behind glBegin, glEnd, glVertex, glNormal, etc. has been
-   totally rewritten.  It's a cleaner implementation now and should use
-   less memory. (Keith)
-
 
 
 To Do

docs/RELNOTES-6.0

@@ -1,86 +0,0 @@
-
-                           Mesa 6.0 release notes
-
-                             January 16, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 5.1) designate new developmental releases.
-Even numbered versions (such as 6.0) designate stable releases.
-
-Mesa version 6.0 signifies two things:
-
-  1. A stabilization of the 5.1 development release
-  2. Implementation of the OpenGL 1.5 specification.  When you query
-     glGetString(GL_VERSION) "1.5" will be returned (as long as the
-     driver supports all the required features).
-
-
-Note that the Mesa major version number is incremented with the OpenGL
-minor version number:
-
-   Mesa 1.x  ==  OpenGL 1.0
-   Mesa 2.x  ==  OpenGL 1.1
-   Mesa 3.x  ==  OpenGL 1.2
-   Mesa 4.x  ==  OpenGL 1.3
-   Mesa 5.x  ==  OpenGL 1.4
-   Mesa 6.x  ==  OpenGL 1.5
-
-
-
-New Features
-------------
-
-Mesa 5.1 already had all the new features of OpenGL 1.5, implemented as
-extensions.  These extensions were simply promoted to standard features:
-
-   GL_ARB_occlusion_query extension
-   GL_ARB_texture_non_power_of_two extension
-   GL_ARB_vertex_buffer_object extension
-   GL_EXT_shadow_funcs
-
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on
-the device driver.  For example, if the driver enables all the ARB
-extensions which are part of OpenGL 1.3 then glGetString(GL_VERSION)
-will return "1.3".  Otherwise, it'll return "1.2".
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-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.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-
-
-Other Changes
--------------
-
-See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.0.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.0.1

@@ -1,49 +0,0 @@
-
-		       Mesa 6.0.1 release notes
-
-			    April 2, 2003
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 6.0.x) designate stable releases.
-Odd-numbered versions (such as 6.1.x) designate new developmental releases.
-
-Mesa 6.0.1 just fixes bugs found since the 6.0 release.  See the VERSIONS
-file for details.
-
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5
-depending on the device driver's capabilities.  For example, if the
-driver enables all the ARB extensions which are part of OpenGL 1.5
-then glGetString(GL_VERSION) will return "1.5".  Otherwise, it'll
-return "1.4" or the next lower version that implements all required
-functionality.
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-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.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.1

@@ -1,111 +0,0 @@
-
-                           Mesa 6.1 release notes
-
-                              August 18, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.0) designate stable releases.
-
-
-New Features
-------------
-
-Half-precision floating point (GLhalf) pixel formats are supported
-in Mesa, but the feature isn't exposed yet since the ARB extension
-hasn't been finalized yet.
-
-
-Texture image handling
-----------------------
-
-The code which implements image conversion, pixel transfer ops, etc
-for glTexImage commands has been rewritten.
-
-Now the gl_texture_format struct has a new StoreImage function
-pointer.  Each texture format must implement this function.  The
-function is totally responsible for converting the user's texture
-image into the specific format.  A few helper functions makes this
-relatively simple.
-
-Overall, the code is much simpler, cleaner and easier to work with
-now.  Adding new texture formats is straight-forward and there's no
-longer any distinction between "hardware" and "software" formats.
-
-Finally, the code for compressed texture images has been reorganized
-as well.
-
-Removed files:
-  texutil.c
-  texutil.h
-  texutil_tmp.h
-
-New files:
-  texcompress_s3tc.c
-  texcompress_fxt1.c
-
-
-
-Driver / context changes
-------------------------
-
-The _mesa_create_context() and _mesa_initialize_context() function
-parameters have changed.  They now take a pointer to a struct
-dd_function_table.  Drivers can initialize this table by calling
-_mesa_init_driver_functions().  Drivers should then plug in the special
-functions they implement.  In particular, the ctx->Driver.NewTextureObject
-pointer _must_ be set so that the default texture objects created in
-_mesa_create/initialize_context() are correctly built.
-
-The _mesa_init_driver_functions() function allows a lot of redundant code
-to be removed from the device drivers (such as initializing
-ctx->Driver.Accum to point to _swrast_Accum).  Adding new functions to
-the dd_function_table can be done with less hassle since the pointer can
-be initialized in _mesa_init_driver_functions() rather than in _all_ the
-drivers.
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5
-depending on the device driver's capabilities.  For example, if the
-driver enables all the ARB extensions which are part of OpenGL 1.5
-then glGetString(GL_VERSION) will return "1.5".  Otherwise, it'll
-return "1.4" or the next lower version that implements all required
-functionality.
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-
-Other Changes
--------------
-
-See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.1.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.2

@@ -1,51 +0,0 @@
-
-                           Mesa 6.2 release notes
-
-                              October 2, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-This release primarily just fixes bugs found in the Mesa 6.1 release.
-See the VERSIONS file for details.
-
-
-ToDo: PBO for polygon stipple, convolution filter, etc.
-
-
-
-Known Issues
-------------
-
-The GL_EXT_pixel_buffer_object extension isn't fully implemented for
-functions like glPolygonStipple, glConvolutionFilter, glColorTable,
-etc.  The important functions like glRead/DrawPixels, glTex[Sub]Image,
-and glBitmap work with PBOs.
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.2.1

@@ -1,49 +0,0 @@
-
-                           Mesa 6.2.1 release notes
-
-                              December 9, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.2.x) designate stable releases.
-
-
-This release primarily just fixes bugs found in the Mesa 6.2 release.
-See the VERSIONS file for details.
-
-
-
-Known Issues
-------------
-
-The GL_EXT_pixel_buffer_object extension isn't fully implemented for
-functions like glPolygonStipple, glConvolutionFilter, glColorTable,
-etc.  The important functions like glRead/DrawPixels, glTex[Sub]Image,
-and glBitmap work with PBOs.  This has been fixed for Mesa 6.3.
-
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3

@@ -1,114 +0,0 @@
-
-                           Mesa 6.3 release notes
-
-                              July 20, 2005
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-
-New Features
-------------
-
-GL_ARB_draw_buffers - allows a fragment program to write to a number of
-  separate color buffers, instead of just one.
-
-GL_OES_read_format - allows one to query the fastest glReadPixels format
-  and datatype.
-
-GL_ARB_pixel_buffer_object - buffer objects for pixel read/write functions.
-
-GL_EXT_framebuffer_object - allows render-to-texture and provides a
-  window-system indepedent Pbuffer facility.
-  The Mesa CVS tree contains a couple tests of this extension.
-
-DirectFB driver, contributed by Claudio Ciccani.  See docs/README.directfb
-for details.
-
-
-
-Vertex/Fragment Program PRINT Instruction
------------------------------------------
-
-The GL_NV_vertex_program and GL_NV_fragment_program languages have been
-extended with a PRINT instruction.
-
-
-
-glDeleteTextures(), glDeletePrograms() and glDeleteBuffers() Changed
---------------------------------------------------------------------
-
-To match the behaviour of other OpenGL implementations, glDeleteTextures,
-glDeletePrograms and glDeleteBuffers have been modified so that:
-
-  * The named texture/program/buffer ID is immediately freed for re-use.
-
-  * The actual texture object, program or buffers isn't really deleted until
-    it is no longer bound in any rendering context (the reference count
-    is zero).
-
-Previously, the texture/program/buffer ID wasn't freed until the object
-was really deleted.
-
-Note that textures, programs and buffers can be shared by several rendering
-contexts so they can't be deleted until they're unbound in _all_ contexts.
-
-
-
-GL_EXT_framebuffer_object changes
----------------------------------
-
-Implementing this extension involved changing a lot of code (for the better).
-
-The gl_framebuffer object now a collection of gl_renderbuffer objects.
-Renderbuffers may store colors, stencil indices, or depth values.  The
-gl_framebuffer and gl_renderbuffer types are object-oriented in design.
-
-All the old RGB, color index, stencil and depth-related span functions for
-reading/writing pixels from/to buffers has changed.  Now, all pixels are
-read/written through a set of common renderbuffer functions (methods).
-
-Most device drivers have been updated for these changes, but some haven't.
-
-
-
-To Do (someday) items
----------------------
- Switch to freeglut
- Increase MAX_DRAWBUFFERS
- driver hooks for BeginQuery/EndQuery
-
-
-
-Miscellaneous
--------------
-
-The main/get.c file is now generated with a Python script (get_gen.py).
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3.1

@@ -1,48 +0,0 @@
-
-                           Mesa 6.3.1 release notes
-
-                               July XX, 2005
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-
-DRI drivers
------------
-
-This release includes the DRI drivers and GLX code for hardware rendering.
-
-
-
-Bug fixes
----------
-
-Bugs fixed in 6.3.1 are listed in the VERSIONS file.
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3.2

@@ -1,36 +0,0 @@
-
-		       Mesa 6.3.2 Release Notes
-
-			   August 19, 2005
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-6.3.2 is primarily a bug-fix release.  See the VERSIONS file for details.
-
-
-
-Driver			Status
-----------------------	----------------------
-DRI drivers		varies with the driver
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.4

@@ -1,49 +0,0 @@
-
-		        Mesa 6.4 Release Notes
-
-			   October 24, 2005
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.4) designate stable releases.
-
-
-6.4 is a bug-fix release.  See the VERSIONS file for details.
-
-
-
-GLUT tarball
-------------
-
-Starting with 6.4, the GLUT library sources are distributed in a separate
-tarball.  This was done at the request of Linux distro vendors who prefer
-to use freeglut.
-
-
-
-
-Driver			Status
-----------------------	----------------------
-DRI drivers		varies with the driver
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Windows/Win32		implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)  requires updates	
-SVGA			requires updates
-DJGPP			requires updates
-GGI			requires updates
-BeOS			requires updates
-Allegro			requires updates
-D3D			requires updates
-
-The drivers which require updates mostly need to be updated to work
-with the new gl_renderbuffer / gl_framebuffer infrastructure introduced
-in Mesa 6.3.
-
-
-----------------------------------------------------------------------

docs/VERSIONS

@@ -1146,10 +1146,9 @@ Mesa Version History
 	- build GLUT with -fexceptions so C++ apps propogate exceptions
 
 
-5.1  December 17, 2003
+5.1  Month day, 2003  (NOT RELEASED YET)
     New:
 	- reorganized directory tree
-	- GL_ARB_vertex/fragment_program extensions (Michal Krol & Karl Rasche)
 	- GL_ATI_texture_env_combine3 extension (Ian Romanick)
 	- GL_SGI_texture_color_table extension (Eric Plante)
 	- GL_NV_fragment_program extension
@@ -1166,8 +1165,6 @@ Mesa Version History
 	- demo of per-pixel lighting with a fragment program (demos/fplight.c)
 	- new version (18) of glext.h header
 	- new spriteblast.c demo of GL_ARB_point_sprite
-	- faster glDrawPixels in X11 driver in some cases (see RELNOTES-5.1)
-	- faster glCopyPixels in X11 driver in some cases (see RELNOTES-5.1)
     Bug fixes:
 	- really enable OpenGL 1.4 features in DOS driver.
 	- fixed issues in glDrawPixels and glCopyPixels for very wide images
@@ -1183,332 +1180,3 @@ Mesa Version History
 	- documentation overhaul.  merged with website content.  more html.
 	- glxgears.c demo updated to use GLX swap rate extensions
 	- glTexImage1/2/3D now allows width/height/depth = 0
-	- disable SPARC asm code on Linux (bug 852204)
-
-
-6.0  January 16, 2004
-    New:
-	- full OpenGL 1.5 support
-	- updated GL/glext.h file to version 21
-    Changes:
-	- changed max framebuffer size to 4Kx4K (MAX_WIDTH/HEIGHT in config.h)
-    Bug fixes:
-	- fixed bug in UNCLAMPED_FLOAT_TO_UBYTE macro; solves a color
-	  clamping issue
-	- updated suno5-gcc configs
-	- glColor3 functions sometimes resulted in undefined alpha values
-	- fixed FP divide by zero error seen on VMS with xlockmore, others
-	- fixed vertex/fragment program debug problem (bug 873011)
-	- building on AIX with gcc works now
-	- glDeleteProgramsARB failed for ARB fragment programs (bug 876160)
-	- glDrawRangeElements tried to modify potentially read-only storage
-	- updated files for building on Windows
-
-
-6.0.1  April 2, 2004
-    New:
-	- upgraded glext.h to version 22
-	- new build targets (Dan Schikore)
-	- new linux-x86-opteron build target (Heath Feather)
-    Bug fixes:
-	- glBindProgramARB didn't update all necessary state
-	- fixed build problems on OpenBSD
-	- omit CVS directories from tarballs
-	- glGetTexImage(GL_COLOR_INDEX) was broken
-	- fixed an infinite loop in t&l module
-	- silenced some valgrind warnings about using unitialized memory
-	- fixed some compilation/link glitches on IRIX (Mike Stephens)
-	- glBindProgram wasn't getting compiled into display lists
-	- GLX_FBCONFIG_ID wasn't recognized in glXChooseFBConfig() (bug 888079)
-	- two-sided lighting and vertex program didn't work (bug 887330)
-	- stores to program parameter registers in vertex state programs
-	  didn't work.
-	- fixed glOrtho bug found with gcc 3.2.2 (RH9)
-	- glXCreateWindow() wasn't fully implemented (bug 890894)
-	- generic vertex attribute arrays didn't work in display lists
-	- vertex buffer objects' default usage and access fields were wrong
-	- glDrawArrays with start!=0 was broken
-	- fragment program PK2H, UP2H, UP4B and UP4UB instructions were broken
-	- linux-osmesa16-static config didn't work
-	- fixed a few color index rendering problems (bug 910687)
-	- glInterleavedArrays didn't respect GL_CLIENT_ACTIVE_TEXTURE
-	- OSMesa RGB and BGR modes were broken
-	- glProgramStringARB mistakenly required a null-terminated string
-	- fragment program XPD instruction was incorrect
-	- glGetMaterial() didn't work reliably
-	- ARB_fragment_program KIL instruction was incorrect
-
-
-6.1  August 18, 2004
-    New:
-	- Revamped Makefile system
-	- glXUseRotatedXFont() utility (see xdemos/xuserotfont.c)
-	- internal driver interface changes related to texture object
-	  allocation, vertex/fragment programs, BlendEquationSeparate, etc.
-	- option to walk triangle edges with double-precision floats
-	  (Justin Novosad of Discreet) (see config.h file)
-	- support for AUX buffers in software GLX driver
-	- updated glext.h to version 24 and glxext.h to version 6
-	- new MESA_GLX_FORCE_ALPHA and MESA_GLX_DEPTH_BITS env vars
-	- updated BeOS support (Philippe Houdoin)
-    Changes:
-	- fragment fog interpolation is perspective corrected now
-	- new glTexImage code, much cleaner, may be a bit faster
-    Bug fixes:
-	- glArrayElement in display lists didn't handle generic vertex attribs
-	- glFogCoord didn't always work properly
-	- ARB_fragment_program fog options didn't work
-	- frag prog TEX instruction no longer incorrectly divides s,t,r by q
-	- ARB frag prog TEX and TEXP instructions now use LOD=0
-	- glTexEnviv in display lists didn't work
-	- glRasterPos didn't do texgen or apply texture matrix
-	- GL_DOUBLE-valued vertex arrays were broken in some cases
-	- fixed texture rectangle edge/border sampling bugs
-	- sampling an incomplete texture in a fragment program would segfault
-	- glTexImage was missing a few error checks
-	- fixed some minor glGetTexParameter glitches
-	- GL_INTENSITY was mistakenly accepted as a <format> to glTexImage
-	- fragment program writes to RC/HC register were broken
-	- fixed a few glitches in GL_HP_occlusion_test extension
-	- glBeginQueryARB and glEndQueryARB didn't work inside display lists
-	- vertex program state references were broken
-	- fixed triangle color interpolation bug on AIX (Shane Blackett)
-	- fixed a number of minor memory leaks (bug #1002030)
-
-
-6.2  October 2, 2004
-    New:
-	- enabled GL_ARB_texture_rectangle (same as GL_NV_texture_rectangle)
-	- updated Doxygen support (Jose Fonseca)
-    Changes:
-	- some GGI driver updates (Christoph Egger, bug 1025977)
-    Bug fixes:
-	- Omit GL_ARB_texture_non_power_of_two from list of OpenGL 1.5 features
-	- fixed a few compilation issues on IRIX
-	- fixed a matrix classification bug (reported by Wes Bethel)
-	- we weren't reseting the vertex/fragment program error state
-	  before parsing (Dave Reveman)
-	- adjust texcoords for sampling texture rectangles (Dave Reveman)
-	- glGet*(GL_MAX_VERTEX_ATTRIBS_ARB) wasn't implemented
-	- repeated calls to glDeleteTexture(t) could lead to a crash
-	- fixed potential ref count bugs in VBOs and vertex/fragment programs
-	- spriteblast demo didn't handle window size changes correctly
-	- glTexSubImage didn't handle pixels=NULL correctly for PBOs
-	- fixed color index mode glDrawPixels bug (Karl Schultz)
-
-
-6.2.1  December 9, 2004
-    Bug fixes:
-	- don't apply regular fog or color sum when using a fragment program
-	- glProgramEnvParameter4fARB always generated an error on
-	  GL_FRAGMENT_PROGRAM_ARB (fdo bug 1645)
-	- glVertexAttrib3svNV and glVertexAttrib3svARB were broken
-	- fixed width/height mix-up in glSeparableFilter2D()
-	- fixed regression in glCopyPixels + convolution
-	- glReadPixels from a clipped front color buffer didn't always work
-	- glTexImage didn't accept GL_RED/GREEN/BLUE as the format
-	- Attempting queries/accesses of VBO 0 weren't detected as errors
-	- paletted textures failed if the palette had fewer than 256 entries
-    Changes:
-	- fixed a bunch of compiler warnings found with gcc 3.4
-	- bug reports should to go bugzilla.freedesktop.org
-
-
-6.3  July 20, 2005
-    New:
-	- GL_EXT_framebuffer_object extension
-	- GL_ARB_draw_buffers extension
-	- GL_ARB_pixel_buffer_object extension
-	- GL_OES_read_format extension (Ian Romanick)
-	- DirectFB driver (Claudio Ciccani)
-	- x86_64 vertex transformation code (Mikko T.)
-	- Updated GL/glext.h to version 29
-    Changes:
-	- added -stereo option for glxgears demo (Jacek Rosik)
-	- updated the PBuffer demo code in xdemos/ directory
-	- glDeleteTextures/Programs/Buffers() now makes the object ID
-	  available for immediate re-use
-	- assorted 64-bit clean-ups fixes (x86_64 and Win64)
-	- lots of internal changes for GL_EXT_framebuffer_object
-    Bug fixes:
-	- some functions didn't support PBO functionality
-	- glGetTexImage didn't convert color index images to RGBA as required
-	- fragment program texcoords were sometimes wrong for points and lines
-	- fixed problem with negative dot product in arbfplight, fplight demos
-	- fixed bug in perspective correction of antialiased, textured lines
-	- querying GL_POST_CONVOLUTION_ALPHA_BIAS_EXT returned wrong value
-	- fixed a couple per-pixel fog bugs (Soju Matsumoto)
-	- glGetBooleanv(GL_FRAGMENT_PROGRAM_BINDING_NV) was broken
-	- fixed float parsing bug in ARB frag/vert programs (bug 2520)
-	- XMesaGetDepthBuffer() returned incorrect value for bytesPerValue
-	- GL_COLOR_MATERIAL with glColor3 didn't properly set diffuse alpha
-	- glXChooseFBConfig() crashed if attribList pointer was NULL
-	- program state.light[n].spot.direction.w was wrong value (bug 3083)
-	- fragment program fog option required glEnable(GL_FOG) - wrong.
-	- glColorTable() could produce a Mesa implementation error (bug 3135)
-	- RasterPos could get corrupted by color index rendering path
-	- Removed bad XTranslateCoordinates call when rendering to Pixmaps
-	- glPopAttrib() didn't properly restore GL_TEXTURE_GEN enable state
-	- fixed a few Darwin compilation problems
-
-
-6.3.1
-    This was an intermediate release for X.org which wasn't otherwise released.
-
-
-6.3.2  August 19, 2005
-    New:
-	- The distribution now includes the DRI drivers and GLX code
-    Changes:
-	- Made the DRI "new" driver interface standard, remove old code
-    Bug fixes:
-	- GL_ARB_vertex/fragment_shader were mistakenly listed in the
-	  extensions string
-	- negative relative addressing in vertex programs was broken
-	- update/fix SPARC assembly code for vertex transformation
-	- fixed memory leak when freeing GLX drawables/renderbuffers
-	- fixed display list memory leak
-	- the GL_PIXEL_MAP_I_TO_I table is now floating point, not integer
-	- wglGetProcAddress() didn't handle wgl-functions
-	- fixed glxext.h cross-compile issue (Colin Harrison)
-	- assorted DRI driver fixes
-
-
-6.4  October 24, 2005
-    New:
-	- Added a fast XOR line drawing function in Xlib driver
-	- Added support for GL_ARB_texture_mirrored_repeat to savage
-	  driver (supported only on Savage4 hardware).
-    Changes:
-	- Mesa now packaged in three parts: Library, Demos and GLUT
-    Bug fixes:
-	- GLX_X_RENDERABLE token wasn't accepted by glXChooseFBConfig
-	- Some files were present multiple times in the 6.3.2 tarballs
-	- r200_vtxtmp_x86.S file was missing from 6.3.2 tarball (bug 4207)
-	- glxgears_fbconfig demo didn't work (bug 4237)
-	- fixed bug when bilinear sampling 2d textures with borders
-	- glXCreatePbuffer() could segfault instead of returning 0 (bug 4235)
-	- fixed undefined frexp and rand in X.org libGLcore.a (bug 4242)
-	- fixed a few problems with proxy color tables (bug 4270)
-	- fixed precision problem in Z clearing (bug 4395)
-	- glBitmap, glDraw/CopyPixels mistakenly generated selection hits
-	- fixed potential segfault caused by reading pixels outside
-	  of renderbuffer bounds
-	- glGetTexLevelParameter didn't accept GL_TEXTURE_DEPTH_SIZE_ARB
-	- fixed memory corruption bug involving software alpha buffers
-	- glReadPixels clipped by window bounds was sometimes broken
-	- glDraw/CopyPixels of stencil data ignored the stencil write mask
-	- glReadPixels from a texture bound to a framebuffer object didn't work
-	- glIsRender/FramebufferEXT weren't totally correct
-	- fixed a number of point size attenuation/fade bugs
-	- fixed glFogCoord bug 4729
-	- GLX encoding for transpose matrix functions was broken
-	- fixed broken fragment program KIL and SWZ instructions
-	- fragment programs that wrote result.depth.z didn't work
-
-
-6.4.1  November 30, 2005
-    Bug fixes:
-	- redefining a vertex program string didn't take effect in TNL module
-	- fixed occasional segfault upon vertex/fragment parsing error
-	- vertex program LIT instruction didn't handle 0^0=1 correctly
-	- fragment program fog option didn't work with glDrawPixels, glBitmap
-	- USE_MGL_NAMESPACE didn't work for x86-64
-	- OSMesa demos were missing from previous release tarballs
-	- fixed problem with float->ushort conversion in glClear (bug 4992)
-	- popping of GL_EYE_PLANE texgen state was broken (bug 4996)
-	- popping of GL_SPOT_DIRECTION light state was broken (bug 5005)
-	- fixed occasional triangle color interpolation problem on VMS
-	- work around invalid free() call (bug 5131)
-	- fixed BSD X server compilation problem by including stdint.h
-
-
-6.4.2  February 2, 2006
-    New:
-	- added OSMesaColorClamp() function/feature
-	- added wglGetExtensionStringARB() function
-    Bug fixes:
-	- fixed some problems when building on Windows
-	- GLw header files weren't installed by installmesa script (bug 5396)
-	- GL/glfbdev.h file was missing from tarballs
-	- fixed TNL initialization bug which could lead to crash (bug 5791)
-
-
-6.5  March 31, 2006
-    New:
-	- OpenGL Shading Language support through GL_ARB_shader_objects,
-	  GL_ARB_shading_language_100, GL_ARB_vertex_shader and
-	  GL_ARB_fragment_shader (done by Michal Krol)
-	- GL_EXT_packed_depth_stencil extension
-	- GL_EXT_timer_query extension
-	- GL_EXT_framebuffer_blit extension
-	- GL_ARB_half_float_pixel
-	- reflect demo improved to support multiple windows
-	- singlebuffer demo (shows no/little-flicker single-buffered rendering)
-	- r200: enable GL_ARB_texture_env_crossbar, separate the texture
-	  sampling unit bits from the texture env combine enable bits
-	- r200: add support for GL_ATI_fragment_shader
-	- added fast XOR-mode line drawing optimization
-	- radeon: add support for all 3 tmus, GL_ARB_texture_cube_map
-	  and GL_EXT_fog_coord
-	- MESA_GLX_ALPHA_BITS env var for xlib driver
-	- many DRI driver updates (including screen rotation support
-	  for the Intel DRI driver)
-    Changes:
-	- removed GL_HP_occlusion_test (use GL_ARB_occlusion_query instead)
-	- removed GL_SGIX/SGIS_pixel_texture extensions
-    Bug fixes:
-	- fixed glxcontextmodes.c datatype problem (bug 5835)
-	- fixed aix-gcc build/install bugs (bug 5874)
-	- fixed some bugs in texture env program generation
-	- glXCopyContext() didn't handle texture object bindings properly
-	- glXCopyContext() didn't copy all lighting state
-	- fixed FreeBSD config (Pedro Giffuni)
-	- fixed some minor framebuffer object bugs
-	- replaced dprintf() with _glu_printf() in GLU (bug 6244)
-	- fixed a number of thread safety bugs/regressions
-	- fixed a number of GLU tesselator bugs (John Shell, bug 6339)
-	- paletted texturing was broken w/ floating point palettes (K. Schultz)
-	- lots of assorted framebuffer object bug fixes
-
-6.5.1  August 31, 2006
-    New:
-	- Intel i965 DRI driver
-	- GL_APPLE_vertex_array_object extension (Ian Romanick)
-	- GL_EXT_texture_sRGB extension
-	- GL_EXT_gpu_program_parameters (Ian Romanick)
-	- "engine" demo
-	- updated fbdev driver and GLUT for fbdev (Sean D'Epagnier)
-	- many updates to the DRI drivers
-    Changes:
-	- The glVertexAttribARB functions no longer alias the conventional
-	  vertex attributes.
-	- glxinfo program prints more info with -l option
-	- GL_FRAGMENT_PROGRAM_NV and GL_FRAGMENT_PROGRAM_ARB are now
-	  compatible, in terms of glBindProgramARB()
-    Bug fixes:
-	- fixed broken texture border handling for depth textures (bug 6498)
-	- removed the test for duplicated framebuffer attachments, per
-	  version 117 of the GL_EXT_framebuffer_object specification
-	- fixed a few render-to-texture bugs, including render to depth texture
-	- clipping of lines against user-defined clip planes was broken (6512)
-	- assembly language dispatch for SPARC was broken (bug 6484)
-	- assorted compilation fixes on various Unix platforms (Dan Schikore)
-	- glPopAttrib could restore an invalid value for GL_DRAW_BUFFER
-	- assorted minor fixes for 16 and 32 bit/channel modes
-	- fixed assorted bugs in texture compression paths
-	- fixed indirect rendering vertex array crashes (bug 6863)
-	- glDrawPixels GL_INDEX_OFFSET didn't always work
-	- fixed convolution memory leak (bug 7077)
-	- rectangular depth textures didn't work
-	- invalid mode to glBegin didn't generate an error (bug 7142)
-	- 'normalized' parameter to glVertexAttribPointerARB didn't work
-	- disable bogus GLX_SGI_video_sync extension in xlib driver
-	- fixed R128 driver locking bug (Martijn van Oosterhout)
-	- using evaluators with vertex programs caused crashes (bug 7564)
-	- fragment.position wasn't set correctly for point/line primitives
-	- fixed parser bug for scalar sources for GL_NV_fragment_program
-	- max fragment program length was incorrectly 128, now 1024
-	- writes to result.depth in fragment programs weren't clamped to [0,1]
-	- fixed potential dangling pointer bug in glBindProgram()
-	- fixed some memory leaks (and potential crashes) in Xlib driver

docs/WL_bind_wayland_display.spec

@@ -1,175 +0,0 @@
-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)

docs/autoconf.html

@@ -1,239 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Compilation and Installation using Autoconf</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Compilation and Installation using Autoconf</h1>
-
-<ol>
-<li><p><a href="#basic">Basic Usage</a></li>
-<li><p><a href="#driver">Driver Options</a>
-  <ul>
-  <li><a href="#xlib">Xlib Driver Options</a></li>
-  <li><a href="#dri">DRI Driver Options</a></li>
-  <li><a href="#osmesa">OSMesa Driver Options</a></li>
-  </ul>
-<li><p><a href="#demos">Demo Program Options</a>
-</ol>
-
-
-<h2 id="basic">1. Basic Usage</h2>
-
-<p>
-The autoconf generated configure script can be used to guess your
-platform and change various options for building Mesa. To use the
-configure script, type:
-</p>
-
-<pre>
-    ./configure
-</pre>
-
-<p>
-To see a short description of all the options, type <code>./configure
---help</code>. If you are using a development snapshot and the configure
-script does not exist, type <code>./autogen.sh</code> to generate it
-first. If you know the options you want to pass to
-<code>configure</code>, you can pass them to <code>autogen.sh</code>. It
-will run <code>configure</code> with these options after it is
-generated. Once you have run <code>configure</code> and set the options
-to your preference, type:
-</p>
-
-<pre>
-    make
-</pre>
-
-<p>
-This will produce libGL.so and several other libraries depending on the
-options you have chosen. Later, if you want to rebuild for a different
-configuration run <code>make realclean</code> before rebuilding.
-</p>
-
-<p>
-Some of the generic autoconf options are used with Mesa:
-
-<ul>
-<li><code>--prefix=PREFIX</code> - This is the root directory where
-files will be installed by <code>make install</code>. The default is
-<code>/usr/local</code>.
-</li>
-<li><code>--exec-prefix=EPREFIX</code> - This is the root directory
-where architecture-dependent files will be installed. In Mesa, this is
-only used to derive the directory for the libraries. The default is
-<code>${prefix}</code>.
-</li>
-<li><code>--libdir=LIBDIR</code> - This option specifies the directory
-where the GL libraries will be installed. The default is
-<code>${exec_prefix}/lib</code>. It also serves as the name of the
-library staging area in the source tree. For instance, if the option
-<code>--libdir=/usr/local/lib64</code> is used, the libraries will be
-created in a <code>lib64</code> directory at the top of the Mesa source
-tree.
-</li>
-<li><code>--enable-static, --disable-shared</code> - By default, Mesa
-will build shared libraries. Either of these options will force static
-libraries to be built. It is not currently possible to build static and
-shared libraries in a single pass.
-</li>
-<li><code>CC, CFLAGS, CXX, CXXFLAGS</code> - These environment variables
-control the C and C++ compilers used during the build. By default,
-<code>gcc</code> and <code>g++</code> are used with the options
-<code>"-g -O2"</code>.
-</li>
-<li><code>LDFLAGS</code> - An environment variable specifying flags to
-pass when linking programs. These are normally empty, but can be used
-to direct the linker to use libraries in nonstandard directories. For
-example, <code>LDFLAGS="-L/usr/X11R6/lib"</code>.
-</li>
-<li><code>PKG_CONFIG_PATH</code> - When available, the
-<code>pkg-config</code> utility is used to search for external libraries
-on the system. This environment variable is used to control the search
-path for <code>pkg-config</code>. For instance, setting
-<code>PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig</code> will search for
-package metadata in <code>/usr/X11R6</code> before the standard
-directories.
-</li>
-</ul>
-
-<p>
-There are also a few general options for altering the Mesa build:
-<ul>
-<li><code>--with-x</code> - When the X11 development libraries are
-needed, the <code>pkg-config</code> utility <a href="#pkg-config">will
-be used</a> for locating them. If they cannot be found through
-<code>pkg-config</code> a fallback routing using <code>imake</code> will
-be used. In this case, the <code>--with-x</code>,
-<code>--x-includes</code> and <code>--x-libraries</code> options can
-control the use of X for Mesa.
-</li>
-<li><code>--enable-gl-osmesa</code> - The <a href="osmesa.html">OSMesa
-library</a> can be built on top of libGL for drivers that provide it.
-This option controls whether to build libOSMesa. By default, this is
-enabled for the Xlib driver and disabled otherwise. Note that this
-option is different than using OSMesa as the driver.
-</li>
-<li><code>--enable-debug</code> - This option will enable compiler
-options and macros to aid in debugging the Mesa libraries.
-</li>
-<li><code>--disable-asm</code> - There are assembly routines
-available for a few architectures. These will be used by default if
-one of these architectures is detected. This option ensures that
-assembly will not be used.
-</li>
-<li><code>--enable-32-bit, --enable-64-bit</code> - By default, the
-build will compile code as directed by the environment variables
-<code>CC</code>, <code>CFLAGS</code>, etc. If the compiler is
-<code>gcc</code>, these options offer a helper to add the compiler flags
-to force 32- or 64-bit code generation as used on the x86 and x86_64
-architectures.
-</li>
-</ul>
-
-
-<h2 id="driver">2. Driver Options</h2>
-
-<p>
-There are several different driver modes that Mesa can use. These are
-described in more detail in the <a href="install.html">basic
-installation instructions</a>. The Mesa driver is controlled through the
-configure option --with-driver. There are currently three supported
-options in the configure script.
-</p>
-
-<h3 id="xlib">Xlib</h3><p>This is the default mode for building Mesa.
-It uses Xlib as a software renderer to do all rendering. It corresponds
-to the option <code>--with-driver=xlib</code>. The libX11 and libXext
-libraries, as well as the X11 development headers, will be need to
-support the Xlib driver.
-
-<h3 id="dri">DRI</h3><p>This mode uses the DRI hardware drivers for
-accelerated OpenGL rendering. Enable the DRI drivers with the option
-<code>--with-driver=dri</code>. See the <a href="install.html">basic
-installation instructions</a> for details on prerequisites for the DRI
-drivers.
-
-<!-- DRI specific options -->
-<dl>
-<dt><code>--with-dri-driverdir=DIR</code>
-<dd><p> This option specifies the
-location the DRI drivers will be installed to and the location libGL
-will search for DRI drivers. The default is <code>${libdir}/dri</code>.
-<dt><code>--with-dri-drivers=DRIVER,DRIVER,...</code>
-<dd><p> This option
-allows a specific set of DRI drivers to be built. For example,
-<code>--with-dri-drivers="swrast,i965,radeon,nouveau"</code>. By
-default, the drivers will be chosen depending on the target platform.
-See the directory <code>src/mesa/drivers/dri</code> in the source tree
-for available drivers. Beware that the swrast DRI driver is used by both
-libGL and the X.Org xserver GLX module to do software rendering, so you
-may run into problems if it is not available.
-<!-- This explanation might be totally bogus. Kristian? -->
-<dt><code>--disable-driglx-direct</code>
-<dd><p> Disable direct rendering in
-GLX. Normally, direct hardware rendering through the DRI drivers and
-indirect software rendering are enabled in GLX. This option disables
-direct rendering entirely. It can be useful on architectures where
-kernel DRM modules are not available.
-<dt><code>--enable-glx-tls</code> <dd><p>
-Enable Thread Local Storage (TLS) in
-GLX.
-<dt><code>--with-expat=DIR</code> <dd> The DRI-enabled libGL uses expat to
-parse the DRI configuration files in <code>/etc/drirc</code> and
-<code>~/.drirc</code>. This option allows a specific expat installation
-to be used. For example, <code>--with-expat=/usr/local</code> will
-search for expat headers and libraries in <code>/usr/local/include</code>
-and <code>/usr/local/lib</code>, respectively.
-</dl>
-
-<h3 id="osmesa">OSMesa </h3><p> No libGL is built in this
-mode. Instead, the driver code is built into the Off-Screen Mesa
-(OSMesa) library. See the <a href="osmesa.html">Off-Screen Rendering</a>
-page for more details.
-
-<!-- OSMesa specific options -->
-<dl>
-<dt><code>--with-osmesa-bits=BITS</code>
-<dd><p> This option allows the size
-of the color channel in bits to be specified. By default, an 8-bit
-channel will be used, and the driver will be named libOSMesa. Other
-options are 16- and 32-bit color channels, which will add the bit size
-to the library name. For example, <code>--with-osmesa-bits=16</code>
-will create the libOSMesa16 library with a 16-bit color channel.
-</dl>
-
-
-<h2 id="library">3. Library Options</h2>
-
-<p>
-The configure script provides more fine grained control over the GL
-libraries that will be built. More details on the specific GL libraries
-can be found in the <a href="install.html">basic installation
-instructions</a>.
-
-
-<h2 id="demos">4. Demo Program Options</h2>
-
-<p>
-There are many demonstration programs in the MesaDemos tarball. If the
-programs are available when <code>./configure</code> is run, a subset of
-the programs will be built depending on the driver and library options
-chosen. See the directory <code>progs</code> for the full set of demos.
-
-<dl>
-<dt><code>--with-demos=DEMOS,DEMOS,...</code>
-<dd><p> This option allows a
-specific set of demo programs to be built. For example,
-<code>--with-demos="xdemos,slang"</code>. Beware that if this option is
-used, it will not be ensured that the necessary GL libraries will be
-available.
-<dt><code>--without-demos</code> <dd><p> This completely disables building the
-demo programs. It is equivalent to <code>--with-demos=no</code>.
-</dl>
-
-</body>
-</html>