+.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 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.)
+
+Note that the OpenGL-based graphics demos are real pigs on machines that
+don't have texture hardware.
+
+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
+.B Doom and Quake
+On some systems, Doom, Quake, and other games intercept the keyboard in
+ways that X programs can never detect. Therefore, when running these games,
+xscreensaver might think the console is idle, and activate. In the worst
+case, xscreensaver might blank the screen and mess up the game. Alternately,
+xscreensaver might activate on the X display while leaving the game visible,
+and merely cause the game to slow down.
+
+I don't know how to fix this, because I don't know how to detect the kind
+of keyboard activity that occurs during these games. Suggestions are welcome.
+.TP 8
+.B 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
+.B XFree86's Magic Keystrokes
+The XFree86 X server traps certain magic keystrokes before client programs ever
+see them. Two that are of note are Ctrl+Alt+Backspace, which causes
+the X server to exit; and Ctrl+Alt+F\fIn\fP, which switches virtual consoles.
+The X server will respond to these keystrokes even if xscreensaver has the
+screen locked. Depending on your setup, you might consider this a problem.
+
+Unfortunately, there is no way for xscreensaver itself to override the
+interpretation of these keys. If you want to disable Ctrl+Alt+Backspace
+globally, you need to set the \fIDontZap\fP flag in
+your \fI/etc/X11/XF86Config\fP file. See the
+.BR XF86Config (5)
+manual for details.
+
+There is no way (as far as I can tell) to disable the VT-switching keystrokes.
+
+Some Linux systems come with a VT_LOCKSWITCH ioctl, that one could
+theoretically use to prevent VT-switching while the screen is locked;
+but unfortunately, this ioctl can only be used by root, which means
+that xscreensaver can't use it (since xscreensaver disavows its privileges
+shortly after startup, for security reasons.)
+
+Any suggestions for other solutions to this problem are welcome.
+.TP 8