Xdmx(1)Xdmx(1)NAMEXdmx - Distributed Multi-head X server
SYNOPSISXdmx [:display] [option ...]
DESCRIPTIONXdmx is a proxy X server that uses one or more other X servers as its
display devices. It provides multi-head X functionality for displays
that might be located on different machines. Xdmx functions as a
front-end X server that acts as a proxy to a set of back-end X servers.
All of the visible rendering is passed to the back-end X servers.
Clients connect to the Xdmx front-end, and everything appears as it
would in a regular multi-head configuration. If Xinerama is enabled
(e.g., with +xinerama on the command line), the clients see a single
large screen.
Xdmx communicates to the back-end X servers using the standard X11 pro‐
tocol, and standard and/or commonly available X server extensions.
OPTIONS
In addition to the normal X server options described in the Xserver(1)
manual page, Xdmx accepts the following command line switches:
-display display-name
This specifies the name(s) of the back-end X server display(s)
to connect to. This option may be specified multiple times to
connect to more than one back-end display. The first is used
as screen 0, the second as screen 1, etc. If this option is
omitted, the $DISPLAY environment variable is used as the sin‐
gle back-end X server display.
-xinput input-source
This specifies the source to use for XInput extension devices.
The choices are the same as for -input , described below,
except that core devices on backend servers cannot be treated
as XInput extension devices. (Although extension devices on
backend and console servers are supported as extension devices
under Xdmx).
-input input-source
This specifies the source to use for the core input devices.
The choices are:
dummy
A set of dummy core input drivers are used. These never
generate any input events.
local
The raw keyboard and pointer from the local computer are
used. A comma-separated list of driver names can be
appended. For example, to select the example Linux key‐
board and PS/2 mouse driver use: -input local,kbd,ps2. The
following drivers have been implemented for Linux: kbd, ms
(a two-button Microsoft mouse driver), ps2 (a PS/2 mouse
driver), usb-mou (a USB mouse driver), usb-kbd (a USB key‐
board driver), and usb-oth (a USB non-keyboard, non-mouse
driver). Additional drivers may be implemented in the
future. Appropriate defaults will be used if no comma-sep‐
arated list is provided.
display-name
If the display-name is a back-end server, then core input
events are taken from the server specified. Otherwise, a
console window will be opened on the specified display.
If the display-name is followed by ",xi" then XInput exten‐
sion devices on the display will be used as Xdmx XInput
extension devices. If the display-name is followed by
",noxi" then XInput extension devices on the display will
not be used as Xdmx XInput extension devices. Currently,
the default is ",xi".
If the display-name is followed by ",console" and the dis‐
play-name refers to a display that is used as a backend
display, then a console window will be opened on that dis‐
play and that display will be treated as a backend display.
Otherwise (or if ",noconsole" is used), the display will be
treated purely as a backend or a console display, as
described above.
If the display-name is followed by ",windows", then out‐
lines of the windows on the backend will be displayed
inside the console window. Otherwise (or if ",nowindows"
is used), the console window will not display the outlines
of backend windows. (This option only applies to console
input.)
If the display-name is followed by ",xkb", then the next 1
to 3 comma-separated parameters will specify the keycodes,
symbols, and geometry of the keyboard for this input
device. For example, ",xkb,xfree86,pc104" will specify
that the "xfree86" keycodes and the "pc104" symbols should
be used to initialize the keyboard. For an SGI keyboard,
",xkb,sgi/indy(pc102)" might be useful. A list of key‐
codes, symbols, and geometries can be found in
/usr/share/X11/xkb. Use of keycodes, symbols and geome‐
tries for XKB configuration is deprecated in favor of the
rules, layout, model, variant and options settings avail‐
able via the -param command line switch. If this option is
not specified, the input device will be queried, perhaps
using the XKEYBOARD extension.
If this option isn't specified, the default input source is the
first back-end server (the one used for screen 0). The console
window shows the layout of the back-end display(s) and pointer
movements and key presses within the console window will be
used as core input devices.
Several special function keys are active, depending on the
input source:
Ctrl-Alt-q will terminate the Xdmx server in all modes.
Ctrl-Alt-g will toggle a server grab in console mode (a
special cursor, currently a spider, is used to indicate
an active server grab).
Ctrl-Alt-f will toggle fine-grain motion in console mode
(a special cursor, currently a cross hair, is used to
indicate this mode). If this mode is combined with a
server grab, then the cursor will have 4 lines instead
of only 2.
Ctrl-Alt-F1 through Ctrl-Alt-F12 will switch to another
VC in local (raw) mode.
-shadowfb
This option turns on (legacy) support for the shadow frame buf‐
fer.
-noshadowfb
This option turns off (legacy) support for the shadow frame
buffer. Note that this option has been deprecated and will be
removed in the next release.
-nomulticursor
This option turns off support for displaying multiple cursors
on overlapped back-end displays. This option is available for
testing and benchmarking purposes.
-fontpath
This option sets the Xdmx server's default font path. This
option can be specified multiple times to accommodate multiple
font paths. See the FONT PATHS section below for very impor‐
tant information regarding setting the default font path.
-configfile filename
Specify the configuration file that should be read. Note that
if the -display command-line option is used, then the configu‐
ration file will be ignored.
-config name
Specify a configuration to use. The name will be the name fol‐
lowing the virtual keyword in the configuration file.
-stat interval screens
This option enables the display of performance statistics. The
interval is in seconds. The screens is a count of the number
of back-end screens for which data is printed each interval.
Specifying 0 for screens will display data for all screens.
For each screen, the following information is printed: the
screen number, an absolute count of the number of XSync() calls
made (SyncCount), the rate of these calls during the previous
interval (Sync/s), the average round-trip time (in microsec‐
onds) of the last 10 XSync() calls (avSync), the maximum round-
trip time (in microseconds) of the last 10 XSync calls
(mxSync), the average number of XSync() requests that were
pending but not yet processed for each of the last 10 processed
XSync() calls, the maximum number of XSync() requests that were
pending but not yet processed for each of the last 10 processed
XSync() calls, and a histogram showing the distribution of the
times of all of the XSync() calls that were made during the
previous interval.
(The length of the moving average and the number and value of
histogram bins are configurable at compile time in the dmxs‐
tat.h header file.)
-syncbatch interval
This option sets the interval in milliseconds for XSync()
batching. An interval less than or equal to 0 will disable
XSync() batching. The default interval is 100 ms.
-nooffscreenopt
This option disables the offscreen optimization. Since the
lazy window creation optimization requires the offscreen opti‐
mization to be enabled, this option will also disable the lazy
window creation optimization.
-nowindowopt
This option disables the lazy window creation optimization.
-nosubdivprims
This option disables the primitive subdivision optimization.
-noxkb Disable use of the XKB extension for communication with the
back end displays. (Combine with -kb to disable all use of
XKB.)
-depth int
This option sets the root window's default depth. When choos‐
ing a default visual from those available on the back-end X
server, the first visual with that matches the depth specified
is used.
This option can be combined with the -cc option, which speci‐
fies the default color visual class, to force the use of a spe‐
cific depth and color class for the root window.
-norender
This option disables the RENDER extension.
-noglxproxy
This option disables GLX proxy -- the build-in GLX extension
implementation that is DMX aware.
-noglxswapgroup
This option disables the swap group and swap barrier extensions
in GLX proxy.
-glxsyncswap
This option enables synchronization after a swap buffers call
by waiting until all X protocol has been processed. When a
client issues a glXSwapBuffers request, Xdmx relays that
request to each back-end X server, and those requests are
buffered along with all other protocol requests. However, in
systems that have large network buffers, this buffering can
lead to the set of back-end X servers handling the swap buffers
request asynchronously. With this option, an XSync() request
is issued to each back-end X server after sending the swap buf‐
fers request. The XSync() requests will flush all buffered
protocol (including the swap buffers requests) and wait until
the back-end X servers have processed those requests before
continuing. This option does not wait until all GL commands
have been processed so there might be previously issued com‐
mands that are still being processed in the GL pipe when the
XSync() request returns. See the -glxfinishswap option below
if Xdmx should wait until the GL commands have been processed.
-glxfinishswap
This option enables synchronization after a swap buffers call
by waiting until all GL commands have been completed. It is
similar to the -glxsyncswap option above; however, instead of
issuing an XSync(), it issues a glFinish() request to each
back-end X server after sending the swap buffers requests. The
glFinish() request will flush all buffered protocol requests,
process both X and GL requests, and wait until all previously
called GL commands are complete before returning.
-ignorebadfontpaths
This option ignores font paths that are not available on all
back-end servers by removing the bad font path(s) from the
default font path list. If no valid font paths are left after
removing the bad paths, an error to that effect is printed in
the log.
-addremovescreens
This option enables the dynamic addition and removal of
screens, which is disabled by default. Note that GLXProxy and
Render do not yet support dynamic addition and removal of
screens, and must be disabled via the -noglxproxy and -norender
command line options described above.
-param This option specifies parameters on the command line. Cur‐
rently, only parameters dealing with XKEYBOARD configuration
are supported. These parameters apply only to the core key‐
board. Parameter values are installation-dependent. Please
see /usr/share/X11/xkb or a similar directory for complete
information.
XkbRules
Defaults to "evdev". Other values may include "sgi"
and "sun".
XkbModel
Defaults to "pc105". When used with "base" rules,
other values may include "pc102", "pc104", "microsoft",
and many others. When used with "sun" rules, other
values may include "type4" and "type5".
XkbLayout
Defaults to "us". Other country codes and "dvorak" are
usually available.
XkbVariant
Defaults to "".
XkbOptions
Defaults to "".
CONFIGURATION FILE GRAMMAR
The following words and tokens are reserved:
virtual display wall option param { } ; #
Comments start with a # mark and extend to the end of the line. They
may appear anywhere. If a configuration file is read into xdmxconfig,
the comments in that file will be preserved, but will not be editable.
The grammar is as follows:
virtual-list ::= [ virtual-list ] | virtual
virtual ::= virtual [ name ] [ dim ] { dw-list }
dw-list ::= [ dw-list ] | dw
dw ::= display | wall | option
display ::= display name [ geometry ] [ / geometry ] [ origin ]
;
wall ::= wall [ dim ] [ dim ] name-list ;
option ::= option name-list ;
param ::= param name-list ;
param ::= param { param-list }
param-list ::= [ param-list ] | name-list ;
name-list ::= [ name-list ] | name
name ::= string | double-quoted-string
dim ::= integer x integer
geometry ::= [ integer x integer ] [ signed-integer signed-inte‐
ger ]
origin ::= @ integer x integer
The name following virtual is used as an identifier for the configura‐
tion, and may be passed to Xdmx using the -config command line option.
The name of a display should be standard X display name, although no
checking is performed (e.g., "machine:0").
For names, double quotes are optional unless the name is reserved or
contains spaces.
The first dimension following wall is the dimension for tiling (e.g.,
2x4 or 4x4). The second dimension following wall is the dimension of
each display in the wall (e.g., 1280x1024).
The first geometry following display is the geometry of the screen win‐
dow on the backend server. The second geometry, which is always pre‐
ceeded by a slash, is the geometry of the root window. By default, the
root window has the same geometry as the screen window.
The option line can be used to specify any command-line options (e.g.,
-input). (It cannot be used to specify the name of the front-end dis‐
play.) The option line is processed once at server startup, just line
command line options. This behavior may be unexpected.
CONFIGURATION FILE EXAMPLES
Two displays being used for a desktop may be specified in any of the
following formats:
virtual example0 {
display d0:0 1280x1024 @0x0;
display d1:0 1280x1024 @1280x0;
}
virtual example1 {
display d0:0 1280x1024;
display d1:0 @1280x0;
}
virtual example2 {
display "d0:0";
display "d1:0" @1280x0;
}
virtual example3 { wall 2x1 d0:0 d1:0; }
A 4x4 wall of 16 total displays could be specified as follows (if no
tiling dimension is specified, an approximate square is used):
virtual example4 {
wall d0:0 d1:0 d2:0 d3:0
d4:0 d5:0 d6:0 d7:0
d8:0 d9:0 da:0 db:0
dc:0 dd:0 de:0 df:0;
}
FONT PATHS
The font path used by the Xdmx front-end server will be propagated to
each back-end server,which requires that each back-end server have
access to the exact same font paths as the front-end server. This can
be most easily handled by either using a font server (e.g., xfs) or by
remotely mounting the font paths on each back-end server, and then set‐
ting the Xdmx server's default font path with the -I "-fontpath" com‐
mand line option described above.
For example, if you specify a font path with the following command
line:
Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath
/usr/fonts/Type1/ +xinerama
Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
on the Xdmx server and all back-end server, which is d0 in this exam‐
ple.
Font servers can also be specified with the -fontpath option. For
example, let's assume that a properly configured font server is running
on host d0. Then, the following command line
Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xin‐
erama
will initialize the front-end Xdmx server and each of the back-end
servers to use the font server on d0.
Some fonts might not be supported by either the front-end or the back-
end servers. For example, let's assume the front-end Xdmx server
includes support Type1 fonts, but one of the back-end servers does not.
Let's also assume that the default font path for Xdmx includes Type1
fonts in its font path. Then, when Xdmx initializes the default font
path to load the default font, the font path that includes Type1 fonts
(along with the other default font paths that are used by the Xdmx
server) is sent to the back-end server that cannot handle Type1 fonts.
That back-end server then rejects the font path and sends an error back
to the Xdmx server. Xdmx then prints an error message and exits
because it failed to set the default font path and was unable load the
default font.
To fix this error, the offending font path must be removed from the
default font path by using a different -fontpath command line option.
The -fontpath option can also be added to the configuration file as
described above.
COMMAND-LINE EXAMPLES
The back-end machines are d0 and d1, core input is from the pointer and
keyboard attached to d0, clients will refer to :1 when opening windows:
Xdmx :1 -display d0:0 -display d1:0 +xinerama
As above, except with core input from d1:
Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
As above, except with core input from a console window on the local
display:
Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
As above, except with core input from the local keyboard and mouse:
Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xin‐
erama
Note that local input can be used under Linux while another X session
is running on :0 (assuming the user can access the Linux console tty
and mouse devices): a new (blank) VC will be used for keyboard input on
the local machine and the Ctrl-Alt-F* sequence will be available to
change to another VC (possibly back to another X session running on the
local machine). Using Ctrl-Alt-Backspace on the blank VC will termi‐
nate the Xdmx session and return to the original VC.
This example uses the configuration file shown in the previous section:
Xdmx :1 -input :0 +xinerama -configfile filename -config exam‐
ple2
With this configuration file line:
option -input :0 +xinerama;
the command line can be shortened to:
Xdmx :1 -configfile filename -config example2
USING THE USB DEVICE DRIVERS
The USB device drivers use the devices called /dev/input/event0,
/dev/input/event1, etc. under Linux. These devices are driven using
the evdev Linux kernel module, which is part of the hid suite. Please
note that if you load the mousedev or kbddev Linux kernel modules, then
USB devices will appear as core Linux input devices and you will not be
able to select between using the device only as an Xdmx core device or
an Xdmx XInput extension device. Further, you may be unable to unload
the mousedev Linux kernel module if XFree86 is configured to use
/dev/input/mice as an input device (this is quite helpful for laptop
users and is set up by default under some Linux distributions, but
should be changed if USB devices are to be used with Xdmx).
The USB device drivers search through the Linux devices for the first
mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
device.
KEYBOARD INITIALIZATION
If Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD
extension, then a keyboard on a backend or console will be initialized
using the map that the host X server provides.
If the XKEYBOARD extension is used for both Xdmx and the host X server
for the keyboard (i.e., the backend or console X server), then the type
of the keyboard will be obtained from the host X server and the key‐
board under Xdmx will be initialized with that information. Otherwise,
the default type of keyboard will be initialized. In both cases, the
map from the host X server will not be used. This means that different
initial behavior may be noted with and without XKEYBOARD. Consistent
and expected results will be obtained by running XKEYBOARD on all
servers and by avoiding the use of xmodmap on the backend or console X
servers prior to starting Xdmx.
If -xkbmap is specified on the Xdmx command line, then that map will
currently be used for all keyboards.
MULTIPLE CORE KEYBOARDS
X was not designed to support multiple core keyboards. However, Xdmx
provides some support for multiple core keyboards. Best results will
be obtained if all of the keyboards are of the same type and are using
the same keyboard map. Because the X server passes raw key code infor‐
mation to the X client, key symbols for keyboards with different key
maps would be different if the key code for each keyboard was sent
without translation to the client. Therefore, Xdmx will attempt to
translate the key code from a core keyboard to the key code for the key
with the same key symbol of the first core keyboard that was loaded.
If the key symbol appears in both maps, the results will be expected.
Otherwise, the second core keyboard will return a NoSymbol key symbol
for some keys that would have been translated if it was the first core
keyboard.
SEE ALSODMX(3), X(7), Xserver(1), xdmxconfig(1), vdltodmx(1), xfs(1), xkb‐
comp(1), xkeyboard-config(7)AUTHORS
Kevin E. Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>,
and Rickard E. (Rik) Faith <faith@redhat.com>.
Portions of Xdmx are based on code from The XFree86 Project
(http://www.xfree86.org) and X.Org (http://www.x.org).
X Version 11 xorg-server 1.14.3.901 Xdmx(1)
