rabbit@houvmscc.iinus1.ibm.COM (10/01/90)
I am working as part of the design effort for the Mission Control Center for Space Station Freedom. We have a requirement for the capability to share displays between consoles that are going to be a variety of workstations of an unknown flavor running Xwindows. Several hardware and software solutions have been proposed by various people here all of which will have to be custom built for the control center. Thus far none of the proposed solutions has won. Are there any commercially available solutions for sharing displays between workstation running X? (I have heard of some for PC's running DOS). I have heard of something called SharedX but I have not been able to get any information on it. What's the story? On the leading edge, yet somewhat rusty. Bill Kossack
klee@wsl.dec.com (Ken Lee) (10/02/90)
In article <9010011634.AA26923@ATHENA.MIT.EDU>, rabbit@houvmscc.iinus1.ibm.COM writes: |> We have a requirement for the |> capability to share displays between consoles that are going to be a |> variety of workstations of an unknown flavor running Xwindows. There are 2 things that can be shared in a user interface: 1. output - the same graphics are drawn on each monitor 2. input - the user at each monitor may interact with the user interface The first part is easy. There are many techniques, both in hardware and in software, for duplicating displays. Hardware solutions, such as splitting and amplifying the RGB out signals and sending them to multiple monitors are probably the cheapest. If you want many users to be able to send keyboard and mouse input to an X client program, you have to do quite a bit more work. There are several ways to do this: 1. modify the server to split the protocol 2. modify Xlib to split the protocol 3. modify the client to send different protocol streams to different servers All 3 possibilities have been prototyped. 1 and 2 are the cheapest, as you don't have to modify the client programs. With 1, you don't even have to recompile them. As far as I know, none of these prototypes has been made publically available. The third technique, modifying the client, has the potential to give you the best user interface. There are many user interface problems with multi-user application semantics and only modifying the applications gives you a chance to properly address these. Several multi-user clients, mostly games, using this technique are publically available. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
errolc@videovax.tv.tek.com (Errol Crary) (10/02/90)
In article <9010011634.AA26923@ATHENA.MIT.EDU> rabbit@houvmscc.iinus1.ibm.COM writes: >I am working as part of the design effort for the Mission Control >Center for Space Station Freedom. We have a requirement for the >capability to share displays between consoles that are going to be a >variety of workstations of an unknown flavor running Xwindows. > It is difficult to understand the requirements you have. In X, the words are well defined; a display consists of a instance of the server, one or more screens, and a (primary) keyboard and pointer. Since a server can accept connections from remote clients, the client can place graphical data on, and get user input from the display. Likewise, a single client can access multiple displays. This means that one application can have its output appear on multiple displays, and get input from multiple users.
rabbit@houvmscc.iinus1.ibm.COM (10/04/90)
From: zephyr.ens.tek.com!videovax!errolc@uunet.uu.net (Errol Crary) Organization: Tektronix TV Measurement Systems, Beaverton OR Subject: Re: Display sharing >>I am working as part of the design effort for the Mission Control >>Center for Space Station Freedom. We have a requirement for the >>capability to share displays between consoles that are going to be a >>variety of workstations of an unknown flavor running Xwindows. >> >It is difficult to understand the requirements you have. In X, the word >are well defined; a display consists of a instance of the server, one o Maybe I should give a scenario of what the users in our environment want to be able to do. 1) A Flight Controller is looking at a window at his workstation watching a graphical representation of part of the telemetry downlink from the space station. 2) An event takes place that he either doesn't understand or needs to have another controller look at (or maybe a number of people are interested in and ask to look at). As Flight Controllers may be in separate rooms. It would be difficult for one to get up and walk over to the other workstation. Remote connections to workstations will not be permitted because of a number reasons one of which is security. 3) There is a need to be able to select and distribute the content of that window (we call them screens or displays) so they can see what the original Flight Controller is doing. One of the main reasons for this capability is for training new Flight Controller. The capability to share displays should be a separate application and should not have to be custom code that needs to be included in each application or subsystem. Bill Kossack
wicks@AIS1.BAL.MMC.COM (Anthony B. Wicks) (10/04/90)
Date: Wed, 3 Oct 90 13:04:10 CDT
From: rabbit@houvmscc.iinus1.ibm.com
From: zephyr.ens.tek.com!videovax!errolc@uunet.uu.net (Errol Crary)
Organization: Tektronix TV Measurement Systems, Beaverton OR
Subject: Re: Display sharing
...
2) An event takes place that he either doesn't understand or needs
to have another controller look at (or maybe a number of people
are interested in and ask to look at). As Flight Controllers
may be in separate rooms. It would be difficult for one to
get up and walk over to the other workstation. Remote connections
to workstations will not be permitted because of a number
reasons one of which is security.
3) There is a need to be able to select and distribute the content
of that window (we call them screens or displays) so they can
see what the original Flight Controller is doing.
Requirements 2 & 3 seem to be at odds. Either the systems are connected or
they are not. To be able to send information from one system to another
implies a connetion of some type. For security purposes you may need to
use two displays at the remote location -- one for user interaction, and
one for dumping information. This dumping terminal could be some kind of
xterminal which only has a mouse, allowing the user to interact with the
window manager (to close/iconify windows), but not enter data. The Flight
Controller station would have some variant of xwd, modified to only dump
windows with prespecified names (to meet security) to the remote dumping
terminal. This would meet your "separate application" requirment, and
seems like it could be done with very little custom code. Unforetunately
using xwd as the basis would provide the dumping terminal with static
displays only, but this is a starting point. HOWEVER, there must be a
connection between the remote "dumping" X terminal and the Flight
Controller's computer.
____________________________<Anthony B. Wicks, Jr>______________________________rabbit@houvmscc.iinus1.ibm.COM (10/07/90)
In a previous note I said
...
> 2) An event takes place that he either doesn't understand or needs
> to have another controller look at (or maybe a number of people
> are interested in and ask to look at). As Flight Controllers
> may be in separate rooms. It would be difficult for one to
> get up and walk over to the other workstation. Remote connections
> to workstations will not be permitted because of a number
> reasons one of which is security.
> 3) There is a need to be able to select and distribute the content
> of that window (we call them screens or displays) so they can
> see what the original Flight Controller is doing.
Errol Crary replied to me
>Requirements 2 & 3 seem to be at odds. Either the systems are connected or
>they are not. To be able to send information.............
Others have given similar comments with my statement. :-)
Don't worry because there are a couple of people here that have the job of
designing the security system for the network. One of the big problems is
how do you build security into the system to satisfy security requirements
that originated when all of the Mission Control software ran on a mainframe.
We are trying to build a distributed LAN solution with numerous
workstations each running parts of various subsystems and maintain some
of the same security that was available when everyone was connected to one
mainframe and was located in one room.
Needless to say there will be a piece of code or a person somewhere with a
list of who gets to look at what displays (all displays will be known by the
system). There will also probably be strict rules as to how many displays
can be distributed because even though we are talking of a system with
multiple FDDI LANS with the amount of data and the time critical nature
of the data it would be easy to overload the network with shared displays.
Working on weekends is no fun.
Bill Kossack