1Xdmx(1) General Commands Manual Xdmx(1)
2
6 Xdmx - Distributed Multi-head X server
7
9 Xdmx [:display] [option ...]
10
12 Xdmx is a proxy X server that uses one or more other X servers as its
13 display devices. It provides multi-head X functionality for displays
14 that might be located on different machines. Xdmx functions as a
15 front-end X server that acts as a proxy to a set of back-end X servers.
16 All of the visible rendering is passed to the back-end X servers.
17 Clients connect to the Xdmx front-end, and everything appears as it
18 would in a regular multi-head configuration. If Xinerama is enabled
19 (e.g., with +xinerama on the command line), the clients see a single
20 large screen.
21 Xdmx communicates to the back-end X servers using the standard X11 pro‐
23 tocol, and standard and/or commonly available X server extensions.
24
26 In addition to the normal X server options described in the Xserver(1)
27 manual page, Xdmx accepts the following command line switches:
28 -display display-name
30 This specifies the name(s) of the back-end X server display(s)
31 to connect to. This option may be specified multiple times to
32 connect to more than one back-end display. The first is used
33 as screen 0, the second as screen 1, etc. If this option is
34 omitted, the $DISPLAY environment variable is used as the sin‐
35 gle back-end X server display.
36 -xinput input-source
39 This specifies the source to use for XInput extension devices.
40 The choices are the same as for -input , described below,
41 except that core devices on backend servers cannot be treated
42 as XInput extension devices. (Although extension devices on
43 backend and console servers are supported as extension devices
44 under Xdmx).
45 -input input-source
48 This specifies the source to use for the core input devices.
49 The choices are:
50 dummy
52 A set of dummy core input drivers are used. These never
53 generate any input events.
54 local
57 The raw keyboard and pointer from the local computer are
58 used. A comma-separated list of driver names can be
59 appended. For example, to select the example Linux key‐
60 board and PS/2 mouse driver use: -input local,kbd,ps2. The
61 following drivers have been implemented for Linux: kbd, ms
62 (a two-button Microsoft mouse driver), ps2 (a PS/2 mouse
63 driver), usb-mou (a USB mouse driver), usb-kbd (a USB key‐
64 board driver), and usb-oth (a USB non-keyboard, non-mouse
65 driver). Additional drivers may be implemented in the
66 future. Appropriate defaults will be used if no comma-sep‐
67 arated list is provided.
68 display-name
71 If the display-name is a back-end server, then core input
72 events are taken from the server specified. Otherwise, a
73 console window will be opened on the specified display.
74 If the display-name is followed by ",xi" then XInput exten‐
76 sion devices on the display will be used as Xdmx XInput
77 extension devices. If the display-name is followed by
78 ",noxi" then XInput extension devices on the display will
79 not be used as Xdmx XInput extension devices. Currently,
80 the default is ",xi".
81 If the display-name is followed by ",console" and the dis‐
83 play-name refers to a display that is used as a backend
84 display, then a console window will be opened on that dis‐
85 play and that display will be treated as a backend display.
86 Otherwise (or if ",noconsole" is used), the display will be
87 treated purely as a backend or a console display, as
88 described above.
89 If the display-name is followed by ",windows", then out‐
91 lines of the windows on the backend will be displayed
92 inside the console window. Otherwise (or if ",nowindows"
93 is used), the console window will not display the outlines
94 of backend windows. (This option only applies to console
95 input.)
96 If the display-name is followed by ",xkb", then the next 1
98 to 3 comma-separated parameters will specify the keycodes,
99 symbols, and geometry of the keyboard for this input
100 device. For example, ",xkb,xfree86,pc104" will specify
101 that the "xfree86" keycodes and the "pc104" symbols should
102 be used to initialize the keyboard. For an SGI keyboard,
103 ",xkb,sgi/indy(pc102)" might be useful. A list of key‐
104 codes, symbols, and geometries can be found in
105 /usr/X11R6/lib/X11/xkb. If this option is not specified,
106 the input device will be queried, perhaps using the XKEY‐
107 BOARD extension.
108 If this option isn't specified, the default input source is the
110 first back-end server (the one used for screen 0). The console
111 window shows the layout of the back-end display(s) and pointer
112 movements and key presses within the console window will be
113 used as core input devices.
114 Several special function keys are active, depending on the
116 input source:
117 Ctrl-Alt-q will terminate the Xdmx server in all modes.
119 Ctrl-Alt-g will toggle a server grab in console mode (a
121 special cursor, currently a spider, is used to indicate
122 an active server grab).
123 Ctrl-Alt-f will toggle fine-grain motion in console mode
125 (a special cursor, currently a cross hair, is used to
126 indicate this mode). If this mode is combined with a
127 server grab, then the cursor will have 4 lines instead
128 of only 2.
129 Ctrl-Alt-F1 through Ctrl-Alt-F12 will switch to another
131 VC in local (raw) mode.
132 -shadowfb
135 This option turns on (legacy) support for the shadow frame buf‐
136 fer.
137 -noshadowfb
140 This option turns off (legacy) support for the shadow frame
141 buffer. Note that this option has been deprecated and will be
142 removed in the next release.
143 -nomulticursor
146 This option turns off support for displaying multiple cursors
147 on overlapped back-end displays. This option is available for
148 testing and benchmarking purposes.
149 -fontpath
152 This option sets the Xdmx server's default font path. This
153 option can be specified multiple times to accommodate multiple
154 font paths. See the FONT PATHS section below for very impor‐
155 tant information regarding setting the default font path.
156 -configfile filename
159 Specify the configuration file that should be read. Note that
160 if the -display command-line option is used, then the configu‐
161 ration file will be ignored.
162 -config name
165 Specify a configuration to use. The name will be the name fol‐
166 lowing the virtual keyword in the configuration file.
167 -stat interval screens
170 This option enables the display of performance statistics. The
171 interval is in seconds. The screens is a count of the number
172 of back-end screens for which data is printed each interval.
173 Specifying 0 for screens will display data for all screens.
174 For each screen, the following information is printed: the
176 screen number, an absolute count of the number of XSync() calls
177 made (SyncCount), the rate of these calls during the previous
178 interval (Sync/s), the average round-trip time (in microsec‐
179 onds) of the last 10 XSync() calls (avSync), the maximum round-
180 trip time (in microseconds) of the last 10 XSync calls
181 (mxSync), the average number of XSync() requests that were
182 pending but not yet processed for each of the last 10 processed
183 XSync() calls, the maximum number of XSync() requests that were
184 pending but not yet processed for each of the last 10 processed
185 XSync() calls, and a histogram showing the distribution of the
186 times of all of the XSync() calls that were made during the
187 previous interval.
188 (The length of the moving average and the number and value of
190 histogram bins are configurable at compile time in the dmxs‐
191 tat.h header file.)
192 -syncbatch interval
195 This option sets the interval in milliseconds for XSync()
196 batching. An interval less than or equal to 0 will disable
197 XSync() batching. The default interval is 100 ms.
198 -nooffscreenopt
201 This option disables the offscreen optimization. Since the
202 lazy window creation optimization requires the offscreen opti‐
203 mization to be enabled, this option will also disable the lazy
204 window creation optimization.
205 -nowindowopt
208 This option disables the lazy window creation optimization.
209 -nosubdivprims
212 This option disables the primitive subdivision optimization.
213 -noxkb Disable use of the XKB extension for communication with the
216 back end displays. (Combine with -kb to disable all use of
217 XKB.)
218 -depth int
221 This option sets the root window's default depth. When choos‐
222 ing a default visual from those available on the back-end X
223 server, the first visual with that matches the depth specified
224 is used.
225 This option can be combined with the -cc option, which speci‐
227 fies the default color visual class, to force the use of a spe‐
228 cific depth and color class for the root window.
229 -norender
232 This option disables the RENDER extension.
233 -noglxproxy
236 This option disables GLX proxy -- the build-in GLX extension
237 implementation that is DMX aware.
238 -noglxswapgroup
241 This option disables the swap group and swap barrier extensions
242 in GLX proxy.
243 -glxsyncswap
246 This option enables synchronization after a swap buffers call
247 by waiting until all X protocol has been processed. When a
248 client issues a glXSwapBuffers request, Xdmx relays that
249 request to each back-end X server, and those requests are
250 buffered along with all other protocol requests. However, in
251 systems that have large network buffers, this buffering can
252 lead to the set of back-end X servers handling the swap buffers
253 request asynchronously. With this option, an XSync() request
254 is issued to each back-end X server after sending the swap buf‐
255 fers request. The XSync() requests will flush all buffered
256 protocol (including the swap buffers requests) and wait until
257 the back-end X servers have processed those requests before
258 continuing. This option does not wait until all GL commands
259 have been processed so there might be previously issued com‐
260 mands that are still being processed in the GL pipe when the
261 XSync() request returns. See the -glxfinishswap option below
262 if Xdmx should wait until the GL commands have been processed.
263 -glxfinishswap
266 This option enables synchronization after a swap buffers call
267 by waiting until all GL commands have been completed. It is
268 similar to the -glxsyncswap option above; however, instead of
269 issuing an XSync(), it issues a glFinish() request to each
270 back-end X server after sending the swap buffers requests. The
271 glFinish() request will flush all buffered protocol requests,
272 process both X and GL requests, and wait until all previously
273 called GL commands are complete before returning.
274 -ignorebadfontpaths
277 This option ignores font paths that are not available on all
278 back-end servers by removing the bad font path(s) from the
279 default font path list. If no valid font paths are left after
280 removing the bad paths, an error to that effect is printed in
281 the log.
282 -addremovescreens
285 This option enables the dynamic addition and removal of
286 screens, which is disabled by default. Note that GLXProxy and
287 Render do not yet support dynamic addition and removal of
288 screens, and must be disabled via the -noglxproxy and -norender
289 command line options described above.
290 -param This option specifies parameters on the command line. Cur‐
293 rently, only parameters dealing with XKEYBOARD configuration
294 are supported. These parameters apply only to the core key‐
295 board. Parameter values are installation-dependent. Please
296 see /usr/X11R6/lib/X11/xkb or a similar directory for complete
297 information.
298 XkbRules
300 Defaults to "xfree86". Other values may include "sgi"
301 and "sun".
302 XkbModel
305 Defaults to "pc101". When used with "xfree86" rules,
306 other values may include "pc102", "pc104", "pc105",
307 "microsoft", and many others. When used with "sun"
308 rules, other values may include "type4" and "type5".
309 XkbLayout
312 Defaults to "us". Other country codes and "dvorak" are
313 usually available.
314 XkbVariant
317 Defaults to "".
318 XkbOptions
321 Defaults to "".
322
324 The following words and tokens are reserved:
325 virtual display wall option param { } ; #
326 Comments start with a # mark and extend to the end of the line. They
328 may appear anywhere. If a configuration file is read into xdmxconfig,
329 the comments in that file will be preserved, but will not be editable.
330 The grammar is as follows:
332 virtual-list ::= [ virtual-list ] | virtual
333 virtual ::= virtual [ name ] [ dim ] { dw-list }
335 dw-list ::= [ dw-list ] | dw
337 dw ::= display | wall | option
339 display ::= display name [ geometry ] [ / geometry ] [ origin ]
341 ;
342 wall ::= wall [ dim ] [ dim ] name-list ;
344 option ::= option name-list ;
346 param ::= param name-list ;
348 param ::= param { param-list }
350 param-list ::= [ param-list ] | name-list ;
352 name-list ::= [ name-list ] | name
354 name ::= string | double-quoted-string
356 dim ::= integer x integer
358 geometry ::= [ integer x integer ] [ signed-integer signed-inte‐
360 ger ]
361 origin ::= @ integer x integer
363 The name following virtual is used as an identifier for the configura‐
365 tion, and may be passed to Xdmx using the -config command line option.
366 The name of a display should be standard X display name, although no
367 checking is performed (e.g., "machine:0").
368 For names, double quotes are optional unless the name is reserved or
370 contains spaces.
371 The first dimension following wall is the dimension for tiling (e.g.,
373 2x4 or 4x4). The second dimension following wall is the dimension of
374 each display in the wall (e.g., 1280x1024).
375 The first geometry following display is the geometry of the screen win‐
377 dow on the backend server. The second geometry, which is always pre‐
378 ceeded by a slash, is the geometry of the root window. By default, the
379 root window has the same geometry as the screen window.
380 The option line can be used to specify any command-line options (e.g.,
382 -input). (It cannot be used to specify the name of the front-end dis‐
383 play.) The option line is processed once at server startup, just line
384 command line options. This behavior may be unexpected.
385
387 Two displays being used for a desktop may be specified in any of the
388 following formats:
389 virtual example0 {
390 display d0:0 1280x1024 @0x0;
391 display d1:0 1280x1024 @1280x0;
392 }
393 virtual example1 {
395 display d0:0 1280x1024;
396 display d1:0 @1280x0;
397 }
398 virtual example2 {
400 display "d0:0";
401 display "d1:0" @1280x0;
402 }
403 virtual example3 { wall 2x1 d0:0 d1:0; }
405 A 4x4 wall of 16 total displays could be specified as follows (if no
406 tiling dimension is specified, an approximate square is used):
407 virtual example4 {
408 wall d0:0 d1:0 d2:0 d3:0
409 d4:0 d5:0 d6:0 d7:0
410 d8:0 d9:0 da:0 db:0
411 dc:0 dd:0 de:0 df:0;
412 }
413
415 The font path used by the Xdmx front-end server will be propagated to
416 each back-end server,which requires that each back-end server have
417 access to the exact same font paths as the front-end server. This can
418 be most easily handled by either using a font server (e.g., xfs) or by
419 remotely mounting the font paths on each back-end server, and then set‐
420 ting the Xdmx server's default font path with the -I "-fontpath" com‐
421 mand line option described above.
422 For example, if you specify a font path with the following command
424 line:
425 Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath
426 /usr/fonts/Type1/ +xinerama
427 Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
428 on the Xdmx server and all back-end server, which is d0 in this exam‐
429 ple.
430 Font servers can also be specified with the -fontpath option. For
432 example, let's assume that a properly configured font server is running
433 on host d0. Then, the following command line
434 Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xin‐
435 erama
436 will initialize the front-end Xdmx server and each of the back-end
437 servers to use the font server on d0.
438 Some fonts might not be supported by either the front-end or the back-
440 end servers. For example, let's assume the front-end Xdmx server
441 includes support Type1 fonts, but one of the back-end servers does not.
442 Let's also assume that the default font path for Xdmx includes Type1
443 fonts in its font path. Then, when Xdmx initializes the default font
444 path to load the default font, the font path that includes Type1 fonts
445 (along with the other default font paths that are used by the Xdmx
446 server) is sent to the back-end server that cannot handle Type1 fonts.
447 That back-end server then rejects the font path and sends an error back
448 to the Xdmx server. Xdmx then prints an error message and exits
449 because it failed to set the default font path and was unable load the
450 default font.
451 To fix this error, the offending font path must be removed from the
453 default font path by using a different -fontpath command line option.
454 The -fontpath option can also be added to the configuration file as
456 described above.
457
459 The back-end machines are d0 and d1, core input is from the pointer and
460 keyboard attached to d0, clients will refer to :1 when opening windows:
461 Xdmx :1 -display d0:0 -display d1:0 +xinerama
462 As above, except with core input from d1:
464 Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
465 As above, except with core input from a console window on the local
467 display:
468 Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
469 As above, except with core input from the local keyboard and mouse:
471 Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xin‐
472 erama
473 Note that local input can be used under Linux while another X session
474 is running on :0 (assuming the user can access the Linux console tty
475 and mouse devices): a new (blank) VC will be used for keyboard input on
476 the local machine and the Ctrl-Alt-F* sequence will be available to
477 change to another VC (possibly back to another X session running on the
478 local machine). Using Ctrl-Alt-Backspace on the blank VC will termi‐
479 nate the Xdmx session and return to the original VC.
480 This example uses the configuration file shown in the previous section:
482 Xdmx :1 -input :0 +xinerama -configfile filename -config exam‐
483 ple2
484 With this configuration file line:
485 option -input :0 +xinerama;
486 the command line can be shortened to:
487 Xdmx :1 -configfile filename -config example2
488
490 The USB device drivers use the devices called /dev/input/event0,
491 /dev/input/event1, etc. under Linux. These devices are driven using
492 the evdev Linux kernel module, which is part of the hid suite. Please
493 note that if you load the mousedev or kbddev Linux kernel modules, then
494 USB devices will appear as core Linux input devices and you will not be
495 able to select between using the device only as an Xdmx core device or
496 an Xdmx XInput extension device. Further, you may be unable to unload
497 the mousedev Linux kernel module if XFree86 is configured to use
498 /dev/input/mice as an input device (this is quite helpful for laptop
499 users and is set up by default under some Linux distributions, but
500 should be changed if USB devices are to be used with Xdmx).
501 The USB device drivers search through the Linux devices for the first
503 mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
504 device.
505
507 If Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD
508 extension, then a keyboard on a backend or console will be initialized
509 using the map that the host X server provides.
510 If the XKEYBOARD extension is used for both Xdmx and the host X server
512 for the keyboard (i.e., the backend or console X server), then the type
513 of the keyboard will be obtained from the host X server and the key‐
514 board under Xdmx will be initialized with that information. Otherwise,
515 the default type of keyboard will be initialized. In both cases, the
516 map from the host X server will not be used. This means that different
517 initial behavior may be noted with and without XKEYBOARD. Consistent
518 and expected results will be obtained by running XKEYBOARD on all
519 servers and by avoiding the use of xmodmap on the backend or console X
520 servers prior to starting Xdmx.
521 If -xkbmap is specified on the Xdmx command line, then that map will
523 currently be used for all keyboards.
524
526 X was not designed to support multiple core keyboards. However, Xdmx
527 provides some support for multiple core keyboards. Best results will
528 be obtained if all of the keyboards are of the same type and are using
529 the same keyboard map. Because the X server passes raw key code infor‐
530 mation to the X client, key symbols for keyboards with different key
531 maps would be different if the key code for each keyboard was sent
532 without translation to the client. Therefore, Xdmx will attempt to
533 translate the key code from a core keyboard to the key code for the key
534 with the same key symbol of the first core keyboard that was loaded.
535 If the key symbol appears in both maps, the results will be expected.
536 Otherwise, the second core keyboard will return a NoSymbol key symbol
537 for some keys that would have been translated if it was the first core
538 keyboard.
539
541 DMX(3X), X(7), Xserver(1), xdmxconfig(1), vdltodmx(1), xfs(1), xkb‐
542 comp(1)
543
545 Kevin E. Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>,
546 and Rickard E. (Rik) Faith <faith@redhat.com>.
547 Portions of Xdmx are based on code from The XFree86 Project
549 (http://www.xfree86.org) and X.Org (http://www.x.org).
550X Version 11 xorg-server 1.9.5 Xdmx(1)