Skip to ContentSun and Oracle Channel Sun How to Buy Log In

OpenWindows Server Programmer's Guide

Contained Within

Solaris 2.4 Software Developer AnswerBook

Find More Documentation

Featured Support Resources

Descargar este libro en PDF

Visuals and Display Devices

6

This chapter defines some of the terms used to describe how client applications and the OpenWindows server interact to control what is displayed on a user's screen. Multiple hardware colormaps and advanced display devices are discussed, and some important programming hints are provided.

The X11 server requires you to take responsibility for ensuring your applications run properly on a wide variety of machine configurations.

Display Devices

The computer monitor is connected to a display device (also called a graphics adapter) that controls what is shown on the screen. The display device has memory dedicated to storing display information.

Reference Display Devices

The OpenWindows server treats certain display devices as reference devices. This means that example device handlers for these devices are provided in the Solaris DDK (Driver Developer Kit). These devices are described in more detail in "Reference Devices and Visuals" on page 51.

SPARC Supported Reference Devices

The SPARC reference devices supported by the OpenWindows server are:

x86 Supported Reference Devices

The x86 reference devices supported by the OpenWindows server are:

vga4
vga8
8514

IHV Display Devices

In addition to the reference devices, the OpenWindows server supports any device for which a valid device handler is written and configured into the system. The process of writing and configuring a device handler is described in the OpenWindows Server Device Developer's Guide, which is included in the Solaris DDK product.

Visuals

A display device can support one or more display formats. In the X window system, the display formats supported by the window server are communicated to client applications in the form of visuals. A visual is a data structure describing the display format a display device supports.

Multiple Depth Devices

These devices are called multi-depth devices. Since most of these devices are implemented with separate groups of bit planes for each depth, the term multiple plane group (MPG) device is often used.

For most MPG devices, windows can be created using any of the exported visuals.

Default Visual

For each X11 screen, there is one special visual that is designated the default visual. This is the visual assigned to the screen's root window and is, unless otherwise specified by the client, the visual which client window's are assigned. See "The Default Visual" on page 55 for more information.

Reference Devices and Visuals

This section describes in greater detail the reference display devices supported and the visuals they export.

Reference Devices

The reference display devices supported by OpenWindows are listed in Table 6-1.

Note - Throughout this chapter "n/a" means not applicable.

Table 6-1

Product Name	Device Name	Device Driver	Bus	Exported Depths
n/a	BW2	`/dev/fbs/bwtwo`X	SBus, VME/obio, P4	1-bit
n/a	CG3	`/dev/fbs/cgthree`X	SBus	8-bit
GX	CG6	`/dev/fbs/cgsix`X	SBus, P4	8-bit
GXplus/ TurboGXplus	CG6	`/dev/fbs/cgsix`X	SBus	8-bit
TC	CG8	`/dev/fbs/cgeight`X	SBus, P4	1, 24-bit (MPG)
VGA	vga4	`N/A`	ISA, EISA, MCA	8-bit
VGA	vga8	`N/A`	ISA, EISA, MCA	8-bit
8514/A	i8514	`N/A`	ISA, EISA, MCAS	8-bit

Product Name The product name is commonly used to identify the type of display card.

Device Name The device name is used to specify the display adapter to OpenWindows.

Note - If there is a distinct product name for a device, the product name is used in preference to the CGn device name (for example, TC is used, not CG8).

Device Driver The device driver is the name of a device in the UNIX file system, where X is the number of that particular device on your system. For example, if a system has two CG3s, the first would be /dev/fbs/cgthree0, and the second would be /dev/fbs/cgthree1. If a system has one CG3 and one GX, the CG3 would be /dev/fbs/cgthree0 and the GX /dev/fbs/cgsix0. The server is configured to support a maximum of 16 displays; the limitations you might encounter are the number of framebuffers your hardware supports.

Bus The bus is the system input/output (I/O) link. The display device is both physically and logically connected to the system by the bus. The SBus, VME, and P4 buses are used in SPARC systems. A third party system may use a bus other than one of these three buses.

Exported Depths These are the depths of the visuals advertised by the server for screens of this particular device type. MPG (Multiple Plane Groups) indicates that this device supports multiple depth visuals.

SPARC Device-Specific Information

BW2 The BW2 is a simple 1-bit frame buffer, supporting monochrome monitors. The device handler for this device exports the 1-bit StaticGray visual only. Therefore, this visual is the built-in default visual. A variety of BW2 frame buffers is available for different buses and different screen resolutions, including third party offerings.

CG3 The CG3 is a simple 8-bit indexed color, dumb frame buffer for SBus systems. The device handler for this device exports several 8-bit visuals (listed below). The built-in default visual is 8-bit PseudoColor.

GX and GXplus (CG6) The GX is an 8-bit indexed color graphics accelerator, specializing in 2D and 3D wireframe, flat-shaded polygon, and general window system acceleration. Window system acceleration is automatic; you can access other acceleration features through Solaris visual graphics APIs. Several 8-bit visuals are supported (see below) and the built-in default visual is 8-bit PseudoColor. The GX is available for SBus and P4 bus.

The GXplus device is similar to the GX with additional memory that can be used for double buffering and expanded screen resolution on SBus systems. The OpenWindows server uses the GXplus to automatically accelerate X11 pixmaps by using offscreen storage whenever possible.

Note - This chapter treats the GXplus as a GX.

TC (CG8) The TC device possesses two separate memory buffers, or plane groups: 1-bit monochrome and 24-bit color. Windows may be created in both plane groups; therefore, it is an MPG device. All 1-bit and 24-bit visuals are supported.

Some (older) X11 client applications assume that color frame buffers use an 8-bit built-in default visual and do not run in color on the TC. To avoid this, the built-in default visual is 1-bit StaticGray. "The Default Visual" on page 55 describes how to change the default if a color default visual is desired.

The plane groups of the TC do not conflict with each other; they are completely separate memory buffers. OpenWindows, by default, takes advantage of this to increase system performance by not damaging 1-bit windows when they are occluded by 24-bit windows, and vice versa. This behavior is called minimized exposure. This behavior may be disabled by using the -nominexp option of openwin(1). If this option is used, 1-bit windows will damage 24-bit windows and 24-bit windows may damage 1-bit windows.

The OpenWindows server also provides minimized exposure for other IHV MPG devices, when applicable. Use the -nominexp option of openwin with these devices.

Note - The X protocol states that cursor components can be arbitrarily transformed. To enhance general system performance, the OpenWindows server always renders the cursor in the 1-bit plane group of the TC.

x86 Device-Specific Information

VGA

The VGA is a simple color dumb frame buffer. The server supports VGAs as 8-bit indexed color with all visual types and a default of PseudoColor (vga8), or 4-bit StaticColor (vga4). When using 8-bit mode, the resolution is most often 1024x768. 4-bit mode is often limited to a resolution of 640x480 as this is the basic VGA graphics mode that is available on all VGA devices. Most VGAs provide a bitsPerRGB of 6.

Support for VGA panning is available in modes of the 4-bit VGA. Panning mode provides the ability to have a physical window that maps onto a larger virtual display. Movement within the virtual display is performed by "pushing" the mouse past the edge of the screen. The display will automatically move the physical window in the virtual display in the direction that the mouse was pushed until the physical window hits the edge of the virtual boundary.

Use panning only if you are an experienced OpenWindows user. Icons, pop-up boxes (menus/dialogs etc.) can appear off screen with no immediate visible notification. You must be experienced enough to recognize these situations, and be able to recover by looking for the hidden window objects. Pop-up pointer jumping is highly recommended while using panning. Virtual window managers, such as olvwm or tvwm, can cause additional confusion; do not use them.

The vga8 server is also capable of supporting the XGA as a dumb frame buffer.

8514/A

The 8514/A is an 8-bit indexed color graphics accelerator providing general window system acceleration. It provides substantially improved performance compared to a VGA. The server limits its support of 8514/As to 8-bit indexed color and a resolution of 1024x768 or 1280x1024. It supports all 8-bit visuals. The built-in visual is 8-bit PseudoColor. Most 8514/As provide a bitsPerRGB of 6.

The Default Visual

At all times, a default visual exists. The default visual of an X11 screen is one of the exported visuals for the screen. When a client application is executed, its windows are assigned the default visual unless it specifies non-default or alternate visuals.

The built-in default visual is the visual hard-coded in the OpenWindows server. This is the default visual unless you specify a different default visual when you run openwin(1). The built-in default visual for each screen varies with the characteristics of the screen's display device.

The screen default visual is the visual advertised to clients in the connection block. This is the built-in default visual unless you specify a different supported visual to be the default when you start up OpenWindows.

An allowable default visual is a supported visual that can be the screen default visual.

Changing the Screen Default Visual

At times, it may be desirable to change the default visuals that the X11 window server advertises in the X11 connection block. One possible reason is to force client programs that cannot run in alternate or non-default visuals to run in a selected visual. You should be careful when using this mode because the default visual can have a subtle effect on the behavior of many client programs. Often, client programs are unable to deal with visuals of some depths or classes, especially those with 24-bit depths.

The default visual and the list of supported visuals exported by the server can be examined from X11 using XGetVisualInfo(3).

To make an allowable default visual the screen default visual, the class and depth of the visual must be specified on the openwin command line with the -dev option:


  example% openwin -dev <device modifier options>

Table 6-2 describes the available device modifier options pertaining to the screen default visual.

Table 6-2

Device Modifier Options	Description
`defclass` *<class>*	This option uses the specified visual as the default visual. The default is device-dependent. The legal values are: GrayScale, StaticGray, PseudoColor, StaticColor, DirectColor, and TrueColor.
`defdepth` *<n>*	This option selects the depth of the screen default visual. n is an integer that specifies the depth. The default is device-dependent.
`grayvis`	This option indicates the screen default visual is to have a gray class (StaticGray or GrayScale).

The defclass option is used to determine the visual class of the screen default visual, and may be used by itself or in combination with grayvis.

If grayvis is specified, color visuals are not supported by the server. After using the grayvis option, StaticColor and PseudoColor are not returned by XGetVisualInfo(3).

SPARC Example

As an example, the following command line runs OpenWindows on the GX device with an 8-bit StaticGray screen default visual.


  example% openwin -dev /dev/fbs/cgsix0 grayvis

x86 Example

As an example, the following command line runs OpenWindows on the VGA device with an 8-bit GrayScale screen default visual.


  example% openwin -dev vga8 grayvis

Troubleshooting/Error Messages

If the device does not support the requested visual, the following error message is returned. (# represents the depth number requested and n represents the requested display device.)


  Error: cannot provide a default depth # for device /dev/fbs/n

If this message is returned for a supported visual/device combination as indicated in Table 6-1 on page 51, then an installation problem exists.

If you are experiencing improper graphics and double-buffering performance (such as lack of acceleration), OpenWindows might not have been installed as root.

Hints for Windows Programming With Visuals

This section discusses various issues that arise when programming X11 applications targeted to devices that support different visuals. In particular, programming for portability is discussed.

Default Visual Assumptions

A common mistake in programming an X11 client is assuming that the default visual has an indexed class (for example, PseudoColor or StaticColor). It is possible for the default visual to be 24-bit TrueColor on some devices. Clients expecting to run on these devices must be prepared to handle this type of default visual.

Here are some common mistakes:

Assuming the default depth is 8

Assuming the colormap is writable
Using a default visual that is not appropriate rather than searching for an appropriate visual using XGetVisualInfo

In general, clients may need to be modified to make them more portable in the presence of different default visual types.

Multiple Hardware Colormaps

The OpenWindows environment also supports devices with multiple hardware color lookup tables (LUTs). Multiple color LUTs are provided on some devices to reduce colormap flashing. This is a visual effect (sometimes called technicolor) which happens when the pixels of one window are displayed with the colors of another window, because there are not enough simultaneously displayable colors on the device. Multiple color LUTs increases the number of colors simultaneously displayable and, thus, alleviates colormap flashing.

This section describes information you should know about multiple hardware colormaps from an application programming and end user perspective.

Colormap Installation-Multiple LUT Devices

Ultimately, it is the window manager that decides which colormaps are installed in which LUTs. This is referred to as the window manager colormap installation policy. This policy is different from the server colormap installation policy. The server colormap installation policy only specifies how the server reacts to various InstallColormap and UninstallColormap requests; the window manager colormap installation policy defines how and when a window manager will send these requests to the server.

Colormap Demo

The program /usr/openwin/bin/xcolor provides a convenient way of visually understanding what is happening to your hardware LUT. It always displays the most recently installed colors in the hardware colormap, arranged in a 2D array. Each row has 16 colors. Pixel 0 is in the upper left-hand corner and pixel 255 is in the lower right-hand corner. This demo program is very useful for understanding colormap flashing behavior.

Note - Do not confuse what you see with the contents of the default software colormap. The default software colormap will be seen only if it is installed. Additionally, extra colors may be present in the hardware colormap that are not allocated in the default colormap because of installation rules.

Note - xcolor is only useful for viewing the LUT on a single LUT device. On a multiple LUT device, the LUT viewed may change in unpredictable ways.

Gamma-Corrected Visuals

The linearity attribute of a visual describes the intensity response of colors it displays. On a cathode ray tube (CRT) monitor, the colors displayed are actually darker than the colors requested. This darkening is caused by the physics of monitor construction. The actual light intensity response of CRT monitors follows a power function:

Figure 6-1

The exponent of this function (.) is called the visual's gamma. The dotted line in the figure represents the desired response. The solid line represents the actual response of the monitor. On Sun systems, gamma is usually 2.22 but, in general, it can vary slightly between monitors. Most liquid crystal display (LCD) monitors have a gamma of exactly 1.0.

Some devices support visuals that compensate for this darkening effect. This is called gamma correction. The ZX, a Sun 3D accelerator, is an example of a device that does this. This correction is done by altering colors coming out of the frame buffer with the inverse of the monitor's response.

Figure 6-2

Refer to Fundamentals of Computer Graphics, Foley and Van Dam for a fuller discussion of gamma correction.

Because the overall intensity response is a straight line, a gamma corrected visual is called a linear visual. A visual that is not gamma corrected is called a nonlinear visual.

Some applications require a linear visual to avoid visible artifacts. For example, an XGL application using antialiased lines may produce objectionable "roping" artifacts if it does not use a linear visual. This kind of application is called a linear application. An application requiring a nonlinear visual for best display of colors is called a nonlinear application. Most X11 applications are of this variety.

The linearity of default visuals on most devices is nonlinear. Therefore, linear applications should not depend on the default and should always explicitly search for a linear visual. See "Finding a Linear Visual" on page 61 for an example.

Note - In similar fashion, it is a good idea for nonlinear applications to explicitly search for a nonlinear visual. However, since this is typically the default on most devices, it is not as critical. But it is still a good policy to do so.

Finding a Linear Visual

Linearity is not a standard X11 attribute. However, it can be determined on Solaris by querying the visual's gamma. This is done by calling XSolarisGetVisualGamma(3). To use this routine, the application must be linked with the Solaris libXmu. If the gamma value is equal to (or close to) 1.0, the visual is linear. Otherwise, it is nonlinear. (A good rule-of-thumb for the closeness tolerance is 10%).

Code Example 6-1 on page 62 is an example of selecting the best visual for a typical XGL 3D linear application. In this example, the application uses a nonlinear visual if a linear one cannot be found. This is only one possible visual selection policy.

Code Example 6-1 XGL 3D linear Visual Selection


  /*  
  ** Returns the visual of the given depth, class and linearity,  
  ** or NULL if not found.  
  */  
  Visual *  
  match_visual (Display *dpy, int screen, int depth, int class,  
                 Bool wantLinear)  
  {  
   XVisualInfo template;  
   XVisualInfo *vinfo, *vi;  
   int nitems, isLinear, i;  
   double gamma;  
  
   template.screen = screen;  
   template.depth = depth;  
   template.class = class;  
   if (!(vinfo = XGetVisualInfo(dpy, VisualScreenMask | VisualDepthMask |  
                    VisualClassMask, &template, &nitems)) || nitems <= 0) {  
       return (NULL);  
   }  
  
   for (i = 0, vi = vinfo; i < nitems; i++, vi++) {  
       if (XSolarisGetVisualGamma(dpy, screen, vi->visual, &gamma)  
           == Success) {  
        /*  
        ** A good rule of thumb for linearity of a visual is whether  
        ** the gamma is within 10% of 1.0.  
        */  
        isLinear = (gamma >= 0.9 && gamma <= 1.1);  
        if ((wantLinear && isLinear) || (!wantLinear && !isLinear)) {  
           Visual *visual = vi->visual;  
           XFree(vinfo);  
           return (visual);  
        }  
       }  
   }  
  
  XFree(vinfo);  
  return (NULL);  
  }

Here is the main routine of the example:


  main ()  
  {  
       Visual vis;  
   ...  
  
   if ((vis = match_visual(display, screen, 24, TrueColor, True))) {  
       fprintf(stderr, "Found a linear 24-bit TrueColor visual\n");  
       visualClass = TrueColor;  
       depth = 24;  
  }  
  else if ((vis = match_visual(display, screen, 24, TrueColor, False))){  
       fprintf(stderr, "Found a nonlinear 24-bit TrueColor visual\n");  
       visualClass = TrueColor;  
       depth = 24;  
  }  
  else if ((vis = match_visual(display, screen, 8, PseudoColor, False))){  
       fprintf(stderr, "Found a nonlinear 8-bit PseudoColor visual\n");  
       visualClass = PseudoColor;  
       depth = 8;  
  }  
  else {  
       fprintf(stderr, "Cannot match 24 or 8 bit visual\n");  
       exit(1);  
  }  
  
   ...  
  }

Note - If the gamma of any visual on the device is changed, either through reconfiguration or calibration, the window system should be restarted. Otherwise applications using XSolarisGetVisualGamma that are already running will not detect the change and may use the wrong visual.

Visual Selection Alternatives

The above example illustrates only one possible visual selection policy. Other policies can be implemented. It is recommended that applications be written to handle a wide variety of visual configurations. Some devices, for example GX, do not have any linear visuals. Other devices, for example ZX, have only a single linear 24-bit TrueColor visual. Other devices like SX (a Sun imaging accelerator) can support such a visual but don't by default; they must be

reconfigured. Some other devices may support both linear and nonlinear visuals at the same time. In general, the most prudent way to write a portable application is to deal gracefully with all these configurations. This may involve printing a warning message if the visual of the desired linearity is not found. Or, if a linear application cannot find a linear visual, a useful trick is to manually darken in the application the colors given to X11. This is tantamount to performing your own gamma correction. The gamma value returned by XSolarisGetVisualGamma can be used to determine how much to darken the colors.

Support Level

XSolarisGetVisualGamma is a Public interface of Solaris and is fully supported. In the future, a color management system may also provide this functionality. When this occurs, this will become the preferred way of getting this information. But until then, XSolarisGetVisualGamma should be used. When this color management system is introduced, applications using XSolarisGetVisualGamma will continue to run with no modification and will actually benefit from the increased accuracy of the color management system.