Conference bulova::decw_jan-89_to_nov-90

  Here's a thought...

  Split the RGB...one goes to your terminal the other to a multi-outlet
video amplifier...

  You could probably just t-connect a small amount (<3) terminals together.

					-=> Jim <=-

    Have you thought about using a projection tv system. We use a BARCO
    system here that has a VS3500, a VT340, and a VAXmate connected.
    THis gives an image on the wall of approx 6-8ft x 6ft. The workstation
    is connected via T pieces in the monitor cable. I am sure you should
    be able to slave monitors in the same way (although i suspect that
    you might need some amplifiers to keep the picture bright enough)
    
    Gerry
    
    ps If you have any more questions mail me on yuppy::connolly or
    phone on DTN 837 4117 (we are currently on GMT+1)

    Sorry about .2
    
    .1 got in while i was writing mine
    
    Gerry

Thanks for your suggestions.

Does anyone out there have a software solution?

Thanks in advance!

- John Argentati

One of the original applications which Athena was wanting to use X for was the
classroom. The X protocol certainly allows you to open connections to multiple
displays and to draw the same on each of the displays. Unfortunately in practice
this doesn't work well because applications have typically been written to work
only with one server and to interact only with one keyboard. You could modify 
the code to handle multiple servers, but this means cracking open a "dusty deck"
and changing things you'd rather not touch. In short, there is nothing OOTB that
will allow you do to this.

One idea is to take the code for Xliddy (the protocol logger/verifier) and to 
turn it into an X11 analogue of tee(3). The idea is that this tee would appear
to an application as a single virtual X server but would replicate each of it's
actions to a list of X servers. This may provide the capability you desire. It
would be tricky since you would want to be selective about how exposures were
handled since this could cause large amounts of unneeded redrawing but I believe
it could be done.

James
 

	I recommended using the Xliddy approch in the FireFox conference 
	but got absolutely no positive response and gave up.

    Hi folks!
    
    	Don't go for the "wire" approach, its full of ratholes like
    	matching Server replies to your Xlib requests - you send a
    	request to the servers out there, then you start to get events
    	back from the servers, it gets hard to figure out what is
    	happening - its doable, just a bit hairy. Also when you get
    	down to trying to do XPutImage transforms on to different
    	servers (VMS allocates colours top down, Ultrix bottom up)
    	you get into a mess because you don't know what the application
    	was trying to do.
    
    	A better approach is to write a "skin" over Xlib, and intercept
    	the Xlib calls. (This assumes you have sources for the applications
    	you want to play with, ie xterm but not DECterm etc...) This is
    	much better (and still hard enough to be fun :-) as you have
    	access to the Xlib parameters and can also lie consistently to
    	the application (for example tell the application there is no
    	DirectColor visual if it would screw you if he started to use it).
    	You still get some interesting problems like if the application
    	puts data into a pixmap you don't know which window the data is
    	going to end up in. Another amusing one is XGrabPointer which
    	needs to ask "Which one?"! You can't grab all pointers because you
    	may have two links onto one workstation, you can't grab just one
    	because applications don't like button events outside their window
    	if they grabbed (all sorts of bugs).....
    
    	Did I put you off? I hope not! Its doable, but non trivial.
    
    Regards,
    Paul Tallett
    CEC Karlsruhe

    I agree with .-1 about it being hard.  I think, though, that you might
    be able to limit the definition of the   problem a bit to reduce the
    tai]sk a lot.  For example, if you designate one wkst be the master. 
    All the slaves are required to be configured identically (in terms of
    graphics), and the slaves are required to be dedicated to being slaves
    (so that everything is identical...no exposures on one slave but not
    the other.  No grab interactions.)  All the input comes from the master.
    All grabs etc go to it.  Only pay attention to events from it.  Then analyze
    each protocol request to see which ones with replies have graphic side
    effects.  Most requests with replies you pass only to the master
    (things like allocating colors, or querying fonts for example).
    Now you have to keep a chart of how each server wants you to build ids.
    (What is your client number, where does it go, and where to the other
    bits go).  Make a routine to change an id from the master into one from
    one of the slaves.  ETc etc etc.
    
    I don't think this is any harder than doing the xlib overlay.  It may
    be easier, since you only have to deal with 128 requests, not 3 or 400
    routines.
    
    But as KASINO::TALLETT said, it's not easy!
    
    Burns
    

    Note that I am not recommending either approach for cold hard
    money-bearing customers.  If you want to do a midnite hack, have fun.
    For real, I would use the hardware solution:  A monitor cable splitter.
    
    Burns
    

    Re. 8: He knows what he's talking about because he has seen Michael
    	   Altenhofen and me struggling with the wire for some time.
    
    Re. 9: Don't even think of limiting yourself..., it's all doable,
           and in fact we have done it. We started out with a pseudoserver
    	   and dropped that at about 6 weeks into the coding because
    	   of *hairy* problems with parsing the incoming replies. You
    	   know, there can't be more than one reply outstanding right ?
    	   Wrong, if you have several servers and that makes parsing of
    	   the wires inpleasant. Image calls are a nightmare on the wire
    	   and so on.
    
    	   What we did was to move one step back into Xlib and we now have
    	   a (somewhat alpha) version of the MIT R3 Xlib that *dynamically*
    	   allows to add and and remove displays on a *per application*
    	   base. This means that students can work on their machines and
    	   still see what the tutor currently is doing. 
    
    	   We will present this at the 4th annual X technical conference
    	   in January and will donate a R4 version of it to the X
    	   consortium as one possible starting point for work on shared X
    	   ( our name for it is "shared X").
    
    	   Advantages of the this approach are multiplexing on a per
    	   application base, dynamic adding and removing of displays,
    	   compatibility between displays with different color allocations
    	   (depending on what graphic requests you use you can even work
    	    between machines with different depths, most extreme beeing
    	    staring on a color and going to a mono subsequently). Drawbacks
    	    are the need for relinking the application (unless you have
    	    shared libraries), multiple redraws for multiple displays
    	   and the fact that this currently doesn't cover the odd Xlib
    	  that DEC currently ships.
    
    	  I agree that this is not okay for customers, but it may be nice
    	  for people to play with it. I can place shared-X libraries and
    	  some sample clients (idraw among them) for VAX and RISC Ultrix
    	  on a public host here if there's interest.
    
    
    	  Burkhard Neidecker-Lutz, CEC Karlsruhe, Project NESTOR
    
    PS: This is not exactly a midnight hack but has been a masters thesis
    	

Glad to hear someone has done it!  I'll be interested to hear your paper.
I suspect you may have made a lot of people happy!

Burns

RE: Software solution

Performance! We need no stinking performance! 
Think of the traffic jam on the network...???!!!###<>

RE: Hardware aproach...

Becareful, the video drives expect certain impedences and 
just using T connectors will burn them. We cacasded sucessfully 16
monitors on 4 GPX systems at DECworld useing RGB line amps.
This was very inexpensive and also a monitor switch can be added so 
student switches from teachers to own system. The BEDFORD television
studio people know the current offerings, usually and can point you to 
venders. If not call me DTN 223-4944

	Lee...

  

    A RISC/Ultrix version of the library I've been talking about in this
    note is available now. I started a thread for it in
    
    	RDVAX::X, Note 747