3
.\" Copyright 2001-2004 Red Hat Inc., Durham, North Carolina.
4
.\" All Rights Reserved.
6
.\" Permission is hereby granted, free of charge, to any person obtaining
7
.\" a copy of this software and associated documentation files (the
8
.\" "Software"), to deal in the Software without restriction, including
9
.\" without limitation on the rights to use, copy, modify, merge,
10
.\" publish, distribute, sublicense, and/or sell copies of the Software,
11
.\" and to permit persons to whom the Software is furnished to do so,
12
.\" subject to the following conditions:
14
.\" he above copyright notice and this permission notice (including the
15
.\" next paragraph) shall be included in all copies or substantial
16
.\" portions of the Software.
18
.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
19
.\" EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
20
.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
21
.\" NON-INFRINGEMENT. IN NO EVENT SHALL RED HAT AND/OR THEIR SUPPLIERS
22
.\" BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
23
.\" ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
24
.\" CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
26
.TH Xdmx 1 __vendorversion__
28
Xdmx - Distributed Multi-head X server
31
[:display] [option ...]
34
is a proxy X server that uses one or more other X servers as its display
35
devices. It provides multi-head X functionality for displays that might
36
be located on different machines.
38
functions as a front-end X server that acts as a proxy to a set of
39
back-end X servers. All of the visible rendering is passed to the
40
back-end X servers. Clients connect to the
42
front-end, and everything appears as it would in a regular multi-head
43
configuration. If Xinerama is enabled (e.g., with
45
on the command line), the clients see a single large screen.
48
communicates to the back-end X servers using the standard X11 protocol,
49
and standard and/or commonly available X server extensions.
51
In addition to the normal X server options described in the
55
accepts the following command line switches:
57
.BI "\-display " display-name
58
This specifies the name(s) of the back-end X server display(s) to connect
59
to. This option may be specified multiple times to connect to more than
60
one back-end display. The first is used as screen 0, the second as screen 1,
61
etc. If this option is omitted, the
63
environment variable is used as the single back-end X server display.
66
.BI "\-xinput " input-source
67
This specifies the source to use for XInput extension devices. The
68
choices are the same as for
70
described below, except that core devices on backend servers cannot be
71
treated as XInput extension devices. (Although extension devices on
72
backend and console servers are supported as extension devices under
76
.BI "\-input " input-source
77
This specifies the source to use for the core input devices. The choices are:
81
A set of dummy core input drivers are used. These never generate any
86
The raw keyboard and pointer from the local computer are used. A
87
comma-separated list of driver names can be appended. For example, to
88
select the example Linux keyboard and PS/2 mouse driver use:
89
.BR "-input local,kbd,ps2" .
90
The following drivers have been implemented for Linux: kbd, ms (a
91
two-button Microsoft mouse driver), ps2 (a PS/2 mouse driver), usb-mou
92
(a USB mouse driver), usb-kbd (a USB keyboard driver), and usb-oth (a
93
USB non-keyboard, non-mouse driver). Additional drivers may be
94
implemented in the future. Appropriate defaults will be used if no
95
comma-separated list is provided.
99
If the display-name is a back-end server, then core input events are
100
taken from the server specified. Otherwise, a console window will be
101
opened on the specified display.
105
is followed by ",xi" then XInput extension devices on the display will
108
XInput extension devices. If the
110
is followed by ",noxi" then XInput extension devices on the display will
114
XInput extension devices. Currently, the default is ",xi".
118
is followed by ",console" and the
120
refers to a display that is used as a backend display, then a console
121
window will be opened on that display
123
that display will be treated as a backend display. Otherwise (or if
124
",noconsole" is used), the display will be treated purely as a backend
125
or a console display, as described above.
129
is followed by ",windows", then outlines of the windows on the backend
130
will be displayed inside the console window. Otherwise (or if
131
",nowindows" is used), the console window will not display the outlines
132
of backend windows. (This option only applies to console input.)
136
is followed by ",xkb", then the next 1 to 3 comma-separated parameters
137
will specify the keycodes, symbols, and geometry of the keyboard for
138
this input device. For example, ",xkb,xfree86,pc104" will specify that
139
the "xfree86" keycodes and the "pc104" symbols should be used to
140
initialize the keyboard. For an SGI keyboard, ",xkb,sgi/indy(pc102)"
141
might be useful. A list of keycodes, symbols, and geometries can be
143
.IR /usr/X11R6/lib/X11/xkb .
144
If this option is not specified, the input device will be queried,
145
perhaps using the XKEYBOARD extension.
149
If this option isn't specified, the default input source is the first
150
back-end server (the one used for screen 0). The console window shows
151
the layout of the back-end display(s) and pointer movements and key
152
presses within the console window will be used as core input devices.
154
Several special function keys are active, depending on the input
165
server grab in console mode (a special cursor, currently a spider, is
166
used to indicate an active server grab).
169
will toggle fine-grain motion in console mode (a special cursor,
170
currently a cross hair, is used to indicate this mode). If this mode is
171
combined with a server grab, then the cursor will have 4 lines instead
174
.BR Ctrl-Alt-F1 " through " Ctrl-Alt-F12
175
will switch to another VC in local (raw) mode.
181
This option turns on (legacy) support for the shadow frame buffer.
185
This option turns off (legacy) support for the shadow frame buffer.
186
Note that this option has been deprecated and will be removed in the
191
This option turns off support for displaying multiple cursors on
192
overlapped back-end displays. This option is available for testing and
193
benchmarking purposes.
199
server's default font path. This option can be specified multiple times
200
to accommodate multiple font paths. See the
202
section below for very important information regarding setting the
206
.BI "-configfile " filename
207
Specify the configuration file that should be read. Note that if the
209
command-line option is used, then the configuration file will be
214
Specify a configuration to use. The
216
will be the name following the
218
keyword in the configuration file.
221
.BI "-stat " "interval screens"
222
This option enables the display of performance statistics. The interval
223
is in seconds. The screens is a count of the number of back-end screens
224
for which data is printed each interval. Specifying 0 for screens will
225
display data for all screens.
227
For each screen, the following information is printed: the screen
228
number, an absolute count of the number of XSync() calls made
229
(SyncCount), the rate of these calls during the previous interval
230
(Sync/s), the average round-trip time (in microseconds) of the last 10
231
XSync() calls (avSync), the maximum round-trip time (in microseconds) of
232
the last 10 XSync calls (mxSync), the average number of XSync() requests
233
that were pending but not yet processed for each of the last 10
234
processed XSync() calls, the maximum number of XSync() requests that
235
were pending but not yet processed for each of the last 10 processed
236
XSync() calls, and a histogram showing the distribution of the times of
237
all of the XSync() calls that were made during the previous interval.
239
(The length of the moving average and the number and value of histogram
240
bins are configurable at compile time in the
245
.BI "-syncbatch " interval
248
in milliseconds for XSync() batching. An
250
less than or equal to 0 will disable XSync() batching. The default
255
.BI "-nooffscreenopt"
256
This option disables the offscreen optimization. Since the lazy window
257
creation optimization requires the offscreen optimization to be enabled,
258
this option will also disable the lazy window creation optimization.
262
This option disables the lazy window creation optimization.
266
This option disables the primitive subdivision optimization.
270
Disable use of the XKB extension for communication with the back end
271
displays. (Combine with
273
to disable all use of XKB.)
277
This option sets the root window's default depth. When choosing a
278
default visual from those available on the back-end X server, the first
279
visual with that matches the depth specified is used.
281
This option can be combined with the
283
option, which specifies the default color visual class, to force the use
284
of a specific depth and color class for the root window.
288
This option disables the RENDER extension.
292
This option disables GLX proxy -- the build-in GLX extension
293
implementation that is DMX aware.
296
.BI "-noglxswapgroup"
297
This option disables the swap group and swap barrier extensions in GLX
302
This option enables synchronization after a swap buffers call by waiting
303
until all X protocol has been processed. When a client issues a
304
glXSwapBuffers request, Xdmx relays that request to each back-end X
305
server, and those requests are buffered along with all other protocol
306
requests. However, in systems that have large network buffers, this
307
buffering can lead to the set of back-end X servers handling the swap
308
buffers request asynchronously. With this option, an XSync() request is
309
issued to each back-end X server after sending the swap buffers request.
310
The XSync() requests will flush all buffered protocol (including the
311
swap buffers requests) and wait until the back-end X servers have
312
processed those requests before continuing. This option does not wait
313
until all GL commands have been processed so there might be previously
314
issued commands that are still being processed in the GL pipe when the
315
XSync() request returns. See the
317
option below if Xdmx should wait until the GL commands have been
322
This option enables synchronization after a swap buffers call by waiting
323
until all GL commands have been completed. It is similar to the
325
option above; however, instead of issuing an XSync(), it issues a
326
glFinish() request to each back-end X server after sending the swap
327
buffers requests. The glFinish() request will flush all buffered
328
protocol requests, process both X and GL requests, and wait until all
329
previously called GL commands are complete before returning.
332
.BI "-ignorebadfontpaths"
333
This option ignores font paths that are not available on all back-end
334
servers by removing the bad font path(s) from the default font path
335
list. If no valid font paths are left after removing the bad paths, an
336
error to that effect is printed in the log.
339
.BI "-addremovescreens"
340
This option enables the dynamic addition and removal of screens, which
341
is disabled by default. Note that GLXProxy and Render do not yet
342
support dynamic addition and removal of screens, and must be disabled
347
command line options described above.
351
This option specifies parameters on the command line. Currently, only
352
parameters dealing with XKEYBOARD configuration are supported. These
353
parameters apply only to the core keyboard. Parameter values are
354
installation-dependent. Please see
355
.I /usr/X11R6/lib/X11/xkb
356
or a similar directory for complete information.
360
Defaults to "xfree86". Other values may include "sgi" and "sun".
364
Defaults to "pc101". When used with "xfree86" rules, other values may
365
include "pc102", "pc104", "pc105", "microsoft", and many others. When
366
used with "sun" rules, other values may include "type4" and "type5".
370
Defaults to "us". Other country codes and "dvorak" are usually
381
.SH "CONFIGURATION FILE GRAMMAR"
382
The following words and tokens are reserved:
395
Comments start with a
397
mark and extend to the end of the line. They may appear anywhere. If a
398
configuration file is read into
400
the comments in that file will be preserved, but will not be editable.
402
The grammar is as follows:
404
virtual-list ::= [ virtual-list ] | virtual
413
dw-list ::= [ dw-list ] | dw
415
dw ::= display | wall | option
419
name [ geometry ] [ / geometry ] [ origin ]
424
[ dim ] [ dim ] name-list
442
param-list ::= [ param-list ] | name-list
445
name-list ::= [ name-list ] | name
447
name ::= string | double-quoted-string
453
geometry ::= [ integer
455
integer ] [ signed-integer signed-integer ]
466
is used as an identifier for the configuration, and may be passed to
470
command line option. The name of a display should be standard X display
471
name, although no checking is performed (e.g., "machine:0").
473
For names, double quotes are optional unless the name is reserved or
476
The first dimension following
478
is the dimension for tiling (e.g., 2x4 or 4x4). The second dimension
481
is the dimension of each display in the wall (e.g., 1280x1024).
483
The first geometry following
485
is the geometry of the screen window on the backend server. The second
486
geometry, which is always preceeded by a slash, is the geometry of the
487
root window. By default, the root window has the same geometry as the
492
line can be used to specify any command-line options (e.g.,
494
(It cannot be used to specify the name of the front-end display.) The
495
option line is processed once at server startup, just line command line
496
options. This behavior may be unexpected.
497
.SH "CONFIGURATION FILE EXAMPLES"
498
Two displays being used for a desktop may be specified in any of the
503
display d0:0 1280x1024 @0x0;
504
display d1:0 1280x1024 @1280x0;
508
display d0:0 1280x1024;
509
display d1:0 @1280x0;
514
display "d1:0" @1280x0;
517
virtual example3 { wall 2x1 d0:0 d1:0; }
520
A 4x4 wall of 16 total displays could be specified as follows (if no
521
tiling dimension is specified, an approximate square is used):
525
wall d0:0 d1:0 d2:0 d3:0
533
The font path used by the
535
front-end server will be propagated to each back-end server,which
536
requires that each back-end server have access to the exact same font
537
paths as the front-end server. This can be most easily handled by
538
either using a font server (e.g., xfs) or by remotely mounting the font
539
paths on each back-end server, and then setting the
541
server's default font path with the
543
command line option described above.
545
For example, if you specify a font path with the following command line:
547
Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ +xinerama
549
Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
552
server and all back-end server, which is d0 in this example.
554
Font servers can also be specified with the
556
option. For example, let's assume that a properly configured font
557
server is running on host d0. Then, the following command line
559
Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama
561
will initialize the front-end
563
server and each of the back-end servers to use the font server on d0.
565
Some fonts might not be supported by either the front-end or the
566
back-end servers. For example, let's assume the front-end
568
server includes support Type1 fonts, but one of the back-end servers
569
does not. Let's also assume that the default font path for
571
includes Type1 fonts in its font path. Then, when
573
initializes the default font path to load the default font, the font
574
path that includes Type1 fonts (along with the other default font paths
577
server) is sent to the back-end server that cannot handle Type1 fonts.
578
That back-end server then rejects the font path and sends an error back
583
then prints an error message and exits because it failed to set the
584
default font path and was unable load the default font.
586
To fix this error, the offending font path must be removed from the
587
default font path by using a different
593
option can also be added to the configuration file as described above.
594
.SH "COMMAND-LINE EXAMPLES"
595
The back-end machines are d0 and d1, core input is from the pointer and
596
keyboard attached to d0, clients will refer to :1 when opening windows:
598
Xdmx :1 -display d0:0 -display d1:0 +xinerama
601
As above, except with core input from d1:
603
Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
606
As above, except with core input from a console window on the local
609
Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
612
As above, except with core input from the local keyboard and mouse:
614
Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xinerama
616
Note that local input can be used under Linux while another X session is
617
running on :0 (assuming the user can access the Linux console tty and
618
mouse devices): a new (blank) VC will be used for keyboard input on the
619
local machine and the Ctrl-Alt-F* sequence will be available to change
620
to another VC (possibly back to another X session running on the local
621
machine). Using Ctrl-Alt-Backspace on the blank VC will terminate the
622
Xdmx session and return to the original VC.
624
This example uses the configuration file shown in the previous section:
626
Xdmx :1 -input :0 +xinerama -configfile filename -config example2
628
With this configuration file line:
630
option -input :0 +xinerama;
632
the command line can be shortened to:
634
Xdmx :1 -configfile filename -config example2
636
.SH "USING THE USB DEVICE DRIVERS"
638
The USB device drivers use the devices called
639
.IR /dev/input/event0 ", " /dev/input/event1 ", etc."
640
under Linux. These devices are driven using the
642
Linux kernel module, which is part of the hid suite. Please note that
647
Linux kernel modules, then USB devices will appear as core Linux input
648
devices and you will not be able to select between using the device only
653
XInput extension device. Further, you may be unable to unload the
655
Linux kernel module if
659
as an input device (this is quite helpful for laptop users and is set up
660
by default under some Linux distributions, but should be changed if USB
661
devices are to be used with
664
The USB device drivers search through the Linux devices for the first
665
mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
667
.SH "KEYBOARD INITIALIZATION"
675
compiled to use the XKEYBOARD extension, then a keyboard on a backend or
676
console will be initialized using the map that the host X server
679
If the XKEYBOARD extension is used for both
681
and the host X server for the keyboard (i.e., the backend or console X
682
server), then the type of the keyboard will
683
be obtained from the host X server and the keyboard under
685
will be initialized with that information. Otherwise, the default type
686
of keyboard will be initialized. In both cases, the map from the host X
689
be used. This means that different initial behavior may be noted with
690
and without XKEYBOARD. Consistent and expected results will be obtained
691
by running XKEYBOARD on all servers and by avoiding the use of
693
on the backend or console X servers prior to starting
700
command line, then that map will currently be used for all keyboards.
701
.SH "MULTIPLE CORE KEYBOARDS"
702
X was not designed to support multiple core keyboards. However,
704
provides some support for multiple core keyboards. Best results will be
705
obtained if all of the keyboards are of the same type and are using the
706
same keyboard map. Because the X server passes raw key code information
707
to the X client, key symbols for keyboards with different key maps would
708
be different if the key code for each keyboard was sent without
709
translation to the client. Therefore,
711
will attempt to translate the key code from a core keyboard to the key
712
code for the key with the same key symbol of the
714
core keyboard that was loaded. If the key symbol appears in both maps,
715
the results will be expected. Otherwise, the second core keyboard will
716
return a NoSymbol key symbol for some keys that would have been
717
translated if it was the first core keyboard.
725
.BR DMX "(3X), " X "(__miscmansuffix__), " Xserver "(1), " xdmxconfig "(1), "
726
.BR vdltodmx "(1), " xfs "(1), " xkbcomp (1)
731
.I <dawes@xfree86.org>,
733
Rickard E. (Rik) Faith
734
.IR <faith@redhat.com> .
738
are based on code from The XFree86 Project
739
.RI ( http://www.xfree86.org )
741
.RI ( http://www.x.org ).
added
removed
hw/dmx/Xdmx.man
