peterson@SW.MCC.COM (James Peterson) (12/01/88)
The X11R3 Sun Color support is slower than the monochrome support. A color screen can be faster if the -mono switch is used, to treat it as a monochrome display, instead of a color display. With this switch only one of the 8 bit planes is modified to create an image and the color map is set to display only that bit plane. That means that the other 7 bit planes are wasted. The patches in the next message allow the other 7 bit planes to also be used as monochrome displays. This means that the Sun color display (CG2) can contain up to 8 separate virtual monochrome screens -- each virtual monochrome screen stored in one of the 8 bit planes of the color display. Only one screen is visible at a time, but hiding one and displaying another requires simply changing the color map which is a very fast operation. All clients and the server itself think there are up to 8 separate screens. Clients do not have to repaint their images as you switch from virtual screen to virtual screen since the complete screen image is stored, completely updated, in the color display memory at all times. Switching from screen to screen can be done with the mouse (move the mouse off the edge of the display and a new screen appears) or with the Sun function buttons (press F1 and you are on screen 0, press F8 and you are immediately on screen 7). You have 8 times the available screen space (you just can't see it all at once). Each screen can be any two colors (but only two) and the topology of the screens (which screen is up, down, left, right from any other screen) is user settable. Command Line Options and Environment Variables: 1. -mono<n>. The number of virtual screens can vary from one to eight for each color display. Currently, the X11 server will autoconfigure a color display to be a color display. The option ``-mono<n>'' (where the variable <n> is 1, 2, 3, 4, 5, 6, 7, or 8 selects the number of virtual screens) will cause the color display to support monochrome virtual screens. For example, ``-mono3'' creates three virtual screens: 0.0, 0.1, and 0.2. 2. -skey c. The use of function buttons to select a virtual screen is optional. It can be invoked by the command line argument "-skey c" where c is either F (to use the F1, F2, ... function keys), R (to use the R1, R2, ... function keys), or L (to use the L1, L2, ... function keys). It has been argued that screen switching should be a function of the window manager, not the window server. 3. XSCREENCOLORS. Each virtual screen has two colors: a foreground and a background color. A default selection of colors is compiled into the server. The user can override these defaults by creating a file with their own selection of forground and background colors. The environment variable XSCREENCOLORS should be set to the name of the file. The file is a set of lines; each line contains (1) the screen index (from 0 to n-1 for n screens), (2) the foreground color name (e.g., black), and the background color name (e.g., white). For two screens, for example, the file might be: 0 white blue 1 lightblue black 4. XSCREENTOPOLOGY. For n screens, the mouse automatically assumes that screen i-1 is to the left of screen i and that screen i+1 is to the right of screen i. (All arithmetic is modulo the number of screens.) This can be modified by the user to create a user-specific screen topology. The environment variable XSCREENTOPOLOGY should be set to the name of a file which defines the topology of all screens. The file specifies, for each screen, the screen to its left, right, above, and below. For example, the line "0: R1 U2 L3 D4" specifies that screen 1 is to the right of screen 0, screen 2 is up from screen 0, screen 3 is to the left of screen 0, and screen 4 is down from screen 0. If no screen is indicated in a particular direction from a given screen, the mouse will be unable to move off that edge. So if no screen is to the right of screen 3, the mouse cannot be moved off screen 3 to the right. This option required rewriting the screen selection code in sunMouse.c The changes to the server are: 1. Change each of sunBW2Probe, sunCG2CProbe, sunCG3CProbe, and sunCG4CProbe to return the number of screens that it found, rather than just true or false. 2. Change the code in InitOutput to accept the number of screens found by a <display-type>Probe routine and sum them to get the total number of screens. 3. Change the code in sunCG2C.c and sunIo.c to recognize the extended form of the -mono switch. 4. Change the call from sunCG2CProbe to sunCG2MProbe (in the case where the -mono switch has been found) to pass the -mono switch also. 5. Add code to sunCG2MProbe to interpret the -mono switch and compute the number of desired virtual screens. 6. Modify the size and location of the frame buffer memory for the display that is mapped into memory in sunCG2MProbe to provide access to the desired bit planes, registers, and color map. 7. Each screen has an associated descriptor of Sun-specific information stored in an array of static descriptors, sunFbs. Change the initialization of this data structure to compute the correct image address. 8. Each bit plane needs its own color map. It would be possible to compute it on the fly when we change screens, but for speed, we precompute a particular color map and save it for each virtual screen. We need to declare the color map as part of sunFbs[i] saved for each frame buffer, and add code to make the private color map for each virtual screen. 9. The original code stored the color map for its one mono screen into the hardware color map once when the device was initialized and then never changed it. We need to change it every time that a new screen is entered. The sample code has a operation for each screen, sunFbs[index].EnterLeave which can be called every time a screen is entered or left -- previously that was a non-op. We wrote a routine that would change the hardware color map to the private color map for the selected screen. These changes (and correction of bugs in sunInit.c and main.c in code which incorrectly allocated arrays based on NUMSCREENS and MAXSCREENS) created our X11R3 server with multiple virtual screens. Code was already in sunMouse.c to allow changing screens as the mouse is moved left and right or up and down; additional code was added to sunKbd.c to sunKbdGetEvents to support screen switching with the function keys. LIMITATIONS: The multi-screen patches can be used with either one CG2 display or a CG2 display and a B/W display (two display system). The use of the mouse to move from screen to screen does not work if adjacentscreens is controlling the movement of the mouse from screen to screen (for example if X11 is running on the color display and SunWindows on the B/W display) since in this case X11 never sees mouse movement off the screen and so never invokes the screen changing code. INSTALLATION AND USAGE: 1. Install the patches. 2. Change your Sun.macros or Imakefile or Makefile to include -DMVMS as a cc option. 3. Recompile your server. 4. Create an color definition file. I call mine XColors and put it in ~/lib Then I define "setenv XSCREENCOLORS $HOME/lib/XColors". My file is: 1 white blue 2 lightblue black 3 springgreen black 4 mediumvioletred black 5 white grey61 6 blue green 7 green black 8 red cyan (screen 0 is a B/W display, so the color ones are 1 to 8). 5. Create a topology definition file. I call mine XScreens and put it in ~/lib Then I define "setenv XSCREENTOPOLOGY $HOME/lib/XScreens". My file is: 0: R1 L7 U0 1: R2 L0 U0 2: R3 L1 U0 3: R4 L2 U0 4: R5 L3 U0 5: R6 L4 U0 6: R7 L5 U0 7: R0 L6 U0 (this allows me to get to screen 0 by going up at any time, otherwise it is a barrel roll on left to right mouse movements) 6. Start up the server with -mono8 and your choice of function key selection I use "-skey f". 7. Move the mouse left and right or up to change screens, or use the function keys. Notice the foreground/background colors change as you move from screen to screen. You can also set the root backgrounds on each screen differently to aid you in keeping straight where you are. 8. You will need to give explicit display numbers to start programs on different screens -- setenv DISPLAY foo:0.3;xterm& and so on. jim
usenet@cps3xx.UUCP (Usenet file owner) (12/01/88)
In article <8811302337.AA08445@cleo.sw.mcc.com> peterson@SW.MCC.COM (James Peterson) writes: > > ... This means that the Sun color display >(CG2) can contain up to 8 separate virtual monochrome screens -- each >virtual monochrome screen stored in one of the 8 bit planes of the >color display. Would it be possible to do the same thing for the CG4? -- Patrick Flynn, Dept. of Computer Science, Michigan State University flynn@cpsvax.cps.msu.edu flynn@eecae.UUCP FLYNN@MSUEGR.BITNET "First we break 'em in half.... then we mash 'em to a pulp."
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (12/02/88)
<1215@cps3xx.UUCP>, by usenet@cps3xx.UUCP (Usenet file owner):
- In article <8811302337.AA08445@cleo.sw.mcc.com> peterson@SW.MCC.COM (James Peterson) writes:
->
-> ... This means that the Sun color display
->(CG2) can contain up to 8 separate virtual monochrome screens -- each
->virtual monochrome screen stored in one of the 8 bit planes of the
->color display.
-
- Would it be possible to do the same thing for the CG4?
Probably, but we've found that painting on only some of the bitplanes of
the color planes in a cgfour can actually be SLOWER than using all 8 bit
planes. The cgfour is just memory and relies on the system CPU to do all
the bit-pushing, so it's pretty slow to begin with.
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303david@sun.uucp (David DiGiacomo) (12/02/88)
In article <1215@cps3xx.UUCP> flynn@pixel.cps.msu.edu (Patrick J. Flynn) writes: >In article <8811302337.AA08445@cleo.sw.mcc.com> peterson@SW.MCC.COM (James Peterson) writes: >> ... This means that the Sun color display >>(CG2) can contain up to 8 separate virtual monochrome screens -- each >>virtual monochrome screen stored in one of the 8 bit planes of the >>color display. > >Would it be possible to do the same thing for the CG4? Nope. The cg2 has special hardware to make the frame buffer addressable by plane or by pixel. The cg4 frame buffer is only addressable by pixel.
janssen@titan.sw.mcc.com (Bill Janssen) (12/02/88)
Another way to move to a desired screen when running Jim Peterson's
virtual screen variation of X11 is to simply warp the mouse to the
desired X screen. The following is a simple program which takes
a single integer argument, the number of the screen to be selected,
and warps the mouse to it. It can be called as a shell function
from twm or rtl, allowing them to work with the virtual screen
system.
#include <stdio.h>
#define TRUE 1
#define FALSE 0
typedef int Boolean;
#define AND &&
#define OR ||
#define NOT !
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <ctype.h> /* for isdigit */
main (ac, av, envp)
int ac;
char **av;
char **envp;
{
Window root, child;
int root_x, root_y, win_x, win_y;
unsigned int mask;
int newscreen;
Display *disp;
freopen ("/dev/console", "a", stderr);
if (ac < 2 OR NOT(isdigit(*av[1])))
{
fprintf (stderr, "Usage: warptoscreen <screen-number>\n");
return 1;
}
newscreen = atoi(av[1]);
disp = XOpenDisplay (NULL);
if (disp == NULL)
{
fprintf (stderr, "Usage: can't access X11 display\n");
return 1;
}
if (newscreen >= ScreenCount(disp))
{
fprintf (stderr, "Can't warp to screen %d; only %d screens\n",
newscreen, ScreenCount(disp));
return 1;
}
/* get current mouse position */
XQueryPointer (disp, DefaultRootWindow(disp),
&root, &child, &root_x, &root_y,
&win_x, &win_y, &mask);
XWarpPointer (disp, None, RootWindow(disp, newscreen),
0, 0, 0, 0, root_x, root_y);
XCloseDisplay (disp);
return 0;
}
--