+.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
+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.
+.TP 8
+.B \-log \fIfilename\fP
+This is exactly the same as redirecting stdout and stderr to the given
+file (for append). This is useful when reporting bugs.
+.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.
+The various graphics demos are, in fact, just standalone programs that
+know how to draw on the provided window.
+
+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.
+
+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.
+
+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.
+Alternatively, 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 GNOME OR UNITY
+For the better part of a decade, GNOME shipped xscreensaver as-is,
+and everything just worked out of the box. In 2005, however, they
+decided to re-invent the wheel and ship their own replacement for
+the \fIxscreensaver\fP daemon called "\fIgnome-screensaver\fP",
+rather than improving xscreensaver and contributing their changes
+back. As a result, the "\fIgnome-screensaver\fP" program is insecure,
+bug-ridden, and missing many features of xscreensaver. You shouldn't
+use it.
+
+To replace gnome-screensaver with xscreensaver:
+.RS 4
+.TP 3
+\fB1: Fully uninstall the gnome-screensaver package.\fP
+.EX
+sudo apt-get remove gnome-screensaver
+.EE
+or possibly
+.EX
+sudo dpkg -P gnome-screensaver
+.EE
+.TP 3
+\fB2: Launch xscreensaver at login.\fP
+Select "\fIStartup Applications\fP" from the menu (or manually
+launch "\fIgnome-session-properties\fP") and add "\fIxscreensaver\fP".
+
+Do this as your normal user account, not as root.
+(This should go without saying, because you should never, ever, ever
+be logged in to the graphical desktop as user "root".)
+.TP 3
+\fB3: Make GNOME's "Lock Screen" use xscreensaver.\fP
+.EX
+sudo ln -sf /usr/bin/xscreensaver-command \\
+ /usr/bin/gnome-screensaver-command
+.EE
+That doesn't work under Unity, though. Apparently it has its own
+built-in screen locker which is not gnome-screensaver, and cannot be
+removed, and yet still manages to be bug-addled and insecure.
+Keep reinventing that wheel, guys! (If you have figured out how to
+replace Unity's locking "feature" with xscreensaver, let me know.)
+.TP 3
+\fB4: Turn off Unity's built-in blanking.\fP
+Open "\fISystem Settings / Brightness & Lock\fP";
+.br
+Un-check "\fIStart Automatically\fP";
+.br
+Set \fI"Turn screen off when inactive for"\fP to \fI"Never".\fP
+.SH USING KDE
+Like GNOME, KDE also decided to invent their own screen saver framework
+from scratch instead of simply using xscreensaver. To replace the KDE
+screen saver with xscreensaver, do the following:
+.RS 4
+.TP 3
+\fB1: Turn off KDE's screen saver.\fP
+Open the "\fIControl Center\fP" and
+select the "\fIAppearance & Themes / Screensaver\fP" page.
+Un-check "\fIStart Automatically\fP".
+
+Or possibly:
+Open "\fISystem Settings\fP" and
+select "\fIScreen Locking\fP".
+Un-check "\fILock Screen Automatically\fP".
+.TP 3
+\fB2: Find your Autostart directory.\fP
+Open the "\fISystem Administration / Paths\fP" page,
+and see what your "Autostart path" is set to: it will
+probably be something like \fI~/.kde/Autostart/\fP
+or \fI~/.config/autostart/\fP
+
+If that doesn't work, then try this:
+
+Open "\fISystem Settings / Startup/Shutdown / Autostart\fP", and then
+add "\fI/usr/bin/xscreensaver\fP".
+
+If you are lucky, that will create a \fIxscreensaver.desktop"\fP file
+for you in \fI~/.config/autostart/\fP or \fI~/.kde/Autostart/\fP.
+.TP 3
+\fB3: Make xscreensaver be an Autostart program.\fP
+If it does not already exist, create a file in your autostart directory
+called \fIxscreensaver.desktop\fP that contains the following six lines:
+.EX
+[Desktop Entry]
+Exec=xscreensaver
+Name=XScreenSaver
+Type=Application
+StartupNotify=false
+X-KDE-StartupNotify=false
+.EE
+.TP 3
+\fB4: Make the various "lock session" buttons call xscreensaver.\fP
+The file you want to replace next has moved around over the years. It
+might be called \fI/usr/libexec/kde4/kscreenlocker\fP,
+or it might be called "\fIkdesktop_lock\fP" or "\fIkrunner_lock\fP"
+or "\fIkscreenlocker_greet\fP", and
+it might be in \fI/usr/lib/kde4/libexec/\fP
+or in \fI/usr/kde/3.5/bin/\fP or even in \fI/usr/bin/\fP,
+depending on the distro and phase of the moon. Replace the contents
+of that file 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 SYSTEMD
+If the above didn't do it, and your system has
+.BR systemd (1),
+then give this a try:
+.TP 3
+\fB1: Create a service.\fP
+Create the file \fI~/.config/systemd/user/xscreensaver.service\fP
+containing:
+.EX
+[Unit]
+Description=XScreenSaver
+[Service]
+ExecStart=/usr/bin/xscreensaver
+[Install]
+WantedBy=default.target
+.EE
+.TP 3
+\fB2. Enable it.\fP
+.EX
+systemctl --user enable xscreensaver
+.EE
+Then restart X11.
+.SH USING UPSTART
+If it's still not working, but on your distro, that newfangled
+.BR systemd (1)
+nonsense has already fallen out of favor? Then maybe this will work:
+launch the \fI"Startup Applications"\fP applet, click \fI"Add"\fP,
+enter these lines, then restart X11:
+.EX
+Name: XScreenSaver
+Command: xscreensaver
+Comment: xscreensaver
+.EE
+.SH USING GDM
+You can run \fIxscreensaver\fP from your
+.BR gdm (1)
+session, so that the screensaver will run even when nobody is logged
+in on the console. To do this, run
+.BR gdmconfig (1).
+
+On the \fIGeneral\fP page set the \fILocal Greeter\fP to
+\fIStandard Greeter\fP.
+
+On the \fIBackground\fP page, type the
+command \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.)
+
+If that doesn't work, you can edit the config file directly. Edit
+\fI/etc/X11/gdm/gdm.conf\fP to include:
+.EX
+Greeter=/usr/bin/gdmlogin
+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.
+
+It is safe to run \fIxscreensaver\fP as root (as \fIxdm\fP or \fIgdm\fP may 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 \fIgdm\fP, then this probably means that you have
+.BR xauth (1)
+or some other security mechanism turned on. For 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 BUGS
+Bugs? There are no bugs. Ok, well, maybe. If you find one, please let
+me know. https://www.jwz.org/xscreensaver/bugs.html explains how to
+construct the most useful bug reports.
+.PP
+.TP 4
+.B Locking and root logins
+In order for it to be safe for xscreensaver to be launched by \fIxdm\fP,
+certain precautions had to be taken, among them that xscreensaver never
+runs as \fIroot\fP. In particular, if it is launched as root (as \fIxdm\fP
+is likely to do), xscreensaver will disavow its privileges, and switch
+itself to a safe user id (such as \fInobody\fP).
+
+An implication of this 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
+launched by the
+.BR xdm (1)
+.I Xsetup
+file).
+
+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?)
+
+Proper Unix hygiene dictates that you should log in as yourself, 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 4
+.B XAUTH and XDM
+For xscreensaver to work when launched by
+.BR xdm (1)
+or
+.BR gdm (1),
+programs running on the local machine as user \fI"nobody"\fP must be
+able to connect to the X server. This means that if you want to run
+xscreensaver on the console while nobody is logged in, you may need
+to disable cookie-based access control (and allow all users who can log
+in to the local machine to connect to the display).
+
+You should be sure that this is an acceptable thing to do in your
+environment before doing it. See the "\fIUsing GDM\fP" section,
+above, for more details.
+.TP 4
+.B Passwords
+If you get an error message at startup 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 in order for
+locking to work. 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
+.BR getpwent (3)
+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. On some systems, it may accept \fIboth\fP your old and new
+passwords. So, after you change your password, you'll have to do
+.EX
+xscreensaver-command -restart
+.EE
+to make \fIxscreensaver\fP notice.
+.TP 4
+.B PAM Passwords
+If your system uses PAM (Pluggable Authentication Modules), then in order
+for xscreensaver to use PAM properly, PAM must be told about xscreensaver.
+The xscreensaver installation process should update the PAM data (on Linux,
+by creating the file \fI/etc/pam.d/xscreensaver\fP for you, and on Solaris,
+by telling you what lines to add to the \fI/etc/pam.conf\fP file).
+
+If the PAM configuration files do not know about xscreensaver, then
+you \fImight\fP be in a situation where xscreensaver will refuse to ever
+unlock the screen.
+
+This is a design flaw in PAM (there is no way for a client to tell the
+difference between PAM responding "I have never heard of your module",
+and responding, "you typed the wrong password"). As far as I can tell,
+there is no way for xscreensaver to automatically work around this, or
+detect the problem in advance, so if you have PAM, make sure it is
+configured correctly!
+.TP 4
+.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 consume many
+cycles. Care has been taken in all the modules shipped with xscreensaver
+to sleep periodically, and not run full tilt, so as not to cause
+appreciable load.
+
+However, if you are running the OpenGL-based screen savers on a machine
+that does not have a video card with 3D acceleration, they \fIwill\fP
+make your machine slow, despite
+.BR nice (1).
+
+Your options are: don't use the OpenGL display modes; or, collect the
+spare change hidden under the cushions of your couch, and use it to
+buy a video card manufactured after 1998. (It doesn't even need to be
+\fIfast\fP 3D hardware: the problem will be fixed if there is any
+3D hardware \fIat all.\fP)
+.TP 4
+.B Magic Backdoor Keystrokes
+The XFree86 X server and the Linux kernel both trap certain magic
+keystrokes before X11 client programs ever see them. If you care
+about keeping your screen locked, this is a big problem.
+.RS 4
+.TP 3
+.B Ctrl+Alt+Backspace
+This keystroke kills the X server, and on some systems, leaves you at
+a text console. If the user launched X11 manually, that text console
+will still be logged in. To disable this keystroke globally and
+permanently, you need to set the \fBDontZap\fP flag in your
+\fIxorg.conf\fP or \fIXF86Config\fP or \fIXF86Config-4\fP file,
+depending which is in use on your system. See
+.BR XF86Config (5)
+for details.
+.TP 3
+.B Ctrl-Alt-F1, Ctrl-Alt-F2, etc.
+These keystrokes will switch to a different virtual console, while
+leaving the console that X11 is running on locked. If you left a
+shell logged in on another virtual console, it is unprotected. So
+don't leave yourself logged in on other consoles. You can disable VT
+switching globally and permanently by setting \fBDontVTSwitch\fP in
+your \fIxorg.conf\fP, but that might make your system harder to use,
+since VT switching is an actual useful feature.
+
+There is no way to disable VT switching only when the screen is
+locked. It's all or nothing.
+.TP 3
+.B Ctrl-Alt-KP_Multiply
+This keystroke kills any X11 app that holds a lock, so typing this
+will kill xscreensaver and unlock the screen. This so-called
+"feature" showed up in the X server in 2008, and as of 2011, some
+vendors are shipping it turned on by default. How nice. You can
+disable it by turning off
+\fBAllowClosedownGrabs\fP in \fIxorg.conf\fP.
+.TP 3
+.B Alt-SysRq-F
+This is the Linux kernel "OOM-killer" keystroke. It shoots down
+random long-running programs of its choosing, and so might might
+target and kill xscreensaver, and there's no way for xscreensaver to
+protect itself from that. You can disable it globally with:
+.EX
+echo 176 > /proc/sys/kernel/sysrq
+.EE
+.RE
+There's little that I can do to make the screen locker be secure so long
+as the kernel and X11 developers are \fIactively\fP working against
+security like this. The strength of the lock on your front door
+doesn't matter much so long as someone else in the house insists on
+leaving a key under the welcome mat.
+.TP 4
+.B Dangerous Backdoor Server Extensions
+Many distros enable by default several X11 server extensions that can
+be used to bypass grabs, and thus snoop on you while you're typing
+your password. These extensions are nominally for debugging and
+automation, but they are also security-circumventing keystroke
+loggers. If your server is configured to load the \fBRECORD, XTRAP\fP
+or \fBXTEST\fP extensions, you absolutely should disable those, 100%
+of the time. Look for them in \fIxorg.conf\fP or whatever it is
+called.
+.SH X RESOURCES
+These are the X resources use by the \fIxscreensaver\fP program.
+You probably won't need to change these manually (that's what the
+.BR xscreensaver\-demo (1)
+program is for).
+.TP 8
+.B timeout\fP (class \fBTime\fP)
+The screensaver will activate (blank the screen) after the keyboard and
+mouse have been idle for this many minutes. Default 10 minutes.
+.TP 8
+.B cycle\fP (class \fBTime\fP)