Received: by ATHENA-PO-1.MIT.EDU (5.45/4.7) id AA12874; Thu, 11 Oct 90 15:45:22 EDT
Received: from EXPO.LCS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA11735; Thu, 11 Oct 90 15:45:17 EDT
Received: from ATHENA.MIT.EDU by expo.lcs.mit.edu; Thu, 11 Oct 90 15:42:31 EDT
Received: from BOOM.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA10057; Thu, 11 Oct 90 15:14:10 EDT
From: dcc@ATHENA.MIT.EDU
Received: by BOOM (5.57/4.7) id AA15165; Thu, 11 Oct 90 15:14:03 EDT
Message-Id: <9010111914.AA15165@BOOM>
To: vex@expo.lcs.mit.edu
Subject: Device control and connectivity in VEX?
Date: Thu, 11 Oct 90 15:14:00 EDT


  I've been discussing VEX with engineers in DEC who are involved with
  interactive video research and development, and while we haven't yet
  compiled a comprehensive response to the VEX submission, one major
  issue that we immediately agreed upon was that VEX, or any extension
  to X for that matter, should not manage video device control and
  connectivity.  Since this is a major component of VEX, it seems
  a suitable topic for discussion in the trial review period.

  Our reasons for not wanting device control and connectivity as part
  of an extension to X are as follows.  Realize that we are not
  debating the advantages of having a service that manages video
  devices, only whether it is desirable for the X server to provide
  that service:

    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.

    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.

    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.

    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.  One partial solution is to make
      transitions occur within a time small relative to human
      perception.  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.

    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.

    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.

/David Carver (DEC Workstations Engineering/Project Athena)
