Miscellaneous Topics

Setting/Unsetting Environment Variables

Each type of shell (sh, csh and ksh) have different ways of setting and unsetting the value of environment variables to desired values. The following table shows an example of how the DISPLAY variable is set (where 〈value〉 would be in the 〈host〉:〈display〉.〈screen 〉 format) and unset for each shell type.

Throughout this file, when an environment variable is defined, it will include a list of valid values or will state that any value is acceptable. When any value is specified, any non-null string is acceptable, but often the value is set by convention, to TRUE (e.g., "export 〈variable〉 =TRUE" in ksh).

Double Buffer Extension (DBE)

DBE is an extension to the X server that provides a double-buffering Application Programming Interface (API). Note that MBX (the Multi-Buffering eXtension to X) has not been adopted as an industry standard, as DBE has. Thus, it is recommended that applications that use MBX be ported to DBE usage in preparation for future MBX obsolescence. For more information about DBE and the API, consult the DBE man pages:

MBX

The MBX extension (Multi-Buffering Extension) is supported on all graphics devices supported on the HP 9000/700 machines, except the PersonalVRX and the TurboVRX.

HP's implementation of MBX exists mainly to support fast double-buffering for PEX applications. Therefore, MBX only supports allocation of one or two MBX buffers; no more. Some graphics devices/visuals have a single 8-plane buffer; these include Internal Color Graphics, Integrated Color Graphics, Color Graphics cards, Dual Color Graphics cards and the overlay planes on the CRX-24[Z], CRX-48Z, the HCRX family and the Freedom Series Graphics (S3150, S3250 and S3400). For these devices, MBX double-buffering is still supported, but the second bank is allocated in virtual memory. Rendering and buffer-swapping in these instances is slower than devices/visuals that support true hardware double-buffering.

Currently, there is no easy way to determine which visuals, from a device's list of visuals, support fast MBX hardware double-buffering. The CRX and Dual-CRX device is a double-buffered device and therefore always supports MBX hardware double-buffering. The Internal Color Graphics, Integrated Color Graphics, Color Graphics cards and Dual Color Graphics cards only support MBX software buffering. All other devices that have both overlay and image planes support fast MBX hardware double-buffering in the image planes and slower MBX software double-buffering in the overlays. Consult the following device-specific sections for a list of visuals that support software and hardware MBX double-buffering.

For performance reasons, the default MBX behavior is to not synchronize with the monitors vertical retrace period. In some instances, image tearing could be visible while swapping large MBX windows. For those instances where tearing would occur and is undesirable, an optional X server mode is available to allow for synchronization with vertical retrace. To activate this optional X server mode, set the environment variable SWAP_BUFFERS_ON_VBLANK to any value before the X server is started.

With this mode enabled, all MBX buffer swaps are synchronized with the monitor's vertical retrace period. This mode is not needed in drawables used for PEX rendering. PEX turns synchronization on and thus does not require this tuning.

The MBX Application Programming Interface is thoroughly discussed in the O'Reilly & Associates, Inc. PEXlib Programming Manual by Tom Gaskins. Consult that manual to understand the creation, manipulation, and destruction of MBX buffers.

Since MBX is not an industry standard, developers should replace MBX calls with DBE calls.

	NOTE: Note that XmbufGetScreenInfo() can indicate that a window supports MBX even if only one MBX buffer is supported. An application should always check the max_buffers field in the returned XmbufBufferInfo structure before assuming that a window supports two MBX buffers.

Single Logical Screen (SLS)

SLS is a mechanism for treating homogeneous multi-display configurations as a single "logical" screen. This allows the moving/spanning of windows across multiple physical screens. "Homogeneous" means SLS only works if the graphics devices included in the "SLS Configuration" are of the same type (see the list of the supported SLS configurations shown below.) SLS is enabled via the /usr/lib/X11/X0screens file with the syntax:

SingleLogicalScreen n m
    /dev/crt0 ... /dev/crtk

where n=the number of "rows" in the physical configuration, m=the number of "columns" in the physical configuration, and the product of n×m is less than or equal to four.

For example, to create a logical screen that is one screen tall by two screens wide, the following syntax would be used:

SingleLogicalScreen 1 2
    /dev/crt0 /dev/crt1

Whereas for a logical screen that is two screens tall by one screen wide, the syntax would be:

SingleLogicalScreen 2 1
    /dev/crt0 /dev/crt1

HP Color Recovery

Color Recovery is a technique that generates a better picture by eliminating the graininess caused by traditional dithering techniques. It is available on these graphics devices:

Color Recovery is available when using either PseudoColor or depth-8 TrueColor visuals.

There are two components to the Color Recovery process. First, a different dither-cell size (16×2) is used when rendering shaded polygons. Second, a digital filter is used when displaying the contents of the frame buffer to the screen.

Under some conditions, Color Recovery can produce undesirable artifacts in the image (this also happens with dithering, but the artifacts are different). However, images rendered with Color Recovery are seldom worse than what dithering produces. In most cases, Color Recovery produces significantly better pictures than dithering.

Color Recovery is available by default for all depth-8 color visuals on devices that support the feature. If, for some reason, you wish to disable Color Recovery, set the HP_DISABLE_COLOR_RECOVERY environment variable to any value before starting the server.

Color Recovery is enabled in conjunction with a particular X colormap that is associated with your window. If the X colormap is not installed in hardware, you may not see the effect of the Color Recovery filter (you may not even see the correct colors for that window). Given that more than one hardware colormap (or "color lookup table") is available, this should happen infrequently.

The Color Recovery colormap is a read-only colormap. Any attempts to change it will be ignored and no error will be reported.

Access to the Color Recovery capability is transparent when using a 3D graphics API such as Starbase, HP-PHIGS or PEX. If you are producing graphics using Xlib calls, your application must perform some of the necessary processing. The method to access Color Recovery via Xlib is described in a section called "Accessing HP Color Recovery Technology via Xlib" in the device-dependent sections.

Dynamic Loading

HP's X server now dynamically loads the appropriate device drivers and extensions based on the target graphics display device and the extensions it supports. This feature should be transparent to X server users.

The extension/device relationships are explained in the extension specific sections of this file.

	NOTE: Altering or removing files under /usr/lib/X11/Xserver may prevent the X server from running.

Shared Memory Usage

Graphics processes use shared memory to access data pertaining to the display device and X11 resources created by the server. ("Resources" includes windows, colormaps, and cursors.) The X11 server initiates an independent process called the Graphics Resource Manager (GRM) to manage these resources among graphics processes. Graphics processes include PEXlib, PHIGS, and Starbase applications. One problem encountered with GRM shared memory is that it may not be large enough to run some applications.

Graphics applications that require VM double-buffering (for example, when the HP_VM_DOUBLE_BUFFER environment variable is used) use large amounts of shared memory. Shared memory can be completely consumed by several double-buffered graphics windows. When an application attempts to use more shared memory than is available, the application encounters errors and might terminate.

You can circumvent the problem by using environment variables to change the shared memory size.

Changing Graphics Shared Memory Size

The size of the shared memory segment used by the GRM can be controlled through an environment variable. The default value is 0x580000 (5.5 Mbytes) on Series 700 computers.

	NOTE: The actual GRM shared memory size on a system can be determined by running "ipcs -ma", finding the entry with CPID matching the process ID of the grmd process and then checking the segment size (SEGSZ) field.

If more shared memory space is needed, graphics shared memory size can be increased. For example, to set it to eight megabytes in ksh:

export GRM_SIZE=0x800000

Note that the value must be in hexadecimal. The new value won't take effect until you restart the X11 server.

It is also possible to decrease the size of GRM shared memory. You may want to do this if you want to reduce the swap space requirements of your system and/or you do not intend to run any 3D graphics processes. For example, you could reduce graphics shared memory size to 0x100000 (one megabyte).

Count Transparent In Overlay Visual

In some configurations, an 8-plane overlay visual may have less than 256 colors. This should not cause a problem for most applications. If an application depends on 8-plane visuals having 256 colormap entries, this option may be useful. Setting this option to any value will cause the X server to count transparent entries in the number of colormap entries.

Examples of Relevant Graphics Devices: CRX-24[Z], CRX-48Z, HCRX-8[Z], HCRX-24[Z], HP Visualize-8, HP Visualize-24, HP Visualize-48

Environment Variable To Use: HP_COUNT_TRANSPARENT_IN_OVERLAY_VISUAL

Enable Overlay Transparency

This option is used to enable the usage of an overlay transparent color on devices that can support it, but, by default, do not allow it (for example, HCRX-8).

Examples of Relevant Graphics Device: HCRX-8[Z], HP Visualize-8

Environment Variable To Use: HP_ENABLE_OVERLAY_TRANSPARENCY

The variable may be set to any value before starting the X server.

Note that setting this variable will cause the number of colormaps to drop to one in the Overlay planes and one in the Image planes. See the section on the HCRX family of devices for more information.

3-Bit Center Color

This option is available to force the X server to center colors in the colormap to values that will reduce the amount of twinkle on flat-panel conversion. This option applies only to flat-panel displays.

The twinkling effect is caused by the analog-to-digital conversion. Due to noise in the analog signal, it is possible for a color near a boundary between two digital values to cause the conversion to bounce back-and-forth between the two colors (i.e., twinkle). In order to avoid this effect, the server "centers" the colors as far from the color boundaries as possible.

Examples of Relevant Graphics Device: Integrated Color Graphics, Color Graphics cards, Internal Color Graphics

Environment Variable To Use: HP_3_BIT_CENTERCOLOR

The variable may be set to any value before starting the X server.

Image Text Via BitMap

When using the Xlib XDrawImageString() call to draw text, a visual effect may be seen where text appears to flicker as the background and foreground are drawn in distinct graphics operations. This option is available to eliminate the flicker effect but at the expense of reduced text performance. The option will make the X server first draw text to an off-screen pixmap prior to displaying it to the screen.

Examples of Relevant Graphics Device: Integrated Color Graphics, Color Graphics cards, CRX-24[Z], CRX-48Z, HCRX-8[Z], HCRX-24[Z], HP Visualize-8, HP Visualize-24, HP Visualize-48

Environment Variable To Use: HPGCRX_IMAGETEXT_VIA_BITMAP

The variable may be set to any value before starting the X server.

	NOTE: Using this option will reduce text performance.

Obsolete Environment Variables

These environment variables are no longer supported:

These environment variables are being replaced and may not be supported in future releases:

Special Device Files

Special device files are used to communicate between the computer and peripheral devices. The X server requires the use of a special device file for each graphics card present in the system.

Special device files are created with the mknod command. The mknod command resides in /etc and may only be invoked by a superuser (i.e., root). Although special device files can be made in any directory of the HP-UX file system, the convention is to create them in the /dev directory. Any name may be used for the special device file; however, the names that are suggested for the devices are crt, crt0, crt1, crt2, or crt3. It is also acceptable to use a name that is descriptive of the graphics device, for example, crt1.left or crt1.right. The usage statement for the mknod command is:

mknod: arg count
usage: mknod name b|c major minor [ cnode ]
       mknod name p

All graphics special device files are character device files with read-write permissions by all. For 9.0x systems, the major number will always be 12. The following table, in which the leading "0x" indicates that the number is in hexadecimal format, indicates which minor numbers to use for creating alternate device files.

Following are some examples of using the mknod entry for the HP-UX Operating System.

For an SPU with only one SGC interface slot (e.g., a Model 720) running Dual CRX graphics, a sample 9.07 mknod entry for the second graphics device would be:

/etc/mknod /dev/crt0.left c 12 0x000004
chmod 666  /dev/crt0.left

For an SPU with two SGC interface slots, a sample mknod entry for the other slot would be:

/etc/mknod /dev/crt1.right c 12 0x000000
chmod 666  /dev/crt1.right

Note that once the device file has been created, it is necessary to ensure that it has read-write permissions by all; i.e., "chmod 666".