The following sections provide details about our window manager and multi-head X-Server setups. This information is intended for anyone in the future changing things such as window manager scripts, multi-head layouts, or observing session window placement rules (all of which are more complicated when there are three monitors per terminal!) There is a separate document on the Web with more user oriented information for local users who just want to customize their desktop colors or window manager menus. The information here is more low-level, and intended for setting up observing sessions. It in the interest of anyone developing user interface software for use at CFHT to at least be aware of these basic layers of the window session.
As the name suggest, Multi-Head involves multiple monitors connected to the same computer, with a single mouse and keyboard. With XFree86, a "ServerLayout" section in the XF86Config file tells the X-Windows system how the monitors are physically located relative to each other.
A basic Multi-Head configuration will come up with one "screen" per monitor. Although the mouse can travel between monitors, windows are confined to the screen on which they were launched (see Single Logical Screen and Xinerama for the New Way.) It is possible to select the screen on which windows are launched by setting the DISPLAY variable or -display option for the application. Assuming windows are launched from the local host:
-display :0.0
or
-display :0
selects the default screen, while
-display :0.1
and
-display :0.2
select the extra screens. If they do not exist, such a display
setting will cause a failure. Since each screen has a different
default value for the DISPLAY variable, no -display option results
in a window being launched on the current screen, as expected.
(The DISPLAY variable is inherited from the window manager.
In the case of FVWM1, there are three window managers running
if you have three multi-head screens.)
Figure 5 shows the particular configuration used on our Hewlett Packard 9000 display host `` neptune'' on the summit.
A small, but handy piece of free software called x2x exists to allow separate X-Terminals to be joined into a similar Multi-Head configuration (where applications remain confined to the terminal on which they began.) As in figure 5, only one keyboard/mouse is used to control up to three screens, but the unix DISPLAY names would be something like ``xt1:0.0'' ``xt2:0.0'' and ``xt3:0.0''.
Another HP on the summit used as the Telescope Control System's display console, ``hookele'' has two of its screens merged into one logical screen using HP's SLS. The main advantage is that windows can be dragged between these two monitors, which are now both seen as one, wide DISPLAY="hookele:0.0".
It then becomes the responsibility of the window manager to know where the divisions between the monitors are, or else windows will tend to pop up right on the split, or on completely different screen from the user's mouse cursor, which can be confusing.
At the time we installed `` hookele'', which is the example shown in figure 6 we made our own, custom SLS patch to the FVWM 1.24 window manager to handle this case. The patch only handles two 1280x1024 monitors put together in a 2560x1024 logical screen.
Xinerama and PanoramiX are associated with new features of the X-Servers used with Linux. They currently provide some of the same functionality as Hewlett Packard's SLS. With XFree86, a Xinerama configuration uses the same XF86Config file as a similar Multi-Head config would use, but with a special flag or option to turn on the Xinerama feature.
The Xinerama extension also provides a way for a window manager to query the server about the physical layout of the monitors making up the logical screen. Version 2 of the FVWM window manager is one of the "Xinerama-aware" window managers currently available. Without any special options or hacks, it automatically handles things like placing windows on the same screen as the mouse pointer, or providing "EdgeResistance" to help snap windows to the physical edges of the monitors. This is more important than it may at first seem. Consider the case where the user is working with a graphical tool that opens a confirmation popup. If this popup appears two screens away where the user may not even notice, this is a Bad Thing.
Figure 7 shows the current configuration of the new Linux Display Hosts maka (at the summit) and ike (at Waimea headquarters.)
The ``Pager'' shows the user which page of the desktop is currently visible, and allows them to move the viewport by clicking on a new section of the desktop. The Control+ArrowKeys have also been configured to move by a page at a time in the direction of the arrow pressed.3
It is worth mentioning a few features of the ``XFree86'' X11 display servers which we currently run on our Linux platforms. We originally purchased a commercial X-Server from Xinside Graphics for our first Linux multi-head display, but today aspects of the free X-Server project have surpassed the commercial version, so all of our displays run either XFree86 version 3 or XFree86 version 4.
Probably the commercial X-Server has caught up, and perhaps added other useful features. Our license should still work with new copies of the product if anyone wishes to experiment. For example, recently on a Sony TR2A laptop we found that the Xinside server was the only way to support its full LCD resolution.
Because of the wide range of AGP and PCI graphics hardware available for PCs, XFree86 version 4 uses loadable modules for each type of graphics card. To simplify installation of the server in our older, RedHat Linux distribution, which was not based on this model, we have chosen an option which builds all drivers statically into the X-Server binary.
Graphics cards and drivers various features which can be interesting to astronomy applications. The following sections list some of these features and the current state of support for these features. Clearly, both the graphics card and the driver for that card must implement the feature for it to be useful to us.
This display mode uses an 8-bit wide (256 entry) color-lookup table. Only 256 colors may be displayed at a time for the whole display. They are chosen from a 24-bit color palette. The color palette could be configured to show 256 grey intensities at a time, or a selected set of colors, or a combination of the two, but the total number of unique colors on the screen can never be greater than 256. Since the color palette must be shared by applications on the same display, there are often problems with applications not getting enough ``color cells.'' Various models for sharing colors and replacing the colormap with the one of the active application (resulting in ``flashing'' of the display) exist, but none of these seem worth it today, when memory costs around 10 cents per megabyte.
All of our new displays and display drivers are capable of using a mode where the intensity of red, green, and blue can be set separately for each pixel to a precision of 8-bits for each primary color. Essentially, any pixel can be any color. This most likely the mode we want to run, but there is a problem.
While PseudoColor mode was mainly invented to save memory, many of the image display tools our users are used to rely on a ``trick'' which requires manipulation of the current colormap to enhance contrast in different parts of the displayed image. This does not work in TrueColor mode.
DirectColor mode may provide a solution to this problem, but would require some minor modifications to the image viewer applications. (Some applications such as IDL already support this mode.) DirectColor also uses 24-bits per pixel, where 8-bits represent red, 8-bits green, and 8-bits for blue (just like 24-bit TrueColor), but the final red, green, and blue intensities for the actual pixel are obtained by looking up the value in a lookup table, much like PseudoColor mode.
When these three lookup tables are all initialized to a linear ramp, DirectColor mode is equivalent to TrueColor. When they are initialized to the appropriate gamma curves, the can be used to perform a final gamma correction of the intensity for a particular monitor. For our application, the lookup table can be used exactly as the lookup table in PseudoColor mode by simply setting the same value for Red, Green, and Blue when drawing the image.
We have not determined which of our graphics cards and/or drivers support this mode.
Overlay mode is another attractive solution allows an actual 8-bit PseudoColor mode to co-exist with 24-bit TrueColor. Both exist at the same time in two different frame buffers, and the X-Server maintains a mask of which pixels on the screen are currently using which color model. With this option, no modifications to old applications requiring 8-bit PseudoColor would be required, while applications which can make use of more ``modern'' color models can request TrueColor for their windows at the same time.
Both types of digital video cards which we have used with our 1600SW flatpanel screens support Overlay mode, but only the X-Server for the 3DLabs card implements the feature. The Number Nine X-Server which we use for both three-headed displays does not.
Window Session software running on the Session Host has been kept purposely light weight. We do not use the CDE, Gnome desktop (which may become the successor to CDE), or KDE. In fact, we run no desktop/session manager at all, only a basic window manager.
FVWM. It has been configured to emulate the Motif Window Manager (MWM) just as the CDE does.
This and a few terminal windows are typically the extent of ``standard'' desktop software an observer needs to do their work. Features like saving workspace states and high level color management are often even undesirable in our environment.
Almost any display in the building (including PCs running an X-Server such as Exceed) can be used as the Display Host. A ``virtual desktop'' feature of the window manager can be enabled by the user to gain more desktop space when running on a single monitor.
The Motif Window Manager is a classic X11 Window manager, and has been the standard for CFHT's ``Pegasus Sessions'' in the past. The CDE's window manager, dtwm, has the same look and feel as the Motif Window Manager.
FVWM is another manager with the ability to emulate the behavior look and feel of Motif Window Manager, making a transition from mwm to fvwm transparent to users. FVWM uses less resources than MWM and has additional features, some of which are described below. Even at the time we started using FVWM 1, it was no longer supported. This did not turn out to be a burden. We did add some trivial patches to the source code to improve handling of configuration files and behavior of the window manager on our first Single-Logical-Screen X-Server (see below.) It was the simplest and most stable window manager which could run the same way on our Solaris, HP-UX, and Linux platforms.
FVWM version 2.4 introduces proper support for arbitrary Single-Logical-Screen configurations through an X-Server extension. In addition, since FVWM 2.4 is actively supported by its developers, CFHT's does not have to maintain a specially patched version (not that this was a very big problem, but it still helps.)
