 
PURPOSE
=======

Xautolock  monitors  console activity  under the X window system, and
fires  up  a  program  of your choice if  nothing  happens  during  a
user configurable  period of time.  You can use this to automatically
start up a screen locker in case you tend to forget to do so manually
before having a coffee break.

 
PLATFORMS
=========

Patchlevels 9 and 10 of xautolock have been verified on the following
platforms:

HP 9000/7xx              HP-UX 9.01 and HP-UX 9.05 / X11R5
Intel x86                Linux 1.0.9 / XFree 2.1.1 (Slackware 2.0.1)
                         Novell Unixware 1.1.2 / beta X11R5
                         FreeBSD 2.0
DECstation               Ultrix 4.3 and Ultrix 4.4 / X11R4 and X11R5
			 OSF/1 2.0
Sparc II                 SunOS 4.1.3 / X11R5

Other people have reported patchlevel 8 to work on:

Intel x86                Linux 0.99pl3 or later / XFree 1.3 or later
                         Novell Unixware 1.?.?
SPARCstation 2           Solaris 2.2 and Solaris 2.3 
HP 9000/7xx              HP-UX 8.07 and HP-UX 9.03
IBM RS/6000              AIX 3.2
IBM RT/PC                AOS 4.3
MIPS                     EP/IX 2.1   
Vax                      BSD 4.3
                         VMS
DECAlpha                 OpenVMS
Tektronix XD88/10        ?.?

Earlier  versions  also  ran  on  the  following machinery, but we no
longer have access to these, so testing it was a bit difficult :-):

DECstation 3100 to 5500  Ultrix 4.2 / X11R3
                         Ultrix 4.2a and Ultrix 4.3 / X11R4
Apollo 3000 -> 4500      DomainOS SR10 / X11R3 and X11R4
HP Apollo 9000/4xx       DomainOS 10.3.5 / X11R4
Sony News 1800           ?.? / X11R4
Sun 3/60                 SunOs ?.?.? / X11R3
Sparc II                 SunOS 4.1.2 / X11R4

 
HOW TO USE IT
=============
 
Just read the man page, it's really simple.

If you're on VMS, you should also check out the VMS.NOTES file.


HOW IT WORKS
============

If  xautolock  has been compiled to support Xidle,  it first tries to
find out  whether  the  X server  also  supports  Xidle.  If it does,
xautolock  will periodically call xidle to determine the elapsed time
since the last input event, and will then base its actions upon that.

In  the  absence  of  Xidle,  when  it  starts  executing,  xautolock
traverses the window tree, selects  SubstructureNotify on all windows
and adds each window to a temporary list.  About +- 30 seconds later,
it scans this list,  and now  asks for KeyPress events.  However,  it
takes  care  to  interfere  as  little  as  possible  with  the event
propagation  mechanism.  This is the reason for the delay between the
moment xautolock learns about a new window (and consequently asks for
SubstructureNotify  events)  and  the  moment  it  asks for  KeyPress
events. Whenever a new window is created by an application, a similar
process takes place.  In contradiction  to what many people  believe,
this scheme does not cause a noticeable overhead. 

In addition, xautolock periodically issues a  QueryPointer request in
order to  find out  whether  the pointer has moved  and implement the
"corners" feature as decribed in the man page.

If nothing happens within a user-specified period of time,  xautolock
will fire up a program  which is supposed  to lock the screen.  While
this program is running, xautolock itself remains on the look-out for
user interaction.


COMPILING XAUTOLOCK
===================

Xautolock  should  compile  straight  out of  the box.  Just  do  the
following:

 1. Edit the Imakefile to your likings.  The one thing to do in any
    case,  is to make sure to compile with the  Xidle  extension if
    you have it. Using Xidle is conceptually much cleaner.

 2. Type:

     xmkmf 
     make
     make install
     make clean 

 3. Have fun.

 
KNOWN BUGS
==========

Important notice:  the first two bugs listed here are only present in
case xautolock  has not been compiled  to support the xidle extension
or in case the X server being used does not support xidle.  They make 
up a good reason to get Xidle installed.

 1. If, when creating a window,  an application waits for more than
    30 seconds before calling selecting KeyPress events on non-leaf
    windows,   xautolock  may interfere with the event  propagation
    mechanism.  This  effect  is  theoretical  and  has never  been
    observed  in real life.  In order to  minimize  the risk  of it
    happening,  an extra delay of 10 seconds has been inserted into
    the xautolock initialisation sequence.  This was  done  because
    xautolock  is  most  likely  to  be started  automatically when
    a user logs in,  and that process can be rather  time-consuming
    on some platforms.

 2. Xautolock  can not properly handle  the secure keyboard mode of
    xterm, since  that  will prevent any other  process,  including
    xautolock,  from  noticing  the  keyboard  events  aimed at the
    xterm.  Consequently, xautolock sometimes will think that there
    is no keyboard activity while in reality there is.

 3. Xidle  mode has not been tested,  the problem being that  Xidle
    seems  to be rather hard  to run into.  At least,  we've  never
    actually been able to lay our hands on a server which had it.

 4. Under some configurations, xautolock fails to exit upon logout.
    This  problem can occur  (but does not always do so)  under the
    following combined circumstances:

     + Xautolock is started in background from within a .xinitrc.
     + Your are trusting your windowmanager to kill all X processes
       when quitting  (which, by the way, is not a good idea).  One
       well known  source of problems in this area consists of olwm
       and its look-alikes.
     + The .xinitrc contains a "wait"  statement to make it collect
       all background processes upon logout.

    The  simplest workround for this problem is to start  xautolock
    from within a subshell. I.e. use this:
    
      ( xautolock & )
    
 5. Xautolock  does not check  whether  the screen locker specified
    actually is available.

 6. The xautolock resources have a dummy resource classes.

If you can find others, please send e-mail to eyckmans@imec.be.


WARNING
=======

It looks like there is a bug in  the event management code of some  X
servers  (amongst  which  both  X11R4 and  X11R5 on older versions of 
SunOS). If you are using  patchlevel 7  of  xautolock,  it is best to
reset  the server before switching to  patchlevel 8 or later.  If you
fail  to do so,  an old  patchlevel 7  bug  may still show up.  (Some
keyboard  events were being hijacked  by  patchlevel 7  of  xautolock,
particularly when using tvtwm). 


COPYRIGHT
=========
 
Copyright 1990, 1992-1995 by S. De Troch and MCE.

Permission to use, copy, modify and distribute  this software and the
supporting documentation without fee is hereby granted, provided that

 1 : Both the above copyright notice and this permission notice
     appear in all copies of both the software and the supporting
     documentation.
 2 : No financial profit is made out of it.

 
DISCLAIMER
==========

THE AUTHORS  DISCLAIM  ALL WARRANTIES  WITH  REGARD TO THIS SOFTWARE,
INCLUDING  ALL IMPLIED WARRANTIES OF MERCHANTABILITY  AND FITNESS, IN
NO  EVENT  SHALL THEY   BE  LIABLE  FOR   ANY  SPECIAL,  INDIRECT  OR
CONSEQUENTIAL DAMAGES  OR ANY DAMAGES WHATSOEVER  RESULTING FROM LOSS
OF  USE,  DATA  OR  PROFITS,   WHETHER  IN  AN  ACTION  OF  CONTRACT,
NEGLIGENCE  OR   OTHER   TORTIOUS  ACTION,   ARISING  OUT  OF  OR  IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

 
AUTHORS
=======

Xautolock was conceived, written and performed by:

 Stefan De Troch             detroch@imec.be
 Michel Eyckmans (MCE)       eyckmans@imec.be


ACKNOWLEDGEMENTS
================

Special thanks to:

 Kris Croes                  croes@imec.be

The patchlevel 8 beta testers:

 Paul D. Smith               paul_smith@dg.com
 Brian                       brian@natinst.com

And the patchlevel 9 beta testers:

 Thanh Ma                    tma@encore.com
 Pierre Didierjean           cisitm@nyassa.cad.cea.fr

No thanks to a certain commercial X server provider who  volunteered
to beta test patchlevel 9 an many, *many* platforms  but didn't live
up to it.  Also our apologies to the candidate beta testers who were
not retained because of this candidate.

