+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 only adjust the power-saving delays by
+changing settings in the BIOS in some hardware-specific way.
+.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