| @@ -0,0 +1,301 @@ | |||
| Mesa 3.0 Unix/X11 Information | |||
| Installation | |||
| ============ | |||
| To compile the library, 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. | |||
| The top-level makefile will execute the makefiles in a number of sub- | |||
| directories. When finished, the Mesa libraries will be in the Mesa-2.6/lib/ | |||
| directory. A few GLUT demos in the demos/ directory should be ready to run. | |||
| If you also downloaded and unpacked the demos there should be executables | |||
| in the "xdemos/", "samples/", and "book/" directories for you to try out. | |||
| If you only want to compile the contents of one subdirectory you can 'cd' | |||
| to that directory and type 'make <config>' there. | |||
| 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. | |||
| If you have compilation problems you should try to fix them and return the | |||
| patches to the author. | |||
| 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) | |||
| Create a few symbolic links so that compiling OpenGL applications is easy: | |||
| cd /usr/local/lib | |||
| IF USING STATIC (lib*.a) FILES THEN | |||
| ln -s libMesaGL.a libGL.a | |||
| ln -s libMesaGLU.a libGLU.a | |||
| ELSE | |||
| ln -s libMesaGL.so libGL.so | |||
| ln -s libMesaGLU.so libGLU.so | |||
| ENDIF | |||
| 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 | |||
| % cd lib | |||
| % ln -s libMesaGL.so libGL.so | |||
| % 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://www.ssec.wisc.edu/~brianp/Togl.html 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 (X11 only): | |||
| 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 (X11 only): | |||
| 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 (X11 only): | |||
| 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 | |||
| Extensions: | |||
| The following OpenGL GLX extensions are currently implemented: | |||
| GLX_EXT_visual_info - GLX visual and transparent pixel extension | |||
| For detailed information about the extensions see www.opengl.org | |||
| There are four Mesa-specific GL/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.0 1998/02/14 17:45:13 brianp Exp $ | |||