6 Configuration of the X-META-X proxy
6.1 Command syntax
6.2 Comments
6.3 Variables
6.4 Arithmetic expressions
6.5 Configuration file
6.6 X Window client connection
6.7 X Window server
6.8 Authorization
6.8.1 Authorization of the X Window clients by the X-META-X proxy
6.8.2 Authorization of the X-META-X proxy by the X Window servers
6.9 X Display Manager Control Protocol
6.10 Common resources and capabilities
6.11 Meta screen
6.11.1 Position of a meta screen
6.11.2 Dimensions of a meta screen
6.11.3 Common resources and capabilities
6.12 Screen
6.12.1 Association between screen and meta screen
6.12.2 Position of a screen
6.12.3 Dynamic position of a screen
6.12.4 Dimensions of a screen
6.12.5 Border width of a screen
6.12.6 Mouse pointer
6.12.7 Input control
6.12.8 Keyboard mapping
6.12.9 Screen tags
6.13 Compensation for X Window client and server bugs
6.13.1 Faulty pointer coordinates
6.13.2 Drawing actively
6.13.3 Ignoring Expose events
6.13.4 Ignoring GraphicsExpose events
6.13.5 Buggy implementation of the bit gravity concept
6.13.6 Partial implementation of the protocol extension GLX version 1.3
6.13.7 Buggy window manager
6.14 Options
6.15 Miscellaneous statements
The X-META-X proxy is stacked via interprocess communication between the clients and the X Window server(s). This has to be done during the start-up of the X Window environment (4 Integration).
Throughout the whole manual the variables $XMETAX_HOME and $XMETAX_ETC refer to the appropriate installation directories (2.2 Installation directories).
This chapter describes the functionality of X-META-X without options. You find additional configuration statements in separate chapters about the individual options.
6.1 Command syntax
When starting, the X-META-X proxy reads configuration statements from the command line or from configuration files (6.5 Configuration file). The statement syntax is identical for both sources. Thus, the command
$XMETAX_HOME/bin/xmetax connection :0.0 \ screen :1.0 screen :1.1 direction right
equals any of the following commands
$XMETAX_HOME/bin/xmetax $XMETAX_ETC/xmetax.conf $XMETAX_HOME/bin/xmetax - < $XMETAX_ETC/xmetax.conf
if the file $XMETAX_ETC/xmetax.conf contains the following lines:
# $XMETAX_ETC/xmetax.conf connection :0.0 screen :1.0 screen :1.1 direction right
This example demonstrates the default configuration, which is effective if xmetax is called without any arguments:
$XMETAX_HOME/bin/xmetax
The same configuration is described by the following lines, which show almost all configuration statements and their default values:
connection :0.0 serverNice 0 authorization none accessControl on serverAuthorization none xdmcpMode off workarounds none options none bell on vendorString none vendorReleaseNumber none nice 0 logDestination stderr logTypes none metaScreen .0 direction none relativeTo none offsetX 0 offsetY 0 width 0 height 0 keepWindowsVisible 0 screen :1.0 display :1.0 ofMetaScreen .0 connectTimeout 20 failsafe off priority 0 0 direction none relativeTo none offsetX 0 offsetY 0 clipX 0 clipY 0 clipWidth 0 clipHeight 0 displayX 0 displayY 0 displayWidth 0 displayHeight 0 borderWidth 1 followPointerX 0 followPointerY 0 followPointerMode continuous followPointerRestrict none pointer on allowEnter on sampleRate 0 sync off wrapX off wrapY off zoom 1 input on clickTransfer off keyboardMapping none tags atom color font glx image
This example also demonstrates that the X-META-X proxy is very easy to configure - in spite of the great number of configuration options. This is the consequence of reasonable default values.
The following sections describe each configuration statement in detail. First, some general notes:
- Words are separated by arbitrary white space characters. The line structure is irrelevant.
- If a word contains white space characters, it has to be surrounded by double quote characters ". This special meaning of the double quote character is overridden by preceding it with a backslash character \.
- Keywords are case-insensitive: the meanings of connectTimeout and ConnecttimeOut are identical.
- Keywords are not reserved.
- Most configuration statements consist of the name of a parameter and its new value. The name may be written with or without a directly following colon :.
- Many statements are valid in the context of a meta screen or screen definition only. They are called sub-statements and must be introduced by the appropriate metaScreen (6.11 Meta screen), screen or window statement (6.12 Screen).
- In the case of multiple parameter definitions with the same name, only the last one is valid, with the exception of the serverCommand statement which concatenates all arguments.
- The configuration parameters are not evaluated until all configuration statements are read in. This is important with respect to relative positioning statements.
The following sections describe the configuration statements by a formal syntax using the following elements:
- keywords have special meanings.
- variable_input depends on the configuration.
- alternative_1|alternative_2: Alternatives are separated by a vertical bar.
- [optional]: Optional parameters are surrounded by brackets.
- parameter...: Repetition (one or more times) is denoted by the ellipsis.
- {element}: Braces are used for grouping:
6.2 Comments
Comments start with a number symbol # and extend to the end of the line.
If a comment - after elimination of white space characters - starts at the beginning of a line, it is associated with the last defined screen or meta screen. When writing a configuration file, the configuration tool places these comment lines just between the corresponding screen or window statement (6.12 Screen) or metaScreen statement (6.11 Meta screen) and the following sub-statements.
The introducing comment lines preceding the first definition of a screen or meta screen are preserved.
All other comments are ignored and not saved by the configuration tool.
6.3 Variables
The environment variables are accessed like in a shell, for example:
serverCommand $OPENWINHOME/bin/X :1
Variable assignments, however, follow a different syntax:
set variable_name value
set XAUTHORITY $HOME/xmetax.xauthority
A variable name begins with a letter (including the underscore _) followed by letters or digits. Braces are used to separate the variable name in special situations:
set server1 remote:1.
screen ${server1}0
Each variable set in the configuration is copied into the environment where it may be accessed by, for instance, the X Window server.
6.4 Arithmetic expressions
Arithmetic expressions may contain the operators *, /, and % (modulus), + and - as well as variable references. They are surrounded by parentheses, for instance:
set nice -5 set serverNice ($nice - 2)
6.5 Configuration file
source file_name|-
file_name|-
is substituted by the contents of a configuration file. The file name - stands for the standard input stream. The file inclusions may be nested arbitrarily, but not cyclically.
stop
terminates the interpretation of a configuration file before reaching the end of the input. The remaining contents are neither read in nor saved by the configuration tool.
6.6 X Window client connection
The communication between the xmetax proxy and the X Window clients uses TCP/IP, UNIX domain sockets or other local transport mechanisms. Clients connect to a certain communication port of the machine which executes the xmetax program. The port number is specified indirectly through the display number with the statement
connection client_connection
or (however only as very first statement)
client_connection
This statement may include a fully qualified X Window display specifier (protocol/hostname:display_number.screen_number). However, only the display number is relevant. The second form of the statement allows to combine the X-META-X proxy with smart start-up programs like openwin (4.4 With openwin under Sun Solaris).
For seamlessly integrating the proxy into an existing X Window environment - the X Window clients continue to connect themselves to :0 -, the default value :0 of this parameter should not be changed. Since two servers cannot share a common communication port, the X Window server must be configured with a different display number (5 Configuration of the X Window servers).
6.7 X Window server
The xmetax program may start the local X Window server automatically. The statement
serverCommand server_program server_argument...
declares the name of the X Window server program and its arguments. All words up to the end of the command line or the configuration file are taken as server_argument.... Since succeeding key words are not recognized, this statement must be the last on the command line or in a configuration file.
Contrary to other configuration statements, the arguments of all serverCommand statements are concatenated.
In most cases, the first server_argument is the non-default display number :1 (5 Configuration of the X Window servers).
The xmetax program transparently passes the signals HUP, TERM, and USR1 and takes care of correct authorization automatically (6.8 Authorization).
serverNice nice_value
changes the relative process priority of the X Window server process. A negative nice_value from -1 to -20 increases the priority, a positive nice_value from 1 to 20 lowers the priority, the default value is 0.
6.8 Authorization
The network transparency of the X Window System holds special risks. For example, you can dump the contents of any window if you have access to the X Window server. Special security methods are used to restrict the access to an X Window server. There are two classes of methods:
- Only X Window clients running on certain machines are allowed to connect to the server (host access control). The server checks the host's network address.
- The X Window server examines a key sent by the client during connection setup (e.g. using the MIT-MAGIC-COOKIE-1 mechanism). Normally the key is stored in a file which can be accessed by the user only ($HOME/.Xauthority usually).
The X-META-X proxy transparently supports both classes of access control. However, there are two levels of authorization:
- on the one hand the authorization of the X Window clients by the X-META-X proxy
- and on the other hand the authorization of the X-META-X proxy by the X Window servers.
6.8.1 Authorization of the X Window clients by the X-META-X proxy
The X-META-X proxy authorizes its clients like an X Window server.
When (re-)initializing, the xmetax program reads the names of the hosts, which are permitted by host access control, from the file /etc/Xdisplay_number.hosts. The display_number corresponds to the client connection (6.6 X Window client connection), hence usually 0. Local connections are generally allowed. You may add or delete machines later using the program xhost.
For authorization through a key (the X-META-X proxy supports MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1), the statement
authorization file_name|none
specifies an authorization file, which the X-META-X proxy uses to authorize X Window clients.
However, if there is an authorization file defined through the -auth argument in a serverCommand statement (6.7 X Window server), then this file is also used by the X-META-X proxy. Display managers usually append the -auth argument (4.1 With a display manager).
A display manager may transmit the authorization key to the xmetax program through the Display Manager Control Protocol (6.9 X Display Manager Control Protocol).
accessControl on|off
switches the authorization of clients generally on (default value) or off.
6.8.2 Authorization of the X-META-X proxy by the X Window servers
The X-META-X proxy must be authorized by the X Window servers like a normal client. If the access to the real X Window servers is unlimited, any access restriction by X-META-X is useless.
For host access control, the name of the machine running the xmetax program must be written into the access file, usually the file /etc/Xdisplay_number.hosts, unless the xmetax program and the X Window server are running on the same machine. The display_number corresponds to the display number of the X Window server (6.7 X Window server), hence usually 1 with the proxy, otherwise 0. Using the program xhost, the hostname can be added later when the X Window server is already running.
For key authorization (the X-META-X proxy supports MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1) the file $HOME/.Xauthority and the environment variable $XAUTHORITY are relevant. However they can be overridden by the statement
serverAuthorization file_name|own|none
defining an authorization file, which is used by the X-META-X proxy only for the authorization by the X Window servers, which are started by the proxy, namely through the serverCommand statement (6.7 X Window server) or as ressource manager using one of the options INWINDOW (8.3 Resource manager) or DYNAMICSERVER (9.3 Resource manager).
The parameter own lets the X-META-X proxy generate a random key for authorization by the X Window servers.
If this server side authorization file is not configured, the xmetax program tries to get an appropriate key from the client side (6.8.1 Authorization of the X Window clients by the X-META-X proxy). In general it succeeds if the authorization file is configured by the display manager using the -auth argument. (4.1 With a display manager).
6.9 X Display Manager Control Protocol
The X Display Manager Protocol (XDMCP) is used by a display manager (usually the xdm program or the dtlogin program under CDE) for managing remote X Window servers, mostly X terminals. The communication between display manager and X Window server comprises the following simplified steps:
- During its initialization the X Window server tries to connect to a display manager on the network which is willing to manage the server.
- If the display manager is willing to manage the server, it begins the login dialog.
- After the user successfully logged in, the display manager starts a session.
- When the user terminates the session, the login dialog is displayed again.
XDMCP has to be configured only if the display manager and the xmetax program are running on different machines. The statements:
xdmcpMode [broadcast|indirect|query|off] [once] xdmcpHost name_of_the_XDMCP_host xdmcpPort XDMCP_port_number
- broadcast: the xmetax program sends XDMCP queries to all hosts on the network.
- indirect: the xmetax program sends indirect XDMCP queries to the host specified by the xdmcpHost statement, which passes them on to certain other hosts.
- query: the xmetax program sends XDMCP queries to the host specified by the xdmcpHost statement only.
- off disables the XDMCP support. This is the default value.
once lets the xmetax program terminate after the execution of one session only. The xdmcpPort statement specifies the port for the XDMCP communication. The default value is the "well known" port number 177.
xdmcpDisplayClass display_class xdmcpDisplayID display_ID
identify the xmetax program to the display manager. The default values are X-SOFTWARE-X-META-X and X-SOFTWARE-X-META-X-system_ID-display_number, respectively.
xdmcpAuthorizationCookie key
specifies a key for the authorization by the XDM-AUTHORIZATION-1 method (6.8 Authorization).
If XCMCP is configured by arguments in a serverCommand statement (6.7 X Window server), these are also used by the X-META-X proxy.
6.10 Common resources and capabilities
X-META-X may combine even rather different screens to meta screens. Therefore, certain characteristics of the screens are matched and equalized automatically and presented to the X Window clients in the connection setup reply. The following statements affect the matching procedures so that the results are more restricted.
However, this is only useful in exceptional cases, for instance, if a DYNAMICSERVER configuration (9 X-META-X Option DYNAMICSERVER) has to be extended later by an additional X Window server with different capabilities.
When playing a file recorded by X-META-X the graphics capabilities of recording and displaying X Window servers should be similar, too. If the playback X Window server does not support all capabilities of the recording X Window server(s), the following statements may be used to let the X-META-X proxy use not all capabilities of the controlled X Window server(s).
Most of the capabilities of the X Window servers as well as of the X-META-X proxy can be examined by the xdpyinfo program.
numberOfKeyCodes number_of_key_codes
specifies the number of codes of the keyboard mapping. Different keyboard mappings are translated automatically.
numberOfButtons number_of_buttons
specifies the number of buttons on the pointing device. Different pointer mappings are translated automatically.
maximumNumberOfScreens number_of_screens_per_server
determines the maximum number of screens per X Window server.
maximumRequestSize size_in_4_byte_quantitities maximumBigRequestSize size_in_4_byte_quantitities
specify the maximum size of X11 protocol requests, without and with the BIG-REQUESTS protocol extension, respectively, each in quantities of four bytes.
numberOfResourceIdBits number
denotes the number of actually variable bits in resource ids. Generally, this value is 19 for X Window servers up to protocol release X11R4, and 22 from release X11R5 on.
fontPath {[+|-]font_path_name}...
specifies which components of the default font path should be presented to the X Window clients initially. If a specifier starts with a minus character -, then the corresponding font path component is deleted from the supported font path, otherwise they are included into the font path. The initial font path depends on the first specifier: if it starts with a minus character -, the initial font path contains the font path components supported by all screens of the meta screen, otherwise the initial font path is empty.
extensions {[+|-]name_of_the_protocol_extension}...
defines the protocol extensions supported by the X-META-X proxy. If a specifier starts with a minus character -, then the corresponding protocol extension is deleted from the set of supported protocol extensions, otherwise they are included into the set. The initial set depends on the first specifier: if it starts with a minus character -, the initial set contains the protocol extensions supported by all screens of the meta screen, otherwise the initial set is empty.
If the X-META-X proxy has to be configured during run-time (19 X-META-X-TOOL configuration tool), the protocol extension X-SOFTWARE META must not be excluded. The same is true for the protocol extensions X-SOFTWARE KEYMAP, X-SOFTWARE POSE, and X-SOFTWARE TRANSLUCENT, respectively.
pixmapFormats {[+|-][depth][:[bits_per_pixel][:[line_padding]]]}...
specifies the pixmap formats which are presented to the X Window clients. If a specifier does not fully qualify a pixmap format (i.e. it contains one or more empty fields between the colons :) the specifier may denote multiple pixmap formats. If a specifier starts with a minus character -, then the corresponding pixmap formats are deleted from the set of supported pixmap formats, otherwise they are included into the set. The initial set depends on the first specifier: if it starts with a minus character -, the initial set contains the pixmap formats supported by all screens of the meta screen, otherwise the initial set is empty.
visuals
{[+|-][class][:[depth]
[:[number_of_significant_bits]
[:[layer][:[transparency_type][:[transparency_value]
[:[singleBuffered|doubleBuffered|singleOnDoubleBuffered]
]]]]]]}...
defaultVisual
[class][:[depth]
[:[number_of_significant_bits]
[:[layer][:[transparency_type][:[transparency_value]
[:[singleBuffered|doubleBuffered|singleOnDoubleBuffered]
]]]]]]
are described in the section about meta screens (6.11.3 Common resources and capabilities).
6.11 Meta screen
Although X-META-X eliminates the borders between the screens of one or more X Window servers, it may offer multiple screens, so-called meta screens, to the clients. For instance, screens with different graphics capabilities may be grouped to several meta screens. In the statement
metaScreen name
name is an arbitrary string. Each meta screen corresponds to a screen number, increasing from .0 on.
Without this statement, the xmetax program creates all meta screens referred to by any screen definition, at least one.
The metaScreen statement introduces sub-statements, which specify additional parameters of the meta screen.
delete
removes a meta screen from a configuration.
6.11.1 Position of a meta screen
Like most X Window servers, X-META-X allows to move the mouse pointer from one screen (here meta screen) to an other. For determining the neighboring meta screen, the relative positions of all meta screens must be known. The sub-statements
direction left|right|up|down|none relativeTo name_of_a_meta_screen offsetX horizontal_offset_in_pixels offsetY vertical_offset_in_pixels
define the position of a meta screen relative to an other one. Cyclic definitions are not allowed. The first two statements have to be specified together. The parameters offsetX and offsetY default to the value 0. Without a position specification the meta screen is positioned right to the preceding one, with the exception of the first one.
6.11.2 Dimensions of a meta screen
width width_in_pixels|double height height_in_pixels|double
define the dimensions of the virtual display area of a meta screen. The default values of 0 have the special meaning that the area is just big enough to enclose the associated screens (6.12.2 Position of a screen). These dimensions can be doubled by specifying double.
For total compliance with the X11 protocol, the whole display area of the meta screen should be covered by screens, and it should be visible - with window type screens, too. The mouse pointer cannot be positioned on invisible areas, except using dynamic positioning of a screen (6.12.3 Dynamic position of a screen). Furthermore, some X Window clients show bugs, if they should draw to invisible areas (6.13 Compensation for X Window client and server bugs). However, in most cases partly displaying a meta screen yields no problems.
keepWindowsVisible number_of_pixels
determines that at least an area of number_of_pixels pixels in both dimensions of each window remains within the visible part of the meta screen, even if it is positioned at an invisible position or if a screen is deleted from the configuration. This works only with window managers compliant to the ICCCM (Inter-Client Communication Conventions Manual) or without any window manager, in rare cases a workaround (6.13.7 Buggy window manager) may be necessary. The default value 0 for number_of_pixels disables this function.
6.11.3 Common resources and capabilities
visuals
{[+|-][class][:[depth]
[:[number_of_significant_bits]
[:[layer][:[transparency_type][:[transparency_value]
[:[singleBuffered|doubleBuffered|singleOnDoubleBuffered]
]]]]]]}...
is used in special cases only (6.10 Common resources and capabilities). It specifies for each meta screen the visuals presented to the X Window clients.
The sub-statement contains one or more visual specifiers. If a specifier does not fully qualify a visual (i.e. it contains one or more empty fields between the colons :) the specifier may denote multiple visuals. The individual fields specify in this order:
- The class of the visual: StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, or DirectColor;
- The color depth;
- The number of significant bits in color specifications;
- The number of the layer associated with the visual;
- The kind of transparency of an overlay visual;
- A value, the meaning of which depends on the kind of transparency;
- The number of buffers associated with each window:
The fields specifying layer and transparency are ignored unless the X Window server follows the SERVER_OVERLAY_VISUALS convention.
If a specifier starts with a minus character -, then the corresponding visuals are deleted from the set of supported visuals, otherwise they are included into the set. The initial set depends on the first specifier: if it starts with a minus character -, the initial set contains the visuals supported by all screens of the meta screen, otherwise the initial set is empty.
Visuals which are not supported by a particular screen of the meta screen can be specified, but will not be offered to the X Window clients, unless the screen has the sloppyVisuals tag (6.12.9 Screen tags) tag.
If two visuals differ in the depth only, then they are associated to a visual of the smaller depth, if the corresponding screen has the sloppyDepths tag (6.12.9 Screen tags).
defaultVisual [class][:[depth] [:[number_of_significant_bits] [:[layer][:[transparency_type][:[transparency_value] [:[singleBuffered|doubleBuffered|singleOnDoubleBuffered] ]]]]]]
denotes the default visual and thus the default color model of the meta screen.
6.12 Screen
Screens describe the available, real entities, which are associated to virtual meta screens.
screen name
declares a screen, where name is an arbitrary string.
A screen is totally controlled by the X-META-X proxy as are the other real screens of the X Window server. X Window clients must connect through the proxy only. Hence, the proxy takes over total control of the X Window server.
If there are no screens defined, the xmetax program tries to control the screen with the display name :1.0. If two or more screens have to be controlled, they must be configured explicitly.
The option INWINDOW (8 X-META-X Option INWINDOW) allows to configure an X11 window as screen.
The configured screens do not have to belong to the same X Window server. The DYNAMICSERVER option (9 X-META-X Option DYNAMICSERVER) allows to add or remove a screen even later. Differing features and capabilities of all participating X Window servers are adjusted automatically (6.10 Common resources and capabilities).
Multiple X Window servers have multiple keyboards and pointing devices. The input sub-statement (6.12.7 Input control) determines the source of input events. The keyboardMapping sub-statement (6.12.8 Keyboard mapping) is used for adapting an X Window server to a special keyboard layout.
If the X-META-X proxy controls multiple X Window servers, all have to support at least one of the protocol extensions DEC-XTRAP, XTEST, and XTestExtension1.
The screen statement and the window statement (8 X-META-X Option INWINDOW) introduce sub-statements, which specify additional parameters of the screen.
delete
removes a screen from a configuration.
display display_name_of_the_real_screen
specifies the display, on which the screen has to be displayed. The display_name is formatted as usual with X Window:
[protocol/][hostname]:display_number[.screen_number]
If the protocol is not specified, the X-META-X proxy chooses the fastest available transport mechanism. The default value is the name of the screen.
connectTimeout timeout_in_seconds
determines the period of time, within which the xmetax program tries to connect to the corresponding X Window server. If the connection cannot be established within the timeout (20 seconds by default) and if failsafe (10 X-META-X Option FAILSAFE) is not configured or if the screen has the static screen tag (6.12.9 Screen tags), the xmetax program terminates.
6.12.1 Association between screen and meta screen
Each screen has to be associated to a meta screen (6.11 Meta screen). A screen without the statement
ofMetaScreen name_of_a_meta_screen
belongs to the most recently defined meta screen.
6.12.2 Position of a screen
A screen may be arbitrarily positioned inside the display area of the associated meta screen (6.11.2 Dimensions of a meta screen), either relative to an other screen of the same meta screen or absolute. Furthermore, the screen may follow the motion of the pointer (6.12.3 Dynamic position of a screen).
The relative position is specified similar to the position of a meta screen:
direction left|right|up|down|same|none relativeTo name_of_a_screen offsetX horizontal_offset_in_pixels offsetY vertical_offset_in_pixels
The first two statements have to be specified together. The direction same means that this screen and the screen denoted by the relativeTo sub-statement are positioned at the same location of the meta screen displaying the same contents. Thus, partially or totally overlapping screens are allowed. Cyclic definitions are not allowed. The parameters offsetX and offsetY default to the value 0. A screen without a position specification is positioned right to the preceding one, with the exception of the first one of the meta screen.
clipX horizontal_position_in_pixels clipY vertical_position_in_pixels
specify a screen position relative to the origin of the display area of the associated meta screen. If only one parameter is defined, the other gets the value 0.
The option VARIO (7 X-META-X Option VARIO) allows to specify the displayed area of the meta screen and therefore to scale up or down the screen contents.
Each screen must lie totally within the display area of the associated meta screen. Therefore during initialization all screens together are moved to non-negative coordinates within the corresponding meta screen and each meta screen is enlarged at the right and bottom sides to comprise all associated screens.
For total compliance with the X11 protocol, the whole display area of the meta screen should be covered by screens, and it should be visible - with window type screens, too. The mouse pointer cannot be positioned on invisible areas, except using dynamic positioning of a screen (6.12.3 Dynamic position of a screen). Furthermore, very few X Window clients show bugs, if they should draw to invisible areas (6.13 Compensation for X Window client and server bugs). However, in most cases partly displaying a meta screen yields no problems.
6.12.3 Dynamic position of a screen
A screen can be configured to follow the motion of the pointer. In this case the positioning sub-statements (6.12.2 Position of a screen) define the starting position of the screen.
followPointerX horizontal_step_in_pixels followPointerY vertical_step_in_pixels
specify whether the screen should follow the pointer motion and the amount of screen movement. The default value of 0 for both parameters denotes a fixed position of the screen. If only one step value is defined, it is valid for both directions.
If the pointer reaches a screen border, the display area of the screen is shifted on the virtual area of the associated meta screen in the direction of the pointer motion, unless a fixed screen can be reached directly. If multiple screen type screens are defined to follow the pointer, they are moved together as group without changing the relative position to each other.
followPointerMode continuous|jump
distinguishes two kinds of pointer and screen movement:
- With the default value continuous the logical pointer position remains at the screen border and the screen movement is not stopped until the pointer is moved in the opposite direction.
- With jump the pointer is moved back to its logical position automatically and the screen movement is stopped immediately.
followPointerRestrict {shift|lock|control
|mod1|mod2|mod3|mod4|mod5|none}...
lets the screen follow the mouse only if certain modifier keys or at least one mouse button are pressed. This helps avoiding unintentional screen movements. The restriction is switched off by default.
6.12.4 Dimensions of a screen
The display area of a screen may be smaller than the area of the monitor. This is useful when regularly arranging monitors with different dimensions in one meta screen. The unused areas are controlled by the X Window server, but may be displayed in black color using the borderWidth sub-statement (6.12.5 Border width of a screen). The position and the dimensions of the viewable display area are specified by the sub-statements
displayX horizontal_position_in_pixels displayY vertical_position_in_pixels displayWidth width_in_pixels displayHeight height_in_pixels displayGeometry widthxheight [+horizontal_position+vertical_position]
The default value of 0 for all scalar parameters and 0x0+0+0 for displayGeometry, respectively, mean that the screen fills the whole display area of the monitor. Since the X-META-X proxy needs a border, which is at least one pixel wide, on every screen (6.12.5 Border width of a screen), the maximum dimensions of a screen type screen are two pixels smaller than the real dimensions of the monitor, for instance 1278×1022 instead of 1280×1024 pixels.
If the parameters displayWidth or displayHeight are negative, the maximum values - under consideration of the displayOffsetX and displayOffsetY parameters - of width and height are reduced by their absolute values, respectively.
The option VARIO (7 X-META-X Option VARIO) allows to specify the displayed area of the meta screen and therefore to scale up or down the screen contents.
6.12.5 Border width of a screen
Each screen has a black border of at least one pixel width. The sub-statement
borderWidth width_in_pixels
specifies the width of the border. The default value is 1. The border is drawn outside the display area defined by the parameters displayX, displayY, displayWidth, and displayHeight (6.12.4 Dimensions of a screen).
6.12.6 Mouse pointer
pointer [on|off]
introduces sub-sub-statements, which configure the mouse pointer on the screen. In addition the pointer image can be switched on (by default) or off totally. However, the pointer image on the screen which carries the input screen tag (6.12.9 Screen tags) cannot be switched off.
allowEnter on|off
allows (by default) or prevents that the pointer enters the screen.
If the X-META-X proxy controls multiple X Window Servers, it often has to transfer pointer movements from the input machine (6.12.7 Input control) to an other server. If the input server is much more powerful than the other server, the pointer image may not keep up with the actual movement. The sub-sub-statement
sampleRate number_of_samples_per_second
limits the number of pointer movements transferred in one second. The default value of 0 means that all mouse movements are sent.
Certain combinations of X Window servers yield jerky movements of the pointer images on remote servers. The sub-sub-statement
sync on|off
determines, whether each pointer movement request is flushed immediately or not (default).
wrapX on|off wrapY on|off
determine, whether the pointer should be warped to the horizontally or vertically opposite border when touching the visible border of the respective meta screen or not (default).
zoom zoom_factor
defines an integer zoom factor for all pointer images of a screen. The smoothing algorithm works best with a power of two as factor. The default value is 1. Some X Window servers clip or even distort large cursor images.
6.12.7 Input control
input [on|off]
introduces sub-sub-statements, which configure the input for the screen. In addition the source of input events can be changed. If input is switched on for a screen, the X-META-X proxy receives all input events from the corresponding X Window server only.
If the input screen is changed at runtime, the keyboard and pointer mappings are changed and all X Window clients receive the appropriate MappingNotify events. Thus, it is possible to switch between keyboards with different layouts or to support multiple languages.
clickTransfer on|off
allows or disallows (by default), that the source of input events can be transferred by simply clicking into the appropriate screen.
6.12.8 Keyboard mapping
keyboardMapping name_of_the_keyboard_mapping_file
names a file in xmodmap format which is loaded into the appropriate X Window server during the first configuration and at each server reinitialisation. Thus, the X Window server can be adapted to special keyboard layouts.
The file may be generated using the command
$XMETAX_HOME/bin/makeKeyboardMapping [-display display_name_of_the_real_screen] [-xmodmap name_of_the_xmodmap_program]
without running the xmetax program. The default values for -display and -xmodmap are :0.0 and $XMETAX_HOME/bin/xxmodmap (17.2 Configuration), respectively.
6.12.9 Screen tags
Screen tags can be switched on or off for each screen.
The xmetax program sends most X11 request to multiple screens of a meta screen. Nevertheless, using the first set of tags
tags {[+|-]atom|[+|-]color|[+|-]font|[+|-]glx|[+|-]image|none}...
individual screens or X Window servers can be tagged and distinguished:
- The atom screen (atom) is used for all requests related to the X Window terms atom, property, and selection.
- The color screen (color) is used for lookup of color names. Each meta screen has its own color screen.
- All font inquiries are sent to the font screen (font).
- Certain GLX protocol extension inquiries are sent to the GLX screen (glx).
- The image screen (image) determines the image format (bit and byte order, padding, etc.) of the virtual server.
Most of these properties are irrelevant if the X-META-X proxy controls only one X Window server. The defaults (mostly first screen or first screen of a meta screen, respectively) should be sufficient.
Otherwise, every tagged screen should determine an X Window server, which fulfils the corresponding task most efficiently. For instance, the font screen should not need to query a remote font server for font lookups.
The screen with the worst color resolution (significant bits in color specification) must be the color screen. If only one of the screens has only static visuals (StaticGray, StaticColor, DirectColor), this screen should be specified as color screen.
tags {[+|-]optimizedDraw|[+|-]serverFonts|[+|-]sloppyDepths
|[+|-]sloppyVisuals|[+|-]staticDisplay
|[+|-]zoomedFonts|none}...
determine additional features of a screen:
- optimizedDraw denotes that certain optimizations during drawing requests should be carried out in any case. Otherwise, by default, the X-META-X proxy automatically determines if these optimizations would break the X11 protocol.
- If the X-META-X proxy controls multiple X Window servers, the fonts of the server with the font tag are used also for text display on the other screens. The screen tag serverFonts lets the proxy use the local fonts of the corresponding server. However, in this case the default font paths as well as the contents of the font directories must be equal for all servers. Since different X Window servers transform even identical font data in different manners, one should use an X font server in case of a heterogeneous configuration. Thus, all font data is transformed by one authority only, the X font server, and even scaled fonts are uniformly displayed on all X Window servers.
- When building the common subset of visuals supported by a meta screen (6.11.3 Common resources and capabilities), screens with the sloppyDepths tag are treated in a special way: if there is no normal mapping for a certain visual, it is mapped on a visual with same characteristics but smaller depth, as long as this mapping is reversible. Thus, a screen with a TrueColor visual with a depth of 15 bits and a screen with a TrueColor visual with a depth of 16 bits can match, and the X Window clients can use a 15 bit visual.
- When building the common subset of visuals supported by a meta screen(6.11.3 Common resources and capabilities), screens with the sloppyVisuals tag are neglected. Drawing requests with a wrong visual in this sense are not executed, the window background remains white. This screen tag allows to combine, for instance, a screen with a depth of 8 bits with a 24 bits deep screen to a meta screen. However, 24 bits graphics are displayed on the second screen only, not on the first screen.
- If the position and dimensions of a screen relative to its meta screen remain constant, the staticDisplay tag may yield some optimizations with respect to memory consumption by the X Window server.
- If the X-META-X proxy controls multiple X Window servers and the screen tag serverFonts is set, the zoomedFonts tag determines whether the proxy itself should scale fonts or choose smaller or larger fonts depending on the scale factors. The first, default, method gives more performance, the second method generally gives better looking results.
The sloppyVisuals tag cannot be combined with the color tag.
The screen tags atom, font, and image are specified in the screen sub-statement, but are associated to the entire X Window server which displays the screen.
The screen tags atom, color, and font can be applied to screen type screens only. You find additional screen tags in the chapters about the options INWINDOW (8 X-META-X Option INWINDOW) and DYNAMICSERVER (9 X-META-X Option DYNAMICSERVER).
Only the screen tag optimizedDraw can be modified when the xmetax program is running.
If the X-META-X resource manager is started automatically using the DYNAMICSERVER option (9.3 Resource manager) or the INWINDOW option (8.3 Resource manager), it gets the screen tags atom, color, and font regardless of the particular configuration.
6.13 Compensation for X Window client and server bugs
workarounds {[+|-]activeDrawInWindow
|[+|-]exposeAfterGraphicsExpose
|[+|-]exposeBeforeGraphicsExpose
|[+|-]exposeInsteadOfGraphicsExpose
|[+|-]fixPointerCoordinates
|[+|-]forgetBitGravity
|[+|-]glx13
|[+|-]mapDiscardExpose
|[+|-]refreshBitGravity
|[+|-]wmIgnoresMoveWindow
|[+|-]wmIncludesDecoration|none}...
may be used for compensation for bugs of X Window clients and servers which arise with certain configurations of X-META-X, or for certain enhancements. The means do not always comply with the X11 protocol. However, they do never harm well behaving clients.
The following sections and some of the chapters about options describe the problems and the solutions by example.
6.13.1 Faulty pointer coordinates
Some X Window servers yield wrong pointer coordinates in certain situations. The statement
workarounds fixPointerCoordinates
lets the xmetax program ignore unreasonable motion events and correct wrong return values of the XQueryPointer request.
6.13.2 Drawing actively
An X Window client should never draw on his own but wait for and react on Expose or GraphicsExpose events. Especially some window managers do not obey this rule. They grab the server, draw and ignore one or all expose events until the release of the server grab. An X Window client acting so without grabbing the server would be incorrect even without X-META-X.
While interactively moving or resizing a window, the window manager mostly provides visual feedback through drawing repeatedly the window's outline. This is done using the GXxor rasterop, because simply re-drawing with the same parameters erases the outline.
If in this situation the position of the screen is changed by moving the pointer (6.12.3 Dynamic position of a screen), then a region of the meta screen becomes visible, where the outline is not yet drawn. The following drawing operation for erasing the outline draws the outline in this newly exposed area.
The window managers of OpenWindows (olwm), OSF/Motif (mwm), and CDE (dtwm) show this behavior. Each of these window managers can be configured so that it moves the whole window instead of the window's outline. However, this does not help when resizing a window.
workarounds activeDrawInWindow
makes the xmetax program refresh the newly visible areas after release of the server grab. Thus, the wrong remainders of the outline are erased.
6.13.3 Ignoring Expose events
Before the OpenWindows window manager olwm exits, it actively draws a confirmation dialog. Afterwards, it ignores the first Expose event after the MapWindow request.
If the region of the meta screen, in which the dialog should appear, happens to be invisible, the drawing operations have no effect. When the screen is moved for showing the dialog, Expose events are generated. However, the first Expose event is ignored by olwm.
workarounds mapDiscardExpose
makes the xmetax program send one additional Expose event to the client.
6.13.4 Ignoring GraphicsExpose events
Few buggy X Window clients (like the demo program puzzle) ignore GraphicsExpose events assuming that their windows are always unobscured. For instance, if a client actively draws the contents of a scrolling window instead of reacting on Expose and GraphicsExpose events, newly visible areas of the windows might not get correctly updated.
workarounds exposeAfterGraphicsExpose workarounds exposeBeforeGraphicsExpose workarounds exposeInsteadOfGraphicsExpose
make the xmetax program send an Expose event for each GraphicsExpose event to the client, after, before and instead of the GraphicsExpose event, respectively. This event should cause a refresh of the new window contents.
6.13.5 Buggy implementation of the bit gravity concept
Some X Window clients try to take advantage of the concept of bit gravity in order to minimize the areas to be redrawn. Not all X Window servers implement this concept correctly.
workarounds forgetBitGravity
switches off the bit gravity totally and the statement
workarounds refreshBitGravity
makes the xmetax program totally refresh the window contents after resizing.
6.13.6 Partial implementation of the protocol extension GLX version 1.3
workarounds glx13
lets the X-META-X proxy interpret and process the GLX requests GetFBConfigs, MakeContextCurrent, CreateWindow, DestroyWindow, GetColorTable, GetColorTableParameter*, GetConvolutionFilter, GetConvolutionParameter*, GetSeparableFilter, GetHistogram, GetHistogramParameter*, GetMinmax, and GetMinmaxParameter*, which are not defined in version 1.2 of the GLX protocol extension.
6.13.7 Buggy window manager
For the correct function of the keepWindowsVisible statement (6.11.2 Dimensions of a meta screen) one or both of the following workarounds may be necessary.
If the window manager refuses to position a window according to the ICCCM (Inter-Client Communication Conventions Manual) the statement
workarounds wmIgnoresMoveWindow
lets the X-META-X proxy directly position the window.
If the visible window seems to be mispositioned by the width of the window decoration the statement
workarounds wmIncludesDecoration
6.14 Options
options {[+|-]dynamicServer|[+|-]failsafe|[+|-]inWindow
|[+|-]keymap|[+|-]multiMedia|[+|-]pose|[+|-]translucent
|[+|-]vario|none}...
enables or disables product options. However, only options which are covered by the license key (3 Licensing) may be enabled. The default setting - no additional options - corresponds to the X-META-X base product.
Separate chapters introduce each individual option.
6.15 Miscellaneous statements
Every X Window server knows a default font, which can be used by a client without opening the font explicitly. Because the name of this font cannot be inquired, the statement
fontName font_name
declares the default font for the X-META-X proxy (the default value is fixed).
bell on|off
lets the X-META-X proxy pass the audible bell X11 request to the controlled X Window(s) (default) or not. This allows to run a virtual proxy silently.
X Window clients may ask for the identity (vendor string) and version number (vendor release number) of the X Window server. The statements
vendorString none|same|vendor_string vendorReleaseNumber none|same|vendor_release_number
specify the values to be returned to the clients. The value same lets the xmetax program pass on the values of the (first) X Window server unmodified, with the default value of none the vendor string
X-META-X of X-Software GmbH
and the vendor release number 71 are returned.
nice nice_value
changes the relative priority of the xmetax process. A negative nice_value from -1 to -20 increases the priority, a positive nice_value from 1 to 20 lowers the priority, the default value is 0.
The destination of error messages and warnings may be specified by the statement
logDestination -|stdout|stderr|syslog|file_name
If file_name ends with .html or .htm, the messages are output in HTML format, else in plain text format. The default destination is the standard error output stream. Syntax error messages are printed there, too.
logTypes {[+|-]dynamicServerStatistics|[+|-]extensionDetails
|[+|-]protocolErrors|[+|-]visualDetails|none}...
configures additional logging output:
- dynamicServerStatistics prints the number of each type of X11 request transferred to an X Window server.
- extensionDetails prints the names of all protocol extensions queried by the X Window clients.
- protocolErrors traces X11 protocol errors.
- visualDetails prints informations about the matching of visuals of the controlled screens (6.11.3 Common resources and capabilities).
| |||||||||||||||
 | |||||||||||||||
 | |||||||||||||||
 | |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||