Compensation for X Window client and server bugs

The statement

workarounds {[+|-]absoluteInputDeviceMode
|[+|-]activeDrawInWindow
|[+|-]exposeAfterGraphicsExpose
|[+|-]exposeBeforeGraphicsExpose
|[+|-]exposeInsteadOfGraphicsExpose
|[+|-]fixPointerCoordinates
|[+|-]forgetBitGravity
|[+|-]mapDiscardExpose
|[+|-]refreshBitGravity
|[+|-]wmIgnoresMoveWindow
|[+|-]wmIncludesDecoration|none}...

may be used for compensation for bugs of X Window clients and servers which arise with certain configurations of XmetaX, or for special enhancements. These corrections do not always comply with the X11 protocol. However, they do never harm well behaving clients.

The following sections describe the problems and the solutions by example.

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

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

The statement

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.

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.

The statement

workarounds mapDiscardExpose

makes the xmetax program send one additional Expose event to the client.

Ignoring GraphicsExpose events

Few buggy X Window clients erroneously 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.

The statements

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 the redraw of the new window contents.

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.

The statement

workarounds forgetBitGravity

switches off the bit gravity totally and the statement

workarounds refreshBitGravity

makes the xmetax program totally refresh the window contents after resizing.

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.

Faulty pointer coordinates mode

If a screen is to be rotated (Rotating a screen), on certain architectures (Configuration of the X Window servers) the XmetaX proxy tries to use a virtual input device for direct control of the pointer image. Some X Window servers erroneously report absolute instead of relative mouse pointer coordinates.

The statement

workarounds absoluteInputDeviceMode

lets the xmetax program interpret the pointer coordinates relatively instead of absolutely.

Buggy window manager

For the correct function of the keepWindowsVisible statement (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 XmetaX proxy directly position the window.

If the visible window seems to be mispositioned by the width of the window decoration the statement

workarounds wmIncludesDecoration

will help.

Partial implementation of the protocol extension GLX version 1.3

Copyright © 2018 X-Software GmbH
info@x-software.com