xlockmore: the UNofficial version of xlock, see Revisions for version #
Primary site: ftp.x.org in /contrib/applications
Maintainer: David A. Bagley <bagleyd@source.asset.com>
Adapted from Patrick J. Naughton's original (and official) xlock.

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

    If your using X11R6 then:
        xmkmf
	make depend
        make
	./xlock -mode spline

    If your using X11R5 then:
        xmkmf
        make
	./xlock -mode spline

    If your using X11R4 then:
        mv Imakefile Imakefile.r5
        sed 's/^XCOMM/\/\*\*\/#/' > Imakefile < Imakefile.r5
        xmkmf
        make
        ./xlock -mode spline
 
    Note: if you don't have 'xmkmf' or the "Makefile" it generates
    doesn't work well, edit Makefile.std for appropriate settings for
    XINCLUDEPATH and XLIBPATH, then try:
	make -f Makefile.std
        ./xlock -mode spline


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.  See recommendation for your OS.

  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

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

  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?).

  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.
    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)
    No problem.  :)

  Linux (Intel 80386, 80486, & Pentium)
    If you are using shadow passwords make sure you:
        compile with -DHAS_SHADOW
        link with -lshadow -lgdbm
        chown root.root xlock  (or root.shadow if it exists)
        chmod 4755 xlock
    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 600 /etc/shadow
    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.

  Solaris2.x (Sun SPARC)
    Imake will compile with the -DSOLARIS_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
    Solaris as shipped may not have a correct OSMinorVersion in
      /usr/openwin/lib/config/sun.cf, compare with `uname -a`.
      If it is correct then
      Solaris2.2 and less:
        compile with usleep provided
        link with -lnsl -lposix4
      Solaris2.3 and greater:
        compile with HAS_NANOSLEEP
        link with -lposix4 -lthread
    Solaris2.x NIS+ or using no NIS (/etc/passwd):
      Setuid xlock to root to get encrypted password.

  SunOS4.1.x (Sun Sparc & 68000)
    No problem.  :)

  Ultrix (DEC)
    I heard that the logout button just kills xlock.
    USE_XLOCKRC feature unimplemented, but may not be hard to do.

  VMS (DEC)
    All you should need to do to build the executable is type @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.
    -allowroot only works if you have SYSPRV enabled which is a bit limiting.
    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, AUTO_LOGOUT, and LOGOUT_BUTTON features unimplemented.
     AXP:
       Commented sections in make.com need to be uncommented.
        
  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 your using
      Linux, try vlock on tsx-11.mit.edu in /pub/linux/sources/usr.bin .
      I hear that XFree86 3.2 when it comes out MAY have a server
      extension for catching or disabling VT switching.  Any ideas in the
      meanwhile?

  X-Terminal
    (My heart bleeds for you.)
    To get xlock to run, run with -remote option or set XLock.remote on
    in XLock.ad .
        
  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 (and swirl) 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
    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
    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.
    If swirl does not work, edit resource.c, grep on NUMSPECIAL (this is
    too bad because its generally viewed as the best one).
#define NUMSPECIAL 2 /* # of Special Screens */
    change to
#define NUMSPECIAL 3 /* # of Special Screens */
    and rebuild.  That way `xlock -mode random` will not bomb out as
    well.


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 or a Makefile 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 or a
  Makefile file for an example.  Edit your /etc/xlock.staff file to
  reflect your policy.

  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, usleep.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.


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

  You may want to compile xlock.c using -DMOUSEMOTION, then xlock will
  respond to (you guessed it) the motion of the mouse.  This is not
  recommended if your 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 "blank" to "random",
  "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 done for blank.  In resource.c just put the stuff that you do
  not like in the LockProcs to the end of the static array and 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 .

  You may want to try xautolock.  It runs xlock after a user defined
  idle time.  Its at ftp.x.org in /contrib/applications, but I do not
  maintain it.

  If your system has pixmaps, you may want to edit the Imakefile to
  have -mode image display a pixmap.  -mono has no affect here and
  I would like to randomly change the colors of the image but have
  not figured out how to do this.  If you are into American Football,
  there is a husker mode available from me or the author
  <Skip_Burrell@sterling.com> .  I guess the pixmaps (and bitmaps)
  can be easily transformed to your favorite.

  If you want to remove some unwanted modes just edit "mode.h" and grep
  the for the unwanted modes, 4 lines per mode.  You might want to edit
  the man page and the make file as well.

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

  A setterm command should blank out the screen to activate the
  powersaver, if one exists, in blank mode.

  I am always looking to improve life and life3d.  If anyone knows
  any new collections (I have lifep.zip (May 94) and xlife 3.0)
  let me know. 

  Some windows (like swirl) should be informed about window movement with
  -inroot and -inwindow.
 
  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).

  Penrose tiling lockscreen needed.  Anyone have an algorithm out there?

  In "bounce" sometimes a ball does not roll off another ball.

  "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.

  I want to be able to vary the colors of the pixmaps to randomly.  If
  anyone knows how to do this let me know.  Related minor bug, -mono
  does not work on a color monitor with pixmaps.


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>.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), 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@lucid.com).  At the time, I had trouble with getting it to compile
  so I moved the "interesting" algorithms to xlock.  Many of the others
  were "borrowed" from old demos from Sun.  My favorite of this new bunch
  is "spline", "borrowed" from Jef Poskanzer (jef@netcom.com ||
  jef@well.sf.ca.us).

  I will consider putting new ones in if (1) they are more or less public
  domain, (2) they are neat (I am biased towards mathematically based
  programs), and (3) I have the time.

  Also many thanks to the people that helped me with the main program
  itself mentioned in "Revisions".
