Conference bulova::decw_jan-89_to_nov-90

    There's no supported way to do that.  By the way, the problem is
    presumably not just output -- input (X events) needs to be
    handled as well.  For example, both displays could generate
    expose events.  A simple application could handle exposes by
    replotting both displays, but it definitely needs to see
    the events from both of 'em.
    
    I think I remember hearing that someone had tried to build
    a 'tee' program.  This tee would look like an X server, so
    you'd use it as kaleidoscope's display.  It would in turn
    pass a copy of every message to each of two real X servers.
    I don't know if or how input was to be dealt with.
    
    Anyone admit to trying this, or is it just wishful thinking
    on my part?

If you give us two or three more month we will have something for you. As part
of a research project going on here we are building a new Xlib, that when linked
to your application will allow to multiplex input and output between several
X servers. We tried to do it with a pseudo server but that has to many problems
in reconstructing some parameters from the wire events. 

Right now a few clients run in a distributed fashion, but it's not perfect
(and will never be). Many things break in uninitiated applications if they have
to deal with several mouse pointers (as a simple but fun example). It's
still useful as it saves you a lot of the work when you want to go from a
single display application to a "shared-window" application (WYSIWIS - what
you see is what I see).

		Burkhard Neidecker-Lutz , CEC Karlsruhe , Project NESTOR

    Sounds good for training purposes, if nowt else....
    
    - ���

    
    If you give us two or three months you can do it with XUIS - one
    virtual display with windows on multiple displays...
    
    _Fred

    Thanks everyone for the replies so far.   Someone in my office thinks
    that they remember seeing two workstations running DECwindows at DECtop
    that were playing a game of chess.  THey thought that as pieces moved
    on one workstation they also moved on the other.  Did this really
    exist?
    
    I also remember "NETpool" from VWS days that played a pool game across
    two UIS workstations...

    One more thing.   For the customer who is raising this question, it
    would be totally acceptable to have input allowed only from one
    specific workstation.  All other workstations would be output only
    displays.

	re .5

	Yes, there is a chess program that draws a board on
	two workstations.  It is programmed to do that ... it
	explicitly opens both connections, and it explicitly
	draws to/reads from from displays.  I think the replies
	were about whether one can take a program dealing with
	only one display and somehow through SET DISPLAY get it
	to use two displays instead.

	Dave Burleigh's chess example would be described in
	the examples conference, and I also have it available at
	zfc::zfc$disk1:[public.tbd1].  The files are *chess*
	and I think *hyperbutton*.

	Dan

    XChess also does this; you have the option of opening two displays or
    playing against GNU Chess...
    	-Rick

	Dont be in a hurry to discount the usefulness of multiple input
	streams this would be most useful for debugging and testing also
	excellent for having a hidden partner sending events doing the reverse
	of the XWOODWARD program and being able to multiplex into
	a customers workstation for problem resolution from your desk.

	In fact there are some brilliant things that could done
	in this area

	Karl Mutch
	New Zealand Software Services

I ran  into  the  multiplexed  I/O  problme while hacking around with XCONQ.
XCONQ  opens  multiple displays, where each display corresponds to a player.
While one player is making moves, the other players (on the Unix version...)
can  go around looking at the map, sending each other messages, or doing any
number of other things which don't take any game time.

On Unix,  this  is  somehow  accomplished using select(), but that is not an
option  on  VMS... What I have to do is use XPending() in a loop with a time
delay.  I  want to have some function which I pass an array of displays, and
which  then  blocks  until  input is available on one of the displays. There
seems  to be a function called XMultiplexInput which is supposed to do that,
but  I  can't find any documentation on it, and it doesn't seem to work... I
only  know  about  it because somebody (Brad Merrill?) tried to get the code
working using it, and failed to get it working.

- Brad

I have XtMultiplexInput() working.  It's a little trickey, and the
blinking text cursors don't always work right, but other than that it
seems to work.

In PRNSYS::RELEASED_TOOLS:[COMMAND]*.*, you will find a generic
DECWindows interface for applications who's input can be described with
the VMS CLD facility.  (The DECWindows portion consists of a command
widget and a menu bar, where the menu bar items each translate into a
command line to execute.)

This is a command interface that is designed to simultaniously accept
multiple command input streams from DECWindow screens, terminals, and
mailboxes.

A demo program is included.  To demo the muiltiple display capability,
modify the main() routine to contain a few instances of:

	{
	SESSION_ID s;
	s->co = cmdopen_input( "WSA1:", NULL, "DEMO> ", DEMOCLD, s);
	}

where in each instance you replace "WSA1:" with the WSA device names of
the displays and screens that you want to open.

Make sure that you compile the demo CC/DEFINE=DECWINDOWS, as there is a
non-DECWindows subset also.

What do the arguments mean?  Here is all I've been able to figure out:

XMultiplexInput(int *count, Display **display_list, int *evmask, int *foo1,
		int *foo2, int *retval)

_displaylist_ is  an  array  of  _count_  pointers  to displays, evmask is a
pointer  to  two longwords containing an event mask, and retval is a pointer
to  a  longword  in  which  to  store the number of the display returning an
event,  or  -1  if  it returns for some event other than an explicit display
event.

What do  foo1  and foo2 do? What is the behavior if there is a pending event
one  one  of the displays at the time you call XMultiplexInput? What happens
if several displays have pending input?

Thanks,
- Brad

 unsigned int foo1Timeout; /* Number of milliseconds to wait before returning regardless
		     of whether any events have happened. 0 means wait forever*/

 unsigned int foo2Options; /* Mask with bits indicating options:

	XMINoBlock:  Do not wait for input if none is ready (timeout
 			meaningless)
	XMINewInput: Do not consider currently enqueued events as available
			input.


BTW, a retval of 0 means no input available if the noblock option is chosen.

Burns