+.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-demo"
+ "Screen Saver Preferences" !"xscreensaver-demo -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 xscreensaver menu items
+directly into the root menu.
+.RE
+
+For Fvwm2, the process is similar: first create a \fI~/.fvwm2rc\fP file
+if you don't already have one, by making a copy of
+the \fI/etc/X11/fvwm2/system.fvwm2rc\fP file. Then, add a menu definition
+to it:
+.EX
+AddToMenu XScreenSaver "XScreenSaver" Title
++ "Blank Screen Now" Exec xscreensaver-command -activate
++ "Lock Screen Now" Exec xscreensaver-command -lock
++ "Screen Saver Demo" Exec xscreensaver-command -demo
++ "Screen Saver Preferences" Exec xscreensaver-command -prefs
++ "Reinitialize Screen Saver" Exec xscreensaver-command -restart
++ "Kill Screen Saver" Exec xscreensaver-command -exit
++ "Launch Screen Saver" Exec xscreensaver
++ "Run Next Demo" Exec xscreensaver-command -next
++ "Run Previous Demo" Exec xscreensaver-command -prev
+
+# To put the XScreenSaver sub-menu at the end of the root menu:
+AddToMenu RootMenu "XScreenSaver" Popup XScreenSaver
+.EE
+The Enlightenment window manager keeps each of its menus in a separate
+file. So, you need to create a file
+named \fI~/.enlightenment/xscreensaver.menu\fP with the contents:
+.EX
+"XScreenSaver Commands"
+ "Blank Screen Now" NULL exec "xscreensaver-command -activate"
+ "Lock Screen Now" NULL exec "xscreensaver-command -lock"
+ "Screen Saver Demo" NULL exec "xscreensaver-command -demo"
+ "Screen Saver Prefs" NULL exec "xscreensaver-command -prefs"
+ "Reinitialize Saver" NULL exec "xscreensaver-command -restart"
+ "Kill Screen Saver" NULL exec "xscreensaver-command -exit"
+ "Launch Screen Saver" NULL exec "xscreensaver"
+.EE
+then add
+.EX
+ "XScreenSaver" NULL menu "xscreensaver.menu"
+.EE
+to \fI~/.enlightenment/file.menu\fP to put the XScreenSaver submenu on
+your left-button root-window menu.
+
+As you see, every window manager does this stuff gratuitously differently,
+just to make your life difficult. You are in a maze of twisty menu
+configuration languages, all alike.
+.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.
+.TP 8
+.B Locking and XDM
+If xscreensaver has been launched from
+.BR xdm (1)
+before anyone has logged in, you will need to kill and then restart the
+xscreensaver daemon after you have logged in, or you will be confused by
+the results. (For example, locking won't work, and your \fI~/.xscreensaver\fP
+file will be ignored.)
+
+When you are logged in, you want the \fIxscreensaver\fP daemon to be
+running under \fIyour\fP user id, not as root or some other user.
+
+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
+The ``\fIUsing XDM(1)\fP'' section, above, goes into more detail, and explains
+how to configure the system to do this for all users automatically.
+.TP 8
+.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 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 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 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 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. So, after you change your password, you'll have to do
+.EX
+xscreensaver-command -restart
+.EE
+to make \fIxscreensaver\fP notice.
+.TP 8
+.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 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 have this problem. The race condition exists
+because X (really, ICCCM) 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 xscreensaver installs its colormap, \fBtwm\fP
+responds to the resultant \fBColormapNotify\fP event 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.
+.RS 8
+.TP 4
+.B Attention, window manager authors!
+You should only call
+.BR XInstallColormap (3)
+in response to user events. That is, it is appropriate to install a colormap
+in response to \fBFocusIn\fP, \fBFocusOut\fP, \fBEnterNotify\fP,
+and \fBLeaveNotify\fP events; but it is not appropriate to call it in
+response to \fBColormapNotify\fP events. If you install colormaps in
+response to \fIapplication\fP actions as well as in response to \fIuser\fP
+actions, then you create the situation where it is impossible for
+override-redirect applications (such as xscreensaver) to display their
+windows in the proper colors.
+.RE
+.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 Machine Load