From: staceyc@sco.COM (Stacey Campbell)
Subject: Re: SCO X11R4 EFS and MultiScreens
Organization: The Santa Cruz Operation, Inc.
Date: Wed, 12 Aug 1992 16:43:46 GMT


[this is kind 'o long, but it is certainly something we (the X server group)
have given a lot of consideration]

In article <9208110506.AA05016@bazooka.Altos.COM> bazooka!thilo@altos.Altos.COM (Thilo Koenig) writes:
>...annoying "feature" of the Xsco SVGA X server...
>Namely, if I switch to a different MultiScreen, all processing on the
>X server stops (i.e., all clients seem to hang, including any normal
>non-X UNIX processes running in an xterm >window).  And when I switch
>back to the X server screen, processing resumes.

I'll preface my explanation by saying that when you screen switch away
from an X server you (the server) basically give up all rights on the
video card on a SCO system.  You cannot write to the card, read from
the card, or when you switch back to the server, assume that the card
is in any sort of valid text or graphics mode.  This is because the user
could be running anything on the multiscreen they switched to, including
a DOS graphics application, another X server, or a simple VGA text
program (assuming we are talking about a VGA video card here).

So while you are switched away the server needs to maintain state so
that all your graphics applications that have been sending drawing and
reading requests to the server still look okay.  The solution in the
old server (X11R3) was to malloc a pixmap that was the size of the screen,
dump the screen onto the pixmap, then start drawing and reading on the
pixmap until the user switched back.  This obviously sucks up an enormous
amount of virtual memory, for a 1280x1024-256 color server this comes to
1310720 bytes (we support quite a number of cards that run at this
resolution and depth), and if your server is quite active while you
are switched away, this translates into paging and RAM.

If a user starts up a couple of servers then switches away from both,
then clearly they are going to be thrashing their system in short
order (assuming 8-12M of RAM).  One of the main design thrusts behind
X11R4 was to make it a lot smaller than X11R3, and now with ODT 2.0
running many X applications, we are trying to be real lean and mean
with RAM usage.  Since MIT has gone to great pains to shave a byte here
and a byte there, it is not seemly that we should go and malloc a meg
of memory and blow away a lot of the benefit of X11R4.

However, since a few people such as yourself have mentioned that they
miss the continue-while-I'm-gone feature of X11R3 (maybe more than
they miss that one meg pixmap ;-) we have been considering some
alternatives, and a little input from the net wouldn't hurt here;

A. Disable screen switching while the server is running; you wouldn't
believe what a royal pain it is to screen switch a TMS34020 based
video card with a VGA on board!

B. Provide a command line arg to the server that enables the old method
but the default is to do what it is doing now.

C. When the user switches away ignore all hardware drawing requests,
just throw them away, when a program does a getimage from the screen
send back either garbage, a black area, or hang until the server gets
the video card back.  When the server gets the video card, send out
expose events to all the clients, and get the screen back into a
sane state.  Usually when someone switches away from a screen it's
unlikely a client will be doing a getimage anyway.

D. Keep doing what we are doing now and avoid rude hacks and giant
memory allocations.

So A is basically out of the question, the server group wouldn't mind
throwing out screen switching tomorrow, but one of the fellows that
runs the company is very attached to screen switching and wont let
us. ;-)  I guess we are tossing up between B, C, and D, where
C is getting a lot of consideration (though the idea of hanging on
getimage, then expecting the client to redraw with an expose event before
we give them their image back, is probably far fetched).
-- 
          Stacey Campbell - staceyc@sco.com - uunet!sco!staceyc
Newsgroups: biz.sco.general