Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!orca!mesa!rthomson
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Newsgroups: comp.windows.x
Subject: Re: Multi-screen XServer: Where can I find one?
Keywords: multi-screen xserver available
Message-ID: <1991Jun30.224600.16200@dsd.es.com>
Date: 30 Jun 91 22:46:00 GMT
References: <906@pdxvme.pdx.csd.mot.com> <1991Jun28.034016.9875@dsd.es.com> <1991Jun29.104006.18467@thunder.mcrcim.mcgill.edu>
Sender: usenet@dsd.es.com
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Lines: 41
Nntp-Posting-Host: 130.187.85.21

In article <1991Jun29.104006.18467@thunder.mcrcim.mcgill.edu>
	mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>[...] While
>it's possible to multiplex multiple screens onto a single monitor, this
>is an ugly kludge; simply supporting multiple visuals on one screen is
>probably a better fit to the X model.

There are several reasons for this multiplexing.  In our
implementation, each screen provides *all* the visuals supported by
our server, but each screen has a different visual class for the root
window.  Why?  Because lots of X software out there makes bad
assumptions about the characteristics of the machine based on
properties of the root window.  That's right, they don't use
XMatchVisualInfo, etc.  They expect that the root window is a
pseudocolor 8-bit visual, for instance.  Even though you can provide
this visual in the list of visuals supported, they won't find it if
the root window isn't using that visual.  For instance, our root
window is a TrueColor visual.  This software would just crash and burn
if we didn't provide a screen with an 8-bit PC visual.

Also, multiple video modes on the same frame buffer are better merged
into the X world by multiplexing another screen (different resolution)
onto the physical one.  After using it for a while, I find it to be a
great convenience by allowing my an array of work areas where I can
arrange the X windows by groups.  Of course, this is a side benefit --
there already is software that does this function -- the main point is
to integrate poorly written applications and different video scanout
resolutions into a single system.

Life would be alot easier if applications were written with
portability across different X implementations with respect to
visuals.  This still wouldn't solve the stereo problem, though.
[Multibuffering doesn't address the video resolution issue either, I
believe]

							-- Rich
-- 
  ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon
	    Disclaimer: I speak for myself, except as noted.
UUCP: ...!uunet!dsd.es.com!rthomson		Rich Thomson
Internet: rthomson@dsd.es.com			PEXt Programmer