-When \fImode\fP is set to \fIone\fP, this is the one, indicated by its
-index in the \fIprograms\fP list. You're crazy if you count them and
-set this number by hand: let
-.BR xscreensaver\-demo (1)
-do it for you!
-.TP 8
-.B programs\fP (class \fBPrograms\fP)
-The graphics hacks which \fIxscreensaver\fP runs when the user is idle.
-The value of this resource is a multi-line string, one \fIsh\fP-syntax
-command per line. Each line must contain exactly one command: no
-semicolons, no ampersands.
-
-When the screensaver starts up, one of these is selected (according to
-the \fBmode\fP setting), and run. After the \fIcycle\fP period
-expires, it is killed, and another is selected and run.
-
-If a line begins with a dash (-) then that particular program is
-disabled: it won't be selected at random (though you can still select
-it explicitly using the
-.BR xscreensaver\-demo (1)
-program.)
-
-If all programs are disabled, then the screen will just be made blank,
-as when \fImode\fP is set to \fIblank\fP.
-
-To disable a program, you must mark it as disabled with a dash instead
-of removing it from the list. This is because the system-wide (app-defaults)
-and per-user (.xscreensaver) settings are merged together, and if a user
-just \fIdeletes\fP an entry from their programs list, but that entry still
-exists in the system-wide list, then it will come back. However, if the
-user \fIdisables\fP it, then their setting takes precedence.
-
-If the display has multiple screens, then a different program will be run
-for each screen. (All screens are blanked and unblanked simultaneously.)
-
-Note that you must escape the newlines; here is an example of how you
-might set this in your \fI~/.xscreensaver\fP file:
-
-.RS 8
-.EX
-programs: \\
- qix -root \\n\\
- ico -r -faces -sleep 1 -obj ico \\n\\
- xdaliclock -builtin2 -root \\n\\
- xv -root -rmode 5 image.gif -quit \\n
-.EE
-.RE
-.RS 8
-Make sure your \fB$PATH\fP environment variable is set up correctly
-\fIbefore\fP xscreensaver is launched, or it won't be able to find the
-programs listed in the \fIprograms\fP resource.
-
-To use a program as a screensaver, two things are required: that that
-program draw on the root window (or be able to be configured to draw on
-the root window); and that that program understand ``virtual root''
-windows, as used by virtual window managers such as
-.BR tvtwm (1).
-(Generally, this is accomplished by just including the \fI"vroot.h"\fP
-header file in the program's source.)
-
-If there are some programs that you want to run only when using a color
-display, and others that you want to run only when using a monochrome
-display, you can specify that like this:
-.EX
- mono: mono-program -root \\n\\
- color: color-program -root \\n\\
-.EE
-.RE
-.RS 8
-More generally, you can specify the kind of visual that should be used for
-the window on which the program will be drawing. For example, if one
-program works best if it has a colormap, but another works best if it has
-a 24-bit visual, both can be accommodated:
-.EX
- PseudoColor: cmap-program -root \\n\\
- TrueColor: 24bit-program -root \\n\\
-.EE
-.RE
-.RS 8
-In addition to the symbolic visual names described above (in the discussion
-of the \fIvisualID\fP resource) one other visual name is supported in
-the \fIprograms\fP list:
-.RS 1
-.TP 4
-.B default-n
-This is like \fBdefault\fP, but also requests the use of the default colormap,
-instead of a private colormap. (That is, it behaves as if
-the \fI\-no\-install\fP command-line option was specified, but only for
-this particular hack.) This is provided because some third-party programs
-that draw on the root window (notably:
-.BR xv (1),
-and
-.BR xearth (1))
-make assumptions about the visual and colormap of the root window:
-assumptions which xscreensaver can violate.
-
-.RE
-If you specify a particular visual for a program, and that visual does not
-exist on the screen, then that program will not be chosen to run. This
-means that on displays with multiple screens of different depths, you can
-arrange for appropriate hacks to be run on each. For example, if one screen
-is color and the other is monochrome, hacks that look good in mono can be
-run on one, and hacks that only look good in color will show up on the other.
-.RE
-.PP
-.PP
-You shouldn't ever need to change the following resources:
-.PP
-.TP 8
-.B pointerPollTime\fP (class \fBTime\fP)
-When server extensions are not in use, this controls how
-frequently \fIxscreensaver\fP checks to see if the mouse position or buttons
-have changed. Default 5 seconds.
-.TP 8
-.B pointerHysteresis\fP (class \fBInteger\fP)
-If the mouse moves less than this-many pixels in a second, ignore it
-(do not consider that to be "activity.") This is so that the screen
-doesn't un-blank (or fail to blank) just because you bumped the desk.
-Default: 10 pixels.
-.TP 8
-.B windowCreationTimeout\fP (class \fBTime\fP)
-When server extensions are not in use, this controls the delay between when
-windows are created and when \fIxscreensaver\fP selects events on them.
-Default 30 seconds.
-.TP 8
-.B initialDelay\fP (class \fBTime\fP)
-When server extensions are not in use, \fIxscreensaver\fP will wait this many
-seconds before selecting events on existing windows, under the assumption that
-\fIxscreensaver\fP is started during your login procedure, and the window
-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.
-.SH COMMAND-LINE OPTIONS
-.I xscreensaver
-also accepts a few command-line options, mostly for use when debugging:
-for normal operation, you should configure things via the \fI~/.xscreensaver\fP
-file.
-.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.
-.TP 8
-.B \-verbose
-Same as setting the \fIverbose\fP resource to \fItrue\fP: print diagnostics
-on stderr and on the xscreensaver window.
-.TP 8
-.B \-no-capture-stderr
-Same as setting the \fIcaptureStderr\fP resource to \fIfalse\fP: do not
-redirect the stdout and stderr streams to the xscreensaver window itself.
-If xscreensaver is crashing, you might need to do this in order to see
-the error message.
-.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. Each window is created in such a way
-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 receive. (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 (after a few minutes), 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.
-
-As of version 3.28 (Feb 2001), the \fI~/.xscreensaver\fP file controls the
-configuration of your display's power management settings: if you have
-used
-.BR xset (1)
-to change your power management settings, then xscreensaver will
-override those changes with the values specified
-in \fI~/.xscreensaver\fP (or with its built-in defaults, if there
-is no \fI~/.xscreensaver\fP file yet.)
-
-To change your power management settings, run
-.BR xscreensaver\-demo (1)
-and change the various timeouts through the user interface.
-Alternately, you can edit the \fI~/.xscreensaver\fP file directly.
-
-If the power management section is grayed out in the
-.BR xscreensaver\-demo (1)
-window, then that means that your X server does not support
-the XDPMS extension, and so control over the monitor's power state
-is not available.
-
-If you're using a laptop, don't be surprised if changing the DPMS
-settings has no effect: many laptops have monitor power-saving behavior
-built in at a very low level that is invisible to Unix and X. On such
-systems, you can typically adjust the power-saving delays only by
-changing settings in the BIOS in some hardware-specific way.
-
-If DPMS seems not to be working with XFree86, make sure the "DPMS"
-option is set in your \fI/etc/X11/XF86Config\fP file. See the
-.BR XF86Config (5)
-manual for details.
-.SH USING XDM(1)
-You can run \fIxscreensaver\fP from your
-.BR xdm (1)
-session, so that the screensaver will run even when nobody is logged
-in on the console.
-
-The trick to using xscreensaver with \fIxdm\fP is this: keep in mind the
-two very different states in which xscreensaver will be running:
-.RS 4
-.TP 3
-.B 1: Nobody logged in.
-
-If you're thinking of running xscreensaver from XDM at all, then it's
-probably because you want graphics demos to be running on the console
-when nobody is logged in there. In this case, xscreensaver will function
-only as a screen saver, not a screen locker: it doesn't make sense
-for xscreensaver to lock the screen, since nobody is logged in yet!
-The only thing on the screen is the XDM login prompt.
-.TP 3
-.B 2: Somebody logged in.
-
-Once someone has logged in through the XDM login window, the situation is
-very different. For example: now it makes sense to lock the screen (and
-prompt for the logged in user's password); and now xscreensaver should
-consult that user's \fI~/.xscreensaver\fP file; and so on.
-.RE
-
-The difference between these two states comes down to a question of,
-which user is the \fIxscreensaver\fP process running as? For the first
-state, it doesn't matter. If you start \fIxscreensaver\fP in the usual
-XDM way, then xscreensaver will probably end up running as root, which
-is fine for the first case (the ``nobody logged in'' case.)
-
-However, once someone is logged in, running as root is no longer fine:
-because xscreensaver will be consulting root's \fI.xscreensaver\fP file
-instead of that of the logged in user, and won't be prompting for the
-logged in user's password, and so on. (This is not a security problem,
-it's just not what you want.)
-
-So, once someone has logged in, you want xscreensaver to be running as that
-user. The way to accomplish this is to kill the old xscreensaver process
-and start a new one (as the new user.)
-
-The simplest way to accomplish all of this is as follows:
-.RS 4
-.TP 3
-.B 1: Launch xscreensaver before anyone logs in.
-
-To the file \fI/usr/lib/X11/xdm/Xsetup\fP, add the lines
-.EX
-xhost +localhost
-xscreensaver-command -exit
-xscreensaver &
-.EE
-This will run xscreensaver as root, over the XDM login window.
-Moving the mouse will cause the screen to un-blank, and allow the user
-to type their password at XDM to log in.
-.TP 3
-.B 2: Restart xscreensaver when someone logs in.
-
-Near the top of the file \fI/usr/lib/X11/xdm/Xsession\fP, add those same lines:
-.EX
-xscreensaver-command -exit
-xscreensaver &
-.EE
-When someone logs in, this will kill off the existing (root) xscreensaver
-process, and start a new one, running as the user who has just logged in.
-If the user's .xscreensaver file requests locking, they'll get it. They
-will also get their own choice of timeouts, and graphics demos, and so on.
-
-Alternately, each user could just put those lines in their
-personal \fI~/.xsession\fP files.
-.RE
-
-Make sure you have \fB$PATH\fP set up correctly in the \fIXsetup\fP
-and \fIXsession\fP scripts, or \fIxdm\fP won't be able to
-find \fIxscreensaver\fP, and/or \fIxscreensaver\fP won't be able to
-find its graphics demos.
-
-(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.)
-
-It is safe to run \fIxscreensaver\fP 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.
-
-An unfortunate side effect of this (important) security precaution is that
-it may conflict with cookie-based authentication.
-
-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 the \fIXsetup\fP file
-might not be possible, and xscreensaver will only work when running as
-a normal, unprivileged user.
-
-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 GDM(1)
-Using xscreensaver with
-.BR gdm (1)
-is easy, because gdm has a configuration tool. Just fire up
-.BR gdmconfig (1)
-and on the \fIBackground\fP page, type \fB"xscreensaver -nosplash"\fP into
-the \fIBackground Program\fP field. That will cause gdm to run xscreensaver
-while nobody is logged in, and kill it as soon as someone does log in.
-(The user will then be responsible for starting xscreensaver on their
-own, if they want.)
-
-Another way to accomplish the same thing is to edit the
-file \fI/etc/X11/gdm/gdm.conf\fP to include:
-.EX
-BackgroundProgram=xscreensaver -nosplash
-RunBackgroundProgramAlways=true
-.EE
-In this situation, the \fIxscreensaver\fP process will probably be running
-as user \fIgdm\fP instead of \fIroot\fP. You can configure the settings
-for this nobody-logged-in state (timeouts, DPMS, etc.) by editing
-the \fI~gdm/.xscreensaver\fP file.
-
-To get gdm to run the BackgroundProgram, you may need to switch it from
-the "Graphical Greeter" to the "Standard Greeter".
-.SH USING KDE (K DESKTOP ENVIRONMENT)
-I understand that KDE has invented their own wrapper around xscreensaver,
-that is inferior to
-.BR xscreensaver-demo (1)
-in any number of ways. I've never actually seen it, but I'm told that
-this is the way you disable it:
-.RS 4
-.TP 3
-\fB1: Switch off KDE's screen saver.\fP
-Open the ``\fIControl Center\fP'' and
-select the ``\fILook and Feel / Screensaver\fP'' page.
-Turn off the ``\fIEnable Screensaver\fP'' checkbox.
-.TP 3
-\fB2: Find your Autostart directory.\fP
-Open the ``\fILook and Feel / Desktop / Paths\fP'' page,
-and see what your ``Autostart'' directory is set to: it will
-probably be \fI~/.kde3/Autostart/\fP or something similar.
-.TP 3
-\fB3: Make xscreensaver be an Autostart program.\fP
-Create a file in your autostart directory
-called \fIxscreensaver.desktop\fP that contains the following five lines:
-.EX
-[Desktop Entry]
-Exec=xscreensaver
-Name=XScreensaver
-Type=Application
-X-KDE-StartupNotify=false
-.EE
-.TP 3
-\fB4: Make the various "lock session" buttons call xscreensaver.\fP
-Replace the file \fI/usr/bin/kdesktop_lock\fP with these two lines:
-.EX
-#!/bin/sh
-xscreensaver-command -lock
-.EE
-Make sure the file is executable (chmod a+x).
-.RE
-.PP
-Now use xscreensaver normally, controlling it via the usual
-.BR xscreensaver-demo (1)
-and
-.BR xscreensaver-command (1)
-mechanisms.
-.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
-And make sure the sessionetc file is executable.
-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 BUGS
-Bugs? There are no bugs. Ok, well, maybe. If you find one, please let
-me know. http://www.jwz.org/xscreensaver/bugs.html explains how to
-construct the most useful bug reports.