Multiple Virtual Display Screens for X11

James L. Peterson

Software Technology Program
Microelectronics and Computer Technology Corporation (MCC)
3500 West Balcones Center
Austin, Texas 78759-6509

15 Nov 1988


We have modified the X11R3 window server to allow a color Sun display to support up to eight monochrome virtual screens. Only one virtual screen is visible at a time, but switching between virtual screens (using the mouse, keys, or under program control) is very fast, since it requires only the reloading of the color map. We discuss the concept and implementation of virtual screens, how they can be used, and some limitations and generalizations of the concept.


Window systems are becoming quite commonplace. A window system controls access to a display terminal, allocating space on the display to multiple activities. This allows the (human) user to have several (possibly unrelated) programs running at the same time. The output of each program is displayed in its own window.

Window systems greatly improve the ease of working with a multi-process interactive computer system. Especially with a large high-resolution display, it is possible to have many windows on the display at the same time.

Over the past few years, the value of window systems has become increasingly apparent, and many window systems have been developed. Many new computer systems (such as the Macintosh, Amiga, and NeXT computer systems) come with a window system which is an integral part of the basic software. In other cases, a window system can be written as a user-supplied program. This encourages the creation of many different window systems. For example, many window systems have been written for the Sun workstation, including SunView [Sun 1986], the Andrew window manager [Morris et al 1986], the X window system [Scheifler et al 1986], NeWS [Gosling 1986], and GMW [Hagiya 1987]. These window systems are quite different in the specifics of their use. At the same time, they have many common properties.

The X11 Window System

The X11 window system is of particular interest. The X Consortium at MIT supports the core server code and some basic clients. There is also a large amount of contributed software. The source code for X11 is distributed freely and can be run on many different workstations. X11R3, the third source release of X11 has drivers for Sun, MicroVax, Apollo, HP, IBM/RT and Macintosh II workstations.

There are problems with the X11R3 window server, however. While the code provided by the X Consortium does compile, install, and run (quite well) on many different workstations, it is considered ``sample server'' code and is not, generally, complete production quality code. A particular problem, for example, is speed. The sample server code is often slow, since it emphasizes portability over speed.

The slow server speed is particularly noticeable with the color Sun support. Many bitmapped displays map the bits controlling the display image directly into memory. This allows standard programming techniques to directly modify the display by simply changing the values of memory bits. Generic code for supporting memory-mapped displays is included in the X11R3 sample server and the Sun sample server uses this generic code to drive its displays.

The use of the generic server code to drive a monochrome (black/white) server is acceptably fast, since each display pixel is only one memory bit. Color displays are more complicated, however. The Sun color display, for example, is typical of many color displays. The display needs 24 bits per display pixel: 8 bits of red, 8 bits of green, and 8 bits of blue. To reduce memory requirements, however, only 8 bits are stored for each pixel. This 8-bit value is an index (0 to 255) into a color map table of 24-bit color values. By reloading the color map, any color can be obtained, but only 256 distinct colors may be on the screen at any one time.

The Sun color display allows the color display memory to be viewed as one bit plane of 8-bit bytes (each byte holds the color map index for one pixel) or as 8 1-bit bit planes. Each bit plane is the size of the physical display. If the display memory is viewed as 8 1-bit bit planes (rather than one 8-bit bit plane), the color map index for a given pixel is determined by the 8-bit value selected by picking one bit from each bit plane to define the 8-bit color map index.

To save on program size and development time, the Sun sample X11R3 server uses the generic monochrome support code for its color support. For a color operation, the monochrome code is called 8 times (once for each bit plane) to affect each of the 8 bits per pixel for a color display. This slows color Sun displays considerably, almost by a factor of 8, but did not require a large amount of additional code to operate on 8-bit bit planes.

To avoid this particularly slow color Sun problem, Adam de Boor of the University of California at Berkeley, modified the color Sun driver to optionally operate in ``mono'' mode. In mono mode, the Sun driver ignores all but one bit of the 8-bit color pixels and consequently operates as a monochrome display at monochrome speeds on the color Sun display. The other bits of the color display memory are ignored by careful setting of the colormap. In particular, if all even (xxxxxxx0) color map entries are set black and all odd (xxxxxxx1) color map entries are set white, only the bottom bit plane defines the image on the display. This means that the device driver code need only modify one of the 8 bit planes to display an image.

Multiple Virtual Screens

At MCC, we have generalized this mono mode to provide a new means of using a color display. Rather than using only one of the 8 bit planes in the color Sun display to hold and display a monochrome image, our X11R3 server allows up to eight separate monochrome screens, one in each of the 8 bit planes of the color Sun display.

We have already seen that the image in the bottom bit plane can be used to define the display image by setting even (xxxxxxx0) color map entries to black and odd (xxxxxxx1) color map entries to white. Suppose instead that the first 128 entries of the color map are set to black and the last 128 entries are set to white. For this color map, only the bits in the top bit plane can affect the color displayed on the screen. That is, any 8-bit color index of the form 0xxxxxxx will display black and any 8-bit color index of the form 1xxxxxxx will display white. Only the top bit plane affects the image on the display.

In general, a specific pattern of black/white color map entries can be defined for each of the 8 bit planes to make it visible on the display (and all others invisible). Each bit plane defines a separate ``virtual screen''. Each virtual screen is the same size (width and height) as the physical display screen. At any given time, the user has selected a particular virtual screen. The selected virtual screen is shown on the physical display. If the user changes the selected virtual screen, the contents of the old virtual screen are saved and the newly selected virtual screen is displayed.

Each virtual screen is black and white (not color) and so only needs one bit to specify each pixel. Each virtual screen is kept updated in the appropriate bit plane of the display memory. Notice that it is not necessary to restrict virtual screens to black and white -- any two colors (background/foreground) will do. In fact, we find it convenient to define each virtual screen to have different background/foreground colors to aid in identifying them.

The physical display can be thought of as a viewing port onto the virtual screens: it allows the user to see any one (but only one) of the virtual screens at a time. Alternatively, the virtual screens can be considered to be paged into and out of the physical display, much like a demand-paged memory management system. Changing to a new virtual screen requires only loading a new color map, a very fast operation.

Virtual screens are selected (in our implementation) by the user. We have three selection methods.

  1. A set of function buttons on the keyboard can select a particular virtual screen, causing it to be displayed. For example, on our Sun workstations, function keys F1, F2, F3, ..., F8 can be used to select and display the associated virtual screen.

  2. We also use the mouse to select virtual screens. If the mouse moves off the right or left edge of the current virtual screen (screen i), the display is switched to screen i-1 or screen i+1 (modulo the number of screens).

  3. A window manager (or other program) may ``warp'' the mouse. X11 defines a command to redefine the position of the mouse pointer. This can be used to move the mouse from one screen to another under program control or user direction.
Using any one, or more, of these techniques, the user can quickly select from the set of virtual screens.

Using Multiple Virtual Screens

How can multiple virtual screens be used? Over two years ago, I implemented the multiple virtual screen concept for the old Andrew window manager. After several years of working with this system, I have found the following to be a common way of using the system: Over the course of a day, I use the computer system for several unrelated tasks. Each task might require several windows simultaneously. For example, a simple programming task might require an editor window on the program, a shell window for compilation and program execution, and a window to display the output of the program under development. All of these windows are needed at the same time and should be tiled to allow easy and immediate access.

A more complex programming task might require several editor windows on several related program files, windows displaying help information about system calls and libraries and several output windows to allow the current output to be viewed and compared with previous program outputs. Another task might be reading system bulletin boards with additional windows to send and read mail. Electronic mail often requires several windows since a mail inquiry may require searching through the file system to find relevant information for the reply.

In general, each task requires a set of windows. The tasks partition the complete set of windows for a user. Thus the tasks of a user define a partition of windows into window sets.

The set of windows for a particular task may change, over time, as new windows become necessary for a task, are used, and eventually are no longer necessary and are deleted. However, windows seldom move from one task set to another, in my experience. Occasionally, a window which is part of one task set may become the center of a separate task (a large sub-goal or digression from the original task) and may then result in the creation of a separate set of windows for this new task.

Since each window for a particular task is necessary for that task, the windows within a window set should be tiled. However, the window set of one task is unrelated to the window set of another task, and since the user can only direct attention to one task at a time (with relatively infrequent and obvious switching between tasks), separate window sets can be overlapped.

Tasks may be long-lived or short-lived. I may be working on several projects at a time (working on a program, writing a technical paper, preparing class notes, reading mail or news -- which tends to spawn many short-lived tasks -- and so on), so I may have several window sets at a time. Some window sets last for weeks while others are created, used, and deleted in minutes.

In the extremes, this layout model includes both traditional tiled and overlapped systems. If all windows are in the same window set, the layout is completely tiled. If each window is in its own window set (a singleton set), the layout can be completely overlapped.

With multiple virtual screens, each virtual screen can be used to hold one window set. Switching between window sets requires switching between virtual screens. This can be easily done with either mouse or function keys.

The concept of ``window sets'' and multiple virtual screens that we are using here is similar to the ``Projects'' concept of SmallTalk [Goldberg 1984] or the ``Rooms'' concept from Xerox Parc [Card and Henderson 1987].

Implementation Coding

The modification of the X11R3 sample Sun server to support multiple virtual screens took about a week of programming time. Much of this was in finding the affected data structures and code. The modification was then fairly straightforward.

The major data structure that needs to be changed is screenInfo. This data structure contains a description of each screen which the server is supporting. For the Sun code, it is initialized by calling InitOutput which calls each of sunBW2Probe, sunCG2CProbe, sunCG3CProbe, and sunCG4CProbe. These routines each search for their particular display. If they find one, they call AddScreen which calls <display-type>Init. The result of this autoconfiguration is the data structure screenInfo has a number of screens screenInfo.numScreens and an array screenInfo.screen[] of screen descriptors.

Our first set of changes was then,

  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; additional code was added to sunKbd.c to sunKbdGetEvents to support screen switching with the function keys.

Implementation Limitations

While the initial implementation of multiple virtual screens for X11 was usable and demonstrated the relatively simple changes needed, a number of generalizations were immediately apparent to allow a user to tailor the system to his or her own style of use.

  1. -monon. 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 is ``-monon'' (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. It has been argued that screen switching should be a function of the window manager, not the window server. 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).

  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).

  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
These changes do not affect the basic code or theory of operation of the multiple virtual screen feature of our X11 Sun server -- they simply generalize policies that were initially wired in to allow a demonstration of the feasibility and usefulness of multiple virtual screens.

A more important issue with the use of multiple virtual screens with the X11R3 system is the poor support for multiple screens provided by the available window managers. It appears that each screen must have its own window manager and windows cannot be moved from screen to screen. This is true for both multiple physical screens and multiple virtual screens.


We have modified the Sun sample X11R3 server to provide multiple virtual screens on a color display. Our implementation uses the color map to select and display a particular virtual screen. This provides very rapid switching from one virtual screen to another, and allows up to 8 different virtual screens on each color display, using each of the 8 bit-planes in the color display as a separate monochrome virtual screen.

In general, it would be possible to break an 8-bit color map up into a number of colored virtual screens also. For example, one 8-bit color map could provide:

In addition, the general concept of virtual screens can also be implemented with other hardware. For example:

  1. A virtual screen can be defined as a particular set of windows (a ``window set''). Whenever a switch is made from one virtual screen to another, all old windows are unmapped and each window in the newly selected window set is mapped, causing it to re-display itself. This requires no extra work for the window manager and each client program should be prepared to redraw itself when necessary anyway. However, this approach can be painfully slow. The process for each window in the selected window set must be signaled by the window manager, scheduled by the operating system, paged in by the paging algorithms, and then must recompute its display image.

  2. Another approach to switching virtual screens is to maintain an up-to-date image of each virtual screen in memory and to copy this image to the physical display as necessary. When a new virtual screen is selected, the old virtual screen must be copied from the physical display into memory and the new virtual screen must be copied onto the physical display. If a copy of the current virtual screen is kept updated in memory as well as on the screen, then only one copy is needed. Even so, this approach is too slow for large bit-mapped displays, such as the Sun. For small, character oriented displays, the performance of this approach may be quite reasonable.

  3. With a little hardware help, the copying can be completely avoided. For example, if the display is refreshed from main memory, then we need only to be able to reset where in memory the display image is located. This is easily supplied by a base register. With a base register, each virtual screen is continually updated in main memory. To switch from one virtual screen to another, we need only change the base register to point to the memory for the selected virtual screen. The display change is effectively instantaneous (one screen refresh time). In general, the virtual screen model cannot be efficiently implemented without hardware help, and few displays provide such hardware base registers into general memory.


We have reported on modifications which we have made to the X11R3 Sun server to allow multiple monochrome virtual screens on a color display. This particular change was possible because of the generic monochrome driver support code for X11R3 and the flexibility of memory mapping for the Sun color display. Our server demonstrates the practicality and usefulness of multiple virtual screens.