-.SH COMMAND-LINE OPTIONS
-.I xscreensaver
-also accepts the following command line options. Except for
-the \fI\-display\fP option, these command-line options are all
-simply shorthand for the X resources described in
-the \fIConfiguration\fP section, above.
-.TP 8
-.B \-display \fIhost:display.screen\fP
-The X display to use. For displays with multiple screens, XScreenSaver
-will manage all screens on the display simultaniously; the \fIscreen\fP
-argument (the ``default'' screen) says which screen should be used for
-dialog boxes (the password window, \fIDemo Mode\fP, etc.)
-.TP 8
-.B \-timeout \fIminutes\fP
-Same as the \fItimeout\fP resource.
-.TP 8
-.B \-cycle \fIminutes\fP
-Same as the \fIcycle\fP resource.
-.TP 8
-.B \-lock\-mode
-Same as setting the \fIlock\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-lock\-mode
-Same as setting the \fIlock\fP resource to \fIfalse\fP.
-.TP 8
-.B \-lock\-timeout \fIminutes\fP
-Same as the \fIlockTimeout\fP resource.
-.TP 8
-.B \-visual \fIvisual\fP
-Same as the \fIvisualID\fP resource.
-.TP 8
-.B \-install
-Same as setting the \fIinstallColormap\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-install
-Same as setting the \fIinstallColormap\fP resource to \fIfalse\fP.
-.TP 8
-.B \-verbose
-Same as setting the \fIverbose\fP resource to \fItrue\fP.
-.TP 8
-.B \-silent
-Same as setting the \fIverbose\fP resource to \fIfalse\fP.
-.TP 8
-.B \-timestamp
-Same as setting the \fItimestamp\fP resource to \fItrue\fP.
-.TP 8
-.B \-capture\-stderr
-Same as setting the \fIcaptureStderr\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-capture\-stderr
-Same as setting the \fIcaptureStderr\fP resource to \fIfalse\fP.
-.TP 8
-.B \-splash
-Same as setting the \fIsplash\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-splash
-Same as setting the \fIsplash\fP resource to \fIfalse\fP.
-.TP 8
-.B \-nice \fIinteger\fP
-Same as the \fInice\fP resource.
-.TP 8
-.B \-sgi\-extension
-Same as setting the \fIsgiSaverExtension\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-sgi\-extension
-Same as setting the \fIsgiSaverExtension\fP resource to \fIfalse\fP.
-.TP 8
-.B \-mit\-extension
-Same as setting the \fImitSaverExtension\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-mit\-extension
-Same as setting the \fImitSaverExtension\fP resource to \fIfalse\fP.
-.TP 8
-.B \-xidle\-extension
-Same as setting the \fIxidleExtension\fP resource to \fItrue\fP.
-.TP 8
-.B \-no\-xidle\-extension
-Same as setting the \fIxidleExtension\fP resource to \fIfalse\fP.
-.TP 8
-.B \-xrm \fIresource-specification\fP
-As with all other Xt programs, you can specify X resources on the command-line
-using the \fI\-xrm\fP argument. Most of the interesting resources have
-command-line equivalents, however.
-.SH HOW IT WORKS
-When it is time to activate the screensaver, a full-screen black window is
-created on each screen of the display. The window or windows is given the
-appropriate properties so that, to any subsequently-created programs, it
-will appear to be a ``virtual root'' window. Because of this, any program
-which draws on the root window (and which understands virtual roots) can be
-used as a screensaver.
-
-When the user becomes active again, the screensaver windows are unmapped and
-the running subprocesses are killed by sending them \fBSIGTERM\fP. This is
-also how the subprocesses are killed when the screensaver decides that it's
-time to run a different demo: the old one is killed and a new one is launched.
-
-Before launching a subprocess, \fIxscreensaver\fP stores an appropriate value
-for \fB$DISPLAY\fP in the environment that the child will recieve. (This is
-so that if you start \fIxscreensaver\fP with a \fI-display\fP argument, the
-programs which \fIxscreensaver\fP launches will draw on the same display;
-and so that the child will end up drawing on the appropriate screen of a
-multi-headed display.)
-
-When the screensaver turns off, or is killed, care is taken to restore
-the ``real'' virtual root window if there is one. Because of this, it is
-important that you not kill the screensaver process with \fIkill -9\fP if
-you are running a virtual-root window manager. If you kill it with \-9,
-you may need to restart your window manager to repair the damage. This
-isn't an issue if you aren't running a virtual-root window manager.
-
-For all the gory details, see the commentary at the top of xscreensaver.c.
-
-You can control a running screensaver process by using the
-.BR xscreensaver\-command (1)
-program (which see.)
-.SH POWER MANAGEMENT
-Modern X servers contain support to power down the monitor after an idle
-period. If the monitor has powered down, then \fIxscreensaver\fP will
-notice this, and will not waste CPU by drawing graphics demos on a black
-screen. An attempt will also be made to explicitly power the monitor
-back up as soon as user activity is detected.
-
-If your X server supports power management, then
-.BR xset (1)
-will accept a \fBdpms\fP option. So, if you wanted \fIxscreensaver\fP
-to activate after 5 minutes, but you wanted your monitor to power down
-after one hour (3600 seconds) you would do this:
-.EX
-xset dpms 3600
-.EE
-See the man page for the
-.BR xset (1)
-program for details. (Note that power management requires both software
-support in the X server, and hardware support in the monitor itself.)
-.SH USING XDM(1)
-You can run \fIxscreensaver\fP from your xdm session, so that the
-screensaver will run even when nobody is logged in on the console.
-Simply add \fB"xscreensaver &"\fP to your \fI/usr/lib/X11/xdm/Xsetup\fP
-file. Because \fIxdm\fP grabs the keyboard, keypresses will not make
-the screensaver deactivate, but any mouse activity will.
-
-Make sure you have \fB$PATH\fP set up correctly in the Xsetup script, or
-\fIxdm\fP won't be able to find \fIxscreensaver\fP, and/or \fIxscreensaver\fP
-won't be able to find its graphics hacks.
-
-(If your system does not seem to be executing the \fIXsetup\fP file, you
-may need to configure it to do so: the traditional way to do this is
-to make that file the value of the \fIDisplayManager*setup\fP resource
-in the \fI/usr/lib/X11/xdm/xdm-config\fP file. See the man page for
-.BR xdm (1)
-for more details.)
-
-Users may want to add \fB"xscreensaver-command -restart"\fP to their
-startup scripts, so that the screensaver will be reinitialized with
-their private resource settings when they log in. Users who don't do
-this will get the system-wide defaults instead.
-
-It is safe to run this program as root (as \fIxdm\fP is likely to do.) If
-run as root, \fIxscreensaver\fP changes its effective user and group ids to
-something safe (like \fI"nobody"\fP) before connecting to the X server
-or launching user-specified programs.
-
-Locking doesn't work if the screensaver is launched by \fIxdm\fP. To get
-around this, you can run the screensaver from \fIxdm\fP without locking,
-and kill and restart it from your personal X startup script to enable
-locking; for example, by using this pair of commands:
-
-.EX
-xscreensaver-command -exit
-xscreensaver
-.EE
-If you get "connection refused" errors when running \fIxscreensaver\fP
-from \fIxdm\fP, then this probably means that you have
-.BR xauth (1)
-or some other security mechanism turned on. One way around this is to
-add \fB"xhost\ +localhost"\fP to \fIXsetup\fP, just before \fIxscreensaver\fP
-is launched.
-
-Note that this will give access to the X server to anyone capable of logging
-in to the local machine, so in some environments, this might not be
-appropriate. If turning off file-system-based access control is not
-acceptable, then running \fIxscreensaver\fP from \fIxdm\fP might not be
-possible, and users will have to launch it themselves instead of having it
-be launched by \fIxdm\fP before anyone logs in.
-
-For more information on the X server's access control mechanisms, see the
-man pages for
-.BR X (1),
-.BR Xsecurity (1),
-.BR xauth (1),
-and
-.BR xhost (1).
-.SH USING CDE (COMMON DESKTOP ENVIRONMENT)
-The easiest way to use \fIxscreensaver\fP on a system with CDE is to simply
-switch off the built-in CDE screensaver, and use \fIxscreensaver\fP instead;
-and second, to tell the front panel to run
-.BR xscreensaver\-command (1)
-with the \fI\-lock\fP option when the \fILock\fP icon is clicked.
-
-To accomplish this involves five steps:
-.RS 4
-.TP 3
-\fB1: Switch off CDE's locker\fP
-Do this by turning off ``\fIScreen Saver and Screen Lock\fP'' in the
-Screen section of the Style Manager.
-.TP 3
-\fB2: Edit sessionetc\fP
-Edit the file \fI~/.dt/sessions/sessionetc\fP and add to it the line
-
-.EX
-xscreensaver &
-.EE
-This will cause \fIxscreensaver\fP to be launched when you log in.
-(As always, make sure that xscreensaver and the graphics demos are on
-your \fB$PATH\fP; the path needs to be set in \fI.cshrc\fP
-and/or \fI.dtprofile\fP, not \fI.login\fP.)
-.TP 3
-\fB3: Create XScreenSaver.dt\fP
-Create a file called \fI~/.dt/types/XScreenSaver.dt\fP with the following
-contents:
-
-.EX
-ACTION XScreenSaver
-{
- LABEL XScreenSaver
- TYPE COMMAND
- EXEC_STRING xscreensaver-command -lock
- ICON Dtkey
- WINDOW_TYPE NO_STDIO
-}
-.EE
-This defines a ``lock'' command for the CDE front panel, that knows how
-to talk to \fIxscreensaver\fP.
-.TP 3
-\fB4: Create Lock.fp\fP
-Create a file called \fI~/.dt/types/Lock.fp\fP with the following
-contents:
-
-.EX
-CONTROL Lock
-{
- TYPE icon
- CONTAINER_NAME Switch
- CONTAINER_TYPE SWITCH
- POSITION_HINTS 1
- ICON Fplock
- LABEL Lock
- PUSH_ACTION XScreenSaver
- HELP_TOPIC FPOnItemLock
- HELP_VOLUME FPanel
-}
-.EE
-This associates the CDE front panel ``Lock'' icon with the lock command
-we just defined in step 3.
-.TP 3
-\fB5: Restart\fP
-Select ``\fIRestart Workspace Manager\fP'' from the popup menu to make
-your changes take effect. If things seem not to be working, check the
-file \fI~/.dt/errorlog\fP for error messages.
-.RE
-.SH USING HP VUE (VISUAL USER ENVIRONMENT)
-Since CDE is a descendant of VUE, the instructions for using xscreensaver
-under VUE are similar to the above:
-
-.RS 4
-.TP 3
-\fB1: Switch off VUE's locker\fP
-Open the ``\fIStyle Manager\fP'' and select ``\fIScreen\fP.''
-Turn off ``\fIScreen Saver and Screen Lock\fP'' option.
-.TP 3
-\fB2: Make sure you have a Session\fP
-Next, go to the Style Manager's, ``\fIStartup\fP'' page.
-Click on ``\fISet Home Session\fP'' to create a session, then
-on ``\fIReturn to Home Session\fP'' to select this session each
-time you log in.
-.TP 3
-\fB3: Edit vue.session\fP
-Edit the file \fI~/.vue/sessions/home/vue.session\fP and add to it
-the line
-.EX
-vuesmcmd -screen 0 -cmd "xscreensaver"
-.EE
-This will cause \fIxscreensaver\fP to be launched when you log in.
-(As always, make sure that xscreensaver and the graphics demos are on
-your \fB$PATH\fP; the path needs to be set in \fI.cshrc\fP
-and/or \fI.profile\fP, not \fI.login\fP.)
-.TP 3
-\fB3: Edit vuewmrc\fP
-Edit the file \fI~/.vue/vuewmrc\fP and add (or change) the Lock control:
-.EX
-CONTROL Lock
-{
- TYPE button
- IMAGE lock
- PUSH_ACTION f.exec "xscreensaver-command -lock"
- HELP_TOPIC FPLock
-}
-.EE
-This associates the VUE front panel ``Lock'' icon with the xscreensaver
-lock command.
-.RE
-.PP
-.SH ADDING TO MENUS
-The
-.BR xscreensaver-command (1)
-program is a perfect candidate for something to add to your window manager's
-popup menus. If you use
-.BR mwm (1),
-.BR 4Dwm (1),
-.BR twm (1),
-or (probably) any of \fItwm\fP's many descendants, you can do it like this:
-.RS 0
-.TP 3
-\fB1. Create ~/.mwmrc (or ~/.twmrc or ...)\fP
-If you don't have a \fI~/.mwmrc\fP file (or, on SGIs, a \fI~/.4Dwmrc\fP file;
-or, with twm, a \fI~/.twmrc\fP file) then create one by making a copy of
-the \fI/usr/lib/X11/system.mwmrc\fP
-file (or \fI/usr/lib/X11/twm/system.twmrc\fP, and so on.)
-.TP 3
-\fB2. Add a menu definition.\fP
-Something like this:
-.EX
-menu XScreenSaver
-{
- "Blank Screen Now" !"sleep 3; xscreensaver-command -activate"
- "Lock Screen Now" !"sleep 3; xscreensaver-command -lock"
- "Screen Saver Demo" !"xscreensaver-command -demo"
- "Screen Saver Preferences" !"xscreensaver-command -prefs"
- "Reinitialize Screen Saver" !"xscreensaver-command -restart"
- "Kill Screen Saver" !"xscreensaver-command -exit"
- "Launch Screen Saver" !"xscreensaver &"
-}
-.EE
-.TP 3
-\fB3. Add the menu\fP
-For
-.BR mwm (1)
-and
-.BR 4Dwm (1),
-find the section of the file that says \fIMenu DefaultRootMenu\fP.
-For
-.BR twm (1),
-it will probably be \fImenu "defops"\fP. If you add a line somewhere
-in that menu definition that reads
-.EX
- "XScreenSaver" f.menu XScreenSaver
-.EE
-then this will add an XScreenSaver sub-menu to your default root-window
-popup menu. Alternately, you could just put the \fIxscreensaver-command\fP
-menu items directly into the root menu.
-.RE
-
-Other window managers might (and probably do) do things differently.
-.SH BUGS
-(This is not a bug, but) note that as of release 1.32, the \fBcolorPrograms\fP
-and \fBmonoPrograms\fP resources are no longer used: they have been
-supplanted by the extended syntax of the \fBprograms\fP resource (which is
-described in the \fIConfiguration\fP section, above.)
-.TP 8
-.B Extensions
-If you are not making use of one of the server extensions (\fBXIDLE\fP,
-\fBSGI SCREEN_SAVER\fP, or \fBMIT-SCREEN-SAVER\fP), then it is possible, in
-rare situations, for \fIxscreensaver\fP to interfere with event propagation
-and make another X program malfunction. For this to occur, that other
-application would need to \fInot\fP select \fBKeyPress\fP events on its
-non-leaf windows within the first 30 seconds of their existence, but then
-select for them later. In this case, that client \fImight\fP fail to receive
-those events. This isn't very likely, since programs generally select a
-constant set of events immediately after creating their windows and then
-don't change them, but this is the reason that it's a good idea to install
-and use one of the server extensions instead, to work around this shortcoming
-in the X protocol.
-.TP 8
-.B Machine Load
-Although this program ``nices'' the subprocesses that it starts,
-graphics-intensive subprograms can still overload the machine by causing
-the X server process itself (which is not ``niced'') to suck a lot of
-cycles. Care should be taken to slow down programs intended for use as
-screensavers by inserting strategic calls to
-.BR sleep (3)
-or
-.BR usleep (3)
-(or making liberal use of any \fI\-delay\fP options which the programs
-may provide.)
-
-Also, an active screensaver will cause your X server to be pretty much
-permanently swapped in; but the same is true of any program that draws
-periodically, like
-.BR xclock (1)
-or
-.BR xload (1).
-.TP 8
-.B Latency and Responsiveness
-If the subprocess is drawing too quickly and the connection to the X
-server is a slow one (such as an X terminal running over a phone line) then
-the screensaver might not turn off right away when the user becomes active
-again (the
-.BR ico (1)
-demo has this problem if being run in full-speed mode). This can be
-alleviated by inserting strategic calls to
-.BR XSync (3)
-in code intended for use as a screensaver. This prevents too much graphics
-activity from being buffered up.
-.TP 8
-.B Locking and XDM
-If xscreensaver has been launched from
-.BR xdm (1),
-you will need to cause the xscreensaver daemon to exit and restart in
-order to lock the screen.
-
-The reason for this is, if xscreensaver has been launched by
-.BR xdm (1),
-that means it was launched \fIbefore\fP you logged in: so it has no way of
-knowing who the logged-in user is, and therefore, whose password it should
-prompt for.
-
-So if you want to use it as a locker, you must start it with your user id.
-If it has already been started by \fIxdm\fP, you can kill it by sending
-it the \fBexit\fP command, and then re-launching it as you, by putting
-something like the following in your personal X startup script:
-.EX
-xscreensaver-command -exit
-xscreensaver &
-.EE
-See the ``\fIUsing XDM(1)\fP'' section, above, for more details.
-.TP 8
-.B Locking and root logins
-An implication of the above is that if you log in as \fIroot\fP on the
-console, xscreensaver will refuse to lock the screen (because it can't tell
-the difference between \fIroot\fP being logged in on the console, and a
-normal user being logged in on the console but xscreensaver having been run
-by
-.BR xdm (1)).
-
-The solution to this is simple: you shouldn't be logging in on the console
-as \fIroot\fP in the first place! (What, are you crazy or something?) You
-should log in as you, and
-.BR su (1)
-to \fIroot\fP as necessary. People who spend their day logged in
-as \fIroot\fP are just begging for disaster.
-.TP 8
-.B XAUTH and XDM
-For xscreensaver to work when launched by
-.BR xdm (1),
-programs running on the local machine as user \fI"nobody"\fP must be
-able to connect to the X server. This means that \fB"xhost +localhost"\fP
-is required if xscreensaver is to be launched by
-.BR xdm (1).
-This is \fInot\fP required if \fIxscreensaver\fP is launched by the
-individual users: it is only necessary when it is launched by
-.BR xdm (1),
-before any user has logged in. See the ``\fIUsing XDM(1)\fP'' section,
-above, for more details.
-
-If anyone has suggestions on how xscreensaver could be made to work with
-.BR xdm (1)
-without first turning off \fI.Xauthority\fP-based access control, please
-let me know.
-.TP 8
-.B Passwords
-If you get an error message like ``couldn't get password of \fIuser\fP''
-then this probably means that you're on a system in which the
-.BR getpwent (3)
-library routine can only be effectively used by root. If this is the case,
-then \fIxscreensaver\fP must be installed as setuid to root. Care has
-been taken to make this a safe thing to do.
-
-It also may mean that your system uses shadow passwords instead of the
-standard \fIgetpwent\fP interface; in that case, you may need to change
-some options with \fIconfigure\fP and recompile.
-
-If you change your password after xscreensaver has been launched, it will
-continue using your old password to unlock the screen until xscreensaver
-is restarted. So, after you change your password, you'll have to do
-.EX
-xscreensaver-command -restart
-.EE
-to make \fIxscreensaver\fP notice.
-.TP 8
-.B Colormap lossage: TWM
-The \fBinstallColormap\fP option doesn't work very well with the
-.BR twm (1)
-window manager and its descendants.
-
-There is a race condition between the screensaver and this window manager,
-which can result in the screensaver's colormap not getting installed
-properly, meaning the graphics hacks will appear in essentially random
-colors. (If the screen goes white instead of black, this is probably why.)
-
-The
-.BR mwm (1)
-and
-.BR olwm (1)
-window managers don't seem to have this problem. The race condition exists
-because X does not provide a way for an OverrideRedirect window to have its
-own colormap, short of grabbing the server (which is neither a good idea, nor
-really possible with the current design.) What happens is that, as soon as
-the screensaver installs its colormap, \fBtwm\fP responds to
-the \fBColormapNotify\fP event that is generated by re-instaling the default
-colormap. Apparently, \fBtwm\fP doesn't \fIalways\fP do this; it seems to do
-it regularly if the screensaver is activated from a menu item, but seems to
-not do it if the screensaver comes on of its own volition, or is activated
-from another console. Any thoughts on this problem are welcome...
-.TP 8
-.B Colormap lossage: XV, XAnim, XEarth
-Some programs don't operate properly on visuals other than the default one,
-or with colormaps other than the default one. See the discussion of the
-magic "default-n" visual name in the description of the \fBprograms\fP
-resource in the \fIConfiguration\fP section. When programs only work with
-the default colormap, you need to use a syntax like this:
-.EX
- default-n: xv -root image-1.gif -quit \\n\\
- default-n: xearth -nostars -wait 0 \\n\\
-.EE
-It would also work to turn off the \fBinstallColormap\fP option altogether,
-but that would deny extra colors to those programs that \fIcan\fP take
-advantage of them.
-.TP 8
-.B XView Clients
-Apparently there are some problems with XView programs getting confused
-and thinking that the screensaver window is the real root window even when
-the screensaver is not active: ClientMessages intended for the window manager
-are sent to the screensaver window instead. This could be solved by making
-xscreensaver forward all unrecognised ClientMessages to the real root window,
-but there may be other problems as well. If anyone has any insight on the
-cause of this problem, please let me know. (XView is an X11 toolkit that
-implements the (quite abominable) Sun OpenLook look-and-feel.)
-.TP 8
-.B MIT Extension and Fading
-When using the \fBMIT-SCREEN-SAVER\fP extension in conjunction with
-the \fBfade\fP option, you may notice an unattractive flicker just before
-the fade begins. This is because the server maps a black window just before
-it tells the \fIxscreensaver\fP process to activate. The \fIxscreensaver\fP
-process immediately unmaps that window, but this results in a flicker. I
-haven't figured a way to get around this; it seems to be a fundamental
-property of the (mis-) design of this server extension.
-
-It sure would be nice if someone would implement the \fBSGI SCREEN_SAVER\fP
-extension in XFree86; it's dead simple, and works far better than the
-overengineered and broken \fBMIT-SCREEN-SAVER\fP extension.
-.TP 8
-.B Lesstif (Motif clone)
-\fIDemo Mode\fP is buggy if XScreenSaver was compiled against really old
-versions Lesstif; if you use Lesstif, make sure you use version 0.82 or newer.
-.TP 8
-.B Athena Widgets
-If you compiled against the Athena widget toolkit, the dialog boxes are
-pretty ugly, especially the password dialog. Use Motif! If you don't
-have OSF Motif, use GNU Lesstif, it's free: http://www.lesstif.org/
-.TP 8
-.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 Red Hot Lava
-There need to be a lot more graphics hacks. In particular, there should be
-a simulation of a Lavalite (tm).