- Screen

Compensation for X Window client and server bugs
Meta screen

Show version changes

# Screen

Screens describe the available, real entities, which are associated to virtual meta screens.

The statements

    screen name
    window name

declare screens of screen type (Screen of type screen) and window type (Screen of type window), respectively, where name is an arbitrary string.

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 configured screens do not have to belong to the same X Window server. The DynamicServer option (Dynamic configuration) allows to add or remove a screen even later. Differing features and capabilities of all participating X Window servers are adjusted automatically (Common resources and capabilities).

Multiple X Window servers have multiple keyboards and pointing devices. The input sub-statement (Input source) determines the source of input events. The keyboardMapping sub-statement (Keyboard mapping) is used for adapting an X Window server to a special keyboard layout.

If the XmetaX 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 as well as the window statement introduce sub-statements, which specify additional parameters of the screen.

The sub-statement

        display display_name

specifies the display, on which the screen has to be displayed. The display_name is formatted as usual with X11:

    [protocol/][hostname]:display_number[.screen_number]

If the protocol is not specified, the XmetaX proxy chooses the fastest available transport mechanism. The default value is the name of the screen.

The sub-statement

        connectTimeout timeout

determines the period of time (Points of time and periods 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 the failsafe operation (Failsafe operation) is not configured or if the screen has the static screen tag (Screen tags), the xmetax program terminates.

The sub-statement

        delete

removes a screen from a configuration.

## Types of screens

There are two distinct types of screens, real hardware screens and — using the option InWindow (Options) — X11 windows.

### Screen of type screen

The statement

    screen name

declares a screen of screen type, where name is an arbitrary string.

A screen of screen type is totally controlled by the XmetaX proxy as are the other screens of the X Window server. X Window clients must connect through the proxy only. Thus, the proxy takes over total control of the X Window server.

### Screen of type window

The option InWindow (Options) allows to configure an X11 window as screen.

The statement

    window name

declares a screen of window type, where name is an arbitrary string.

The screen is displayed in an X11 window. In this case, the proxy behaves totally cooperative and does not disturb the other clients of the hosting X Window server. Such a screen can be used in two ways:

The screen may be integrated into a running X11 session, where it is controlled by a window manager. Position and size of the screen window can be controlled through the window manager. However, only with the DynamicServer option (Dynamic configuration) one can close a screen window through the window manager and thus delete the corresponding screen from the configuration. This also happens if the X11 session is terminated properly, supposing ICCCM compliant session and window managers. If the session terminates prematurely, the XmetaX proxy also stops unless failsafe operation (Failsafe operation) is configured.

The screen may be used without controlling window manager, if the restrictions of a screen of screen type are too limiting (Screen of type screen). The XmetaX proxy takes over some tasks of a window manager, if the screen has the notManaged tag (Screen tags).

## Association between screen and meta screen

Each screen has to be associated to a meta screen (Meta screen). A screen without the statement

        ofMetaScreen name_of_a_meta_screen

belongs to the most recently defined meta screen.

## Dynamic configuration

The option DynamicServer (Options) allows to connect and disconnect X Window servers at runtime.

Screens may be deleted from or added to the configuration during runtime using the configuration program xmetaxtool (XmetaXtool: configuration with graphical user interface).

When starting the XmetaX proxy, at least one screen must be configured. The common subset of the servers' resources and capabilities cannot be reduced by adding a screen.

If the XmetaX proxy cannot at least contact all potential screens at start-up, the common resources and capabilities have to be defined in advance (Common resources and capabilities).

### Priority

An xmetax program may be driven out by a second one from a screen. The screen is automatically deleted from the configuration of the first XmetaX proxy and included into the new configuration. This is useful, if, for instance, a specialized screen, like a wall display, has to be interactively associated to alternating meta screens.

Therefore, each screen — each controlled X Window server actually — gets a priority value. If a screen has to be associated to another meta screen, it is released only if its priority value increases. This new priority value can be decreased at once to avoid escalation.

The screen sub-statement

        priority priority [later_priority]

specifies both priority values. The default values are 0, i.e. driving out is impossible.

### Failsafe operation

The XmetaX proxy with the option Failsafe (Options) detects the breakdown of an X Window server, disconnects it, and deletes the corresponding screens from the configuration. The X Window clients are not affected.

Of course, the XmetaX proxy is failsafe only if the xmetax program and consequently the resource manager are executed on a failsafe computer.

The screen sub-statement

        failsafeTimeout timeout

determines the period of time (Points of time and periods of time), within which the X Window server has to honor X11 requests, before it is regarded as broken. The default value is 20 seconds.

## Emulation of visuals

The option VisEmu (Options) emulates PseudoColor visuals of depths 4 and 8 on a 24 bits deep TrueColor visual. Thus it is possible to display X Window clients designed for older graphics systems of lower depths on modern hardware often supporting 24 bits depth only.

The sub-statement

      emulateVisual {PseudoColor4|PseudoColor8|none}...

enables a specific emulation or totally disables the emulation (default).

## Resource manager

If not at least one screen of each meta screen has the static tag (Screen tags), the XmetaX proxy may be configured in such a way, that it does not control any real X Window server at all. This is also true if all screens of a meta screen are of window type. In these cases, for independently managing the X11 requests — windows, pixmaps, fonts, etc. —, the virtual X Window server xvx is automatically started on the computer which executes the XmetaX proxy. With respect to resources, this resource manager acts like an additional X Window server. However, it never needs explicit configuration nor can it be configured.

The resource manager always gets the screen tags atom, color, doNotEnter, glx, image, and static (Screen tags) regardless of the particular configuration. This affects the lookup of color names, which is done with respect to the color database in the directory /etc/opt/XSOXmetaX/rgb/. If the color name lookup should equal the lookup of a certain X Window server, the $COLOR_DATABASE_FILE environment variable of the xvx shell script (usually /opt/XSOXmetax/bin/xvx) can be set on the command line or modified in the script accordingly.

If the resource manager is running, the option GLXplus (Option GLXplus: Tunneling OpenGL through GLX) cannot be used.

One may avoid the resource manager using the static screen tag (Screen tags).

## Position of a screen

A screen may be arbitrarily positioned inside the display area of the associated meta screen (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 (Dynamic position of a screen).

The relative position is specified similar to the position of a meta screen:

        northOf|northEastOf|eastOf|sourthEastOf|southOf|southWestOf|westOf|northWestOf|sameAs
            name_of_a_screen
            [horizontal_offset_in_pixels vertical_offset_in_pixels]

The term sameAs means that the two referred screens 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 offset parameters 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.

The sub-statements

        clipX horizontal_position_in_pixels
        clipY vertical_position_in_pixels

specify a screen position relative to the origin, i.e. the uper left corner, of the display area of the associated meta screen. If only one parameter is defined, the other gets the value 0.

The option Vario (Zooming a screen) 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 each screen is 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.

In most cases only partly displaying a meta screen yields no problems. However, only 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. The mouse pointer cannot be positioned on invisible areas, except using dynamic positioning of a screen (Dynamic position of a screen). Furthermore, some X Window clients show bugs, if they should draw to invisible areas (Drawing actively) (Ignoring Expose events).

## Dynamic position of a screen

A screen can be configured to follow the motion of the pointer. In this case the positioning sub-statements (Position of a screen) define the starting position of the screen.

The sub-statements

        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.

The sub-statement

        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.

The sub-statement

        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.

## 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 (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 XmetaX proxy needs a border, which is at least one pixel wide, on every screen (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 displayX and displayY parameters — of width and height are reduced by their absolute values, respectively.

## Zooming a screen

The option Vario (Options) allows to specify the displayed area of the meta screen and therefore to scale up or down the screen contents.

The screen sub-statements

        clipX horizontal_position_in_pixels
        clipY vertical_position_in_pixels
        clipWidth width_in_pixels
        clipHeight height_in_pixels
        clipGeometry widthxheight
            [+horizontal_position+vertical_position]

determine the dimensions of the meta screen area to be displayed on the screen. Both the horizontal and the vertical dimensions can be zoomed independently. All X11 requests are scaled up or down correspondingly. Especially with non-integer zoom factors scalable fonts should be used.

The default value of 0 for all scalar parameters and 0x0+0+0 for clipGeometry, respectively, mean that the parameters displayWidth and displayHeight (Dimensions of a screen) are taken, and thus the screen is not zoomed.

If the screen is zoomed, then the screen sub-statement

        minimumTextSize height_in_pixels

determines the minimum font height for text output. Text to be displayed with a smaller font is represented by rectangles. The default value of 0 means normal text output.

## Rotating a screen

The option Vario (Options) allows to rotate a screen.

The screen sub-statements

        rotate|rotation 0|none
        rotate|rotation 90|quarter|oneQuarter [noPointer]
        rotate|rotation 180|half|twoQuarter|twoQuarters [noPointer]
        rotate|rotation 270|threeQuarter|threeQuarters [noPointer]

rotate the screen contents by 0 degrees (default), 90 degrees, 180 degrees, or 270 degrees counter-clockwise. The movements of pointer devices are adapted correspondingly unless noPointer is specified. Some X Window servers may need additional configuration for smooth pointer movement (Configuration of the X Window servers).

## Border width of a screen

In the simple cases of regularily arranged screens of same dimensions (measured in pixels) of one X Window server only the XmetaX proxy does not need to control the mouse pointer and may rely on the X Window server (Screen arrangement). In all other cases 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 of -1 lets the XmetaX proxy decide whether the screen needs a border (of width 1) or not.

The border is drawn outside the display area defined by the parameters displayX, displayY, displayWidth, and displayHeight (Dimensions of a screen).

## GLXplus

The sub-statement

        glxPlus [on|off]

enables or disables (default) the GLXplus functionality for OpenGL hardware acceleration (Option GLXplus: Tunneling OpenGL through GLX) and introduces sub-sub-statements which further configure the option.

The sub-sub-statement

            libraryPath file_name[{:file_name}...]

specifies how to find the OpenGL library to be used. A library can be specified as a fully qualified path to a file, a fully qualified path to search for a matching library, or a file to search for in the default library search path. The first valid library found will be used. The default value of GL searches in the default library search path for a library with a name containing the string GL.

X Window clients using OpenGL have to be started through the glxPlus script.

## Input source

The sub-statement

        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 XmetaX 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.

The sub-sub-statement

            clickTransfer on|off

allows or disallows (by default), that the source of input events can be transferred by simply clicking into the appropriate screen. The screen receiving input control and the screen losing input control both need this configuration statement.

### Mouse pointer

The sub-statement

        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, on the input server (Input source) the pointer image cannot be switched off.

The sub-sub-statement

            allowEnter on|off

allows (by default) or prevents that the pointer enters the screen.

If the XmetaX proxy controls multiple X Window Servers, it often has to transfer pointer movements from the input server (Input source) 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).

The sub-sub-statements

            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).

The sub-sub-statement

            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.

### Keyboard mapping

The sub-statement

        keyboardMapping name_of_the_keyboard_mapping_file

names a file in xmodmap format describing a keyboard mapping 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

    /opt/XSOXmetaX/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 /opt/XSOXmetaX/bin/xxmodmap (Configuration), respectively.

### Selections

Selections are mainly used for communication between X Window clients through an X Window server, for instance to transfer cut&paste data.

The sub-statement

        selectionSync on|off [refresh]

lets the XmetaX proxy synchronize the selections of the controlled X Window servers (off by default). In case of problems with certain X Window servers the argument refresh may help.

## Screen tags

Screen tags can be switched on or off for each screen by configuring a list (Lists) of tags.

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 XmetaX 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.

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.

If the XmetaX resource manager is started automatically using the DynamicServer or the InWindow option (Resource manager), it gets the screen tags atom, color, and font regardless of the particular configuration.

The screen tags atom, color, and font can be applied to screen type screens only.

The tags

        tags {[+|-]iconify|[+|-]notManaged|[+|-]onTop|[+|-]overlay|none}...

determine additional features of a screen of window type (Screen of type window):

A screen with the iconify tag is iconified (minimized).

For a screen which has the notManaged tag, the XmetaX proxy takes over certain tasks of a window manager, like for instance installing the correct colormap. If the screen in addition has the overlay tag, it may be positioned by dragging its border with the mouse.

A screen is mapped on top of all other windows if it is configured with the onTop tag.

If a screen of window type has to be displayed on top of a screen screen — partially obscuring it — and if both screens should receive input events, then the top screen needs the overlay tag. It provides for correct direction of input events. If the screen in addition has the notManaged tag, it may be positioned by dragging its border with the mouse.

Only the screen tags iconify and onTop can be modified when the xmetax program is running.

The other screen tags

        tags {[+|-]optimizedDraw|[+|-]probeOnly|[+|-]serverFonts
            |[+|-]static
            |[+|-]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 XmetaX proxy automatically determines if these optimizations would break the X11 protocol.

A screen marked probeOnly will be used only at startup of the XmetaX proxy for determining the subset of common resources and capabilities (Common resources and capabilities) and for calculating the meta screen dimensions (Dimensions of a meta screen) before it is deleted from the current configuration. So the proxy can take screens into account which are to be controlled later.

If the XmetaX 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.

static determines that the screen cannot be deleted from a configuration, even with the DynamicServer option. This may be used to avoid the XmetaX resource manager (Resource manager).

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 servers.

If the XmetaX 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.

Only the screen tag optimizedDraw can be modified when the xmetax program is running.

top
Compensation for X Window client and server bugs
Meta screen

Copyright © 2016 X-Software GmbH
info@x-software.com
2009-07-30 14:44:05 +0200