|
HP OpenVMS Systems Documentation |
|
HP DECwindows Motif for OpenVMS
|
| Previous | Contents | Index |
The following sections contain definitions and examples for all the
parameters listed in Table 3-1.
3.1.2.1 Server Process
As part of the DECwindows startup process, the display server is invoked as a detached process. Normally, the default quotas assigned to the server process are sufficient. However, in some instances, certain parameters may need to be increased. By defining symbols in DECW$PRIVATE_SERVER_SETUP.COM, server process quotas can be adjusted.
For example, you might need to increase quota values in the following instances:
For more information on tuning the DECwindows display server, see Appendix A.
The DECW$SERVER_PRIORITY parameter controls the priority of the display server process. This parameter enables you to reduce the priority of the server process and improve system performance in request-intensive situations where response time is sluggish.
Estimate the optimal priority for the server process; valid values range from 1 (low) to 15 (high). For the best results, HP recommends that you use a mid-range value of 4, 5, or 6 (default). Setting the priority too low can reduce the responsiveness of input devices (such as keyboard or mouse actions).
The following symbol definition assigns a priority of 4 to the DECwindows display server:
$ DECW$SERVER_PRIORITY == "4"
|
This parameter defines the process limits (in pagelets) to be applied to the DECwindows display server process. DECW$SERVER_WSDEF values that are larger than the value of DECW$SERVER_WSQUOTA revert to the value of DECW$SERVER_WSQUOTA. For information about establishing working set sizes, see the Guide to OpenVMS Performance Management manual.
The following logical definition assigns a working set size of 5000 pagelets for the DECwindows display server:
$ DEFINE DECW$SERVER_WSDEF 5000
|
This parameter defines the maximum amount of physical memory (working set) that can be allocated to the DECwindows server. For information about establishing working set sizes, see the Guide to OpenVMS Performance Management manual.
The following logical definition establishes the maximum number of pagelets allocated to the DECwindows server as 10000:
$ DEFINE DECW$SERVER_WSQUOTA 10000
|
This parameter defines the absolute limit on physical memory that the DECwindows display server is to be allocated if the server requires more space than the DECW$SERVER_WSDEF value allots. The total number of pagelets allocated to the DECwindows server may exceed the value in DECW$SERVER_WSQUOTA (up to the value of DECW$SERVER_WSEXTENT if the additional pagelets are available). For information about establishing working set sizes, see the Guide to OpenVMS Performance Management manual.
The following logical definition allocates 20000 pagelets for the DECwindows server on an as-needed basis, not to exceed the value in DECW$SERVER_WSQUOTA:
$ DEFINE DECW$SERVER_WSEXTENT 20000
|
This parameter defines the maximum amount of virtual memory (in pagelets) that the DECwindows display server can use.
The following logical definition increases the size of the page file to 1000000 blocks:
$ DEFINE DECW$SERVER_PAGE_FILE 1000000
|
This parameter defines the maximum number of files the server can open at one time. It also represents the maximum number of concurrent client connections. The default is 200 files.
The following logical definition increases the maximum number of files the server can open to 275:
$ DEFINE DECW$SERVER_FILE_LIMIT 275
|
This parameter defines the maximum number of outstanding locks that can be used in sharing resources, particularly files, between processes. The default is 512 locks.
The following logical definition doubles the default enqueue limit to 1024 locks:
$ DEFINE DECW$SERVER_ENQUEUE_LIMIT 1024
|
A feature of all the X display servers is the ability to support server extensions. These extensions are additions to the X display server that interpret additional protocol requests and perform new or improved functions.
While some extensions are built-in and always enabled, some require activation through a parameter definition. OpenVMS display servers support dynamically-loaded extensions. These extensions are contained in separate shareable images and are activated on demand. The advantage of dynamically loaded extensions is that the resources required by an extension are not used unless the extension is used.
The display server requires that certain dynamic extensions be loaded at server initialization time. Use the symbol DECW$SERVER_EXTENSIONS to identify which extensions to load.
This parameter is used to define a list of extensions to load at server initialization. The parameter translates to a list of dynamically-loadable extension images (in addition to the built-in extensions).
Table 3-2 lists the available server extensions. The default value for this parameter is "XIE,DEC-XTRAP,MULTI-BUFFERING,SEC_XAG".
| Extension Name | Parameter Value | Description |
|---|---|---|
| Digital 2D Extension | D2DX | Enhances server performance in 2D graphics environment. |
| Digital Trapping Extension | DEC-XTRAP 1 | Performs event trapping and simulation. |
| Low-Bandwidth X Extension | LBX | Enables Low-Bandwidth X proxy capabilities. |
| X Double-Buffering Extension | DBE | Provides flicker-free windows and smooth animation. |
| X Imaging Extension | XIE 1 | Performs imaging operations locally. |
| X Keyboard Extension | XKB | Enables use of X keymaps, keyboard compilers, and the AccessX keyboard features for the movement impaired. |
| X Multi-Buffering Extension | MULTI-BUFFERING 1 | Enables multi-buffered windows for smooth animation. |
| X Security and Application Group Extensions | SEC_XAG 1 | Enables X security and application grouping capabilities. |
| Xinerama Extension | XINERAMA | Enables configuration of multihead systems based on the XINERAMA protocol. |
Table 3-3 lists the built-in server extensions.
| Extension Name | Parameter Value | Description |
|---|---|---|
| Big Requests | BIG-REQUESTS | Extends the length field of a protocol request to a 32-bit value. |
| Colormap Utilization Policy | TOG-CUP | Provides colormap management policies to the display server. |
| DEC-Server-Mgmt-Extension | -- | Provides server management functions used exclusively by the Session Manager. |
| Extended Visual Information | EVI | Enables a client to query the server for information about the core X visuals, such as colormap information or framebuffer levels. |
| MIT Miscellaneious | MIT-SUNDRY-NONSTANDARD | Provides miscellaneous bug compatibility mode control. |
| MIT Screen Saver | MIT-SCREEN-SAVER | Enables a client to be notified when the screen saver is activated or cycles. |
| MIT Shared Memory | MIT-SHM | Enables shared memory, fast PutImage support. |
| Non-Rectangular Window Shape | SHAPE | Enables non-rectangular windows. |
| X Miscellaneous | XC-MISC | Allows previously-used resource ID ranges to be retreived from the display server. |
| X Synchronization | SYNC | Provides primitive calls that synchronize requests from multiple clients on different operating systems. |
| X Test | XTEST | Provides simple event trapping and simulation capabilities. |
If you have images for user-written, third-party, or other X Window System extensions, you can also use this parameter to enable these extensions at server startup. Note that some graphics devices load additional extensions used by the device (such as XFree86-DRI, GLX, and SGI-GLX).
To prevent server resource contention, some combinations of extensions should not be loaded on the same display server system. See the HP DECwindows Motif for OpenVMS Release Notes for information on extension restrictions. |
The following symbol definition specifies the range of server extensions to enable at startup:
$ DECW$SERVER_EXTENSIONS == "XIE,DEC-XTRAP,XINERAMA,SEC_XAG,DBE"
|
This parameter controls whether test extensions, XTEST and DEC-XTRAP, are enabled. Valid values for this parameter are T (True-disable) or F (False-enable) The default value is F.
The following symbol definition disables all test extensions:
$ DECW$SERVER_DISABLE_TEST == "T"
|
DECwindows supports the following mechanisms that enable you to manage access to the X display server:
Each of these methods provides additional means for defining which clients are authorized to connect to an X display server and what operations they can perform once connected. Use the parameters in this section to specify the location of the files used with these mechanisms (security policy, X authority, access allowed, and access trusted files).
See Section 3.3 for details on implementing an access control scheme for the display server.
When using the Security extension, this parameter specifies the name of the security policy file. By default, no file is specified.
The following symbol definition specifies the security policy file SYS$MANAGER:DECW$SECURITY_POLICY.DAT:
$ DECW$SECURITY_POLICY == "SYS$MANAGER:DECW$SECURITY_POLICY.DAT"
|
This parameter specifies the name of the X authority file referenced by the display server. This file provides records used to authorize client connections to the server. By default, no file is specified. This allows access to the server from the local SYSTEM account (via DECnet or the Local transport) without requiring additional authentication from the client.
If a file is specified, the values from this file are loaded into the server and can be used by all client connections. To allow a normal login process to occur, trusted access must be explicitly granted using the DECW$SERVER_ACCESS_TRUSTED.DAT file.
Note that the settings in the X authority file specified by DECW$SERVER_XAUTHORITY apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's X authority settings are applied.
The following symbol definition specifies the X authority file SYS$MANAGER:DECW$XAUTH.DAT:
$ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:DECW$XAUTH.DAT"
|
This parameter specifies the name of the trusted access file. This file lists those clients who maintain trusted access to the server. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_TRUSTED.DAT.
Note that the settings in the trusted access file specified by DECW$SERVER_ACCESS_TRUSTED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.
The following symbol definition changes the trusted access file specification to DECW$SERVER1_ACCESS_TRUSTED.DAT:
$ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER1_ACCESS_TRUSTED.DAT"
|
This parameter specifies the name of the access allowed file. This file lists those clients who are granted automatic access to the server without requiring additional authentication. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_ALLOWED.DAT.
Note that the settings in the allowed access file specified by DECW$SERVER_ACCESS_ALLOWED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.
The following symbol definition changes the allowed access file specification to DECW$SERVER1_ACCESS_ALLOWED.DAT:
$ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER1_ACCESS_ALLOWED.DAT"
|
During startup, the DECwindows startup procedures attempt to identify and activate device-specific server components to manage all graphics devices of which the system is aware. You can use the symbols and logicals in this section to influence how many and which specific devices are used by the display server.
Additionally, there is some information that the server cannot obtain from a device or that you may want to override about the display device. For example, you may need to provide information about a special type of monitor with limited color capabilities or construct a multihead system, which is a system that consists of multiple monitors that function as a single, virtual display.
DECwindows supports two types of multihead configurations:
The XINERAMA (formerly known as Panoramix) enables you to construct a multihead system and has multiple parameters to define and enable the screens in the display, control their order, and set the boundary and shape of the display.
By default, all screens in a multihead display are enabled. You can use DECW$SERVER_ONLYSCREEN, DECW$SERVER_DISABLESCREEN to remove one or more screens from the from the display. Disabled screens are not initialized and are not assigned a screen number.
For instructions on how to configure a multihead display, see Section 3.4.
This parameter configures the system for multihead support. The DECW$MULTI_HEAD symbol is already set in the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.TEMPLATE file.
To activate this parameter, copy the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.TEMPLATE to DECW$PRIVATE_SERVER_SETUP.COM.
The server uses this parameter to check for a device name by activating a specific DECW$DEVICE_xx.COM procedure, where xx is the string supplied for the symbol. The following symbol definition assigns GXA0 as the primary device:
$ DECW$PRIMARY_DEVICE == "GXA0"
|
This parameter allows you to identify those graphics devices that are used in a simple multihead configuration and specify their order. By default, the DECW$DEVICE values for will be determined based on the graphics devices installed on the system.
The following example shows a list of graphics devices to be controlled by one server, one mouse, and one keyboard:
$ DECW$DEVICE == "GAA0,GAB0"
|
This parameter overrides the default visual class for each head on a mutihead system. The visual classes, which are numeric and match the definitions in DECW$INCLUDE:X.h, are as follows:
The default for a specific device type is dependent on the hardware and is typically PseudoColor for an 8-plane color board, and TrueColor for a 24-plane option. If you have a monochrome display, you can change the default visual class to GrayScale, which causes the system to convert colors to levels of gray. Output for GrayScale is on the green lead. You can assign multiple values to this parameter for each head in a multihead system.
The following symbol definition specifies PseudoColor on head 0, TrueColor on head 1, StaticGray on head 2:
$ DECW$SEVER_DEFAULT_VISUAL_CLASS == "3,4,0"
|
The monitor density defines the dots per inch (dpi) value of the monitor so that DECwindows Motif applications can determine the actual width of the screen.
The default value for the monitor density is the server density. Because few monitors are actually 75 or 100 dpi (the values used for DECW$SERVER_DENSITY with regard to font size), these values cannot be used to calculate accurately the actual width and length of items on the screen. By setting DECW$MONITOR_DENSITY to the actual value, you can obtain correct values for the width and height of the screen using Xlib routines.
Use the following method to calculate the actual monitor density:
1280 pixels / 13.5 inches = 94.81 dpi |
By rounding the dpi value to the nearest integer, assign 95 to DECW$MONITOR_DENSITY, as shown in the following example:
$ DECW$MONITOR_DENSITY == "95"
|
Setting different values for the monitor density and the server density can cause display problems because you cannot scale the 75- and 100-dpi fonts to match the actual monitor density. |
DECW$MONITOR_DENSITY can be set on a per-monitor basis. The following example shows how to set the monitor densities for a dual-head workstation, where screen 0 is set to 95 dpi and screen 1 is set to 75 dpi:
$ DECW$MONITOR_DENSITY == "95,75"
|
With a multihead system based on XINERAMA, screens are initialized in alphabetical order according to their device name versus their physical position. Use this parameter to change the order in which the screens are initialized.
The following symbol definition changes the initialization order in a four-screen multihead display:
$ DECW$SERVER_SCREENS == "GYB0,GYA0,GYD0,GYC0"
|
With a multihead system based on XINERAMA, you can choose to re-enable disabled screens in the display individually. This parameter enables the specified screen(s). The valid value ranges from 0 to 15, which represents the maximum number of screens supported by the extension.
| Previous | Next | Contents | Index |