X-Git-Url: http://git.hungrycats.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=local%2Fman%2Fman.1%2Fxscreensaver.1;fp=local%2Fman%2Fman.1%2Fxscreensaver.1;h=34c1d80419ed4ec10dde5c9d7042a4b1e2702f56;hb=41fae2ad67bc37e31c4d967bae81e4f3f50fa55a;hp=0000000000000000000000000000000000000000;hpb=278c59e14c53fd412b734e699bd4f314f766f804;p=xscreensaver diff --git a/local/man/man.1/xscreensaver.1 b/local/man/man.1/xscreensaver.1 new file mode 100644 index 00000000..34c1d804 --- /dev/null +++ b/local/man/man.1/xscreensaver.1 @@ -0,0 +1,1358 @@ +.de EX \"Begin example +.ne 5 +.if n .sp 1 +.if t .sp .5 +.nf +.in +.5i +.. +.de EE +.fi +.in -.5i +.if n .sp 1 +.if t .sp .5 +.. +.TH XScreenSaver 1 "20-Jun-99 (3.15)" "X Version 11" +.SH NAME +xscreensaver - graphics hack and screen locker, launched when the user is idle +.SH SYNOPSIS +.B xscreensaver +[\-display \fIhost:display.screen\fP] \ +[\-timeout \fIint\fP] \ +[\-cycle \fIint\fP] \ +[\-lock\-mode] \ +[\-no\-lock\-mode] \ +[\-lock\-timeout \fIint\fP] \ +[\-visual \fIvisual\fP] \ +[\-install] \ +[\-no\-install] \ +[\-verbose] \ +[\-silent] \ +[\-timestamp] \ +[\-capture\-stderr] \ +[\-no\-capture\-stderr] \ +[\-splash] \ +[\-no\-splash] \ +[\-nice \fIint\fP] \ +[\-mit\-extension] \ +[\-no\-mit\-extension] \ +[\-sgi\-extension] \ +[\-no\-sgi\-extension] \ +[\-xidle\-extension] \ +[\-no\-xidle\-extension] \ +[\-proc\-interrupts] \ +[\-no\-proc\-interrupts] \ +[\-xrm \fIresources\fP] +.SH DESCRIPTION +The \fIxscreensaver\fP program waits until the keyboard and mouse have been +idle for a period, and then runs a graphics demo chosen at random. It +turns off as soon as there is any mouse or keyboard activity. + +This program can lock your terminal in order to prevent others from using it, +though its default mode of operation is merely to display pretty pictures on +your screen when it is not in use. + +The benefit that this program has over the combination of the +.BR xlock (1) +and +.BR xautolock (1) +programs is the ease with which new graphics hacks can be installed. You +don't need to recompile (or even re-run) this program to add a new display +mode. +.SH GETTING STARTED +For the impatient, try this: +.EX +xscreensaver & +xscreensaver-demo +.EE +The +.BR xscreensaver-demo (1) +program should pop up a dialog box that lets you experiment with the +xscreensaver settings and graphics modes. + +.B Note: +unlike +.BR xlock (1), +xscreensaver has a client-server model: the \fIxscreensaver\fP program is a +daemon that runs in the background; it is controlled by the foreground +.BR xscreensaver-demo (1) +and +.BR xscreensaver-command (1) +programs. +.SH CONFIGURATION +Options to \fIxscreensaver\fP are specified in one of two places: in +a \fI.xscreensaver\fP file in your home directory; or in the X resource +database. If the \fI.xscreensaver\fP file exists, it overrides any settings +in the resource database. + +The syntax of the \fI.xscreensaver\fP file is similar to that of +the \fI.Xdefaults\fP file; for example, to set the \fItimeout\fP paramter +in the \fI.xscreensaver\fP file, you would write the following: +.EX +timeout: 5 +.EE +whereas, in the \fI.Xdefaults\fP file, you would write +.EX +xscreensaver.timeout: 5 +.EE +If you change a setting in the \fI.xscreensaver\fP file while xscreensaver +is already running, it will notice this, and reload the file. (The file will +be reloaded the next time the screen saver needs to take some action, such as +blanking or unblanking the screen, or picking a new graphics mode.) + +If you change a setting in your X resource database, or if you want +xscreensaver to notice your changes immediately instead of the next time +it wakes up, then you will need to tell the running xscreensaver process +to re-initialize itself, like so: +.EX +xscreensaver-command -restart +.EE +Note that if you changed the \fI.Xdefaults\fP file, you might also need to run +.BR xrdb (1): +.EX +xrdb < ~/.Xdefaults +.EE +If you want to set the system-wide defaults, then make your edits to +the xscreensaver app-defaults file, which should have been installed +when xscreensaver itself was installed. The app-defaults file will +usually be named /usr/lib/X11/app-defaults/XScreenSaver, but different +systems might keep it in a different place (for example, +/usr/openwin/lib/app-defaults/XScreenSaver on Solaris.) + +When settings are changed in the Preferences dialog box (see above) +the current settings will be written to the \fI.xscreensaver\fP file. +(The \fI.Xdefaults\fP file and the app-defaults file will never be +written by xscreensaver itself.) +.PP +.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) +After the screensaver has been running for this many minutes, the currently +running graphics-hack sub-process will be killed (with \fBSIGTERM\fP), and a +new one started. If this is 0, then the graphics hack will never be changed: +only one demo will run until the screensaver is deactivated by user activity. +Default 10 minutes. +.TP 8 +.B lock\fP (class \fBBoolean\fP) +Enable locking: before the screensaver will turn off, it will require you +to type the password of the logged-in user (really, the person who ran +xscreensaver), or the root password. (\fBNote:\fP this doesn't work if the +screensaver is launched by +.BR xdm (1) +because it can't know the user-id of the logged-in user. See +the ``\fIUsing XDM(1)\fP'' section, below. +.TP 8 +.B lockTimeout\fP (class \fBTime\fP) +If locking is enabled, this controls the length of the ``grace period'' +between when the screensaver activates, and when the screen becomes locked. +For example, if this is 5, and \fI\-timeout\fP is 10, then after 10 minutes, +the screen would blank. If there was user activity at 12 minutes, no password +would be required to un-blank the screen. But, if there was user activity +at 15 minutes or later (that is, \fI\-lock\-timeout\fP minutes after +activation) then a password would be required. The default is 0, meaning +that if locking is enabled, then a password will be required as soon as the +screen blanks. +.TP 8 +.B passwdTimeout\fP (class \fBTime\fP) +If the screen is locked, then this is how many seconds the password dialog box +should be left on the screen before giving up (default 30 seconds.) This +should not be too large: the X server is grabbed for the duration that the +password dialog box is up (for security purposes) and leaving the server +grabbed for too long can cause problems. +.TP 8 +.B visualID\fP (class \fBVisualID\fP) +Specify which X visual to use by default. (Note carefully that this resource +is called \fBvisualID\fP, not merely \fBvisual\fP; if you set the \fBvisual\fP +resource instead, things will malfunction in obscure ways for obscure reasons.) + +Legal values for the \fBVisualID\fP resource are: +.RS 8 +.TP 8 +.B default +Use the screen's default visual (the visual of the root window.) +This is the default. +.TP 8 +.B best +Use the visual which supports the most colors. Note, however, that the +visual with the most colors might be a TrueColor visual, which does not +support colormap animation. Some programs have more interesting behavior +when run on PseudoColor visuals than on TrueColor. +.TP 8 +.B mono +Use a monochrome visual, if there is one. +.TP 8 +.B gray +Use a grayscale or staticgray visual, if there is one and it has more than +one plane (that is, it's not monochrome.) +.TP 8 +.B color +Use the best of the color visuals, if there are any. +.TP 8 +.B GL +Use the visual that is best for OpenGL programs. (OpenGL programs have +somewhat different requirements than other X programs.) +.TP 8 +.I class +where \fIclass\fP is one of \fBStaticGray\fP, \fBStaticColor\fP, +\fBTrueColor\fP, \fBGrayScale\fP, \fBPseudoColor\fP, or \fBDirectColor\fP. +Selects the deepest visual of the given class. +.TP 8 +.I number +where \fInumber\fP (decimal or hex) is interpreted as a visual id number, +as reported by the +.BR xdpyinfo (1) +program; in this way you can have finer control over exactly which visual +gets used, for example, to select a shallower one than would otherwise +have been chosen. + +.RE +.RS 8 +Note that this option specifies only the \fIdefault\fP visual that will +be used: the visual used may be overridden on a program-by-program basis. +See the description of the \fBprograms\fP resource, below. +.RE +.TP 8 +.B installColormap\fP (class \fBBoolean\fP) +Install a private colormap while the screensaver is active, so that the +graphics hacks can get as many colors as possible. This is the +default. (This only applies when the screen's default visual is being +used, since non-default visuals get their own colormaps automatically.) +This can also be overridden on a per-hack basis: see the discussion of +the \fBdefault\-n\fP name in the section about the \fBprograms\fP resource. +.TP 8 +.B verbose\fP (class \fBBoolean\fP) +Whether to print diagnostics. Default false. +.TP 8 +.B timestamp\fP (class \fBBoolean\fP) +Whether to print the time of day along with any other diagnostic messages. +Default false. +.TP 8 +.B splash\fP (class \fBBoolean\fP) +Whether to display a splash screen at startup. Default true. +.TP 8 +.B splashDuration\fP (class \fBTime\fP) +How long the splash screen should remain visible; default 5 seconds. +.TP 8 +.B helpURL\fP (class \fBURL\fP) +The splash screen has a \fIHelp\fP button on it. When you press it, it will +display the web page indicated here in your web browser. +.TP 8 +.B loadURL\fP (class \fBLoadURL\fP) +This is the shell command used to load a URL into your web browser. +The default setting will load it into Netscape if it is already running, +otherwise, will launch a new Netscape looking at the \fIhelpURL\fP. +.TP 8 +.B demoCommand\fP (class \fBDemoCommand\fP) +This is the shell command run when the \fIDemo\fP button on the splash window +is pressed. It defaults to \fIxscreensaver\-demo\fP. +.TP 8 +.B prefsCommand\fP (class \fBPrefsCommand\fP) +This is the shell command run when the \fIPrefs\fP button on the splash window +is pressed. It defaults to \fIxscreensaver\-demo\ \-prefs\fP. +.TP 8 +.B nice\fP (class \fBNice\fP) +The sub-processes created by \fIxscreensaver\fP will be ``niced'' to this +level, so that they are given lower priority than other processes on the +system, and don't increase the load unnecessarily. The default is 10. + +(Higher numbers mean lower priority; see +.BR nice (1) +for details.) +.TP 8 +.B fade\fP (class \fBBoolean\fP) +If this is true, then when the screensaver activates, the current contents +of the screen will fade to black instead of simply winking out. This only +works on displays with writable colormaps, that is, if the screen's default +visual is a PseudoColor visual. A fade will also be done when +switching graphics hacks (when the \fIcycle\fP timer expires.) +Default: true. +.TP 8 +.B unfade\fP (class \fBBoolean\fP) +If this is true, then when the screensaver deactivates, the original contents +of the screen will fade in from black instead of appearing immediately. This +only works on displays with writable colormaps, and if \fIfade\fP is true +as well. Default false. +.TP 8 +.B fadeSeconds\fP (class \fBTime\fP) +If \fIfade\fP is true, this is how long the fade will be in +seconds (default 3 seconds.) +.TP 8 +.B fadeTicks\fP (class \fBInteger\fP) +If \fIfade\fP is true, this is how many times a second the colormap will +be changed to effect a fade. Higher numbers yield smoother fades, but +may make the fades take longer than the specified \fIfadeSeconds\fP if +your server isn't fast enough to keep up. Default 20. +.TP 8 +.B captureStderr\fP (class \fBBoolean\fP) +Whether \fIxscreensaver\fP should redirect its stdout and stderr streams to +the window itself. Since its nature is to take over the screen, you would not +normally see error messages generated by xscreensaver or the sub-programs it +runs; this resource will cause the output of all relevant programs to be +drawn on the screensaver window itself, as well as being written to the +controlling terminal of the screensaver driver process. Default true. +.TP 8 +.B font\fP (class \fBFont\fP) +The font used for the stdout/stderr text, if \fBcaptureStderr\fP is true. +Default \fB*\-medium\-r\-*\-140\-*\-m\-*\fP (a 14 point fixed-width font.) +.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 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 at random, and +run. After the \fIcycle\fP period expires, it is killed, and another +is selected and run. + +If the value of this resource is empty, then no programs will be run; the +screen will simply be made black. + +If the display has multiple screens, then a different program will be run +for each screen. (All screens are blanked and unblanked simultaniously.) + +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 +Normally you won't 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 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...) +.TP 8 +.B sgiSaverExtension\fP (class \fBBoolean\fP) +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. + +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 not recommended. +.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 the following command line options. Except for +the \fI\-display\fP option, these command-line options are all +simply shorthand for the X resources described in +the \fIConfiguration\fP section, above. +.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; the \fIscreen\fP +argument (the ``default'' screen) says which screen should be used for +dialog boxes (the password window, \fIDemo Mode\fP, etc.) +.TP 8 +.B \-timeout \fIminutes\fP +Same as the \fItimeout\fP resource. +.TP 8 +.B \-cycle \fIminutes\fP +Same as the \fIcycle\fP resource. +.TP 8 +.B \-lock\-mode +Same as setting the \fIlock\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-lock\-mode +Same as setting the \fIlock\fP resource to \fIfalse\fP. +.TP 8 +.B \-lock\-timeout \fIminutes\fP +Same as the \fIlockTimeout\fP resource. +.TP 8 +.B \-visual \fIvisual\fP +Same as the \fIvisualID\fP resource. +.TP 8 +.B \-install +Same as setting the \fIinstallColormap\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-install +Same as setting the \fIinstallColormap\fP resource to \fIfalse\fP. +.TP 8 +.B \-verbose +Same as setting the \fIverbose\fP resource to \fItrue\fP. +.TP 8 +.B \-silent +Same as setting the \fIverbose\fP resource to \fIfalse\fP. +.TP 8 +.B \-timestamp +Same as setting the \fItimestamp\fP resource to \fItrue\fP. +.TP 8 +.B \-capture\-stderr +Same as setting the \fIcaptureStderr\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-capture\-stderr +Same as setting the \fIcaptureStderr\fP resource to \fIfalse\fP. +.TP 8 +.B \-splash +Same as setting the \fIsplash\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-splash +Same as setting the \fIsplash\fP resource to \fIfalse\fP. +.TP 8 +.B \-nice \fIinteger\fP +Same as the \fInice\fP resource. +.TP 8 +.B \-sgi\-extension +Same as setting the \fIsgiSaverExtension\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-sgi\-extension +Same as setting the \fIsgiSaverExtension\fP resource to \fIfalse\fP. +.TP 8 +.B \-mit\-extension +Same as setting the \fImitSaverExtension\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-mit\-extension +Same as setting the \fImitSaverExtension\fP resource to \fIfalse\fP. +.TP 8 +.B \-xidle\-extension +Same as setting the \fIxidleExtension\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-xidle\-extension +Same as setting the \fIxidleExtension\fP resource to \fIfalse\fP. +.TP 8 +.B \-proc\-interrupts +Same as setting the \fIprocInterrupts\fP resource to \fItrue\fP. +.TP 8 +.B \-no\-proc\-interrupts +Same as setting the \fIprocInterrupts\fP resource to \fIfalse\fP. +.TP 8 +.B \-xrm \fIresource-specification\fP +As with all other Xt programs, you can specify X resources on the command-line +using the \fI\-xrm\fP argument. Most of the interesting resources have +command-line equivalents, however. +.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 recieve. (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, 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. + +If your X server supports power management, then +.BR xset (1) +will accept a \fBdpms\fP option. So, if you wanted \fIxscreensaver\fP +to activate after 5 minutes, but you wanted your monitor to power down +after one hour (3600 seconds) you would do this: +.EX +xset dpms 3600 +.EE +See the man page for the +.BR xset (1) +program for details. (Note that power management requires both software +support in the X server, and hardware support in the monitor itself.) +.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 +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 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 +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 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 + +Other window managers are guaranteed to do things gratuitously differently. +.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 +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 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 +.B XView Clients +Apparently there are some problems with XView programs getting confused +and thinking that the screensaver window is the real root window even when +the screensaver is not active: ClientMessages intended for the window manager +are sent to the screensaver window instead. This could be solved by making +xscreensaver forward all unrecognised ClientMessages to the real root window, +but there may be other problems as well. If anyone has any insight on the +cause of this problem, please let me know. (XView is an X11 toolkit that +implements the (quite abominable) Sun OpenLook look-and-feel.) +.TP 8 +.B MIT Extension and Fading +The \fBMIT-SCREEN-SAVER\fP extension is junk. Don't use it. + +When using the \fBMIT-SCREEN-SAVER\fP extension in conjunction with +the \fBfade\fP option, you'll notice an unattractive flicker just before +the fade begins. This is because the server maps a black window just before +it tells the \fIxscreensaver\fP process to activate. The \fIxscreensaver\fP +process immediately unmaps that window, but this results in a flicker. I +haven't figured a way to get around this; it seems to be a fundamental +property of the (mis-) design of this server extension. + +It sure would be nice if someone would implement the \fBSGI SCREEN_SAVER\fP +extension in XFree86; it's dead simple, and works far better than the +overengineered and broken \fBMIT-SCREEN-SAVER\fP extension. +.TP 8 +.B SGI Power Saver +If you're running Irix 6.3, you might find that your monitor is powering down +after an hour or two even if you've told it not to. This is fixed by SGI +patches 2447 and 2537. + +If you're running Irix 6.5, this bug is back. I don't know a fix. +.TP 8 +.B MesaGL and Voodoo Cards +If you have a 3Dfx/Voodoo card, the default settings for xscreensaver will +run the GL-based graphics demos in such a way that they will not take +advantage of the 3D acceleration hardware. The solution is to change +the \fBprograms\fP entries for the GL hacks from this: +.EX + gears -root \\n\\ +.EE +to this: +.EX + MESA_GLX_FX=fullscreen gears \\n\\ +.EE +That is, make sure that \fB$MESA_GLX_FX\fP is set to \fIfullscreen\fP, and +don't tell the program to draw on the root window. This may seem strange, +but the setup used by Mesa and these kinds of cards \fIis\fP strange! + +For those who don't know, these cards work by sitting between your normal +video card and the monitor, and seizing control of the monitor when it's +time to do 3D. But this means that accelerated 3D only happens in full-screen +mode (you can't do it in a window, and you can't see the output of 3D and 2D +programs simultaniously), and that 3D will probably drive your monitor at a +lower resolution, as well. It's bizarre. + +If you find that GL programs only work properly when run as root, and not +as normal users, then the problem is that your \fI/dev/3dfx\fP file is not +configured properly. Check the Linux 3Dfx FAQ. +.TP 8 +.B Keyboard LEDs +If \fIprocInterrupts\fP is on (which is the default on Linux systems) and +you're using some program that toggles the state of your keyboard LEDs, +xscreensaver won't work right: turning those LEDs on or off causes a +keyboard interrupt, which xscreensaver will interpret as user activity. +So if you're using such a program, set the \fIprocInterrupts\fP resource +to False. +.TP 8 +.B Extensions +If you are not making use of one of the server extensions (\fBXIDLE\fP, +\fBSGI SCREEN_SAVER\fP, or \fBMIT-SCREEN-SAVER\fP), then it is possible, in +rare situations, for \fIxscreensaver\fP to interfere with event propagation +and make another X program malfunction. For this to occur, that other +application would need to \fInot\fP select \fBKeyPress\fP events on its +non-leaf windows within the first 30 seconds of their existence, but then +select for them later. In this case, that client \fImight\fP fail to receive +those events. This isn't very likely, since programs generally select a +constant set of events immediately after creating their windows and then +don't change them, but this is the reason that it's a good idea to install +and use one of the server extensions instead, to work around this shortcoming +in the X protocol. + +In all these years, I've not heard of even a single case of this happening, +but it is theoretically possible, so I'm mentioning it for completeness... +.TP 8 +.B Red Hot Lava +There need to be a lot more graphics hacks. In particular, there should be +a simulation of a Lavalite (tm). +.SH ENVIRONMENT +.PP +.TP 8 +.B DISPLAY +to get the default host and display number, and to inform the sub-programs +of the screen on which to draw. +.TP 8 +.B PATH +to find the sub-programs to run. +.TP 8 +.B HOME +for the directory in which to read and write the \fI.xscreensaver\fP file. +.TP 8 +.B XENVIRONMENT +to get the name of a resource file that overrides the global resources +stored in the RESOURCE_MANAGER property. +.SH UPGRADES +The latest version can always be found at +http://www.jwz.org/xscreensaver/ +.SH SEE ALSO +.BR X (1), +.BR xscreensaver\-demo (1), +.BR xscreensaver\-command (1), +.BR xdm (1), +.BR xset (1), +.BR Xsecurity (1), +.BR xauth (1), +.BR xhost (1). +.BR ant (1), +.BR atlantis (1), +.BR attraction (1), +.BR blitspin (1), +.BR bouboule (1), +.BR braid (1), +.BR bsod (1), +.BR bubble3d (1), +.BR bubbles (1), +.BR cage (1), +.BR compass (1), +.BR coral (1), +.BR critical (1), +.BR crystal (1), +.BR cynosure (1), +.BR decayscreen (1), +.BR deco (1), +.BR deluxe (1), +.BR demon (1), +.BR discrete (1), +.BR distort (1), +.BR drift (1), +.BR epicycle (1), +.BR fadeplot (1), +.BR flag (1), +.BR flame (1), +.BR flow (1), +.BR forest (1), +.BR galaxy (1), +.BR gears (1), +.BR glplanet (1), +.BR goop (1), +.BR grav (1), +.BR greynetic (1), +.BR halo (1), +.BR helix (1), +.BR hopalong (1), +.BR hypercube (1), +.BR ifs (1), +.BR imsmap (1), +.BR interference (1), +.BR jigsaw (1), +.BR julia (1), +.BR kaleidescope (1), +.BR kumppa (1), +.BR lament (1), +.BR laser (1), +.BR lightning (1), +.BR lisa (1), +.BR lissie (1), +.BR lmorph (1), +.BR loop (1), +.BR maze (1), +.BR moebius (1), +.BR moire (1), +.BR moire2 (1), +.BR morph3d (1), +.BR mountain (1), +.BR munch (1), +.BR noseguy (1), +.BR pedal (1), +.BR penetrate (1), +.BR penrose (1), +.BR petri (1), +.BR phosphor (1), +.BR pipes (1), +.BR pulsar (1), +.BR pyro (1), +.BR qix (1), +.BR rd-bomb (1), +.BR rocks (1), +.BR rorschach (1), +.BR rotor (1), +.BR rubik (1), +.BR sierpinski (1), +.BR slidescreen (1), +.BR slip (1), +.BR sonar (1), +.BR sphere (1), +.BR spiral (1), +.BR spotlight (1), +.BR sproingies (1), +.BR squiral (1), +.BR stairs (1), +.BR starfish (1), +.BR strange (1), +.BR superquadrics (1), +.BR swirl (1), +.BR t3d (1), +.BR triangle (1), +.BR truchet (1), +.BR vines (1), +.BR wander (1), +.BR worm (1), +.BR xflame (1), +.BR xjack (1), +.BR xlyap (1), +.BR xmatrix (1), +.BR xroger (1), +.BR bongo (1), +.BR ico (1), +.BR xaos (1), +.BR xbouncebits (1), +.BR xcthugha (1), +.BR xdaliclock (1), +.BR xfishtank (1), +.BR xmountains (1), +.BR xsplinefun (1), +.BR xswarm (1), +.BR xtacy (1), +.BR xv (1), +.BR xwave (1). +.SH COPYRIGHT +Copyright \(co 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999 +by Jamie Zawinski. Permission to use, copy, modify, distribute, and sell +this software and its documentation for any purpose is hereby granted without +fee, provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in supporting +documentation. No representations are made about the suitability of this +software for any purpose. It is provided "as is" without express or implied +warranty. +.SH AUTHOR +Jamie Zawinski . Written in late 1991; first posted +to comp.sources.x on 13-Aug-1992. + +Please let me know if you find any bugs or make any improvements. +.SH ACKNOWLEDGEMENTS +Thanks to the many people who have contributed graphics demos to the package. + +Thanks to David Wojtowicz for implementing \fIlockTimeout\fP. + +Thanks to Martin Kraemer for adding support for shadow passwords and +locking-disabled diagnostics. + +Thanks to Patrick Moreau for the VMS port. + +Thanks to Mark Bowyer for figuring out how to hook it up to CDE. + +Thanks to Nat Lanza for the Kerberos support. + +Thanks to Bill Nottingham for the initial PAM support. + +And thanks to Jon A. Christopher for implementing the Athena dialog +support, back in the days before Lesstif or Gtk were viable alternatives +to Motif.