Index of /pub/X/opengroup/R5contrib/vex
Name Last modified Size Description
Parent Directory -
x92.slides.tar.Z 1992-01-06 07:00 1.5M
mvex-r1.tar.Z 1991-09-30 08:00 444K
mvex-install 1991-09-30 08:00 4.6K
README 1991-09-30 08:00 7.4K
MVEX.doc.6.2.tar.Z 1991-09-30 08:00 78K
vex-papers.tar.Z 1991-05-06 08:00 270K
DCandC.doc.tar.Z 1991-05-06 08:00 106K
MVEX
Protocol version 6.2
VEXlib version 1.12
First software release
Sept 26, 1991
This distribution contains MVEX, and although there exists
more source code, it is largely Tek-specific or proprietary; this
should get you up and running. This README file contains an overview
of the state of the software, and instructions for unpacking,
installing and building this release.
WHAT DOES MVEX EXPRESS?
video input
taking a video stream *into* the workstation and
putting it in a window or pixmap
video output
producing a video stream that comes *out* of a window
or pixmap on the workstation
hue, brightness, contrast and saturation
if available on the hardware, these can be adjusted.
placement, scaling, frame rate, clipping, and overlap limitations
if the client is interested, the detail of the limitations
is available without round trip queries to the server;
if not, they can be ignored.
ports
for each video input and output, a set of atoms is provided,
one for each video port (for example, there may be an RGB port
and an S-VHS port).
ownership
A video manager can be implemented that can be the arbiter for
the video input and output resources.
WHAT'S NEW?
This protocol is not greatly different than MVEX 6.0 that I had posted
in January of this year. A few minor changes:
- the RenderVideo request now takes a gc so that you can specify
a clip mask.
- the override event gained some new bits so that you could
tell what has happened.
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/mvex/doc/protocol/.
To support the protocol, there is the mvex library and a set of
code for the server which implements the protocol extension. The
extension supports video input in the form of a RasterOps SparcCard
TC/PIP; it supports video output (although we only have proprietary
hardware and software for this).
In addition to the library and server, there are eight clients that
work (that I can give you): one that is the mvex equivalent of
xdpyinfo, called mvexinfo; the others are the seven test clients
that Dave Carver wrote for the Xv extension, so that programmers
could compare the two extension.
This release contains the patches to run under either X11r4 or X11r5.
Both are tested and run well. In particular, the server patches for
R4 include changes for ClipNotify() so that the video can be adjusted
as windows are moved. Also included are patches to the cfb code to
support 24-bit color. These were originally derived from Takahashi's
postings around the end of 1990, but now work under both r4 and r5.
Porting to new hardware should be fairly simple because nearly all of
the ddx functionality has been generalized and is available in the
mi directory. For example, complete clipping code is available
to maintain an enable plane.
WHAT DOESN'T WORK?
Nothing that I know of. Since being reduced from the original VEX
protocol, it has been much simpler to implement.
UNPACKING THE RELEASE
This release should be very simple to install. A fairly fool-proof
installation script will ask you questions, unpack, install and
patch everything. Obtain the release with ftp from
export.lcs.mit.edu (18.24.0.12) in
~ftp/contrib/vex/mvex-r1.tar.Z
~ftp/contrib/vex/mvex-install
It doesn't matter where you put it, except that install-mvex and
mvex-r1.tar.Z need to be together. After that, simply run the script:
sh install-mvex
It will ask questions and try to do everything but compile.
The files and directories are:
server/ddx/rasterops directory of our rasterops server
extensions/mvex/lib mvex lib source
extensions/mvex/server/ddx/mi machine independent layer
extensions/mvex/server/dix dix layer mvex source
extensions/mvex/server/include mvex server-specific include files
extensions/mvex/include most of the mvex include files
extensions/mvex/doc/protocol protocol document source
extensions/mvex/doc/lib mvex lib document source
extensions/mvex/doc/encoding encoding document source
extensions/mvex/clients/mvexinfo mvex equivalent of xdpyinfo
extensions/mvex/clients/test seven test clients
The diffs are different for r4 and r5, but they accomplish the same
thing:
config/sun.cf adds mvex and rasterops
extensions/Imakefile adds mvex to the directories built
extensions/server/Imakefile adds ../mvex to the directories built
server/Imakefile adds rasterops and mvex
server/ddx/cfb/* 24-bit color support
server/ddx/mi/miinitext.c adds MvexExtensionInit();
server/ddx/mi/mivaltree.c ClipNotify() mods (r4 only)
server/ddx/sun/* rasterops mods
server/dix/dispatch.c changes CreatePixmap and CreateColormap
server/dix/window.c changes CreateWindow, and ClipNotify()
server/include/scrnintstr.h ClipNotify() mods (r4 only)
The files are diffs based on R4 and R5, so they should patch in
very easily. Hopefully, the files provide enough context to
discern the intent in case there are problems.
For R4, the changes for ClipNotify marked above should be pretty
safe except for server/ddx/mi/mivaltree.c. The same spirit of
changes have been adopted into R5. The are necessary, otherwise
the lowest layer ddx cannot be notified when the clip changes (and
your RenderVideo will continue blasting bits where it shouldn't).
BUILDING THE RELEASE
Again, the patches are based on vanilla R4 and vanilla R5 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
If you have already built an X tree, you can do this with a
little less overkill with the commands:
make Makefile
make -k Makefiles SUBDIRS="extensions server"
make -k includes # very, very important
make -k depend
make -k
There is a little hocus-pocus in the way that makefiles are
generated, such that you should *not* use xmkmf to generate
the Makefile in extensions/mvex/include or any Makefile leading
to it, otherwise the 'make includes' pass will create include
files that point to the wrong place.
At this point, you are on your own (unless you have a Sun SparcStation)
with a RasterOps board. I'll be sending out patches as
appropriate. Send bugs directly to me (toddb@sail.labs.tek.com)
RASTEROPS NOTES
You must be running the 3.1 version of the driver and compile the
server against the 3.1 version of cg8reg.h. These are provided
for you in the distribution in
extensions/mvex/server/ddx/rasterops/3.1-driver. In that directory
are four files. They are placed as follows:
cg8reg.h /usr/include/sbusdev
sparc_card_tc /etc/modules
sparc_card_tc.o /etc/modules
sparc_card_tc.script /etc/modules
After installing these, reboot and you can run the server.
Good luck!!
internet: toddb@sail.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