1Xdmx(1)                     General Commands Manual                    Xdmx(1)
2
3
4

NAME

6       Xdmx - Distributed Multi-head X server
7

SYNOPSIS

9       Xdmx [:display] [option ...]
10

DESCRIPTION

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
22       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

OPTIONS

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
29       -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
37
38       -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, ex‐
41               cept that core devices on backend servers cannot be treated  as
42               XInput extension devices.  (Although extension devices on back‐
43               end and console servers are supported as extension devices  un‐
44               der Xdmx).
45
46
47       -input input-source
48               This  specifies  the  source to use for the core input devices.
49               The choices are:
50
51               dummy
52                   A set of dummy core input drivers are  used.   These  never
53                   generate any input events.
54
55
56               local
57                   The  raw  keyboard  and pointer from the local computer are
58                   used.  A comma-separated list of driver names  can  be  ap‐
59                   pended.   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  fu‐
63                   ture.   Appropriate defaults will be used if no comma-sepa‐
64                   rated list is provided.
65
66
67               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
72                   If the display-name is followed by ",xi" then XInput exten‐
73                   sion devices on the display will be used as Xdmx XInput ex‐
74                   tension  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
79                   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  de‐
85                   scribed above.
86
87                   If  the  display-name  is followed by ",windows", then out‐
88                   lines of the windows on the backend will be  displayed  in‐
89                   side  the console window.  Otherwise (or if ",nowindows" is
90                   used), the console window will not display the outlines  of
91                   backend  windows.  (This option only applies to console in‐
92                   put.)
93
94                   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  de‐
97                   vice.   For example, ",xkb,xfree86,pc104" will specify that
98                   the "xfree86" keycodes and the "pc104"  symbols  should  be
99                   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
109               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
115               Several  special function keys are active, depending on the in‐
116               put source:
117
118                      Ctrl-Alt-q will terminate the Xdmx server in all modes.
119
120                      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
124                      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
130                      Ctrl-Alt-F1 through Ctrl-Alt-F12 will switch to  another
131                      VC in local (raw) mode.
132
133
134       -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
139
140       -fontpath
141               This option sets the Xdmx server's default font path.  This op‐
142               tion 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
146
147       -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
152
153       -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
157
158       -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
164               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
178               (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
182
183       -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
188
189       -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
195
196       -nowindowopt
197               This option disables the lazy window creation optimization.
198
199
200       -nosubdivprims
201               This option disables the primitive subdivision optimization.
202
203
204       -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
208
209       -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
215               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
219
220       -norender
221               This option disables the RENDER extension.
222
223
224       -noglxproxy
225               This option disables GLX proxy -- the  build-in  GLX  extension
226               implementation that is DMX aware.
227
228
229       -noglxswapgroup
230               This option disables the swap group and swap barrier extensions
231               in GLX proxy.
232
233
234       -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  re‐
238               quest  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
253
254       -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
264
265       -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  de‐
268               fault  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
272
273       -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
280
281       -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 in‐
286               formation.
287
288               XkbRules
289                       Defaults to "evdev".  Other values  may  include  "sgi"
290                       and "sun".
291
292
293               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
299
300               XkbLayout
301                       Defaults to "us".  Other country codes and "dvorak" are
302                       usually available.
303
304
305               XkbVariant
306                       Defaults to "".
307
308
309               XkbOptions
310                       Defaults to "".
311

CONFIGURATION FILE GRAMMAR

313       The following words and tokens are reserved:
314              virtual display wall option param { } ; #
315
316       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
320       The grammar is as follows:
321              virtual-list ::= [ virtual-list ] | virtual
322
323              virtual ::= virtual [ name ] [ dim ] { dw-list }
324
325              dw-list ::= [ dw-list ] | dw
326
327              dw ::= display | wall | option
328
329              display  ::= display name [ geometry ] [ / geometry ] [ origin ]
330              ;
331
332              wall ::= wall [ dim ] [ dim ] name-list ;
333
334              option ::= option name-list ;
335
336              param ::= param name-list ;
337
338              param ::= param { param-list }
339
340              param-list ::= [ param-list ] | name-list ;
341
342              name-list ::= [ name-list ] | name
343
344              name ::= string | double-quoted-string
345
346              dim ::= integer x integer
347
348              geometry ::= [ integer x integer ] [ signed-integer signed-inte‐
349              ger ]
350
351              origin ::= @ integer x integer
352
353       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
358       For names, double quotes are optional unless the name  is  reserved  or
359       contains spaces.
360
361       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
365       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
370       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

CONFIGURATION FILE EXAMPLES

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
383              virtual example1 {
384                  display d0:0 1280x1024;
385                  display d1:0 @1280x0;
386              }
387
388              virtual example2 {
389                  display "d0:0";
390                  display "d1:0" @1280x0;
391              }
392
393              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

FONT PATHS

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  ac‐
406       cess to the exact same font paths as the front-end server.  This can be
407       most easily handled by either using a font server (e.g., xfs) or by re‐
408       motely  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
412       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
420       Font  servers can also be specified with the -fontpath option.  For ex‐
421       ample, 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
428       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  in‐
430       cludes  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  be‐
438       cause  it  failed  to set the default font path and was unable load the
439       default font.
440
441       To fix this error, the offending font path must be removed from the de‐
442       fault font path by using a different -fontpath command line option.
443
444       The -fontpath option can also be added to the configuration file as de‐
445       scribed above.
446

COMMAND-LINE EXAMPLES

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
452       As above, except with core input from d1:
453              Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
454
455       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
459       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
470       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

USING THE USB DEVICE DRIVERS

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
491       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

KEYBOARD INITIALIZATION

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
500       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
511       If  -xkbmap  is  specified on the Xdmx command line, then that map will
512       currently be used for all keyboards.
513

MULTIPLE CORE KEYBOARDS

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

SEE ALSO

530       DMX(3), X(7),  Xserver(1),  xdmxconfig(1),  vdltodmx(1),  xfs(1),  xkb‐
531       comp(1), xkeyboard-config(7)
532

AUTHORS

534       Kevin  E.  Martin <kem@redhat.com>, David H. Dawes <dawes@xfree86.org>,
535       and Rickard E. (Rik) Faith <faith@redhat.com>.
536
537       Portions  of  Xdmx  are  based  on  code  from  The   XFree86   Project
538       (http://www.xfree86.org) and X.Org (https://www.x.org).
539
540
541
542X Version 11                  xorg-server 1.20.14                      Xdmx(1)
Impressum