Received: by ATHENA-PO-1.MIT.EDU (5.45/4.7) id AA13638; Thu, 11 Oct 90 16:20:39 EDT
Received: from EXPO.LCS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA13186; Thu, 11 Oct 90 16:20:33 EDT
Received: from xenon.lcs.mit.edu by expo.lcs.mit.edu; Thu, 11 Oct 90 16:17:54 EDT
Received: by xenon; Thu, 11 Oct 90 16:17:45 EDT
Message-Id: <9010112017.AA15650@xenon.lcs.mit.edu>
To: dcc@ATHENA.MIT.EDU
Cc: vex@expo.lcs.mit.edu, keith@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> 
Date: Thu, 11 Oct 90 16:17:43 -0400
From: keith@expo.lcs.mit.edu (Keith Packard)


    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.

While I agree with David in general, I think he's handwaving here.  I have
heard of no designs which provide the level of near-synchronization which the
serial X stream provides.

If a reasonable alternative proposal is forthcoming, I'd really like see the
end of embeded device control in VEX as well.  I think that the functionality
is required at some level though, removing it from VEX without providing a
replacement with no less functionality will cause the usefullness of VEX to
suffer.

I don't like it, but I don't have any better ideas.
