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/share/X11/xkb. Use of keycodes, symbols and geome‐
106 tries for XKB configuration is deprecated in favor of the
107 rules, layout, model, variant and options settings avail‐
108 able via the -param command line switch. If this option is
109 not specified, the input device will be queried, perhaps
110 using the XKEYBOARD extension.
111 If this option isn't specified, the default input source is the
113 first back-end server (the one used for screen 0). The console
114 window shows the layout of the back-end display(s) and pointer
115 movements and key presses within the console window will be
116 used as core input devices.
117 Several special function keys are active, depending on the
119 input source:
120 Ctrl-Alt-q will terminate the Xdmx server in all modes.
122 Ctrl-Alt-g will toggle a server grab in console mode (a
124 special cursor, currently a spider, is used to indicate
125 an active server grab).
126 Ctrl-Alt-f will toggle fine-grain motion in console mode
128 (a special cursor, currently a cross hair, is used to
129 indicate this mode). If this mode is combined with a
130 server grab, then the cursor will have 4 lines instead
131 of only 2.
132 Ctrl-Alt-F1 through Ctrl-Alt-F12 will switch to another
134 VC in local (raw) mode.
135 -nomulticursor
138 This option turns off support for displaying multiple cursors
139 on overlapped back-end displays. This option is available for
140 testing and benchmarking purposes.
141 -fontpath
144 This option sets the Xdmx server's default font path. This
145 option can be specified multiple times to accommodate multiple
146 font paths. See the FONT PATHS section below for very impor‐
147 tant information regarding setting the default font path.
148 -configfile filename
151 Specify the configuration file that should be read. Note that
152 if the -display command-line option is used, then the configu‐
153 ration file will be ignored.
154 -config name
157 Specify a configuration to use. The name will be the name fol‐
158 lowing the virtual keyword in the configuration file.
159 -stat interval screens
162 This option enables the display of performance statistics. The
163 interval is in seconds. The screens is a count of the number
164 of back-end screens for which data is printed each interval.
165 Specifying 0 for screens will display data for all screens.
166 For each screen, the following information is printed: the
168 screen number, an absolute count of the number of XSync() calls
169 made (SyncCount), the rate of these calls during the previous
170 interval (Sync/s), the average round-trip time (in microsec‐
171 onds) of the last 10 XSync() calls (avSync), the maximum round-
172 trip time (in microseconds) of the last 10 XSync calls
173 (mxSync), the average number of XSync() requests that were
174 pending but not yet processed for each of the last 10 processed
175 XSync() calls, the maximum number of XSync() requests that were
176 pending but not yet processed for each of the last 10 processed
177 XSync() calls, and a histogram showing the distribution of the
178 times of all of the XSync() calls that were made during the
179 previous interval.
180 (The length of the moving average and the number and value of
182 histogram bins are configurable at compile time in the dmxs‐
183 tat.h header file.)
184 -syncbatch interval
187 This option sets the interval in milliseconds for XSync()
188 batching. An interval less than or equal to 0 will disable
189 XSync() batching. The default interval is 100 ms.
190 -nooffscreenopt
193 This option disables the offscreen optimization. Since the
194 lazy window creation optimization requires the offscreen opti‐
195 mization to be enabled, this option will also disable the lazy
196 window creation optimization.
197 -nowindowopt
200 This option disables the lazy window creation optimization.
201 -nosubdivprims
204 This option disables the primitive subdivision optimization.
205 -noxkb Disable use of the XKB extension for communication with the
208 back end displays. (Combine with -kb to disable all use of
209 XKB.)
210 -depth int
213 This option sets the root window's default depth. When choos‐
214 ing a default visual from those available on the back-end X
215 server, the first visual with that matches the depth specified
216 is used.
217 This option can be combined with the -cc option, which speci‐
219 fies the default color visual class, to force the use of a spe‐
220 cific depth and color class for the root window.
221 -norender
224 This option disables the RENDER extension.
225 -noglxproxy
228 This option disables GLX proxy -- the build-in GLX extension
229 implementation that is DMX aware.
230 -noglxswapgroup
233 This option disables the swap group and swap barrier extensions
234 in GLX proxy.
235 -glxsyncswap
238 This option enables synchronization after a swap buffers call
239 by waiting until all X protocol has been processed. When a
240 client issues a glXSwapBuffers request, Xdmx relays that
241 request to each back-end X server, and those requests are
242 buffered along with all other protocol requests. However, in
243 systems that have large network buffers, this buffering can
244 lead to the set of back-end X servers handling the swap buffers
245 request asynchronously. With this option, an XSync() request
246 is issued to each back-end X server after sending the swap buf‐
247 fers request. The XSync() requests will flush all buffered
248 protocol (including the swap buffers requests) and wait until
249 the back-end X servers have processed those requests before
250 continuing. This option does not wait until all GL commands
251 have been processed so there might be previously issued com‐
252 mands that are still being processed in the GL pipe when the
253 XSync() request returns. See the -glxfinishswap option below
254 if Xdmx should wait until the GL commands have been processed.
255 -glxfinishswap
258 This option enables synchronization after a swap buffers call
259 by waiting until all GL commands have been completed. It is
260 similar to the -glxsyncswap option above; however, instead of
261 issuing an XSync(), it issues a glFinish() request to each
262 back-end X server after sending the swap buffers requests. The
263 glFinish() request will flush all buffered protocol requests,
264 process both X and GL requests, and wait until all previously
265 called GL commands are complete before returning.
266 -ignorebadfontpaths
269 This option ignores font paths that are not available on all
270 back-end servers by removing the bad font path(s) from the
271 default font path list. If no valid font paths are left after
272 removing the bad paths, an error to that effect is printed in
273 the log.
274 -addremovescreens
277 This option enables the dynamic addition and removal of
278 screens, which is disabled by default. Note that GLXProxy and
279 Render do not yet support dynamic addition and removal of
280 screens, and must be disabled via the -noglxproxy and -norender
281 command line options described above.
282 -param This option specifies parameters on the command line. Cur‐
285 rently, only parameters dealing with XKEYBOARD configuration
286 are supported. These parameters apply only to the core key‐
287 board. Parameter values are installation-dependent. Please
288 see /usr/share/X11/xkb or a similar directory for complete
289 information.
290 XkbRules
292 Defaults to "evdev". Other values may include "sgi"
293 and "sun".
294 XkbModel
297 Defaults to "pc105". When used with "base" rules,
298 other values may include "pc102", "pc104", "microsoft",
299 and many others. When used with "sun" rules, other
300 values may include "type4" and "type5".
301 XkbLayout
304 Defaults to "us". Other country codes and "dvorak" are
305 usually available.
306 XkbVariant
309 Defaults to "".
310 XkbOptions
313 Defaults to "".
314
316 The following words and tokens are reserved:
317 virtual display wall option param { } ; #
318 Comments start with a # mark and extend to the end of the line. They
320 may appear anywhere. If a configuration file is read into xdmxconfig,
321 the comments in that file will be preserved, but will not be editable.
322 The grammar is as follows:
324 virtual-list ::= [ virtual-list ] | virtual
325 virtual ::= virtual [ name ] [ dim ] { dw-list }
327 dw-list ::= [ dw-list ] | dw
329 dw ::= display | wall | option
331 display ::= display name [ geometry ] [ / geometry ] [ origin ]
333 ;
334 wall ::= wall [ dim ] [ dim ] name-list ;
336 option ::= option name-list ;
338 param ::= param name-list ;
340 param ::= param { param-list }
342 param-list ::= [ param-list ] | name-list ;
344 name-list ::= [ name-list ] | name
346 name ::= string | double-quoted-string
348 dim ::= integer x integer
350 geometry ::= [ integer x integer ] [ signed-integer signed-inte‐
352 ger ]
353 origin ::= @ integer x integer
355 The name following virtual is used as an identifier for the configura‐
357 tion, and may be passed to Xdmx using the -config command line option.
358 The name of a display should be standard X display name, although no
359 checking is performed (e.g., "machine:0").
360 For names, double quotes are optional unless the name is reserved or
362 contains spaces.
363 The first dimension following wall is the dimension for tiling (e.g.,
365 2x4 or 4x4). The second dimension following wall is the dimension of
366 each display in the wall (e.g., 1280x1024).
367 The first geometry following display is the geometry of the screen win‐
369 dow on the backend server. The second geometry, which is always pre‐
370 ceeded by a slash, is the geometry of the root window. By default, the
371 root window has the same geometry as the screen window.
372 The option line can be used to specify any command-line options (e.g.,
374 -input). (It cannot be used to specify the name of the front-end dis‐
375 play.) The option line is processed once at server startup, just line
376 command line options. This behavior may be unexpected.
377
379 Two displays being used for a desktop may be specified in any of the
380 following formats:
381 virtual example0 {
382 display d0:0 1280x1024 @0x0;
383 display d1:0 1280x1024 @1280x0;
384 }
385 virtual example1 {
387 display d0:0 1280x1024;
388 display d1:0 @1280x0;
389 }
390 virtual example2 {
392 display "d0:0";
393 display "d1:0" @1280x0;
394 }
395 virtual example3 { wall 2x1 d0:0 d1:0; }
397 A 4x4 wall of 16 total displays could be specified as follows (if no
398 tiling dimension is specified, an approximate square is used):
399 virtual example4 {
400 wall d0:0 d1:0 d2:0 d3:0
401 d4:0 d5:0 d6:0 d7:0
402 d8:0 d9:0 da:0 db:0
403 dc:0 dd:0 de:0 df:0;
404 }
405
407 The font path used by the Xdmx front-end server will be propagated to
408 each back-end server,which requires that each back-end server have
409 access to the exact same font paths as the front-end server. This can
410 be most easily handled by either using a font server (e.g., xfs) or by
411 remotely mounting the font paths on each back-end server, and then set‐
412 ting the Xdmx server's default font path with the -I "-fontpath" com‐
413 mand line option described above.
414 For example, if you specify a font path with the following command
416 line:
417 Xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath
418 /usr/fonts/Type1/ +xinerama
419 Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font paths
420 on the Xdmx server and all back-end server, which is d0 in this exam‐
421 ple.
422 Font servers can also be specified with the -fontpath option. For
424 example, let's assume that a properly configured font server is running
425 on host d0. Then, the following command line
426 Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xin‐
427 erama
428 will initialize the front-end Xdmx server and each of the back-end
429 servers to use the font server on d0.
430 Some fonts might not be supported by either the front-end or the back-
432 end servers. For example, let's assume the front-end Xdmx server
433 includes support Type1 fonts, but one of the back-end servers does not.
434 Let's also assume that the default font path for Xdmx includes Type1
435 fonts in its font path. Then, when Xdmx initializes the default font
436 path to load the default font, the font path that includes Type1 fonts
437 (along with the other default font paths that are used by the Xdmx
438 server) is sent to the back-end server that cannot handle Type1 fonts.
439 That back-end server then rejects the font path and sends an error back
440 to the Xdmx server. Xdmx then prints an error message and exits
441 because it failed to set the default font path and was unable load the
442 default font.
443 To fix this error, the offending font path must be removed from the
445 default font path by using a different -fontpath command line option.
446 The -fontpath option can also be added to the configuration file as
448 described above.
449
451 The back-end machines are d0 and d1, core input is from the pointer and
452 keyboard attached to d0, clients will refer to :1 when opening windows:
453 Xdmx :1 -display d0:0 -display d1:0 +xinerama
454 As above, except with core input from d1:
456 Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
457 As above, except with core input from a console window on the local
459 display:
460 Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
461 As above, except with core input from the local keyboard and mouse:
463 Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xin‐
464 erama
465 Note that local input can be used under Linux while another X session
466 is running on :0 (assuming the user can access the Linux console tty
467 and mouse devices): a new (blank) VC will be used for keyboard input on
468 the local machine and the Ctrl-Alt-F* sequence will be available to
469 change to another VC (possibly back to another X session running on the
470 local machine). Using Ctrl-Alt-Backspace on the blank VC will termi‐
471 nate the Xdmx session and return to the original VC.
472 This example uses the configuration file shown in the previous section:
474 Xdmx :1 -input :0 +xinerama -configfile filename -config exam‐
475 ple2
476 With this configuration file line:
477 option -input :0 +xinerama;
478 the command line can be shortened to:
479 Xdmx :1 -configfile filename -config example2
480
482 The USB device drivers use the devices called /dev/input/event0,
483 /dev/input/event1, etc. under Linux. These devices are driven using
484 the evdev Linux kernel module, which is part of the hid suite. Please
485 note that if you load the mousedev or kbddev Linux kernel modules, then
486 USB devices will appear as core Linux input devices and you will not be
487 able to select between using the device only as an Xdmx core device or
488 an Xdmx XInput extension device. Further, you may be unable to unload
489 the mousedev Linux kernel module if XFree86 is configured to use
490 /dev/input/mice as an input device (this is quite helpful for laptop
491 users and is set up by default under some Linux distributions, but
492 should be changed if USB devices are to be used with Xdmx).
493 The USB device drivers search through the Linux devices for the first
495 mouse, keyboard, or non-mouse-non-keyboard Linux device and use that
496 device.
497
499 If Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD
500 extension, then a keyboard on a backend or console will be initialized
501 using the map that the host X server provides.
502 If the XKEYBOARD extension is used for both Xdmx and the host X server
504 for the keyboard (i.e., the backend or console X server), then the type
505 of the keyboard will be obtained from the host X server and the key‐
506 board under Xdmx will be initialized with that information. Otherwise,
507 the default type of keyboard will be initialized. In both cases, the
508 map from the host X server will not be used. This means that different
509 initial behavior may be noted with and without XKEYBOARD. Consistent
510 and expected results will be obtained by running XKEYBOARD on all
511 servers and by avoiding the use of xmodmap on the backend or console X
512 servers prior to starting Xdmx.
513 If -xkbmap is specified on the Xdmx command line, then that map will
515 currently be used for all keyboards.
516
518 X was not designed to support multiple core keyboards. However, Xdmx
519 provides some support for multiple core keyboards. Best results will
520 be obtained if all of the keyboards are of the same type and are using
521 the same keyboard map. Because the X server passes raw key code infor‐
522 mation to the X client, key symbols for keyboards with different key
523 maps would be different if the key code for each keyboard was sent
524 without translation to the client. Therefore, Xdmx will attempt to
525 translate the key code from a core keyboard to the key code for the key
526 with the same key symbol of the first core keyboard that was loaded.
527 If the key symbol appears in both maps, the results will be expected.
528 Otherwise, the second core keyboard will return a NoSymbol key symbol
529 for some keys that would have been translated if it was the first core
530 keyboard.
531
533 DMX(3), X(7), Xserver(1), xdmxconfig(1), vdltodmx(1), xfs(1), xkb‐
534 comp(1), xkeyboard-config(7)
535
537 Kevin E. Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>,
538 and Rickard E. (Rik) Faith <faith@redhat.com>.
539 Portions of Xdmx are based on code from The XFree86 Project
541 (http://www.xfree86.org) and X.Org (http://www.x.org).
542X Version 11 xorg-server 1.17.4 Xdmx(1)