

				    VEX
			    Protocol version 5.8
			   Alpha software release
			       April 20, 1990

This is it.  This distribution contains almost all of what we have.  This
README file contains an overview of the state of the software, the plans
for the future, and instructions for unpacking and installing this release.
There is a final, important note for parallax users.

OVERVIEW and PLANS
    What works?   From the protocol standpoint, the entire wire
    protocol (requests, replies, events and errors) are supported by
    the server and the library.  This implies that if you understand
    most of the protocol, you will know what this means.  If you don't
    you should read the protocol, found in extensions/vex/doc/protocol,
    and if you don't understand that, send me a mail message, and I'll
    send you a copy of two papers published at NCGA '90 and Unix Review
    Oct. 90.

    In addition to the library and server, there are two basic clients
    that work:  one that is the vex equivalent of xdpyinfo, called
    xvexinfo; and a basic video input client, called vwindow, that just
    puts video in a window.  Unfortunately for some, this client is
    designed to work with motif.  But because it is important as an
    example client I am in the process of porting it to the Athena
    widget set.  I should be done in a few days, and will send it on.
    In the mean time you can try to get your server running.

    We have some other clients that we did not include in the release.
    One is a hacked up version of Dan Applebaum's Galatea, but it is
    a pretty ugly hack (our fault).  Another is a pretty nice motif
    application for looking at maps.  And a third is a hack on xwd that
    essentially does a screen dump to a video output signal.   This
    latter will be cleaned up and sent along to you.

    What doesn't work?  Enough.  Although the implementation allows you
    to send all requests and receive all events, two requests don't do
    anything and as a result, some events are never sent.
    ChangeConnectivity and ChangeOwnership are the two incomplete
    requests, and VideoRequest and VideoConnectivityState are events
    that are never sent.  ChangeOwnership should not be a problem for a
    while because I don't expect to many people have two or more video
    applications that need to use the same resource.  I expect to have
    ChangeConnectivity complete within a few weeks.

    A few of the finer details of RenderVideo and CaptureGraphics are
    not implemented.  For example, a VideoViolation event doesn't get
    sent if the window moves to a new location and the video is
    on an illegal boundary.  You will also notice that there is no
    sample implementation for CaptureGraphics.  We have it working
    here at Tek, but the software is proprietary.  LYON-LAMB
    has a very nice video down-converter that turns an arbitrary window
    into a video signal: and one will arrive here early next week and a
    ddx interface for this product will be provided to you soon after.

    From the library side, the most important missing part is an
    interface for choosing appropriate parameters for RenderVideo and
    CaptureGraphics.  Certain hardware may allow many different scale
    factors for video input, or perhaps many constraints on the
    placement of video picture.  The protocol provides all the
    information you need to decide what the hardware is capable of, but
    there are 11 parameters to choose from and no good programmatical
    interface for choosing them.  There is a beginning in the
    convenience routines XVEXMatchRectangle() and XVEXMatchFraction().
    Fortunately, the protocol allows a client to be stupid and simply
    pick a number, and even if it is wrong, the ddx layer is supposed
    to come as close as possible (and then send you an event that says
    essentially, "close, but not quite").  The example video input
    client has a rather low IQ.

    Another big missing piece is device control.  While the sample
    server can and does control one device, the implementation is
    big and klunky.  What we plan is an interface such that you give
    the server an ascii file that describes the RS232 or network based
    devices that your server will control.  The file will tell the
    server how to connect to the device, and what to say for
    each operation.  I believe the design will support Galatea-type
    device servers as well as devices controlled directly.  It will
    allow you to connect or disconect devices at any time, and to
    change the "controls" offered for each device.

    The final piece missing is the document "VEX Devices and Controls".
    This will follow the device control software described above.

UNPACKING THE RELEASE
    You will receive several mail messages.  One contains this message,
    Others will comprise two uuencoded, compressed tar files.  Gather
    up these latter, remove the mail headers and any trailing blank
    lines, and construct the two files:

	files.tar.Z.uu
	diffs.tar.Z.uu

    Each of these you unpack with the commands

	uudecode < files.tar.Z.uu
	uncompress files.tar.Z
	uudecode < diffs.tar.Z.uu
	uncompress diffs.tar.Z

    Then merge these files with your current distribution.  Do this with
    the commands:

	cd /somewhere/X.V11R4/mit
	tar xf files.tar
	tar xf diffs.tar

    The new files are:

	config/tekplx.cf		    our configuration file
	server/ddx/tek/tekplx		    directory of our parallax server
	extensions/vex/lib		    vex xlib source
	extensions/vex/server/ddx/devices   has pioneer laser disk driver
	extensions/vex/server/ddx/plx	    vex-specific parallax source
	extensions/vex/server/dix	    dix layer vex source
	extensions/vex/server/include	    vex server-specific include files
	extensions/vex/include		    most of the vex include files
	extensions/vex/doc/protocol	    protocol document source
	extensions/vex/doc/vexlib	    vex xlib document source
	extensions/vex/doc/encoding	    encoding document source
	extensions/vex/doc/server	    server porting guide
	extensions/vex/clients/vwindow	    simple video input client
	extensions/vex/clients/xvexinfo	    vex equivalent of xdpyinfo

    The diffs are:

	Imakefile.diff			adds 'vex' to directories built
	config/Imake.tmpl.diff		adds tek-parallax configuration
	config/imakemdep.h.diff		adds -DTEKPLX to imake stuff
	config/tekplx.cf.diff		a needed change to a file listed above
	extensions/Imakefile.diff	adds vex directory
	server/ddx/mi/miinitext.c.diff	adds VexExtensionInit();
	server/include/servermd.h.diff	adds tek-parallax configuration
	server/Imakefile.diff		adds tek-parallax server

    After you have installed these files, make sure you are still in
    the directory /somewhere/X.V11R4/mit, and then run the shell script

	extensions/vex/patch-vex

    The patches are based on vanilla R4 and the installation has been tested
    for precisely that.  At this point, if you were to try to build our server,
    you would need to start with a

	make World

    You can do this with a little less overkill with the commands:

	make Makefile
	make -k Makefiles
	make -k includes		# rather important
	make -k depend
	make -k

    At this point, you are on your own.  I'll be sending out patches as
    appropriate.  Send bugs directly to me (toddb@crl.labs.tek.com)

PARALLAX NOTES

    If you have a parallax, you should note that the directory
    server/ddx/tek/tekplx is a heavily modified version of the
    parallax server that appeared on R3.  Much of the code has been
    reformatted and/or rewritten, and almost all notions of "video"
    capability have been removed: it has basic X server functionality.
    The video capabilities are found in vex/server/ddx/plx, where
    they belong.

    Since parallax licenses their "libplx" I/O library, I cannot
    distribute it.  I have not modified its interface, so it should run
    without change.  The kernel driver is completely different, but its
    interface to the library is not different either.  This all means
    that if you plan to start with my server, you must change the
    server/ddx/tek/tekplx/Imakefile so that the line

	INCLUDES = -I$(LIBSRC)/parallax/include

    points to where you have your own copy of parallax's library.


Good luck!!

internet: toddb@tekcrl.labs.tek.com                                 c--Q Q
US:       Todd Brunhoff; Systems Architecture and Imaging Lab;          `
          Tektronix, Inc.;  Box 500  MS 50-321, Beaverton OR 97077      -
Phone:    (503) 627-1121
