Chapter 1: X Windows: HP-UX 11.0
Table of Contents
This chapter documents information specific to the HP X server. It describes
features unique to HP's X server, provides information on how to configure the
X server and includes a list of supported X configurations. For each
supported graphics device, device-dependent configuration information is
provided.
Information specific to a new release of the X server, beyond the scope of the
general information in this document, can be found in the HP-UX Release Notes
located in /usr/share/doc.
If you prefer to read this information on paper, see the Graphics
Administration Guide. It includes the same information as is contained
here in this on-line document.
Configuration of the X server is supported through SAM via an icon titled "X
Server Configuration". This icon resides either at SAM's top level or under
the top-level "Display" icon. This location is determined by the version of
the HP-UX operating system (later HP-UX releases will place "X Server
Configuration" under the "Display" folder).
There are several X*screens files used to configure the operation of
the X server. The SAM graphical user interface for X server configuration is
provided to simplify complexity and facilitate ease of use. While it is still
possible to modify these files manually (see below), using the SAM interface
greatly simplifies the process for creating Multi-Display and Single Logical
Screen configurations.
Our SAM component has the following actions:
Configure Print Server...
Modify Multi-Screen Layout...
Modify Server Options...
Single Logical Screen (SLS) ->
--------------------------------
Describe Screen...
Identify Screen
Modify Default Visual...
Modify Screen Options...
Add Screen to Configuration
Remove Screen from Configuration
The first group of actions can be thought of as "global" actions. They
will typically be active regardless of what has been selected. If any of
these menu items is not visible, it is because it is not supported under the
current configuration. For example, on systems containing only one graphics
screen, the last three menu items will not be visible.
The second group of actions can be thought of as "screen" actions. They will
be activated depending on which screens have been chosen. It is also possible
that the last two actions (Add and Remove) will be absent. When only one
graphics screen is present, SAM will treat this screen as though it is always
configured. Preselecting both configured and unconfigured screens will result
in only the first two screen menu options being active.
For manual changes, please refer to the sample files in the /etc/X11/
directory. Three files of particular interest are the X0screens,
X0devices, and X0pointerkeys files.
This file belongs in /etc/X11/X*screens, where "*" is the
display number of the server. For example, the "X0screens" file is
used when the $DISPLAY environment variable is set to
hostname
:0.
screen
and the server is invoked using the
":0" option.
The X*screens file is used to specify:
- Device-independent server options, and
- For each screen:
- What device file to use (required),
- The default visual,
- Monitor size, and
- Device-dependent screen options.
Note that all of the items above, except for device-independent server
options, are specified on a per-screen basis.
The X server supports up to four screens at a time. Specifying more than four
screens will cause a server error message.
- Blank lines and comments (text following "#") are ignored.
- Entries can occupy more than a single line.
- All symbols in the file are recognized case-insensitive.
Items must appear in the X*screens file in the order that they are
specified below.
[ServerOptions


server_option






server_option
]
{Screen
device_name
} ||
{SingleLogicalScreen
nRows
nCols



device_name1
. . .
device_nameN
}


[DefaultVisual



[Class
visual_class
]



[Depth
depth
]



[Layer
layer
]



[Transparent]]


[MonitorSize
diagonal_length
units
]


[MinimumMonitorPowerSaveLevel
level
]


[ScreenOptions




screen_option










screen_option
]
Brackets ("[" and "]") denote optional items. Italicized items in angle
brackets ("
" and "
") denote values to be specified. The
double vertical line ("||") denotes that one of the ored values
(items surrounded by braces, "{" and "}") must be included.
The block from the "Screen
device_name
" line to the
final "
screen_option
" line is referred to as a either a "Screen
Entry" or as a "Single Logical Screen entry".
As shown above, the X*screens format is composed of an optional block
specifying device-independent server options followed by one or more either
Screen or Single Logical Screen entries (maximum of four graphics devices).
The minimum X*screens file is a line with the keyword
"Screen" followed by a screen device file. For example:
Screen /dev/crt
For more information about server options, or about additional server
options, look in an information file (for example,
/usr/lib/X11/Xserver/info/screens/hp).
- GraphicsSharedMemorySize
memory_size
- Specify the size of the graphics shared memory region. The size must be
specified in bytes and must be in hexadecimal.
- Default value: 0x580000
- Environment Variables Replaced: GRM_SIZE,
WMSHMSPC.
- SMTSizes
size_spec
- The size of the SMT regions (see the
Shared Memory Transport section).
- Default value: 100000,90000,90000
- FileDescriptors
number
- The number of file descriptors available to the X server for its use. The
number of connections (clients, more or less) is limited by the number of
file descriptors.
The minimum value is 25, and a current maximum (as of HP-UX 10.20) of 384,
allowing a maximum of slightly under 256 total connections to the server.
The default value is 192 (which allows a few under 128 connections). If a
value provided is out of range, the server yields a warning and continues
using the minimum or maximum, as appropriate. There is, however, a limit
of 128 clients that can connect.
The command line option -lf
number
also
specifies the value.
- ImmediateLoadDles
- The Xserver delays loading of some X extensions until the first
protocol request to the given extension is received. Specifying this
server option forces all extensions to be loaded at X server startup.
Immediate loading of X extensions is the historical behavior of the HP-UX
10.10 and 10.20 X servers.
The minimum screen entry is a line with the keyword "Screen" followed
by a screen device file.
Optional specifications for default visual, monitor size, and device-dependent
screen options may follow this minimal screen description line.
- DefaultVisual
- This optional part of the format specifies the default visual that the
screen uses. Valid keywords following the "DefaultVisual"
keyword are "Class", "Depth", "Layer", and
"Transparent".
If no default visual is specified, then the standard default visual class,
depth, layer, and transparency for the graphics device is used.
Not all default visual specifications will work on all devices.
If there is an error in a specification, look in an information file for
more details (for example, /usr/lib/X11/Xserver/info/screens/hp),
in case it is newer than the document you're now reading.
- Class
StaticGray
|
GrayScale
|
StaticColor
|
PseudoColor
|
TrueColor
|
DirectColor
- Specify the class of the default visual.
- Depth
depth_value
- Specify the depth of the default visual (for example 8, 12, or 24).
- Layer
Image
|
Overlay
- Specify the layer of the default visual.
- Transparent
- Specify that a visual with an application-accessible transparent entry
in the default colormap be used.
Specifications in the "DefaultVisual" section, except for
"Depth", are ignored on VRX devices. See the
"ScreenOptions" section below for VRX-related options.
- MonitorSize
diagonal_length
Inches | MM
- Specify the diagonal size of the monitor. After the
"MonitorSize" keyword, you must specify the diagonal length of
the monitor and then the units. Use this entry only if you are using a
non-standard monitor.
- MinimumMonitorPowerSaveLevel
value
- Specify the minimum power save level to be used by the monitor during
screen blanking. You must specify a level of 0
3. If the option is not used, the
default is level 0. On devices that do not support DPMS, this option will
be ignored.
- ScreenOptions
- Screen options are device-dependent options that are documented in a
file in the X server information directory (for example,
/usr/lib/X11/Xserver/info/screens/hp).
Below are several sample X*screens files that illustrate the new format.
- This is the minimum legal X*screens file, the "Screen"
keyword followed by the screen device. Since no other information is
given, the X server will assume default values for other options and
settings.
Screen /dev/crt

Results of Minimal Legal X*screens File
- This is the minimum specification for a two-screen configuration. The
maximum number of screens supported on the X server is four. Here, the
displays associated with /dev/crt0 and /dev/crt1 are
referred to as "
host
:0.0" and "
host
:0.1", respectively.
Screen /dev/crt0
Screen /dev/crt1

Two Physical Displays, Two Separate Screens
- This sample X*screens file could be used on a system using
Internal Color Graphics with a 17-inch monitor. In this example, the
GraphicsSharedMemorySize is decreased to 1 Mbyte in order to
reduce the swap space requirements of the system. Decreasing
GraphicsSharedMemorySize is appropriate when you do not intend
to run any 3D graphics applications.
ServerOptions
GraphicsSharedMemorySize 0x100000
Screen /dev/crt
MonitorSize 17 inches
The display diagram would be the same as that of the "Results of Minimal
Legal X*screens File" configuration, above.
- This sample X*screens file could be used on a system with a CRX24
graphics device. The overlay visual is selected as the default. There
are 255 overlay colormap entries available on the CRX24. The 256th entry
is hard-wired to transparent. Having less than 256 colormap entries
should not cause a problem for most applications, but for those
applications that require 256 colormap entries, the
CountTransparentInOverlayVisual screen option should be used as
shown below. Note that any attempts to modify the 256th entry will have
no effect on the colormap.
Screen /dev/crt
ScreenOptions
CountTransparentInOverlayVisual
The display diagram would be the same as that of the "Results of Minimal
Legal X*screens File" configuration, above.
- This sample X*screens file could be used on a system with a
HCRX-24 graphics device. The default visual on the HCRX-24 is the opaque
overlay visual. All 256 colormap entries are opaque and allocable. If an
application requires transparency in the default visual, the
"Transparent" keyword can be used to select the transparent
overlay visual as shown below.
Screen /dev/crt
DefaultVisual
Transparent
The display diagram would be the same as that of the "Results of Minimal
Legal X*screens File" configuration, above.
- This sample X*screens file could be used on a system with a
HCRX-8 graphics device. By default on the HCRX-8, the overlay visual does
not have a transparent entry available to applications for rendering
transparency. If an application requires overlay transparency, an
optional X server mode is available, but it is restrictive. In this
optional mode, only one hardware colormap is available in the overlays
(instead of two) and only one hardware colormap is available in the image
planes (instead of two). The optional X server mode can be set via the
EnableOverlayTransparency screen option as shown below.
Screen /dev/crt
ScreenOptions
EnableOverlayTransparency
The display diagram would be the same as that of the "Results of Minimal
Legal X*screens File" configuration, above.
- This sample X*screens file could be used on a system using either
a PVRX or TVRX graphics device. The server will run in combined mode with
the default visual residing in the overlay planes. All visual depths
which are supported by the graphics device will be available.
Screen /dev/ocrt
ScreenOptions
VRXSecondaryDevice /dev/crt

PVRX/TVRX Display with Overlays
- This sample X*screens file could also be used on a system using
PVRX or TVRX graphics. The server will run in combined mode with the
default visual in the overlay planes and an 8/8 double-buffered visual in
the image planes. In general, specify VRXDoubleBuffer if
applications will be using DHA (Direct Hardware Access) double-buffer
functionality (e.g., Starbase double buffering).
Screen /dev/ocrt
ScreenOptions
VRXSecondaryDevice /dev/crt
VRXDepth 16
VRXDoubleBuffer
The display diagram would be the same as that of the "PVRX/TVRX Display
with Overlays" configuration, above.
- These sample X*screens file entries could be used on a system
with two homogeneous graphics devices. Assuming the first device is
associated with the device file "/dev/crt0" and the second device
is associated with the device file "/dev/crt1", both examples
specify a horizontal Single Logical Screen configuration.
SingleLogicalScreen 1 2
/dev/crt0 /dev/crt1
or
SingleLogicalScreen 1 2
/dev/crt0
/dev/crt1

Two Physical Displays, Single Logical Screen
(1
2)
- These sample X*screens entries could be used on a system with
four homogeneous graphics devices. Assuming the first device is
associated with the device file "/dev/crt0", the second device is
associated with the device file "/dev/crt1", etc. The following
examples specify valid Single Logical Screen configurations.
SingleLogicalScreen 1 4
/dev/crt0 /dev/crt1 /dev/crt2 /dev/crt3

Four Physical Displays, Single Logical Screen
(1
4)
SingleLogicalScreen 4 1
/dev/crt0
/dev/crt1
/dev/crt2
/dev/crt3

Four Physical Displays, Single Logical Screen
(4
1)
SingleLogicalScreen 2 2
/dev/crt0 /dev/crt1
/dev/crt2 /dev/crt3

Four Physical Displays, Single Logical Screen
(2
2)
- It is possible to include a Screen Entry and an SLS Screen Entry in the
same X*screens File. This creates a situation where there are
two X Screens (e.g.
host
:0.0
and
host
:1.0), one of which happens to
be a Single Logical Screen. Below is an example of this:
Screen /dev/crt0
SingleLogicalScreen 1 2
/dev/crt1 /dev/crt2

Three Physical Displays, Screen plus Single Logical Screen
(1
2)
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
(HP-UX 11.0). For more information about DBE and the API, consult the DBE man
pages:
DBE
XdbeQueryExtension
XdbeGetVisualInfo
XdbeFreeVisualInfo
XdbeAllocateBackBufferName
XdbeDeallocateBackBufferName
XdbeSwapBuffers
XdbeBeginIdiom
XdbeEndIdiom
XdbeGetBackBufferAttributes
For performance reasons, the default DBE behavior is to not synchronize
buffer swaps with the monitor's vertical retrace period. In some instances,
therefore, image tearing (seeing part of the old image and part of the new
image on the display at the same time) could be visible while swapping large
DBE windows. For those instances where tearing would occur and is
undesirable, an optional X server mode is available to allow for
synchronization of buffer swaps with vertical retrace. To activate this
optional X server mode, set the following screen option in the
X*screens File before the X server is started:
SwapBuffersOnVBlank
Note that MBX_SWAP_BUFFERS_ON_VBLANK is obsolete with this release.
The SwapBuffersOnVBlank Screen Option works for both DBE and MBX.
The DBE API does not allow users to determine if double-buffering in a visual
is through software or hardware. However, the API does provide a way to
determine relative swapping performance on a per-visual basis. The
XdbeScreenVisualInfo() function returns information about the swapping
performance levels for the double-buffering visuals on a display. A visual
with a higher performance level is likely to have better double-buffer
graphics performance than a visual with a lower performance level. Nothing
can be deduced from any of the following: the magnitude of the difference of
two performance levels, a performance level in isolation, or comparing
performance levels from different servers.
For more information, refer to the DBE man page on
XdbeScreenVisualInfo().
The X server supports DBE on the following devices:
- Internal Color Graphics
- Integrated Color Graphics
- CRX-24[Z]
- CRX-48Z
- HCRX-8[Z]
- HCRX-24[Z]
- HP VISUALIZE
-EG
- HP VISUALIZE-8
- HP VISUALIZE-24
- HP VISUALIZE-48[XP]
- HP VISUALIZE-FX2
- HP VISUALIZE-FX4
- HP VISUALIZE-FX6
- Freedom Series
Graphics (S3150,
S3250 and S3400)
Monitors constitute a large percentage of the power used by a workstation even
when not actively in use (i.e., during screen blanking). In order to reduce
the power consumption, the Video Electronic Standards Association (VESA) has
defined a Display Power Management Signaling (DPMS) standard which can be used
to greatly reduce the amount of power being used by a monitor during screen
blanking.
The X server features the ability to make use of DPMS on the following
graphics devices:
- HP VISUALIZE-EG
- HCRX-8[Z], HCRX-24[Z]
- HP VISUALIZE-8, HP
VISUALIZE-24, and HP VISUALIZE-48[XP].
- HP VISUALIZE-FX2, HP
VISUALIZE-FX4, HP VISUALIZE-FX6
The following table is a description of the states that are defined by VESA.
The Power Savings column indicates (roughly) the level of power savings
achieved in the given state. The Recovery Time is the amount of time that the
screen takes to return to a usable state when the screen saver is turned off
(by pressing a key or the moving the mouse).
Power-Saving States Defined by VESA
Level |
State |
DPMS Compliance Requirements |
Power Savings |
Recovery Time |
0 |
Screen Saver |
Not Applicable |
None |
Very Short (<1 sec) |
1 |
Stand-by |
Optional |
Minimal |
Short |
2 |
Suspend |
Mandatory |
Substantial |
Longer |
3 |
Off |
Mandatory |
Maximum |
System Dependent |
The actual amount of power saved and the recovery time for each of the states
is monitor-dependent and may vary widely. The customer can compensate for
this by choosing an appropriate level for the monitor that is currently in
use.
By default, the DPMS level used is the Screen Saver (i.e. no power savings).
If you wish to use power saving during screen blanking, set the following
X*screens file entry before starting the server:
MinimumMonitorPowerSaveLevel
level
where
level
is replaced with the single digit 0, 1, 2,
or 3 as specified in the Level column in the above table.
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;
this includes the color graphics device and the overlay planes on the
CRX-24[Z], CRX-48Z, HCRX, and HP VISUALIZE
family. 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.
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 or Color Graphics card devices 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 SwapBuffersOnVBlank Screen Option in the
X*screens file before the X server is started.
Note that MBX_SWAP_BUFFERS_ON_VBLANK is obsolete with this release.
The SwapBuffersOnVBlank Screen Option works for both DBE and MBX.
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
PEXlib Programming Manual by Tom Gaskins, and published by O'Reilly
& Associates, Inc. Consult that manual to understand the creation,
manipulation, and destruction of MBX buffers.
Since MBX is not an industry standard, and will be discontinued on HP-UX 11.0,
developers should replace MBX calls with the appropriate DBE calls.
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.
The MIT shared memory extension provides both shared-memory XImages
and shared-memory pixmaps based on the SYSV shared memory primitives.
Shared memory XImages are essentially a version of the XImage interface
where the actual image data is stored in a shared memory segment, and
thus need not be moved through the Xlib interprocess communication channel.
For large images, use of this facility can result in increased performance.
Shared memory pixmaps are a similar concept implemented for the pixmap
interface. Shared memory pixmaps are two-dimensional arrays of pixels in a
format specified by the X server, where the pixmap data is stored in the
shared memory segment. In all other respects, shared memory pixmaps behave
the same as ordinary pixmaps and can be modified by the usual Xlib routines.
In addition, it is possible to change the contents of these pixmaps directly
without the use of Xlib routines merely by modifying the pixmap data.
The X server supports the MIT shared memory extension on the following
devices:
- Internal Color Graphics
- Integrated Color Graphics
- CRX-24[Z]
- CRX-48Z
- HCRX-8[Z]
- HCRX-24[Z]
- HP VISUALIZE-EG
- HP VISUALIZE-8
- HP VISUALIZE-24
- HP VISUALIZE-48[XP]
- HP VISUALIZE-FX2
- HP VISUALIZE-FX4
- HP VISUALIZE-FX6
Shared Memory Transport (SMT) is a means to more rapidly transport large
amounts of data from the client to the server. It is distinct from the MIT
Shared Memory Extension, which is specifically for various types of images,
although SMT can be used with that extension.
SMT is particulary advantageous for operations that move large amounts of data
in a single request, such as a polyline or a polypoint, and for images when
the MIT Shared Memory Extension is not used. It will work with the Big
Requests Extension, but whether it will exhibit a performance increase depends
on the size of the actual extended size request. There are some X requests
for which no improvement is expected.
SMT is the default transport for 10.20 whenever a display name of any of the
forms listed below are used, and when the client and server are actually on
the same host. Note that ":0.0" is used for simplicity. This
behavior is equally applicable for displays such as ":1.0", etc.
- :0.0
- local:0.0
hostname
:0.0
- shmlink:0.0
A display name of the form unix:0.0 will force the use of Unix Domain
Sockets (UDS), which is identical to the local transport used before HP-UX
10.20.
A display name of the form
nn.nn.nn.nn:0.0
(where nn.nn.nn.nn is
an IP address) will force the use of Internet Sockets, which is the remote
transport normally used, and which can be used locally. (This will be
slow.)
It is possible that an application which violates the X interface standard
will run correctly using UDS but hang or coredump when using SMT. Users
encountering this problem can use:
DISPLAY=unix:0
command_and_args
to run the application compatibly, but without the performance improvement
of SMT.
Note that if neither SMT nor UDS are desired, setting
XFORCE_INTERNET=True before starting the X server forces all protocol
to interact directly with the hardware internet card.
SMT uses file space on the file system containing
/var/spool/sockets/X11. Should it be the case that that file system
is full, the X server will use Unix Domain Sockets (UDS) but print a warning
(in /var/vue/Xerrors if VUE is in use or /var/dt/Xerrors CDE
is in use) on each connection startup. To address this (and if space cannot
be made), /var/spool/sockets/X11 can be a symbolic link to another
file system with more space. If /var/spool/sockets/X11 is on a NFS
file system, currently SMT will (silently) not start, and the connection will
be made using Unix Domain Sockets. Again, a symbolic link to a conventional
file system may be used to deal with this.
The default values of some buffer sizes have been tuned for optimal
performance in most situations. However, these are not necessarily optimal in
all conditions. Under some circumstances system performance might be
optimized (possibly at the expense of X performance) by tuning these
parameters. Under most circumstances this should be unnecessary.
The Server accepts these parameters via the X*screens file, in the
ServerOptions section. In this case, the default for all SMT
connections is set.
The client accepts these parameters via the environment variable
X_SMT_SIZES. For the client, the value affects all client
connections to the server made while this environment variable is set.
In either case, the format and meaning of the fields is the same:

region_size
[,
high_water
[,
buffer_size
]]
with no embedded blanks. For examples:
32000,16000,5000
32000
0
The default is 100000,90000,90000.
The values are accepted as positive decimal, hex, or octal values according to
the C conventions.
The special value of 0 (for buffer size; all other values are ignored)
indicates that SMT is to be suppressed.
region_size
- controls the amount of shared memory allocated for the transport (in
bytes). This has the largest effect on system performance. The value is
rounded up to the next page boundary. Larger values yield faster X
performance but there is a point of diminishing returns. The default is
100000 (which is rounded to 0x19000).
high_water
- is a soft boundary which affects the load on the Virtual Memory system.
The value is rounded up to the next page boundary. The smaller the value,
the smaller the number of pages actually used while sending "normal,
small" X messages. Large messages can still be sent at high efficiency.
In a memory-poor system making this small may be an advantage, but if
sufficient memory is available, the value should be near the default.
The default value for
high_water
is 90000
or, if
region_size
is given, 1/8 of the region size
(which is appropriate in memory-poor systems), with a minimum of 4096. If
high_water
is specified (and if
region_size
is specified,
high_water
usually should be also) it must be
less than the
region_size
.
buffer_size
- is the size used for the "small" requests that X normally generates
protocol for. It is extremely unlikely that this will need tuning. It is
not rounded. It must be at least 4096, but defaults to the same as the
high_water
size (if the option is used). Space
is left for a control region if necessary.
The
high_water
value must fit within the region (and
should be smaller), the buffer must fit within the high-water mark (and
consequently the buffer must fit within the whole region).
If these parameters are used, be sure to confirm that they actually cause an
improvement in actual usage situations. Incorrect values can degrade
performance.
Begin Note for Programmers
X Applications which call fork(), and access the same display
structure from both the parent and the child cannot be expected to operate
reliably without extreme care (if at all), whether or not SMT is used.
However, SMT is more sensitive to this than UDS. The problem is quite similar
to stdio, where fflush() must be used to assure that data
makes it from the buffer onto the file exactly once.
Similarly to stdio's use of fflush(), XFlush() (not
_XFlush()) must be called immediately before any fork() call
that will be accessing the display from both the parent and child, as well as
any time control is transferred between the parent and child, or vice-versa.
(Calls to fork() which immediately do an exec() are not a
problem.)
The SMT library code attempts to detect improper use of display connections
after a fork, and issues a warning at runtime. However, not all all such
usages can be detected. Symptoms include reporting the error, and
applications hanging.
Also, because the parent and child might read from the same display connection
(either replies or events) the library can detect inconsistent sequence
numbers, which it will report. It will attempt to recover from such errors,
but depending on what the application has done, recovery cannot always be
successful.
Only for R5 Applications
SMT requires a change to an internal interface with the X library. In theory,
no application should be calling this interface, but some applications,
including at least one X test suite, are known to call it. The interface is
_XConnectDisplay. Applications using it directly may not be able to
use SMT for the display specified, and must add an extra (ninth) parameter,
which is the address of an integer:
int dummy;
_XConnectDisplay(..., &dummy);
Symptoms include both damaged data and core dumps.
(There was an earlier HP Shared Memory Transport, which this one replaces. It
used the same parameter, so it may be the case that any such calls have
already been fixed.)
This problem does not occur in the R6 library.
End Note for Programmers
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:
- Integrated Color Graphics and plug-in Color Graphics cards
- HP VISUALIZE-EG
- HCRX-8[Z], HCRX-24[Z]
- HP VISUALIZE-8, HP VISUALIZE-24, and HP VISUALIZE-48[XP]
- HP VISUALIZE-FX2, HP
VISUALIZE-FX4, and HP VISUALIZE-FX6
Color Recovery is available when using either depth-8 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 DisableColorRecovery Screen Option in the
X*screens file before starting the server (note that this disables
Color Recovery for 3D APIs as well).
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.
HP's X server now dynamically loads the appropriate device drivers and
extensions based on the target graphics display device and the extensions
the device driver supports. This feature should be transparent to X server
users.
When possible, the loading of X extensions is deferred until the first
protocol request is encountered for a given extension. This feature should
be transparent to X server users; however, it is expected to provide some
performance enhancement.
Dynamically loaded modules are recorded by the X server in the files
"/var/X11/Xserver/logs/X*.log", where the "*" of
X*.log reflects the display identifier for that given run.
Only that last invocation against a given display identifier is retained. The
log file contains the parsed contents of the given X*screens file and
the full path name for all dynamically loaded modules for the given X server
invocation. Deferred loaded modules are recorded as they are referenced.
Note: Altering or removing files under /usr/lib/X11/Xserver
may prevent the X server from running.
When a client application creates an X Graphics Context (GC), it is possible
to specify the subWindowMode component. The two possible values are
ClipByChildren (default) and IncludeInferiors. If the GC
specifies ClipByChildren, any rendering to a window with inferior
windows (i.e., the child is wholly enclosed by the parent) will appear only in
the destination window. In other words, the rendering will not take place
inside the inferiors. If the GC specifies IncludeInferiors, and the
same rendering request is made, it is the responsibility of the X Server to
ensure that the rendering is not clipped from the inferior windows. In other
words, the rendering will appear in the destination window and the inferior
windows.
With the advent of multi-layer devices, the IncludeInferiors mode
became defective. Depending upon which layer or hardware buffer the
destination drawable and inferior windows were in, the rendering may or may
not have taken place. Also, the GetImage protocol clearly specifies
that the default GetImage behavior is to include the depth-dependant
contents of inferior windows (in other words, GetImage requires that
IncludeInferiors work properly).
As of the 10.10 release, HP has offered a solution to the
IncludeInferiors defect. Some customers create their test image
archives using XGetImage (which currently returns incorrect data for
multi-layer and double-buffered devices). Therefore, the Include Inferiors
Fix will not be enabled by default. To enable the Include Inferiors Fix, add
the EnableIncludeInferiorsFix Screen Option to the X*screens
file.
For example:
Screen /dev/crt/
ScreenOptions
EnableIncludeInferiorsFix
This gives a system administrator control over when the fix is active and when
it is not. In this way, each site can evaluate whether or not it is
beneficial to enable this fix.
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 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 Server Options to change the shared
memory size.
The size of the shared memory segment used by the GRM can be controlled through
a Server Option. 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:
ServerOptions
GraphicsSharedMemorySize=0x800000
Note that the value must be in hexadecimal. The new value won't take effect
until you restart the X 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).
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 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
- HP VISUALIZE-EG
- HCRX-8[Z], HCRX-24[Z]
- HP VISUALIZE-8, HP VISUALIZE-24, and HP VISUALIZE-48[XP]
- HP VISUALIZE-FX2, HP
VISUALIZE-FX4, and HP VISUALIZE-FX6
- X*screens File Screen Option To Use:
- CountTransparentInOverlayVisual
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:
- HP VISUALIZE-EG
- HCRX-8[Z]
- HP VISUALIZE-8
- X*screens File Screen Option To Use:
- EnableOverlayTransparency
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
- X*screens File Screen Option To Use:
- 3BitCenterColor
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.
- X*screens File Screen Option To Use:
- ImageTextViaBitMap
Note: Using this option will reduce text performance.
The ImageTextViaBitMap screen option is supported on all graphics devices
supported on the HP 9000/700 machines, except the following:
- PersonalVRX, TurboVRX
- Freedom Series
Graphics (S3150, S3250
and S3400)
These HP-UX 9.x environment variables are no longer supported:
HP_SUPPRESS_TRUECOLOR_VISUAL
HP_COLORMAP_MANAGEMENT_SCHEME
WMSHMSPC
MBX_SWAP_BUFFERS_ON_VBLANK
CRX24_COUNT_TRANSPARENT_IN_OVERLAY_VISUAL
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. On HP-UX 10.x systems,
five special graphics device files are automatically created. The first or
primary graphics card, also known as the "console", uses the
"/dev/crt" or "/dev/crt0" device file. The others are
called "crt1", "crt2", and "crt3" and also reside
in "/dev". Those systems containing multiple graphics devices on a
single card (Dual Color Graphics and Dual CRX, for example) need to have
special device files manually created for them.
Special device files are created by using SAM (the System Administration
Manager tool):
- From SAM's main window, double-click "Peripheral Devices".
- From the "Peripheral Devices" window, double-click "Cards".
- A window will appear, containing a list of all cards that are in your
machine. Once you select any of them (by single-clicking), the "Actions"
menu will contain the options "Show Device Files" and
"Create Device Files." Choose whichever option you desire.
The following definitions are included to reduce confusion between the terms
"multi-display," "multi-screen," "multi-seat," and "single logical screen."
- Multi-Display
- A configuration with multiple graphics devices used concurrently. Any
multi-screen, multi-seat, or single logical screen configuration is
referred to as a multi-display configuration.
- Multi-Screen
- A configuration in which a single X server with a mouse and keyboard
drives multiple graphics devices (where each display is a different X
Screen) concurrently while only allowing the cursor, not windows, to be
moved between displays.

- Multi-Seat
- A configuration with multiple instantiations of the X server, each with
its own mouse, keyboard, and display(s). Multi-seat is not supported in
any HP-UX 10.* release.

- Single Logical Screen
- A configuration in which a single X server with a single mouse and
keyboard drives multiple homogeneous graphics devices concurrently while
allowing the displays to emulate a large single screen. This differs from
a multi-screen environment by allowing windows to be moved and displayed
across displays. See the section in this document on Single Logical
Screen.

Note that different monitor resolutions are not supported with the
multi-display configurations unless stated otherwise in the table below.
The list of supported multi-display configurations is rather large, and it
changes whenever a new graphics device is introduced. Thus, if you are
considering a Single Logical Screen or any other multi-display configuration,
we recommend consulting your HP Sales Representative and inquiring whether the
configuration you have in mind is indeed supported.
There are general guidelines, however. For example:
- Multi-display configurations may be limited by available power. Depending
on the capacity of your computer's power supply, and the power demands of
the combination of graphics cards you are considering, there may or may
not be enough power to operate them all.
- Single Logical Screen configurations must use identical graphics devices
(see the next section).
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 monitors. The word "homogeneous" is included because SLS
only works if the graphics devices included in the SLS Configuration are of
the same type. Note that on-board and "card" versions of the same device can
be considered identical; for example, you could use an on-board
HP VISUALIZE-EG graphics device and an
HP VISUALIZE-EG graphics card, and
still consider them identical devices, thus permitting a 1
2 SLS or a 2
1 SLS.
SLS is enabled by using SAM (the System Administration Manager tool,
/usr/sbin/sam). To enable an SLS configuration, start SAM, and follow the instructions below:
- Double-click on the "X Server Configuration" button. A window entitled
"Graphics" appears, containing an icon for every graphics device on your
system.
- Select the devices you want to combine into an SLS (click the mouse on the
first device, and [Ctrl]-click on the others). At this point, all the
devices you want to combine into an SLS configuration should be
highlighted.
- From the "Actions" menu, choose the menu item "Modify Multi-Screen
Layout". A dialog box appears, allowing you to specify exactly how
you want your SLS configuration to be.
Note that if your machine has only one graphics device, the "Modify
Multi-Screen Layout" menu option does not even appear, since multiple
devices cannot occur in a single-device context.
Note also that DHA (Direct Hardware Access) is not supported in a window that
spans multiple screens. This means, for example, that while graphics is
supported to a window spanning two or more screens, accelerated
graphics is not. "Spanning," in this context, includes a window that is two
or more screens in size, as well as a window that is partially on one screen
and partially on another (even though it would fit on a single screen if it
were moved).
SLS can also be enabled via the /etc/X11/X*screens file via 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 monitor tall by two
monitors wide, the following syntax would be used:
SingleLogicalScreen 1 2
/dev/crt0 /dev/crt1
Whereas for a logical screen that is two monitors tall by one monitor wide,
the syntax is:
SingleLogicalScreen 2 1
/dev/crt0 /dev/crt1
Currently, SLS does not take advantage of 3D acceleration (e.g. CRX-24Z). 3D
applications (from any supported HP 3D API) will continue to run with SLS;
However, 3D performance with SLS will be much slower than it is without SLS.
Please note that HP VUE/CDE has not been modified to take advantage of the
Single Logical Screen capability. When presenting information on your
display, HP VUE may split a window across physical screens. Examples include:
- The login screen.
- The Front Panel.
- Window move and resize boxes.
- The screen lock dialog.
This behavior is the result of HP VUE's naive assumption that it is running
against one large screen; it centers these windows accordingly.
If you are using the default HP VUE key bindings, you can easily reposition
the Front Panel so that it is completely contained within one physical screen:
- With the input focus on the Front Panel, press
![[Alt]](keycaps/AltKey.xbm)
(on older keyboards, use ![[Extend char]](keycaps/ExtCharKey.xbm)
).
- With the Front Panel menu posted and the "Move" menu item selected, press
(on older keyboards,
) to start the move.
- Use the mouse or the arrow keys to reposition the Front Panel to the
desired location.
- Press
(or
) to complete the move. You
may instead press
to cancel the
move.
Afterwards, this setting will be remembered and restored at your next login.
If you have previously set a Home session, you will need to re-set the Home
session in the Style Manager to register the new Front Panel position.
Note that there is no mechanism in HP VUE for repositioning the login screen,
window move/resize boxes, or the screen lock dialog.
This sections includes information on Integrated Color Graphics and Color
Graphics cards.
For color displays:
- Class PseudoColor Depth 8 -
supports DBE and MBX software double-buffering
- Class TrueColor Depth 8 -
supports DBE and MBX software double-buffering
For grayscale displays, only one visual is supported:
- Class GrayScale Depth 8 -
supports DBE and MBX software double-buffering
The following Screen Options are supported:
- DisableColorRecovery
- 3BitCenterColor
- ImageTextViaBitMap
Color Graphics devices have two hardware colormaps (color lookup tables), each
with 256 entries. The X server controls the allocation and contents of these
hardware colormaps.
Many applications use the default X11 colormap. A technicolor effect in the
windows using the default colormap occurs when a non-default colormap is
downloaded in the hardware colormap that had previously contained the
default colormap.
Because so many applications use the default X11 colormap
including the window manager
and because Color Graphics devices have
two hardware colormaps, the default behavior on this device is to dedicate one
hardware colormap to always hold the default X11 colormap. The second
hardware colormap is available to applications that use colormaps other than
the default.
The default behavior can cause technicolor if two or more applications are
using different, non-default colormaps. For example, Application A uses the
default X11 colormap, Application B uses a different colormap, and Application
C uses a third colormap. If applications A, B, and C are all executed
simultaneously on a Model 712, application A would look correct. Either
application B or C would have a technicolor effect
the application whose colormap was last
downloaded in the hardware colormap would look correct.
Color Recovery is a technique to generate a better picture by attempting to
eliminate the graininess caused by dithering. 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. At server startup
(if Color Recovery is not disabled in the X*screens file), the
following properties are defined and placed on the root window:
- _HP_RGB_SMOOTH_TRUE_MAP
- _HP_RGB_SMOOTH_PSEUDO_MAP
- _HP_RGB_SMOOTH_MAP_LIST
These properties are of type RGB_COLOR_MAP and carry pointers to
structures of type XStandardColormap. They may be interrogated with
calls to XGetRGBColormaps. The colormaps in the
_HP_RGB_SMOOTH_TRUE_MAP and _HP_RGB_SMOOTH_PSEUDO_MAP
structures identify colormaps which are created at server startup and are for
use with the TrueColor and PseudoColor visuals, respectively. They are both
initialized to contain the 3:3:2 ramp of 8-bit TrueColor. Neither of these
colormaps can be modified as they are read-only. The property
_HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated
with all of the root window's visual IDs that support Color Recovery. When
the XGetRGBColormaps routine searches this list for a
colormap with a visual ID that matches the visual ID that your window is using
and it finds one, your application knows that your visual supports Color
Recovery, and uses that colormap for any Color Recovery window in your
window's visual.
Note that the algorithm used for the Color Graphics device is slightly
different from that used for the HCRX family of devices. If you do not wish
for your application to have to do device-specific checks, HP recommends that
you use the HCRX encoding algorithm for Color Recovery regardless of the
device on which your application is executing. The results on the Color
Graphics device will not be optimal, but will generally still be much better
than a standard dither. If you are willing to do device-specific checks, the
existence of either the _HP_RGB_SMOOTH_TRUE_MAP or
_HP_RGB_SMOOTH_PSEUDO_MAP property will indicate the device is Color
Graphics.
Color Recovery uses all 256 entries of one of the available colormaps. The
color visual used by Color Recovery emulates the 24-bit TrueColor visual;
thus, the colors red, green, and blue are typically declared as integers in
the range from 0 to 255. Note that each window that uses Color Recovery will
have the same colormap contents.
For Color Recovery to produce the best results, the emulated 24-bit TrueColor
data is dithered as explained below.
A pixel to be dithered is sent to the routine provided in this example. Note
that the values of the variables RedValue, GreenValue, and BlueValue are
generated by an application. In this example, the color values are assumed to
be in the range 0..255.
The given routine receives the color values and the X and Y window address
(Xp and Yp) of the pixel. The X and Y address is used
to access the dither tables. The values from the dither tables are added to
the color values. After the dither addition, the resultant color values are
quantized to three bits of red and green and two bits of blue. The quantized
results are packed into an 8-bit unsigned char and then stored in the frame
buffer. In the process of sending the contents of the frame buffer to the
CRT, a special section in the hardware then converts the frame buffer's 8-bit
data into 24-bit TrueColor data for display.
Here is a routine that can be used to dither the 24-bit TrueColor data.
unsigned char dither_pixel_for_CR(RedValue,GreenValue,BlueValue,Xp,Yp)
int RedValue, GreenValue, BlueValue, Xp, Yp;
{
static short dither_red[2][16] = {
{-16, 4, -1, 11,-14, 6, -3, 9,-15, 5, -2, 10,-13, 7, -4, 8},
{ 15, -5, 0,-12, 13, -7, 2,-10, 14, -6, 1,-11, 12, -8, 3, -9}};
static short dither_green[2][16] = {
{ 11,-15, 7, -3, 8,-14, 4, -2, 10,-16, 6, -4, 9,-13, 5, -1},
{-12, 14, -8, 2, -9, 13, -5, 1,-11, 15, -7, 3,-10, 12, -6, 0}};
static short dither_blue[2][16] = {
{ -3, 9,-13, 7, -1, 11,-15, 5, -4, 8,-14, 6, -2, 10,-16, 4},
{ 2,-10, 12, -8, 0,-12, 14, -6, 3, -9, 13, -7, 1,-11, 15, -5} };
int red, green, blue;
int x_dither_table, y_dither_table;
unsigned char pixel;
/* Determine the dither table entries to use based on the pixel address */
x_dither_table = Xp % 16; /* X Pixel Address MOD 16 */
y_dither_table = Yp % 2; /* Y Pixel Address MOD 2 */
/* Start with the initial values as supplied by the calling routine */
red = RedValue;
green = GreenValue;
blue = BlueValue;
/* Generate the red dither value */
red += dither_red[y_dither_table][x_dither_table];
/* Check for overflow or underflow on red value */
if (red > 0xff) red = 0xff;
if (red < 0x00) red = 0x00;
/* Generate the green dither value */
green += dither_green[y_dither_table][x_dither_table];
/* Check for overflow or underflow on green value */
if (green > 0xff) green = 0xff;
if (green < 0x00) green = 0x00;
/* Generate the blue dither value */
blue += (dither_blue[y_dither_table][x_dither_table]<<1);
/* Check for overflow or underflow on blue value */
if (blue > 0xff) blue = 0xff;
if (blue < 0x00) blue = 0x00;
/* Generate the pixel value by "or"ing the values together */
pixel = ((red & 0xE0) | ((green & 0xE0) >> 3) | ((blue & 0xC0) >> 6));
return(pixel);
}
Only one visual is supported.
For color displays:
- Class PseudoColor Depth 8 -
supports DBE and MBX hardware double-buffering (CRX, Dual CRX)
supports DBE and MBX software double-buffering (Internal Color Graphics)
For grayscale displays:
- Class GrayScale Depth 8 -
supports DBE and MBX hardware double-buffering (GRX)
supports DBE and MBX software double-buffering (Internal GrayScale
Graphics)
The "layer" and "transparent" default visual options are not supported.
The following Screen Options are supported:
- SwapBuffersOnVBlank
- 3BitCenterColor (Internal Color Graphics only)
- EnableIncludeInferiorsFix
The following visuals are supported:
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class PseudoColor Depth 8 Layer Overlay -
supports DBE and MBX software double-buffering
- Class DirectColor Depth 12 Layer Image -
supports DBE and MBX hardware double-buffering
- Class TrueColor Depth 12 Layer Image -
supports DBE and MBX hardware double-buffering
- Class DirectColor Depth 24 Layer Image -
doesn't support DBE and MBX double-buffering
- Class TrueColor Depth 24 Layer Image -
doesn't support DBE and MBX double-buffering
The following Screen Options are supported:
- CountTransparentInOverlayVisual
- SwapBuffersOnVBlank
- ImageTextViaBitMap
- CRX24_FULL_DEFAULT_VISUAL
- EnableIncludeInferiorsFix
The default number of colormap entries in the overlay visual for the CRX-24[Z]
is 255. Entry 255 is excluded because its value is hard-coded to transparent
(that is, show the image planes).
This may have the following two consequences for X11 applications running in
the overlay planes (the default visual):
- Clients attempting to allocate 256 entries do not have their request
granted.
- Clients requesting (via XAllocNamedColor) the rgb.txt
value of "Transparent" are not returned entry 255.
This default behavior can be changed by setting the
CountTransparentInOverlayVisual screen option.
When this option is enabled, the X server does the following:
The following visuals are supported:
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class PseudoColor Depth 8 Layer Overlay -
supports DBE and MBX software double-buffering
- Class DirectColor Depth 24 Layer Image -
supports DBE and MBX hardware double-buffering
- Class TrueColor Depth 24 Layer Image -
supports DBE and MBX hardware double-buffering
The following Screen Options are supported:
- CountTransparentInOverlayVisual
- SwapBuffersOnVBlank
- ImageTextViaBitMap
- EnableIncludeInferiorsFix
The default number of colormap entries in the overlay visual for the CRX-48Z
is 255. Entry 255 is excluded because its value is hard-coded to transparent
(that is, show the image planes).
This may have the following two consequences for X11 applications running in
the overlay planes (the default visual):
- Clients attempting to allocate 256 entries do not have their request
granted.
- Clients requesting (via XAllocNamedColor) the rgb.txt
value of Transparent are not returned entry 255.
This default behavior can be changed by setting the
CountTransparentInOverlayVisual screen option.
When this option is enabled, the X server does the following:
This section includes information on the HCRX-8[Z], HCRX-24[Z], HP VISUALIZE-EG, HP VISUALIZE-8,
HP VISUALIZE-24, and HP VISUALIZE-48[XP] graphics devices.
The HCRX-8[Z] is a one-board device (two, with the optional accelerator) that
has eight overlay planes, two banks of 8 image planes, and 4 hardware
colormaps. This device provides a superset of functionality in the CRX.
The HCRX-24[Z] is a one board device (two, with the optional accelerator) that
has eight overlay planes, two banks of 12 image planes, and 4 hardware
colormaps. This device provides a superset of functionality in the
CRX-24[Z].
The HP VISUALIZE-EG is either an
unaccelerated built-in graphics device or a single board unaccelerated
graphics device (not counting the optional memory daughter card in either
case). This device provides compatible functionality with the Integrated
Color Graphics device when in 8 plane mode and has functionality compatible
with the HCRX-8 device when in double-buffer mode. See below for a
description of these modes. For shorthand notation, from this point on in the
document, HP VISUALIZE-EG will refer to
either mode, HP VISUALIZE-EG(8) will refer to 8 plane
mode only and HP [Dual] VISUALIZE-EG will
refer to double-buffer mode only.
The HP VISUALIZE-8 is a two board
accelerated device that has eight overlay planes, two banks of 8 image planes,
and 4 hardware colormaps. This device provides a superset of functionality in
the CRX.
The HP VISUALIZE-24 is a two board
accelerated device that has eight overlay planes, two banks of 12 image
planes, and 4 hardware colormaps. This device provides a superset of
functionality in the CRX-24[Z].
The HP VISUALIZE-48[XP] is a two-board
accelerated device that fills two slots. If you add either the optional
texture-mapping memory card or the optional video-out card, it becomes a
three-board set that fills three slots. Add both optional cards, and it
becomes a four-board set, but it still fills only three slots. In any case,
it has eight overlay planes, two banks of 24 image planes, and six hardware
colormaps. This device provides a superset of functionality in the CRX-48Z.
The hardware support for accelerating 2D Xlib primitives is similar to that in
the other HCRX devices. The hardware for accelerating 3D geometry, lighting,
and shading, is new.
The following visuals are supported on the HP VISUALIZE-EG(8):
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX software double-buffering
- Class TrueColor Depth 8 Layer Image -
supports DBE and MBX software double-buffering
The following visuals are supported on the HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8:
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class PseudoColor Depth 8 Layer Overlay - (see Note)
supports DBE and MBX software double-buffering
- Class PseudoColor Depth 8 Layer Overlay Transparent - (see Note)
supports DBE and MBX software double-buffering
- Class TrueColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
Note: The two overlay visuals are mutually exclusive, based on the
presence of the EnableOverlayTransparency screen option (i.e., if the
EnableOverlayTransparency screen option is set, then the visual that
supports transparency is available, otherwise the visual which does
not support transparency is available).
The following visuals are supported on the HCRX-24[Z] and HP VISUALIZE-24:
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class PseudoColor Depth 8 Layer Overlay -
supports DBE and MBX software double-buffering
- Class PseudoColor Depth 8 Layer Overlay Transparent -
supports DBE and MBX software double-buffering
- Class TrueColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class DirectColor Depth 12 Layer Image -
supports DBE and MBX hardware double-buffering
- Class TrueColor Depth 12 Layer Image -
supports DBE and MBX hardware double-buffering
- Class DirectColor Depth 24 Layer Image -
doesn't support DBE and MBX double-buffering
- Class TrueColor Depth 24 Layer Image -
doesn't support DBE and MBX double-buffering
The following visuals are supported on the HP VISUALIZE-48[XP]:
- Class PseudoColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class PseudoColor Depth 8 Layer Overlay -
supports DBE and MBX software double-buffering
- Class PseudoColor Depth 8 Layer Overlay Transparent -
supports DBE and MBX software double-buffering
- Class TrueColor Depth 8 Layer Image -
supports DBE and MBX hardware double-buffering
- Class DirectColor Depth 24 Layer Image -
supports DBE and MBX hardware double-buffering
- Class TrueColor Depth 24 Layer Image -
supports DBE and MBX hardware double-buffering
The following Screen Options are supported:
- CountTransparentInOverlayVisual
- DisableColorRecovery
- EnableOverlayTransparency (HCRX-8[Z],
HP [Dual] VISUALIZE-EG and
HP VISUALIZE-8 only)
- SwapBuffersOnVBlank
- ImageTextViaBitMap
- CRX24_FULL_DEFAULT_VISUAL (HCRX-24[Z] only)
- EnableIncludeInferiorsFix
The following modes are supported:
- 8 Plane mode
- Double-Buffer mode
The modes are set from the Boot-Admin at bootup time by selecting from the
menu of options a configuration that supports double-buffer or not. From that
point on (without rebooting) the server will use the selected mode.
Eight-plane mode is compatible with the Integrated Color Graphics device. It
has eight image planes and uses only software double-buffering.
Double-Buffer mode is compatible with the HCRX-8 device. This mode requires
an optional memory daughter card. If the daughter card is installed,
selecting this mode will result in eight overlay planes and 16 image planes
(the same as HCRX-8 and HP VISUALIZE-8
devices). Double-Buffer mode allows the use of hardware double-buffering.
The eight-plane HCRX-8[Z], HP [Dual] VISUALIZE-EG and HP VISUALIZE-8 are the first members of the Series 700
graphics family whose overlay planes and image planes are both depth 8.
- There are two depth-8 PseudoColor visuals (one in the overlay planes,
the other in the image planes). There is also a depth-8 TrueColor visual
in the image planes.
- The default visual (where the root window and default colormap reside) is
in the overlay planes. A DefaultVisual specification in a Screen
Entry in the X*screens file may instead locate the default visual
in the Image Planes (see the X*screens
File section, above).
- Fast 8/8 double-buffering (two hardware buffers) is supported in the
depth-8 image planes, but not in the overlays. The overlay planes support
the slower virtual-memory-based double-buffering.
The default colormap cannot be used with a window in a non-default visual,
even one of the same depth as the default visual.
Before trying to use the default colormap in a depth-8 window, verify that the
window is in the default visual. If the window is not in the default visual,
create a colormap in that visual. This process of creating a non-default
colormap is the same as the one used to create windows in depth-12 or depth-24
visuals.
If you have an application that assumes that the default colormap can be used
with any depth-8 window (even one in an image-plane visual) specify an
image-plane visual as the default.
Unlike the CRX, the HCRX-8[Z]'s default visual the HP [Dual] VISUALIZE-EG's default visual and the HP VISUALIZE-8's default visual do not have fast hardware
double-buffering (but the image planes do).
To obtain hardware double-buffering, find a visual in the image planes. The
best method is to find all the depth-8 PseudoColor visuals returned by
XGetVisualInfo and then eliminate the visuals that are reported in
the SERVER_OVERLAY_VISUALS property (discussed below).
If you have an application that assumes the default visual has fast
double-buffering, specify an image plane visual as the default.
As on the CRX-24[Z] and CRX-48Z, a property on the root window,
SERVER_OVERLAY_VISUALS, is used to describe the visuals that are in
the overlay planes.
The HCRX-8[Z], HP [Dual] VISUALIZE-EG and
HP VISUALIZE-8 each have one visual in the
overlay planes (depth-8 PseudoColor). By default, this overlay visual has no
transparent index available to applications for rendering transparency. This
means the overlay windows with "floating text" are not supported in the
typical X server operation on the HCRX-8[Z], HP [Dual] VISUALIZE-EG or HP VISUALIZE-8.
For applications that require transparent overlay windows on the HCRX-8[Z], HP
VISUALIZE-EG(D) or HP VISUALIZE-8, an optional X server mode is available to
allow for overlay transparency, but it is restrictive. In this optional mode,
overlay colormaps provide a single entry that can be used to render
transparency. Only one hardware colormap is available in the overlays
(instead of two) and only one hardware colormap is available in the image
planes (instead of two).
To activate this optional X server mode to enable transparency, set the
EnableOverlayTransparency screen option. You will need to restart
the X server for the option to take effect.
With this mode enabled, colormaps created in the default visual have 255
entries; entry 256 is reserved for transparency. As on the CRX-24[Z] and
CRX-48Z, the screen option CountTransparentInOverlayVisual can be
used to include the transparent index in the colormap size (256 entries
instead of 255).
- Programmers' Note
- If transparency is not enabled, there are only 252 colors available.
Entries 252-255 are not writable, and should not be used; there are only
252 colormap entries available, even though the server states that there
are 256.
The HCRX-24[Z], HP VISUALIZE-24, and
HP VISUALIZE-48[XP] have two visuals in the
overlay planes, both depth-8 PseudoColor.
The default overlay visual has 256 entries per colormap and no
transparency.
The second overlay visual has 255 entries per colormap and supports
transparency in the same way as the CRX-24[Z]. As on the CRX-24[Z] and
CRX-48Z, the screen option EnableOverlayTransparency can be used to
include the transparent index in the colormap size (256 entries instead of
255).
To allow applications to determine which visuals are in the overlay planes,
both overlay visuals are listed in the SERVER_OVERLAY_VISUALS
property attached to the root window. The default overlay visual has a
transparent type of 0 (None) while the transparent overlay visual has
a transparent type of 1 (TransparentPixel).
If you need an overlay colormap that supports transparency, create the
colormap using the visual that has transparency in its
SERVER_OVERLAY_VISUALS property. To look at the contents of this
property, you would use code similar to the following:
{
typedef struct {
VisualID overlayVisualID;
Card32 transparentType;/* None, TransparentPixel, TransparentMask */
Card32 value; /* Either pixel value or pixel mask */
Card32 layer;
} OverlayVisualPropertyRec;
OverlayVisualPropertyRec *pOverlayVisuals, *pOVis;
XVisualInfo getVis;
XVisualInfo *pVisuals;
Atom overlayVisualsAtom, actualType;
...
/* Get the visuals for this screen and allocate. */
getVis.screen = screen;
pVisuals = XGetVisualInfo(display, VisualScreenMask, &getVis, &nVisuals);
pOverlayVisuals = (OverlayVisualPropertyRec *)
malloc ( (size_t)nVisuals * sizeof(OverlayVisualPropertyRec) );
/* Get the overlay visual information for this screen. Obtain
* this information from the SERVER_OVERLAY_VISUALS property. */
overlayVisualsAtom = XInternAtom(display, "SERVER_OVERLAY_VISUALS", True);
if (overlayVisualsAtom != None)
{
/* Since the Atom exists, request the property's contents. */
bytesAfter = 0;
numLongs = ( nVisuals * sizeof(OverlayVisualPropertyRec) + 3 ) / 4;
XGetWindowProperty(display, RootWindow(display, screen),
overlayVisualsAtom, 0, numLongs, False,
AnyPropertyType, &actualType, &actualFormat,
&numLongs, &bytesAfter, &pOverlayVisuals);
if ( bytesAfter != 0 ) {/* Serious Failure Here */} ;
/* Loop through the pOverlayVisuals array. */
...
nOVisuals = numLongs/sizeof(OverlayVisualPropertyRec);
pOVis = pOverlayVisuals;
while (--nOVisuals >= 0)
{
if ( pOVis->transparentType == TransparentPixel )
{/* Found a transparent overlay visual, set ident. aside. */};
pOVis++;
}
XFree(pOverlayVisuals);
/* There might be some additional checking of the found
transparent overlay visuals wanted; e.g., for depth. */
}
XFree(pVisuals);
}
This program fragment is not complete; its main purpose is to give the idea of
how to find an overlay visual having transparency.
The following information discusses the number of supported colormaps for the
HCRX configurations.
The image planes contain the default colormap permanently installed in the
hardware plus one other hardware colormap available to applications. No
issues involving transparency exist because of the lack of Overlay planes.
When the default visual is in the overlay planes (default location) and the
screen option EnableOverlayTransparency is not set, the overlay
planes contain the default colormap permanently installed in the hardware,
plus one other hardware colormap available to applications. The image planes
contain two hardware colormaps each usable by applications.
When the default visual is in the image planes and the screen option
EnableOverlayTransparency is not set, the overlay planes contain a
single hardware colormap available to applications, plus a colormap reserved
by the server (i.e., unavailable to applications) to guarantee the existence
of transparency, and the image planes contain the default colormap permanently
installed into the hardware, plus one other hardware colormap available to
applications.
When the screen option EnableOverlayTransparency is set, both the
overlay planes and the image planes have access to one hardware colormap. The
default colormap is not permanently installed in the hardware and is in the
overlay planes by default, but the Default Visual can be located in the image
planes as described in a previous section.
The overlay planes contain the default colormap permanently installed in the
hardware, plus one other hardware colormap available to applications. The
image planes contain two hardware colormaps, each usable by applications.
Although two hardware colormaps are available to applications in the image
planes, a hardware restriction allows only one depth-12 or depth-24 colormap
to be installed at any given time. Therefore, if two applications are run
simultaneously and use different depth-12 or depth-24 colormaps, the
application that has the colormap focus looks correct and the other is
technicolored.
The overlay planes contain the default colormap permanently installed in the
hardware, plus one other hardware colormap available to applications. The
image planes contain four hardware colormaps, each usable by applications.
The four hardware colormaps in the image planes can be treated as depth-8 or
depth-24 colormaps. There are no restrictions on the types of colormaps that
can be installed in the hardware at any given time. All four colormaps can be
used with any visual class.
Color Recovery is a technique to generate a better picture by attempting to
eliminate the graininess caused by dithering. 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. At server startup
(if Color Recovery is not disabled in the X*screens file), the
_HP_RGB_SMOOTH_MAP_LIST property is defined and placed on the root
window.
The above property is of type RGB_COLOR_MAP and carries pointers to
structures of type XStandardColormap. It may be interrogated with
calls to XGetRGBColormaps. The property
_HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated
with window visual IDs that support Color Recovery. When the
XGetRGBColormaps routine searches this list for a colormap with a
visual ID that matches your window's visual ID and it finds one, your
application knows that your visual supports Color Recovery, and uses that
colormap for any Color Recovery window in your window's visual.
Color Recovery uses all 256 entries of one of the available colormaps. The
color visual used by Color Recovery emulates the 24-bit TrueColor visual,
thus, the colors red, green, and blue are typically declared as integers in
the range from 0 to 255. Note that each window that uses Color Recovery will
have the same colormap contents.
For Color Recovery to produce the best results, the emulated 24-bit TrueColor
data is dithered as explained below.
A pixel to be dithered is sent to the routine provided in this example. Note
that the values of the variables RedValue, GreenValue, and BlueValue are
generated by an application. In this example, the color values are assumed to
be in the range 0..255.
The given routine receives the color values and the X and Y window address
(Xp and Yp) of the pixel. The X and Y address is used
to access the dither tables. The values from the dither tables are added to
the color values. After the dither addition, the resultant color values are
quantized to three bits of red and green and two bits of blue. The quantized
results are packed into an 8-bit unsigned char and then stored in the frame
buffer. In the process of sending the contents of the frame buffer to the
CRT, a special section in the hardware then converts the frame buffer's 8-bit
data into a 24-bit TrueColor data for display.
Here is a routine that can be used to dither the 24-bit TrueColor data.
unsigned char dither_pixel_for_CR(RedValue,GreenValue,BlueValue,Xp,Yp)
int RedValue,GreenValueBlueValue,Xp,Yp;
{
static short dither_red[2][16] = {
{-16, 4, -1, 11,-14, 6, -3, 9,-15, 5, -2, 10,-13, 7, -4, 8},
{ 15, -5, 0,-12, 13, -7, 2,-10, 14, -6, 1,-11, 12, -8, 3, -9}};
static short dither_green[2][16] = {
{ 11,-15, 7, -3, 8,-14, 4, -2, 10,-16, 6, -4, 9,-13, 5, -1},
{-12, 14, -8, 2, -9, 13, -5, 1,-11, 15, -7, 3,-10, 12, -6, 0}};
static short dither_blue[2][16] = {
{ -3, 9,-13, 7, -1, 11,-15, 5, -4, 8,-14, 6, -2, 10,-16, 4},
{ 2,-10, 12, -8, 0,-12, 14, -6, 3, -9, 13, -7, 1,-11, 15, -5}};
int red, green, blue;
int x_dither_table, y_dither_table;
unsigned char pixel;
/* Determine the dither table entries to use based on the pixel address */
x_dither_table = Xp % 16; /* X Pixel Address MOD 16 */
y_dither_table = Yp % 2; /* Y Pixel Address MOD 2 */
/* Start with the initial values as supplied by the calling routine */
red = RedValue;
green = GreenValue;
blue = BlueValue;
/* Generate the red dither value */
if (red >= 48) /* 48 is a constant required by this routine */
red=red-16;
else
red=red/2+8;
red += dither_red[y_dither_table][x_dither_table];
/* Check for overflow or underflow on red value */
if (red > 0xff) red = 0xff;
if (red < 0x00) red = 0x00;
/* Generate the green dither value */
if (green >= 48) /* 48 is a constant required by this routine */
green=green-16;
else
green=green/2+8;
green += dither_green[y_dither_table][x_dither_table];
/* Check for overflow or underflow on green value */
if (green > 0xff) green = 0xff;
if (green < 0x00) green = 0x00;
/* Generate the blue dither value */
if (blue >= 112) /* 112 is a constant required by this routine */
blue=blue-32;
else
blue=blue/2+24;
blue += (dither_blue[y_dither_table][x_dither_table]<<1);
/* Check for overflow or underflow on blue value */
if (blue > 0xff) blue = 0xff;
if (blue < 0x00) blue = 0x00;
pixel = ((red & 0xE0) | ((green & 0xE0) >> 3) | ((blue & 0xC0) >> 6));
return(pixel);
}