xlockmore4.02: the maintained version of xlock
see docs/Revisions for more version stuff
Primary site: ftp.x.org in /contrib/applications
Maintainer: David A. Bagley <bagleyd@bigfoot.com>
Alpha versions may be available at: http://megahertz.njit.edu/~bagleyd
Adapted from Patrick J. Naughton's original xlock,
  with lots of help from others.

Note to binary redistributers:
-----------------------------
  Probably should not distribute with any library requirements
  (except possibly XPM, unless you statically link them in)
  and with USE_BOMB since it might not run right if you do not know
  if your users will use xdm or not.  For example:
    configure --without-xpm --without-gl --without-dtsaver \
--without-rplay --without-nas --disable-bomb; make
  Also you may want a flag for your particular operating system (many
    different OS's are autodetected but Linux distributions are not), e.g.
    configure ... --enable-flagtype=debian --prefix=/usr/X11R6 ; make
  See the config or flag directory for more info.
  motif (and editres) are used to build xmlock and are not used in xlock.
  Please let me know if there are other concerns.


How to build?
-------------
  An ANSI C compiler is required for build.

  Check below to see if your machine is one mentioned that causes
  problems, otherwise it should be easy.

  There are 3 ways to build:

  configure:
    Relatively new so there is a good possiblity that it is not set up
    correctly on your system.

    "configure --help" to see options.

    configure ; make ; make install

    Really neat but slow sproingies and experimental modes.
    configure --enable-sproingies --enable-hackers ; make ; make install

  imake:
    Sometimes this is not setup correctly by the distributer ... i.e. not
    my fault.  You may want to do these quick edits to the Imakefile so you
    have more capabilities:

    Do you have XPM?    If so, uncomment "#define XpmLibrary".
    Do you have Motif?  If so, uncomment "#define XmLibrary".
    Do you have MESAGL? If so, uncomment "#define GLLibrary".
    Do you have CDE?    If so, uncomment "#define DtSaverLibrary".
    Do you have RPLAY?  If so, uncomment "#define RplayLibrary".
    Do you have NAS?    If so, uncomment "#define NasLibrary".

    Examine Imakefile for other optional capabilities.

    xmkmf ; make depend ; make ; make install
      or
    xmkmf ; make ; make install

  make.com:
    See VMS below.


Likely Problems
---------------
  xlock: user/passwd error -> this usually means you should get your
    administrator to setuid xlock to root or at least setgid xlock to
    shadow.  If you do not have a friendly administrator you can still
    set it up, see USE_XLOCKRC below.

  AIX (IBM RS6000)
    AIX's "make":
      AIX's "make" can not handle "+=" so if you use the Imakefile, you
      have to group all your DEFINES into one long line and use "="
      instead.  GNU's "make" solves this problem.
    AIX 3.1 and less:
      it SHOULD compile automatically with -DLESS_THAN_AIX3_2 using the
      Imakefile, since the passwd struct is not available.
    AIX 3.2 and greater:
      one must have setuid xlock to root if you want to use it
      without being root.
    AFS users:
      See Imakefile, grep on "AFS". 
    Some machines have an alternate password shadowing method, if someone  
      figures it out mail me the patch.

  Alpha-OSF/1 (Digital Equipment Corp)

    Enhanced security:
      Compile with -DOSF1_ENH_SEC see Imakefile
        chown auth.auth xlock
        chmod 2755 xlock
      Unfortunately the following is reportedly broken since xlockmore-2.10
      and needs a patch, I heard it produces the following at runtime.
Unaligned access pid=1767 <xlock> va=140489e24 pc=3ff807d9978 ra=3ff807d9880
type=ldq
Segmentation fault (core dumped)

  Apollo (HP)
    Shift-Control-Break is caught.  See HP.

  CDE (DT)
    (My heart bleeds for you.)
    Common Desktop Environment.  Go to the CDE DT CONFIG SECTION of the
      Imakefile and uncomment (should be autodetected if you use configure)
XCOMM #define DtSaverLibrary
    Then have CDE somehow run xlock with the -dtsaver option.  I am not
      sure what this does for you since I do not use it.  If anyone figures
      this out LET ME KNOW.

  DCE authentication (tested only on HP's)
    See Imakefile (xmkmf) or Makefile.in (configure).

  Digital Unix
    Reported that 3.2D (8bpp) password screen color map gets messed up
    sometimes when in random mode as it switches from one mode to another.
    
  ESIX
    Similar to Solaris2.x.  You will need a -DSVR4 to compile.
    chmod 440 /etc/shadow
    if you get libX11.so.xxx not found
      link with the static versions of the X libraries 
    chmod 2755 xlock

  FreeBSD
    One may have to setuid xlock to root (are there any objections?).
    Also see "XFree86" if applicable.

  GL
    So far I just assume the Mesa 3-D Graphics Library.  See below on
      availability.  Follow its instructions and then go to GL section
      of the Imakefile and uncomment (should be autodetected if you use
      configure)
XCOMM #define GLLibrary

  HP
    Shift-Control-Break is caught.  This uses a library Xhp11 that may
      not exist on some systems.  Comment out
        XHPDisableReset(dsp);
      and
        XHPEnableReset(dsp);
      in "xlock.c" if you do not have this library.
      May have to setuid xlock to root.
    The optimizer may break utils.c .
    HP's "make":
      HP's "make" can not handle "+=" so if you use the Imakefile, you
      have to group all your DEFINES into one long line and use "="
      instead.  GNU's "make" solves this problem.
    HP-UX with Secured Passwords:
      Compile with -DHPUX_SECURE_PASSWD and setuid xlock to root.
    HP-UX with Passwd Etc:
      Compile with -DHP_PASSWDETC .
      Link with -lrgy -lnck -lndbm .

  IRIX (SGI)
    Xsgi process does not die with autologout using 4Dwm.
        /usr/bin/X11/tellwm end_session >/dev/null 2>&1
      Kills all the users processes and returns to the login prompt
      This should be incorporated into xlock.  It is in logout.c as __SGI__
		  but I do not know if it works or what a good define for SGI is.
    The GL modes here probably do not work unless you have MESA GL.
      Help would be nice here, since I do not have a SGI.

  KERBEROS
    See Imakefile (xmkmf) or Makefile.in (configure).
    
  Linux (Intel 80386, 80486, & Pentium)
    If you are using elf _or_ shadow passwords:
      xlock should compile with -DHAVE_SHADOW
      this is already forced if you have elf so do not worry, it should
      work even if you do not have shadow passwording.
    If you are _not_ using elf and are using shadow passwords:
      (this old version of shadowing has a _MAJOR_ known security flaw)
      link with -lshadow -lgdbm
    Next if using shadow passwords:
      chown root.root xlock  (or root.shadow if it exists)
      chmod 4755 xlock
      (chmod 2755 xlock may be better if shadow has group read for root group)
      Also check that the following was done:
        Your /usr/X11R6/lib/X11/config/linux.cf should have
#define HasShadowPasswd         YES
          This would let the Imakefile work automatically for compile/link.
        chown root.root /etc/shadow   (or root.shadow if it exists)
        chmod 400 /etc/shadow
        (chmod 440 /etc/shadow may be better).
    So far, Slackware (a major Linux distribution) does NOT come with shadow
      passwords standard.  If you want to install shadow passwords (be
      careful, it can be tricky) it's on sunsite.unc.edu in
      /pub/Linux/system/Admin .
    Also see "XFree86" if applicable.

  Linux (Alpha)
    Change the order of XLIB and XPMLIB in the Imakefile so the XPMLIB
     comes first.  Intel stuff above probably applies as well.

  Rplay
    Audio package.  See below on availability.  Follow its instructions and
      then go to Imakefile and uncomment (should be autodetected if you use
      configure)
XCOMM #define RplayLibrary
      See config directory for example.  (Note: The example files are
      concerned with getting it working ... not security).

  Solaris2.x (Sun SPARC)
    Imake will compile with the -DHAVE_SHADOW switch.
    With GNU's gcc, get rid of the "-ansi" during compilation, also
      one may want to get rid of the -xF references in
      /usr/openwin/lib/config/sun.cf and Imake.tmpl if you get a
      cc: language F not recognized
    Solaris2.x NIS+ or not using NIS (/etc/passwd):
      Setuid xlock to root to get encrypted password (chmod u+s xlock).
        For some reason when this is done ld can not find -lXext .
        See EXTENSIONLIB commented out in the Imakefile.
      If you use netgroup make sure there is a return at the end of file.

  SunOS4.1.x (Sun Sparc & 680x0)
    Put in a link from /usr/include/X11 to your ${OPENWINHOME}/include/X11
      to use the Imakefile (xmkmf) or use Makefile.in (configure) provided.
    gcc -Wall gives a lot of silly warnings, its safe to disregard them.
 
  Ultrix (DEC)
    I heard that the logout button just kills xlock.
    USE_XLOCKRC feature unimplemented, but may not be hard to do.
    xlock must be either setuid root or setgid authread to validate the
      password on an Ultrix system.

  VMS (DEC)
    You may want to set a few things like vroot, bomb, and sound (see audio
      below) at the top of the file.
    All you should need to do to build the executable is:
        $ @make
    To run xlock a symbol needs to be defined, for example:
        XLOCK:==$H268SYSEXE:XLOCK
      where H268SYSEXE is a logical name pointing to the directory where
      XLOCK.EXE resides. The '$' after == means this is a foreign command
      and VMS makes the command line available to the program.
    If the link bombs out I recommend trying it again like the following:
        $ @make clean
        $ @make
    -allowroot only works if you have SYSPRV enabled which is a bit limiting.
      Unless one uses the privileged install by a system manager.  To do
      this, the following command needs to be executed at system startup
      (i.e. included in systartup_vms.com):
         INSTALL ADD {dev}:[{dir}]XLOCK.EXE/PRIV=(SYSPRV)
      where {dev}:[{dir}] is the full path of the executable.
    The XLock file normally in /usr/lib/X11/app-defaults needs to be in the
      directory DECW$SYSTEM_DEFAULTS on VMS systems and be called
      'DECW$XLOCK.DAT'.
    USE_XLOCKRC, USE_AUTO_LOGOUT, USE_LOGOUT_BUTTON, & USE_MULTIPLE_ROOT
      features are not implemented.
    To use audio:
      Set "sound" to be 1 in the make.com file.  Only available on the Alpha.
      To get it work on a VAX some editing of the make.com is needed
        (scan for USE_VMSPLAY)
      The default sound files are hard coded to be in the current directory
        see line 128 or so of the resource.c file but can be overruled from
        the command line or the resourcefile decw$xlock.dat.
      Sounds did not work for me on the VAX.
      It should work OK on an AXP. (Due to a bug in the SO driver on some
        models running VMS7.0, sounds are only available on the headset).
    To use new event loop:
       For VMS7.0 and higher : new event loop is used by default.
         You do not need to install extra software.
       For VMS6.2 or lower :
         You need some UNIX utilities installed (XVMSUTILS).  See where to get
         it below.
         Look at the make.com and xvmsutil stuff.

  XFree86
    Control-Alt-Backspace will defeat locking mechanism and return your
      console back unless you put "DontZap" in your XF86Config file.
      (In X11R5, that would be a "dontzap" in your Xconfig file).
    Control-Alt-F1 (among others) will defeat locking mechanism with
      virtual terminals. This is not too good, right?  If you are using
      Linux, try vlock on tsx-11.mit.edu in /pub/linux/sources/usr.bin .
      The current XFree86 (as far as I know) does not have a server
      extension for catching or disabling VT switching.
    Here is a work around, put this line in /etc/profile:
        alias x='(startx >/dev/null &);clear;logout'
      then use 'x' instead of 'startx' (with no other active VT's).

  XPM
    Full color pixmap package.  See below on availability.  Follow its
      instructions and then go to Imakefile and uncomment (should be
      autodetected if you use configure)
XCOMM #define XpmLibrary

  X-Terminal
    (My heart bleeds for you.)
    To get xlock to run, run with -remote option or set XLock.remote on
    in XLock.ad .  You might have to use -allowaccess as well.
        
  tvtwm
    One used to get following error when running xlock (+nolock) with
      tvtwm.
    X Error of failed request:  BadWindow (invalid Window parameter)
    What happens is that RootWindow(dsp, screen) fails when tvtwm is
      running.  There is a kludge fix, but multiscreens will not work
      right with tvtwm and xlock. (grep on TVTWM in xlock.c).
    Another option, don't compile with -DUSE_VROOT .  If you debug it
      mail ME -OR- both the author of tvtwm and ME the patch. 
    StickyAbove problems:
      Windows in a tvtwm that have "StickyAbove" set to true are still
      visible when xlock (+inroot) is running. If this bothers you,
      don't compile with -DUSE_VROOT .  Is it possible to have xlock
      set "StickyAbove" to true as well? 

  fvwm
    -install does not install colormaps.  fvwm will not allow an
    application to install its own colormap.  You could always edit the
    source if you have it, (fvwm-1.24r)colormaps.c, where it says 
 if(ReInstall)
   {
     XInstallColormap(dpy,last_cmap);
   }
    make sure this does not happen.

  swirl mode
    Use with -install to see colormap change.
    See "fvwm" if applicable.
    "swirl" cycles its colors, except black and white.
    This is easily seen when on a color monitor one enters:
       ./xlock -mode swirl -inwindow -install
    now move the mouse in the window.
    If you find this annoying compile swirl.c with -DFORCEFIXEDCOLORS.
    I hear it LOCKS UP on i386BsdArchitecture and tvtwm.
    With twm (and fvwm see above) the colormap does not change.


Personal Use
------------
  You may want to compile with USE_XLOCKRC .  xlock will then prompt
  you the first time you use it for a password.  It is then encrypted
  and stored in your $HOME/.xlockrc file.  This is also good for
  users who have an unrecognized shadow password environment.  See
  Imakefile (xmkmf) or Makefile.in (configure) for an example.  Please
  note that it may be rude to use xlock in a lab environment.

Lab Environment
---------------
  The auto logout feature, when enabled, will log out a user after
  30 minutes (by default).  The timeout can be changed or disabled
  with a command-line option (or x resource -- this is allowed because
  the logout button can always be used; see below).  The time
  remaining before auto-logout is displayed on the password entry
  screen.
 
  The logout button, when enabled, is a button that appears on the
  password entry screen after 5 minutes (configurable at
  compile-time) that, when clicked, logs out the user.  The rationale
  for this thing is that in a lab environment, we wanted a way for
  users to be able to reliably lock their display for short periods
  of time, but still be allowed to have the display locked for longer
  than that if the lab isn't busy.  If the lab IS busy, and there is
  a need for workstations, the logout button can be used to logout
  someone who's been gone for more than 5 minutes.
 
  Of course, the auto-logout and the logout button are
  enabled/disabled by compile-time defines.  All these are OFF by
  default.  One can also force use these features with a local policy
  of exemptions (e.g. username or group). See the Imakefile (xmkmf) or
  Makefile.in (configure) file for an example.  Edit your /etc/xlock.staff
  file to reflect your policy.  If using xdm, you may just want to use
  -DCLOSEDOWN_LOGOUT (or -DSESSION_LOGOUT <- old way) in conjuction
  with -DUSE_AUTO_LOGOUT or -DUSE_LOGOUT_BUTTON.  That way all
  backgrounded processes owned by a user do not have to be killed.

  Don't PANIC, the auto-logout and the logout button will not run if
  you are root.  Otherwise, it will kill all of root's processes, not
  a good idea.  As long as you do not lock the screen (using -nolock,
  -inwindow, or -inroot) the policy of xlock users does not go into
  affect.


xlock still does not work:  :-(
-------------------------------
  If all that does not work you may need to adjust xlock.h, utils.c,
  xlock.c, and resource.c since these files are highly implementation
  dependent.  If you have to make this kind of change to get it working,
  let me know.

  You can try compiling with -g and running it with -debug and your
  favorite debugger, so xlock will run in a more friendly way (i.e. it
  does not lock the screen).  There are also may be compile time switches
  that could be turned on with -DDEBUG depending on what is not working
  correctly.  Be aware one mode, puzzle uses XGetImage and this sometimes
  bombs out with a BadMatch (invalid parameter attributes) if moved out of
  view, this should be fixed but it is not a problem except with -inwindow
  or -debug.

  Here is a simple recipe:
    Make sure the 12th line in the Imakefile is a comment
      (This is because the debug library for xpm is not usually installed)
XCOMM #define XpmLibrary
    xmkmf  <or configure --without-xpm>
    edit Makefile  on the line with CC = gcc or or CC = cc change to
               CC = gcc -g -DDEBUG
    make depend <but not if using configure>
    make
    gdb xlock
    run -debug <other xlock options you want here>
    bt  <-After it bombs out try backtrace
    print <relevant variables>
      (you may have to use "up" to take you to xlockmore code)>
    Mail me the results.

  If xlock crashes for you when in random mode... try this and mail
    me the results.  (If it runs for a long time partial result will do
    (gut the middle part)).
  xlock -mode random -modelist all-puzzle +install -debug -verbose
    -modelist all-puzzle: puzzle does not like to be moved off screen. 
    -debug: so it does not lock the screen.
    -verbose: for maximum verbosity.
    +install: so it does not keep changing the colormap


Other things to try: (if you got it working :-) )
-------------------------------------------------

  You may want to compile xlock.c using -DUSE_MOUSE_MOTION, then xlock will
  respond to (you guessed it) the motion of the mouse.  This is not
  recommended if you are using a virtual desktop; a default root window
  that may be larger than the physical displayed resolution on your screen.

  If you need to have a window up all the time, even over xlock, you
  need to comment out
                s[0] = '\0';
                return 1;
  in xlock.c after "case VisibilityNotify:".  The window must be able to
  pop itself to the front whenever it gets a visibility event.  Any
  problems here?

  You may want to change the 1st line of XLock.ad "random" to "blank",
  "life", or whatever your favorite is and copy it to
  /usr/lib/X11/app-defaults or $HOME (or wherever your application
  defaults files are) and rename to XLock .

  You may want some of the modes never to come up in random.  This is
  already hard coded blank.  See xlock man page on "modelist".  In
  mode.c you can hard code others by just putting the stuff that you do
  not like in the LockProcs to the end of the static array and in
  random.c increase NUMSPECIAL by the number of new screens that you do
  not want displayed.

  You may want to move xlock into /usr/bin/X11 (or wherever your X
  binaries are). You may also want to move xlock.man to
  /usr/man/man1/xlock.1 .

  If you want to remove some unwanted modes just edit "mode.h" and
  "mode.c" grep the for the unwanted modes.  You might want to edit
  the man page and your favorite make file as well.

  I am always looking to improve life, life3d, and life1d.  If anyone
  knows any new collections (I have lifep.zip (May 94) and xlife 3.0)
  let me know.  If you would like further information let me know.
  life1d and life3d has compile-time options that you may want to
  check out.  Also ant needs new breeds of interesting ants.
  I would like to add a compile time option to allow the exploration of
  certain modes using run time options of certain modes (life, life1d,
  life3d, & ant).  This should be a compile time since it may increase
  the executable size needlessly for normal use.

  Still like xscreensaver better?  (Obscenities omitted ;) ) Try
  setting your apps-defaults file for xscreensaver like:
*programs:      xlock -nolock +grabmouse -mode random
  or if you want to hard code it in, study docs/xlock2xscreensaver.
  You can mail me updates to it, but don't expect me to help you ;) .

  If you want to hack a new mode check out docs/HACKERS.GUIDE.  Then
  when working, just mail it to me, grep on Maintainer for address.


Other related stuff (all not maintained by me, except the last one):
--------------------------------------------------------------------
  NAME
   LOCATION (last seen at)
   DESCRIPTION
 =============
  xscreensaver
    ftp://ftp.x.org:/contrib/applications
    My competition.  A better design, though not as well maintained IMHO ;).
      Currently needs Motif to lock the screen.  Uses independent programs
      to lock the screen.
  xautolock (runs xlock after a idle time)
    ftp://ftp.x.org:/contrib/applications
  fortune
    ftp://igor.girton.cam.ac.uk//pub/funny/cookie.tgz 
    ftp://ftp.uu.net/systems/unix/BSD/games/fortune
    ftp://ftp.sterling.com/usenet/alt.sources/index (grep for cookie)
    Please note that my format is slightly different.  The number at the
      top of the file should match `grep -c "^%%$" fortune.dat`
  Lesstif
    ftp:/ftp.hungry.com//pub/hungry/lesstif/lesstif-current.tar.gz
    Lesstif Library (just like Motif)
  MesaGL
    ftp:/iris.ssec.wisc.edu//pub/Mesa
    Mesa 3-D Graphics Library (like GL) Mesa-2.2 or greater required
    2.1 or below may leak.
  XPM
    ftp:/ftp.x.org//contrib/libraries
    color pixmaps
  XPM/VMS
    use the one above or xlock may bomb out,
    compile with cc/standard=vaxc/define=(need_strcasecmp,need_strdup)
      except when using XVMSUTILS.
  NAS (audio package)
    ftp:/ftp.x.org//contrib/audio/nas
  rplay (audio package)
    ftp:/ftp.x.org//contrib/audio/rplay
  audio/VMS
    http://axp616.gsi.de:8080/www/vms/mzsw.html
  UNIX/VMS
    Unix-like routines XVMSUTILS can be found at
      http://axp616.gsi.de:8080/www/vms/mzsw.html


Some open problems:  (Suggestions for this would be nice)
---------------------------------------------------------

  0. First mode is never release in random mode.  The error can be seen
   with -debug.  The error may be in mode.c .  Its kind of confusing.

  1. It would be nice to have an option -idletime time.  Where xlock would
   run after a certain idle time.  (Here xautolock may help you, see
   above).

  2. All modes that use MI_PAUSE (eg. life1d, lightning, maze, nose,
   penrose, triangle) get mouse movement events in the little password
   window.  Also on multiheaded machines MI_PAUSE on one screen affects
   both screens.

	3. image and puzzle using xpm occasionally have the wrong colormap
   installed.

  4. -inwindow not correct for multiscreens, there should only be one
   window.

  5. raster files when loaded with -install (for puzzle and image) do not
   preserve foreground, background, or white colors.

  6. -fg -bg colors are not preserved when color map is installed.  This
   is easily noticed with -fg red -bg green when running the tube mode in
   the password window.   This is solved in swirl somehow.

  7. GL modes have a white background on monochromes and -mono does not
   work for GL and XPM.

  8. Options within a mode can not be duplicated in other modes.  Temporary
   solution is to have xlock modes like "-neighbor" that only a few of the
   modes use.

  Not all resources are listed in "xlock -resources", e.g. nolock.

  Add a UNIX man to VMS hlp converter.

  Various modes need better refresh capability.

  ball: can it be updated to use a pixmap instead of a slow circle fill?

  braid: should be made so that it can be interrupted quicker.

  bounce:
    sometimes a ball does not roll off another ball.
    momentum seems to be created.

  ico:
    should have all the features of the original.
    need the 3 dodecahedron stars and the icosahedron star.

  flag:
    should have a runtime option for the string displayed and should use
      the mfont info to generate fonts.
    should not always be at the same starting point.

  kaleid: needs to be triangular.

  life3d: draws invisible cubes when it does not have to.  The original
     MS DOS code weeded this out, but it did not seem to port to X.

  marquee:
    "-messagefile filename" truncates a large file.
    "-message string" does not handle Control-H correctly.

  mountain: -size # for mountain should do something.

  nose: should handle Control-H better for underlining and accents.

  slip:
    should be less jarring
    get rid of single color blotch.
    should be made so that it can be interrupted quicker.

  swirl: does not swirl on 16/24 bit per pixel screens but does on 8.
    Is this fixed?

  wire:  it needs a better circuit generator.

  New lockscreens suggestions (some may be very hard :) ):
		"dead" a Grateful Dead mode with dancing bears/skeletons/turtles.
    "graph" a random planar graph drawn ... filled in by a 5 (or 4 :) )
      coloring algorithm.
    "invert" a demonstration of turning a sphere inside out without creating
      any kinks (two surfaces can occupy the same space at the same time).
      Randomize the viewing angle.
    "minimal" a random minimal surface generator.
    "bubble" lockscreen, maybe something like 2 circles one bigger than
      the other offset and on top of each other but offset to upper right.
    Need a small 3D engine for wire, hidden surface removal, shading, ....

  I REALLY hate to turn down contributions...  some reasons for not making
   it into the main directory...
    Did not black out the screen when they start.  I do not like people
     to see what I am doing. :^|
    Did not work in the little window or buggy.
    Is too similar mode to a mode that already exists.
    Many people complained about the mode (exception if I wrote it. :) ).
    Just not enough randomness or is not interesting enough.
    No multiscreen support.
   But I labor over them (in a haphazard fashion) and they usually are
    released eventually.


Operation: (Blurb taken from Darren Senn's xlock)
------------------------------------------------- 

  Under X, run xlock.  The screen will clear, and some pretty animated
  picture (exactly which depends on which module is active) will appear
  on the screen.  If you hit a key, then the screen will clear, and
  (unless you've changed the application defaults file that I packaged
  with this) you'll get a black screen with some graphics in the top
  center.  These graphics consist of a reduced size image of the module
  you were viewing, the name of the user who executed xlock, and
  password prompt field, and some short instructions.
 
  At this point, you can either click on the graphic to return to xlock,
  or you can type a password.  If the password is verifiable as the
  root password, or the password of the user listed above, then xlock
  will terminate.  THIS IS THE ONLY WAY TO STOP XLOCK WITHOUT SHUTTING
  DOWN THE X SERVER.  That's what makes it a lock.

 
Resources: (Also taken from Darren Senn's xlock)
------------------------------------------------
 
  There are two sets of resources for XLock.  The first set are (what I
  call) global XLock resources, while the second set consists of
  module-specific resources.  I'll get more into modules a little further
  below.
 
  The global resources are:
        XLock.mode: This sets the module.  More about this later.
        XLock.font: This is the font used on the password entry screen.
        XLock.background: The background color for the password entry screen.
        XLock.foreground: The foreground color for the password entry screen.
        XLock.username: The label for the field indicating the user name.
        XLock.password: The label for the password prompt.
        XLock.info: The "short instructions" to print.
        XLock.validate: A message to display while checking the password
        XLock.invalid: A message to display if the password is incorrect
        XLock.nice: How much XLock should nice itself.
        XLock.timeout: How long to wait idle at the password prompt.
        XLock.timeelapsed: Message to see how long lock running (yes or no)
        XLock.mono: Monochrome mode (yes or no)
        XLock.nolock: disable the lock mechanism (yes or no)
        XLock.remote: allow remote locking (meaningless under linux)
        XLock.allowroot: allow the root password to unlock (yes or no)
        XLock.enablesaver: allow the system screensaver to work (yes or no)
        XLock.allowaccess: allow other clients to connect while active
        XLock.echokeys: Echo "?" for each password keypress (yes or no)
        XLock.usefirst: Ignore the first character typed (yes or no)
        XLock.verbose: Verbose mode. (yes or no)
        XLock.inwindow: allow the xlock to run in a window (yes or no)
        XLock.inroot: allow the xlock to run in the root window (yes or no)
        XLock.grabmouse: Grab the keyboard and mouse (yes or no)
 
  XLock has a number of modules which it can display.  (See the man page
  for a complete list).  It turns out that each module is characterized
  by a number of initializations, separated by a number of "draws".
  Each module has the following resources defined:

        XLock.<module>.delay: How long to wait between draws (usec)
        XLock.<module>.batchcount: May mean various things (see man page).
        XLock.<module>.cycles: Controls the timeout of screen (see man page).
        XLock.<module>.size: Controls size of objects on screen (see man page).
        XLock.<module>.saturation: Saturation (as in HSV) of colors to use.


Acknowledgments:
----------------

  I did not write the original algorithms in any of the lock screens
  (except wator, bug, life1d, demon, ant, and daisy), although I did
  convert many of the new ones to run with xlock.  I tried to follow
  the original style of Patrick Naughton.  Updates are made at
  ftp.x.org in directory /contrib/applications.  Many of the additions
  were "borrowed" from xscreensaver (Jamie Zawinski <jwz@netscape.com>).
  Some of the others were "borrowed" from old demos from Sun.  Many more
  are contributions.

  I will consider putting new ones in if (1) they are more or less public
  domain (i.e. BSD, sorry no GNU copyrights), (2) they are neat (I am
  biased towards mathematically based programs (especially the Computer
  Recreations of Scientific American)), and (3) I have the time.

  Also many thanks to the people that helped me with the main program
  itself mentioned in "Revisions", especially Jouk Jansen, Tom Schmidt,
  David Hansen, Ron Hitchens, and Heath A. Kehoe.
