Message-Id: <9010122015.AA15755@zit.WV.TEK.COM>
To: dcc@ATHENA.MIT.EDU
Cc: vex@expo.lcs.mit.edu
Subject: Re: Device control and connectivity in VEX? 
In-Reply-To: Your message of Thu, 11 Oct 90 15:14:00 -0400.
             <9010111914.AA15165@BOOM> 
Reply-To: toddb%sail.labs.tek.com@relay.cs.net
From: toddb%sail.labs.tek.com@relay.cs.net
Date: Fri, 12 Oct 90 13:15:46 PDT
Sender: toddb%zit.wv.tek.com@relay.cs.net

Preface: VEX addresses four areas
  - video input
  - video output
  - device control
  - connectivity

While dave talked about device control, he is also talking
about connectivity (he does mention it once in passing)

>     o since device control represents a significant part of
>       the extension definition, removing it would greatly reduce the
>       complexity of the extension and lessen the load and complexity
>       of the X display server.

This is a non-argument.  For example, font services comprise a significant
part of the core X definition, and removing it too would greatly reduce
the complexity of X.  Certainly, fonts have proven very reasonable and
useful as an integral part of X, therefore while removing would reduce
complexity, it would also reduce flexibility.  Unless you prove that device
control/connectivity is not useful in VEX, this cannot be argued.  In other
words this is backwards.  It should be reasoned:

  "Device control/connectivity is not useful (for these reasons), therefore,
   removing it from the extensions would greatly reduce the complexity."

You have essentially stated the conclusion before proving the premise.

>     o video device control is not a function unique to a workstation
>       display.  Video devices may be used independently of X and
>       control of those devices should not require use of the X server.

Let me help you out here... what you are alluding to is that an API
that provides device control should be generic enough to be used
outside of X, and that because VEX defines an API, it cannot be used
outside of X.  I can disagree with this on two fronts:
  - There exists no universal interface for device control now, nor,
    I think, will it ever exist.  VEX simply provides one now.  If
    a universal interface existed today (like there exists a nearly universal
    tcp/ip interface, and a printf interface, and a postscript interface),
    then I'd use it.
  - There has been some talk here about exporting the VEX device control
    interface in such a way that it could be used as an
    API that is completely independent of VEX.  Few details about it
    are X-specific except for the display pointer, which could be
    genericised.

>     o even when the video devices are used in conjunction with an X
>       display, the advantages, above other alternatives, of
>       controlling those devices through the X server have not been
>       demonstrated.

You don't mention the alternatives, so I find it impossible to respond.

>     o synchronization of video devices and output to the display is a
>       problem.  This problem is not corrected by putting device
>       control in the X server.

You are very much incorrect.  Consider the following two scenarios:
  - I may want to synchronize the playing of my tape machine with the
    RenderVideo of a *particular* frame.
  - I may want to synchronize a wipe from one video sequence to another
    given two video sequences.
In both cases, if this is handled by a single agent, then it can be
dispatched by a single agent that may be designed to handle just
such a task (e.g. the DVI architecture).  If it is handled by two
software agents (a VEX server and a device control server), then
it is frequently impossible.

>       One partial solution is to make
>       transitions occur within a time small relative to human
>       perception.

This is fine for the people doing multi-media where only an impression
is required.  However, if I told my friends at NBC that I can't guarantee
frame accurate transitions, they wouldn't be my friends anymore.

>       Another solution is to make synchronization data
>       part of the video stream (i.e., preset video devices to watch
>       for a particular time code before activating).  Neither solution
>       requires device control to be contained within the X server.

[This is normally done with VITC (vertical interval timecodes) or
 logitudinal time codes.  The former is in the video stream, and the
 latter is in the analog audio track]

One of these video devices may be the video frame buffer, which is controlled
by the X server.  Your proposal would have two different software agents
controlling the digitization process: the VEX server when it does a
RenderVideo and this device control agent.  Again, syncronization will
be impossible.

>     o the above arguments also apply to managing connectivity between
>       video devices.  It may be that someone has a video switcher or
>       router as part of their display subsystem, but the hardware
>       partitioning in this case shouldn't be confused with X extension
>       architecture.

You don't say why.  You have reached a conclusion (hardware... shouldn't
be confused with... extension), but you don't give reasons.  This
is another non-argument.

>     o in general, as video moves into the digital domain the storage
>       and networking of video data will likely share common media with
>       more traditional computer data types and be managed with an
>       integrated set of services.  Moving video storage and networking
>       into the X server is a step in the wrong direction that will
>       tend to tie X into providing services it's not designed to
>       provide.

X is designed to provide display output and user input services.  If I
design an extension to provide video input and output services, then
X is providing a designed service.

The following is is an argument I often give for device control
and connectivity, and I believe that it *proves* that it should
be available as a part of VEX.  **NEVERTHELESS**, I have never said
that other methods could not be used for device control and connectivity.
For example, if the MIT media labs finds that they want to continue
to use the Galatea server by Dan Applebaum, VEX does not preclude that
(the VEX extension would simply say that there are no devices and that
the video inputs and outputs are not connected to anything).  So
here's the argument.

Given an Image processing program that wants to use the X display
(independent of the XIE), after the image is in the X server, the image
is completely independent of the file format that held it; the server
couldn't care less as it filters and convolves.  And in the same way,
when a program puts a 3d object under control of the PEX extension, that
extension has no dependencies on the file that once held it, and
the format or any other aspect of the file has no bearing on the
rotation or scaling that PEX will perform.

The most important parts of VEX are the video input and video output.
But once these are defined portions of the extension, you cannot separate
the devices or the connectivity from them.  This is because video
(in most circles) is defined as 30 frames per second.  Not less, not
more.  And if something doesn't happen at that rate and at the right
time, then it may as well not happen at all.

So anything that must be done with the video inputs and outputs probably
places a constraint on the devices and connectivity.   The way that this
can be accomplished is by giving all the information to a single agent,
in this case the VEX extension, which may then figure out a way to
make it all happen.  If a separate service provides device control and
connectivity, then it is not possible.  Impossible.  Can't be done.

For those of you that don't need such constraints on the performance
of video, then you may find it convenient to ignore the connectivity
and device control portions of VEX.  VEX allows that.

However, if you say that device control and connectivity cannot be
a part of the extension, then we have no extension, and VEX is useless
to me.  And from the many people I have talked to in various parts
of the industry, it is useless to them as well.

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