-.B SGI Power Saver
-If you're running Irix 6.3, you might find that your monitor is powering down
-after an hour or two even if you've told it not to. This is fixed by SGI
-patches 2447 and 2537.
-.TP 8
-.B OpenGL Programs and Visuals
-Some of the graphics demos included with xscreensaver make use of the
-OpenGL (or MesaGL) 3D library, if it is available. It is possible (even
-likely) that \fIxscreensaver\fP's notion of the ``\fIbest\fP'' visual is
-not quite right for these GL programs.
-
-The odd thing about GL programs is that, unlike normal X11 programs, they
-tend to work best on a visual \fIhalf\fP as deep as the depth of the screen,
-since that way, they can do double-buffering. Try it and see, but you will
-probably find that, for these particular programs, you should specify the
-deepest visual that is half as deep as the screen. (See the discussion
-of the \fBprograms\fP resource in the \fIConfiguration\fP section, above.)
-
-For example, on a screen that supports both 24-bit TrueColor and 12-bit
-PseudoColor visuals, the 12-bit visual will probably work best (this is true
-of base-model SGI Indys: the 0x29 visual is the one you want.)
-
-Oddly, on SGI O2s (machines that have serious hardware support for GL), the
-12-bit PseudoColor visual looks awful (you get a black and white, flickery
-image.) On these machines, the visual you want turns out to be 0x31.
-However, 0x31 is but \fIone\fP of the \fIeight\fP 15-bit TrueColor visuals
-(yes, 8, and yes, 15) that the O2 X server provides. This is the only visual
-that works properly: as far as
-.BR xdpyinfo (1)
-is concerned, all of the 15-bit TrueColor visuals are identical, but some
-flicker like mad, and some have deeply weird artifacts (such as hidden
-surfaces that show through, as if depth worked backwards!)
-
-I suppose these other visuals must be tied to some arcane hardware feature...
-If anyone would care to explain it to me, that would be great.
-
-Your mileage, therefore, may vary dramatically.
-.TP 8
-.B MesaGL and Voodoo Cards
-If you have a 3Dfx/Voodoo card, the default settings for xscreensaver will
-run the GL-based graphics demos in such a way that they will not take
-advantage of the 3D acceleration hardware. The solution is to change
-the \fBprograms\fP entries for the GL hacks from this:
-.EX
- gears -root \\n\\
-.EE
-to this:
-.EX
- MESA_GLX_FX=fullscreen gears \\n\\
-.EE
-That is, make sure that \fB$MESA_GLX_FX\fP is set to \fIfullscreen\fP, and
-don't tell the program to draw on the root window. This may seem strange,
-but the setup used by Mesa and these kinds of cards \fIis\fP strange!
-
-For those who don't know, these cards work by sitting between your normal
-video card and the monitor, and seizing control of the monitor when it's
-time to do 3D. But this means that accelerated 3D only happens in full-screen
-mode (you can't do it in a window, and you can't see the output of 3D and 2D
-programs simultaniously), and that 3D will probably drive your monitor at a
-lower resolution, as well. It's bizarre.
-
-If you find that GL programs only work properly when run as root, and not
-as normal users, then the problem is that your \fI/dev/3dfx\fP file is not
-configured properly. Check the Linux 3Dfx FAQ.
-.TP 8