-state may be in flux. Default 30 seconds.
-.TP 8
-.B overlayStderr \fR(class \fBBoolean\fP)
-If \fBcaptureStderr\fP or \fBcaptureStdout\fP are True, and your server
-supports ``overlay'' visuals, then the text will be written into one of
-the higher layers instead of into the same layer as the running screenhack.
-Set this to False to disable that (though you shouldn't need to.)
-.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 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.
-
-(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 \fIxdm-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.
-
-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:
-
-.EX
- xscreensaver-command -exit ; xscreensaver
-.EE
-.SH DEMO MODE
-If \fIxscreensaver\fP receives the \fBDEMO\fP ClientMessage, which is done
-by running the \fBxscreensaver\-command\fP program with the \fB\-demo\fP
-option, the screensaver will black the screen and pop up a dialog box from
-which you can examine and experiment with the client programs.
-
-The dialog box contains a scrolling list, a text field, and a number of
-buttons.
-
-Double-clicking on one of the programs in the list will run it. Clicking
-the mouse again will bring the dialog box back.
-
-Single-clicking in the list will place the indicated program and its args
-in the text field to be edited. Edit the arguments and hit return to run
-the program with the parameters you have specified. (Note that these are
-one-time changes and won't be remembered; to make the changes permanent,
-you need to edit your X resource file.)
-
-The buttons are:
-.TP 8
-.B Run Next
-Clicking this button will run the next program in the list after the
-currently-selected one, and will scroll around to the top when it reaches
-the bottom.
-.TP 8
-.B Run Previous
-Opposite of Run Next; at the top, it scrolls around to the bottom.
-.TP 8
-.B Edit Parameters
-This pops up a second dialog box, in which you have the option to
-interactively change most of the screensaver's operational parameters,
-such as its timeouts, and whether it should lock the screen. Changing
-these parameters here will affect only the running \fIxscreensaver\fP
-process; to make the changes permanent, you need to edit your X resource
-file.
-.TP 8
-.B Exit Demo Mode
-Returns to normal screensaver operation.
-.TP 8
-.B Reinitialize
-This causes the X resource database to be re-read, to pick up any changes
-you might have made. This works by causing the screensaver process to exit
-and then restart itself with the same command-line arguments. This is just
-like the \fI\-restart\fP argument to
-.BR xscreensaver\-command (1)
-except that when executed from this button, the screensaver will
-automatically return to demo mode after restarting.
-.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 (see above.)
-.TP 8
-Extensions
-If you are not making use of one of the server extensions (\fBXIDLE\fP,
-\fBSCREEN_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
-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
-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
-Locking and XDM
-Locking doesn't work if the screensaver is launched by \fIxdm\fP.
-The reason for this is that when it is launched by \fIxdm\fP, the
-screensaver process is owned by some standard user id (such as \fIroot\fP
-or \fIdaemon\fP) instead of the user who is logged in on the console:
-because the screensaver was started \fIbefore\fP anyone was logged in.
-In order for the screensaver to prompt for the password of the person
-who had logged in from \fIxdm\fP, it would need to know who that user was,
-and there is no reliable and safe way to figure that out. (And even if
-there was, there would be some other security issues here as well.)
-
-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 with
-\fBxscreensaver-command -exit\fP, and then start it again as you.
-.TP 8
-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 in \fIconfig.h\fP and recompile.
-.TP 8
-TWM and Colormaps
-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 apparently 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
-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.
-.TP 8
-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.
-.TP 8
-LessTif (Motif Clone)
-Rumor has it that demo mode is buggy if XScreenSaver was compiled with the
-GNU LessTif reimplementation of Motif. Since it works fine with OSF Motif
-on a variety of systems, I assume these problems are due to bugs in LessTif.
-Again, any insight would be appreciated.
-.TP 8
-Red Hot Lava
-There need to be a lot more graphics hacks. In particular, there should be
-a simulation of a Lavalite (tm).
+state may be in flux. Default 0. (This used to default to 30, but that was
+back in the days when slow machines and X terminals were more common...)
+.RE
+.PP
+There are a number of different X server extensions which can make
+xscreensaver's job easier. The next few resources specify whether these
+extensions should be utilized if they are available.
+.TP 8
+.B sgiSaverExtension\fP (class \fBBoolean\fP)
+This resource controls whether the SGI \fBSCREEN_SAVER\fP server extension
+will be used to decide whether the user is idle. This is the default
+if \fIxscreensaver\fP has been compiled with support for this
+extension (which is the default on SGI systems.). If it is available,
+the \fBSCREEN_SAVER\fP method is faster and more reliable than what will
+be done otherwise, so use it if you can. (This extension is only available
+on Silicon Graphics systems, unfortunately.)
+.TP 8
+.B mitSaverExtension\fP (class \fBBoolean\fP)
+This resource controls whether the \fBMIT\-SCREEN\-SAVER\fP server extension
+will be used to decide whether the user is idle. However, the default for
+this resource is \fIfalse\fP, because even if this extension is available,
+it is flaky (and it also makes the \fBfade\fP option not work properly.)
+Use of this extension is strongly discouraged. Support for it will
+probably be removed eventually.
+.TP 8
+.B xidleExtension\fP (class \fBBoolean\fP)
+This resource controls whether the \fBXIDLE\fP server extension will be
+used to decide whether the user is idle. This is the default
+if \fIxscreensaver\fP has been compiled with support for this extension.
+(This extension is only available for X11R4 and X11R5 systems, unfortunately.)
+.TP 8
+.B procInterrupts\fP (class \fBBoolean\fP)
+This resource controls whether the \fB/proc/interrupts\fP file should be
+consulted to decide whether the user is idle. This is the default
+if \fIxscreensaver\fP has been compiled on a system which supports this
+mechanism (i.e., Linux systems.)
+
+The benefit to doing this is that \fIxscreensaver\fP can note that the user
+is active even when the X console is not the active one: if the user is
+typing in another virtual console, xscreensaver will notice that and will
+fail to activate. For example, if you're playing Quake in VGA-mode,
+xscreensaver won't wake up in the middle of your game and start competing
+for CPU.
+
+The drawback to doing this is that perhaps you \fIreally do\fP want idleness
+on the X console to cause the X display to lock, even if there is activity
+on other virtual consoles. If you want that, then set this option to False.
+(Or just lock the X console manually.)
+
+The default value for this resource is True, on systems where it works.
+.TP 8
+.B overlayStderr\fP (class \fBBoolean\fP)
+If \fBcaptureStderr\fP is True, and your server supports ``overlay'' visuals,
+then the text will be written into one of the higher layers instead of into
+the same layer as the running screenhack. Set this to False to disable
+that (though you shouldn't need to.)
+.TP 8
+.B overlayTextForeground\fP (class \fBForeground\fP)
+The foreground color used for the stdout/stderr text, if \fBcaptureStderr\fP
+is true. Default: Yellow.
+.TP 8
+.B overlayTextBackground\fP (class \fBBackground\fP)
+The background color used for the stdout/stderr text, if \fBcaptureStderr\fP
+is true. Default: Black.
+.TP 8
+.B bourneShell\fP (class \fBBourneShell\fP)
+The pathname of the shell that \fIxscreensaver\fP uses to start subprocesses.
+This must be whatever your local variant of \fB/bin/sh\fP is: in particular,
+it must not be \fBcsh\fP.