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. The following drivers have been implemented for
60 Linux: usb-mou (a USB mouse driver), usb-kbd (a USB key‐
61 board driver), and usb-oth (a USB non-keyboard, non-mouse
62 driver). Additional drivers may be implemented in the
63 future. Appropriate defaults will be used if no comma-sep‐
64 arated list is provided.
65 display-name
68 If the display-name is a back-end server, then core input
69 events are taken from the server specified. Otherwise, a
70 console window will be opened on the specified display.
71 If the display-name is followed by ",xi" then XInput exten‐
73 sion devices on the display will be used as Xdmx XInput
74 extension devices. If the display-name is followed by
75 ",noxi" then XInput extension devices on the display will
76 not be used as Xdmx XInput extension devices. Currently,
77 the default is ",xi".
78 If the display-name is followed by ",console" and the dis‐
80 play-name refers to a display that is used as a backend
81 display, then a console window will be opened on that dis‐
82 play and that display will be treated as a backend display.
83 Otherwise (or if ",noconsole" is used), the display will be
84 treated purely as a backend or a console display, as
85 described above.
86 If the display-name is followed by ",windows", then out‐
88 lines of the windows on the backend will be displayed
89 inside the console window. Otherwise (or if ",nowindows"
90 is used), the console window will not display the outlines
91 of backend windows. (This option only applies to console
92 input.)
93 If the display-name is followed by ",xkb", then the next 1
95 to 3 comma-separated parameters will specify the keycodes,
96 symbols, and geometry of the keyboard for this input
97 device. For example, ",xkb,xfree86,pc104" will specify
98 that the "xfree86" keycodes and the "pc104" symbols should
99 be used to initialize the keyboard. For an SGI keyboard,
100 ",xkb,sgi/indy(pc102)" might be useful. A list of key‐
101 codes, symbols, and geometries can be found in
102 /usr/share/X11/xkb. Use of keycodes, symbols and geome‐
103 tries for XKB configuration is deprecated in favor of the
104 rules, layout, model, variant and options settings avail‐
105 able via the -param command line switch. If this option is
106 not specified, the input device will be queried, perhaps
107 using the XKEYBOARD 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 -nomulticursor
135 This option turns off support for displaying multiple cursors
136 on overlapped back-end displays. This option is available for
137 testing and benchmarking purposes.
138 -fontpath
141 This option sets the Xdmx server's default font path. This
142 option can be specified multiple times to accommodate multiple
143 font paths. See the FONT PATHS section below for very impor‐
144 tant information regarding setting the default font path.
145 -configfile filename
148 Specify the configuration file that should be read. Note that
149 if the -display command-line option is used, then the configu‐
150 ration file will be ignored.
151 -config name
154 Specify a configuration to use. The name will be the name fol‐
155 lowing the virtual keyword in the configuration file.
156 -stat interval screens
159 This option enables the display of performance statistics. The
160 interval is in seconds. The screens is a count of the number
161 of back-end screens for which data is printed each interval.
162 Specifying 0 for screens will display data for all screens.
163 For each screen, the following information is printed: the
165 screen number, an absolute count of the number of XSync() calls
166 made (SyncCount), the rate of these calls during the previous
167 interval (Sync/s), the average round-trip time (in microsec‐
168 onds) of the last 10 XSync() calls (avSync), the maximum round-
169 trip time (in microseconds) of the last 10 XSync calls
170 (mxSync), the average number of XSync() requests that were
171 pending but not yet processed for each of the last 10 processed
172 XSync() calls, the maximum number of XSync() requests that were
173 pending but not yet processed for each of the last 10 processed
174 XSync() calls, and a histogram showing the distribution of the
175 times of all of the XSync() calls that were made during the
176 previous interval.
177 (The length of the moving average and the number and value of
179 histogram bins are configurable at compile time in the dmxs‐
180 tat.h header file.)
181 -syncbatch interval
184 This option sets the interval in milliseconds for XSync()
185 batching. An interval less than or equal to 0 will disable
186 XSync() batching. The default interval is 100 ms.
187 -nooffscreenopt
190 This option disables the offscreen optimization. Since the
191 lazy window creation optimization requires the offscreen opti‐
192 mization to be enabled, this option will also disable the lazy
193 window creation optimization.
194 -nowindowopt
197 This option disables the lazy window creation optimization.
198 -nosubdivprims
201 This option disables the primitive subdivision optimization.
202 -noxkb Disable use of the XKB extension for communication with the
205 back end displays. (Combine with -kb to disable all use of
206 XKB.)
207 -depth int
210 This option sets the root window's default depth. When choos‐
211 ing a default visual from those available on the back-end X
212 server, the first visual with that matches the depth specified
213 is used.
214 This option can be combined with the -cc option, which speci‐
216 fies the default color visual class, to force the use of a spe‐
217 cific depth and color class for the root window.
218 -norender
221 This option disables the RENDER extension.
222 -noglxproxy
225 This option disables GLX proxy -- the build-in GLX extension
226 implementation that is DMX aware.
227 -noglxswapgroup
230 This option disables the swap group and swap barrier extensions
231 in GLX proxy.
232 -glxsyncswap
235 This option enables synchronization after a swap buffers call
236 by waiting until all X protocol has been processed. When a
237 client issues a glXSwapBuffers request, Xdmx relays that
238 request to each back-end X server, and those requests are
239 buffered along with all other protocol requests. However, in
240 systems that have large network buffers, this buffering can
241 lead to the set of back-end X servers handling the swap buffers
242 request asynchronously. With this option, an XSync() request
243 is issued to each back-end X server after sending the swap buf‐
244 fers request. The XSync() requests will flush all buffered
245 protocol (including the swap buffers requests) and wait until
246 the back-end X servers have processed those requests before
247 continuing. This option does not wait until all GL commands
248 have been processed so there might be previously issued com‐
249 mands that are still being processed in the GL pipe when the
250 XSync() request returns. See the -glxfinishswap option below
251 if Xdmx should wait until the GL commands have been processed.
252 -glxfinishswap
255 This option enables synchronization after a swap buffers call
256 by waiting until all GL commands have been completed. It is
257 similar to the -glxsyncswap option above; however, instead of
258 issuing an XSync(), it issues a glFinish() request to each
259 back-end X server after sending the swap buffers requests. The
260 glFinish() request will flush all buffered protocol requests,
261 process both X and GL requests, and wait until all previously
262 called GL commands are complete before returning.
263 -ignorebadfontpaths
266 This option ignores font paths that are not available on all
267 back-end servers by removing the bad font path(s) from the
268 default font path list. If no valid font paths are left after
269 removing the bad paths, an error to that effect is printed in
270 the log.
271 -addremovescreens
274 This option enables the dynamic addition and removal of
275 screens, which is disabled by default. Note that GLXProxy and
276 Render do not yet support dynamic addition and removal of
277 screens, and must be disabled via the -noglxproxy and -norender
278 command line options described above.
279 -param This option specifies parameters on the command line. Cur‐
282 rently, only parameters dealing with XKEYBOARD configuration
283 are supported. These parameters apply only to the core key‐
284 board. Parameter values are installation-dependent. Please
285 see /usr/share/X11/xkb or a similar directory for complete
286 information.
287 XkbRules
289 Defaults to "evdev". Other values may include "sgi"
290 and "sun".
291 XkbModel
294 Defaults to "pc105". When used with "base" rules,
295 other values may include "pc102", "pc104", "microsoft",
296 and many others. When used with "sun" rules, other
297 values may include "type4" and "type5".
298 XkbLayout
301 Defaults to "us". Other country codes and "dvorak" are
302 usually available.
303 XkbVariant
306 Defaults to "".
307 XkbOptions
310 Defaults to "".
311
313 The following words and tokens are reserved:
314 virtual display wall option param { } ; #
315 Comments start with a # mark and extend to the end of the line. They
317 may appear anywhere. If a configuration file is read into xdmxconfig,
318 the comments in that file will be preserved, but will not be editable.
319 The grammar is as follows:
321 virtual-list ::= [ virtual-list ] | virtual
322 virtual ::= virtual [ name ] [ dim ] { dw-list }
324 dw-list ::= [ dw-list ] | dw
326 dw ::= display | wall | option
328 display ::= display name [ geometry ] [ / geometry ] [ origin ]
330 ;
331 wall ::= wall [ dim ] [ dim ] name-list ;
333 option ::= option name-list ;
335 param ::= param name-list ;
337 param ::= param { param-list }
339 param-list ::= [ param-list ] | name-list ;
341 name-list ::= [ name-list ] | name
343 name ::= string | double-quoted-string
345 dim ::= integer x integer
347 geometry ::= [ integer x integer ] [ signed-integer signed-inte‐
349 ger ]
350 origin ::= @ integer x integer
352 The name following virtual is used as an identifier for the configura‐
354 tion, and may be passed to Xdmx using the -config command line option.
355 The name of a display should be standard X display name, although no
356 checking is performed (e.g., "machine:0").
357 For names, double quotes are optional unless the name is reserved or
359 contains spaces.
360 The first dimension following wall is the dimension for tiling (e.g.,
362 2x4 or 4x4). The second dimension following wall is the dimension of
363 each display in the wall (e.g., 1280x1024).
364 The first geometry following display is the geometry of the screen win‐
366 dow on the backend server. The second geometry, which is always pre‐
367 ceeded by a slash, is the geometry of the root window. By default, the
368 root window has the same geometry as the screen window.
369 The option line can be used to specify any command-line options (e.g.,
371 -input). (It cannot be used to specify the name of the front-end dis‐
372 play.) The option line is processed once at server startup, just line
373 command line options. This behavior may be unexpected.
374
376 Two displays being used for a desktop may be specified in any of the
377 following formats:
378 virtual example0 {
379 display d0:0 1280x1024 @0x0;
380 display d1:0 1280x1024 @1280x0;
381 }
382 virtual example1 {
384 display d0:0 1280x1024;
385 display d1:0 @1280x0;
386 }
387 virtual example2 {
389 display "d0:0";
390 display "d1:0" @1280x0;
391 }
392 virtual example3 { wall 2x1 d0:0 d1:0; }
394 A 4x4 wall of 16 total displays could be specified as follows (if no
395 tiling dimension is specified, an approximate square is used):
396 virtual example4 {
397 wall d0:0 d1:0 d2:0 d3:0
398 d4:0 d5:0 d6:0 d7:0
399 d8:0 d9:0 da:0 db:0
400 dc:0 dd:0 de:0 df:0;
401 }
402
404 The font path used by the Xdmx front-end server will be propagated to
405 each back-end server,which requires that each back-end server have
406 access to the exact same font paths as the front-end server. This can
407 be most easily handled by either using a font server (e.g., xfs) or by
408 remotely mounting the font paths on each back-end server, and then set‐
409 ting the Xdmx server's default font path with the -I "-fontpath" com‐
410 mand line option described above.
411 For example, if you specify a font path with the following command
413 line:
414 Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath
415 /usr/fonts/Type1/ +xinerama
416 Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
417 on the Xdmx server and all back-end server, which is d0 in this exam‐
418 ple.
419 Font servers can also be specified with the -fontpath option. For
421 example, let's assume that a properly configured font server is running
422 on host d0. Then, the following command line
423 Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xin‐
424 erama
425 will initialize the front-end Xdmx server and each of the back-end
426 servers to use the font server on d0.
427 Some fonts might not be supported by either the front-end or the back-
429 end servers. For example, let's assume the front-end Xdmx server
430 includes support Type1 fonts, but one of the back-end servers does not.
431 Let's also assume that the default font path for Xdmx includes Type1
432 fonts in its font path. Then, when Xdmx initializes the default font
433 path to load the default font, the font path that includes Type1 fonts
434 (along with the other default font paths that are used by the Xdmx
435 server) is sent to the back-end server that cannot handle Type1 fonts.
436 That back-end server then rejects the font path and sends an error back
437 to the Xdmx server. Xdmx then prints an error message and exits
438 because it failed to set the default font path and was unable load the
439 default font.
440 To fix this error, the offending font path must be removed from the
442 default font path by using a different -fontpath command line option.
443 The -fontpath option can also be added to the configuration file as
445 described above.
446
448 The back-end machines are d0 and d1, core input is from the pointer and
449 keyboard attached to d0, clients will refer to :1 when opening windows:
450 Xdmx :1 -display d0:0 -display d1:0 +xinerama
451 As above, except with core input from d1:
453 Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
454 As above, except with core input from a console window on the local
456 display:
457 Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
458 As above, except with core input from the local keyboard and mouse:
460 Xdmx :1 -display d0:0 -display d1:0 -input local,usb-kbd,usb-mou
461 +xinerama
462 Note that local input can be used under Linux while another X session
463 is running on :0 (assuming the user can access the Linux console tty
464 and mouse devices): a new (blank) VC will be used for keyboard input on
465 the local machine and the Ctrl-Alt-F* sequence will be available to
466 change to another VC (possibly back to another X session running on the
467 local machine). Using Ctrl-Alt-Backspace on the blank VC will termi‐
468 nate the Xdmx session and return to the original VC.
469 This example uses the configuration file shown in the previous section:
471 Xdmx :1 -input :0 +xinerama -configfile filename -config exam‐
472 ple2
473 With this configuration file line:
474 option -input :0 +xinerama;
475 the command line can be shortened to:
476 Xdmx :1 -configfile filename -config example2
477
479 The USB device drivers use the devices called /dev/input/event0,
480 /dev/input/event1, etc. under Linux. These devices are driven using
481 the evdev Linux kernel module, which is part of the hid suite. Please
482 note that if you load the mousedev or kbddev Linux kernel modules, then
483 USB devices will appear as core Linux input devices and you will not be
484 able to select between using the device only as an Xdmx core device or
485 an Xdmx XInput extension device. Further, you may be unable to unload
486 the mousedev Linux kernel module if XFree86 is configured to use
487 /dev/input/mice as an input device (this is quite helpful for laptop
488 users and is set up by default under some Linux distributions, but
489 should be changed if USB devices are to be used with Xdmx).
490 The USB device drivers search through the Linux devices for the first
492 mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
493 device.
494
496 If Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD
497 extension, then a keyboard on a backend or console will be initialized
498 using the map that the host X server provides.
499 If the XKEYBOARD extension is used for both Xdmx and the host X server
501 for the keyboard (i.e., the backend or console X server), then the type
502 of the keyboard will be obtained from the host X server and the key‐
503 board under Xdmx will be initialized with that information. Otherwise,
504 the default type of keyboard will be initialized. In both cases, the
505 map from the host X server will not be used. This means that different
506 initial behavior may be noted with and without XKEYBOARD. Consistent
507 and expected results will be obtained by running XKEYBOARD on all
508 servers and by avoiding the use of xmodmap on the backend or console X
509 servers prior to starting Xdmx.
510 If -xkbmap is specified on the Xdmx command line, then that map will
512 currently be used for all keyboards.
513
515 X was not designed to support multiple core keyboards. However, Xdmx
516 provides some support for multiple core keyboards. Best results will
517 be obtained if all of the keyboards are of the same type and are using
518 the same keyboard map. Because the X server passes raw key code infor‐
519 mation to the X client, key symbols for keyboards with different key
520 maps would be different if the key code for each keyboard was sent
521 without translation to the client. Therefore, Xdmx will attempt to
522 translate the key code from a core keyboard to the key code for the key
523 with the same key symbol of the first core keyboard that was loaded.
524 If the key symbol appears in both maps, the results will be expected.
525 Otherwise, the second core keyboard will return a NoSymbol key symbol
526 for some keys that would have been translated if it was the first core
527 keyboard.
528
530 DMX(3), X(7), Xserver(1), xdmxconfig(1), vdltodmx(1), xfs(1), xkb‐
531 comp(1), xkeyboard-config(7)
532
534 Kevin E. Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>,
535 and Rickard E. (Rik) Faith <faith@redhat.com>.
536 Portions of Xdmx are based on code from The XFree86 Project
538 (http://www.xfree86.org) and X.Org (http://www.x.org).
539X Version 11 xorg-server 1.20.3 Xdmx(1)