Path: utzoo!attcan!uunet!husc6!bloom-beacon!EXPO.LCS.MIT.EDU!jim
From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Multiple screens and multiple visuals
Message-ID: <8808231403.AA22734@EXPO.LCS.MIT.EDU>
Date: 23 Aug 88 14:03:13 GMT
References: <13562@agate.BERKELEY.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 42


>         Recently, somebody (was it RWS?) posted a note saying that it
> would be nice X servers will treat multiple screens as a single screen
> with multiple visuals.

Yes, it was Bob.  He was talking about multiple screens on a single display
tube, not multiple heads being driven by a single server.


>         Don't do it.  Future applications may want to use different
> visuals for different sub-windows, and must not be mislead into
> believing that two visuals coexist on the same screen, when in fact
> those visuals span physically disjoint screens.

Two visuals can coexist on the same screen.  Several of the various graphics
supercomputers that are hitting the market already allow 24-bit deep
DirectColor or some number of bits of PseudoColor window to be located at
arbitrary locations on the screen. 

The particular instance that Bob was talking about was the sample server for
color Sun displays that have the extra overlay plane.  For those who haven't
seen one in action, the current implementation provides two separate X screens
on the same display tube (Zaphod mode) which toggle back and forth whenever the
mouse moves off the edge of the root window. 

Instead of having these two separate screens, it would be much nicer to
have both visuals available on one screen (if people like the extra real
estate, they should use a window manager that provides rooms).  This would
allow monochrome applications to use the faster StaticGray visual and color
applications to use a PseudoColor visual.

One reason why we're interested in doing this is to see how many applications
will break because they simply use the default visual instead of looking at
what's available and choosing the correct one.  Unfortunately, the answer is
probably "a lot of them."

The relevant routines in Xlib are XGetVisualInfo and XMatchVisualInfo, although
I would expect various toolkits to provide alternative interfaces.


							Jim Fulton
							MIT X Consortium