Go to main content

man pages section 1: User Commands

Exit Print View

Updated: Wednesday, February 10, 2021

Xdmx (1)


Xdmx - head X server


Xdmx [:display] [option ...]


Xdmx(1)                     General Commands Manual                    Xdmx(1)

       Xdmx - Distributed Multi-head X server

       Xdmx [:display] [option ...]

       Xdmx  is  a proxy X server that uses one or more other X servers as its
       display devices.  It provides multi-head X functionality  for  displays
       that  might  be  located  on  different  machines.  Xdmx functions as a
       front-end X server that acts as a proxy to a set of back-end X servers.
       All  of  the  visible  rendering  is  passed to the back-end X servers.
       Clients connect to the Xdmx front-end, and  everything  appears  as  it
       would  in  a  regular multi-head configuration.  If Xinerama is enabled
       (e.g., with +xinerama on the command line), the clients  see  a  single
       large screen.

       Xdmx communicates to the back-end X servers using the standard X11 pro-
       tocol, and standard and/or commonly available X server extensions.

       In addition to the normal X server options described in the  Xserver(1)
       manual page, Xdmx accepts the following command line switches:

       -display display-name
               This  specifies the name(s) of the back-end X server display(s)
               to connect to.  This option may be specified multiple times  to
               connect  to  more than one back-end display.  The first is used
               as screen 0, the second as screen 1, etc.  If  this  option  is
               omitted,  the $DISPLAY environment variable is used as the sin-
               gle back-end X server display.

       -xinput input-source
               This specifies the source to use for XInput extension  devices.
               The  choices  are  the  same  as  for -input , described below,
               except that core devices on backend servers cannot  be  treated
               as  XInput  extension  devices.  (Although extension devices on
               backend and console servers are supported as extension  devices
               under Xdmx).

       -input input-source
               This  specifies  the  source to use for the core input devices.
               The choices are:

                   A set of dummy core input drivers are  used.   These  never
                   generate any input events.

                   The  raw  keyboard  and pointer from the local computer are
                   used.  A  comma-separated  list  of  driver  names  can  be
                   appended.   For  example,  to select the example Linux key-
                   board and PS/2 mouse driver use: -input local,kbd,ps2.  The
                   following  drivers have been implemented for Linux: kbd, ms
                   (a two-button Microsoft mouse driver), ps2  (a  PS/2  mouse
                   driver),  usb-mou (a USB mouse driver), usb-kbd (a USB key-
                   board driver), and usb-oth (a USB  non-keyboard,  non-mouse
                   driver).   Additional  drivers  may  be  implemented in the
                   future.  Appropriate defaults will be used if no comma-sep-
                   arated list is provided.

                   If  the  display-name is a back-end server, then core input
                   events are taken from the server specified.   Otherwise,  a
                   console window will be opened on the specified display.

                   If the display-name is followed by ",xi" then XInput exten-
                   sion devices on the display will be  used  as  Xdmx  XInput
                   extension  devices.   If  the  display-name  is followed by
                   ",noxi" then XInput extension devices on the  display  will
                   not  be  used as Xdmx XInput extension devices.  Currently,
                   the default is ",xi".

                   If the display-name is followed by ",console" and the  dis-
                   play-name  refers  to  a  display that is used as a backend
                   display, then a console window will be opened on that  dis-
                   play and that display will be treated as a backend display.
                   Otherwise (or if ",noconsole" is used), the display will be
                   treated  purely  as  a  backend  or  a  console display, as
                   described above.

                   If the display-name is followed by  ",windows",  then  out-
                   lines  of  the  windows  on  the  backend will be displayed
                   inside the console window.  Otherwise (or  if  ",nowindows"
                   is  used), the console window will not display the outlines
                   of backend windows.  (This option only applies  to  console

                   If  the display-name is followed by ",xkb", then the next 1
                   to 3 comma-separated parameters will specify the  keycodes,
                   symbols,  and  geometry  of  the  keyboard  for  this input
                   device.  For  example,  ",xkb,xfree86,pc104"  will  specify
                   that  the "xfree86" keycodes and the "pc104" symbols should
                   be used to initialize the keyboard.  For an  SGI  keyboard,
                   ",xkb,sgi/indy(pc102)"  might  be  useful.   A list of key-
                   codes,  symbols,   and   geometries   can   be   found   in
                   /usr/share/X11/xkb.   Use  of  keycodes, symbols and geome-
                   tries for XKB configuration is deprecated in favor  of  the
                   rules,  layout,  model, variant and options settings avail-
                   able via the -param command line switch.  If this option is
                   not  specified,  the  input device will be queried, perhaps
                   using the XKEYBOARD extension.

               If this option isn't specified, the default input source is the
               first back-end server (the one used for screen 0).  The console
               window shows the layout of the back-end display(s) and  pointer
               movements  and  key  presses  within the console window will be
               used as core input devices.

               Several special function keys  are  active,  depending  on  the
               input source:

                      Ctrl-Alt-q will terminate the Xdmx server in all modes.

                      Ctrl-Alt-g  will toggle a server grab in console mode (a
                      special cursor, currently a spider, is used to  indicate
                      an active server grab).

                      Ctrl-Alt-f will toggle fine-grain motion in console mode
                      (a special cursor, currently a cross hair,  is  used  to
                      indicate  this  mode).   If this mode is combined with a
                      server grab, then the cursor will have 4  lines  instead
                      of only 2.

                      Ctrl-Alt-F1  through Ctrl-Alt-F12 will switch to another
                      VC in local (raw) mode.

               This option turns off support for displaying  multiple  cursors
               on  overlapped back-end displays.  This option is available for
               testing and benchmarking purposes.

               This option sets the Xdmx server's  default  font  path.   This
               option  can be specified multiple times to accommodate multiple
               font paths.  See the FONT PATHS section below for  very  impor-
               tant information regarding setting the default font path.

       -configfile filename
               Specify  the configuration file that should be read.  Note that
               if the -display command-line option is used, then the  configu-
               ration file will be ignored.

       -config name
               Specify a configuration to use.  The name will be the name fol-
               lowing the virtual keyword in the configuration file.

       -stat interval screens
               This option enables the display of performance statistics.  The
               interval  is  in seconds.  The screens is a count of the number
               of back-end screens for which data is  printed  each  interval.
               Specifying 0 for screens will display data for all screens.

               For  each  screen,  the  following  information is printed: the
               screen number, an absolute count of the number of XSync() calls
               made  (SyncCount),  the rate of these calls during the previous
               interval (Sync/s), the average round-trip  time  (in  microsec-
               onds) of the last 10 XSync() calls (avSync), the maximum round-
               trip  time  (in  microseconds)  of  the  last  10  XSync  calls
               (mxSync),  the  average  number  of  XSync() requests that were
               pending but not yet processed for each of the last 10 processed
               XSync() calls, the maximum number of XSync() requests that were
               pending but not yet processed for each of the last 10 processed
               XSync()  calls, and a histogram showing the distribution of the
               times of all of the XSync() calls that  were  made  during  the
               previous interval.

               (The  length  of the moving average and the number and value of
               histogram bins are configurable at compile time  in  the  dmxs-
               tat.h header file.)

       -syncbatch interval
               This  option  sets  the  interval  in  milliseconds for XSync()
               batching.  An interval less than or equal  to  0  will  disable
               XSync() batching.  The default interval is 100 ms.

               This  option  disables  the  offscreen optimization.  Since the
               lazy window creation optimization requires the offscreen  opti-
               mization  to be enabled, this option will also disable the lazy
               window creation optimization.

               This option disables the lazy window creation optimization.

               This option disables the primitive subdivision optimization.

       -noxkb  Disable use of the XKB extension  for  communication  with  the
               back  end  displays.   (Combine  with -kb to disable all use of

       -depth int
               This option sets the root window's default depth.  When  choos-
               ing  a  default  visual  from those available on the back-end X
               server, the first visual with that matches the depth  specified
               is used.

               This  option  can be combined with the -cc option, which speci-
               fies the default color visual class, to force the use of a spe-
               cific depth and color class for the root window.

               This option disables the RENDER extension.

               This  option  disables  GLX proxy -- the build-in GLX extension
               implementation that is DMX aware.

               This option disables the swap group and swap barrier extensions
               in GLX proxy.

               This  option  enables synchronization after a swap buffers call
               by waiting until all X protocol has  been  processed.   When  a
               client  issues  a  glXSwapBuffers  request,  Xdmx  relays  that
               request to each back-end  X  server,  and  those  requests  are
               buffered  along  with all other protocol requests.  However, in
               systems that have large network  buffers,  this  buffering  can
               lead to the set of back-end X servers handling the swap buffers
               request asynchronously.  With this option, an  XSync()  request
               is issued to each back-end X server after sending the swap buf-
               fers request.  The XSync() requests  will  flush  all  buffered
               protocol  (including  the swap buffers requests) and wait until
               the back-end X servers have  processed  those  requests  before
               continuing.   This  option  does not wait until all GL commands
               have been processed so there might be  previously  issued  com-
               mands  that  are  still being processed in the GL pipe when the
               XSync() request returns.  See the -glxfinishswap  option  below
               if Xdmx should wait until the GL commands have been processed.

               This  option  enables synchronization after a swap buffers call
               by waiting until all GL commands have been  completed.   It  is
               similar  to  the -glxsyncswap option above; however, instead of
               issuing an XSync(), it issues  a  glFinish()  request  to  each
               back-end X server after sending the swap buffers requests.  The
               glFinish() request will flush all buffered  protocol  requests,
               process  both  X and GL requests, and wait until all previously
               called GL commands are complete before returning.

               This option ignores font paths that are not  available  on  all
               back-end  servers  by  removing  the  bad font path(s) from the
               default font path list.  If no valid font paths are left  after
               removing  the  bad paths, an error to that effect is printed in
               the log.

               This  option  enables  the  dynamic  addition  and  removal  of
               screens,  which is disabled by default.  Note that GLXProxy and
               Render do not yet  support  dynamic  addition  and  removal  of
               screens, and must be disabled via the -noglxproxy and -norender
               command line options described above.

       -param  This option specifies parameters on  the  command  line.   Cur-
               rently,  only  parameters  dealing with XKEYBOARD configuration
               are supported.  These parameters apply only to  the  core  key-
               board.   Parameter  values  are installation-dependent.  Please
               see /usr/share/X11/xkb or  a  similar  directory  for  complete

                       Defaults to "base".  Other values may include "sgi" and

                       Defaults to "pc105".   When  used  with  "base"  rules,
                       other values may include "pc102", "pc104", "microsoft",
                       and many others.  When used  with  "sun"  rules,  other
                       values may include "type4" and "type5".

                       Defaults to "us".  Other country codes and "dvorak" are
                       usually available.

                       Defaults to "".

                       Defaults to "".

       The following words and tokens are reserved:
              virtual display wall option param { } ; #

       Comments start with a # mark and extend to the end of the  line.   They
       may  appear anywhere.  If a configuration file is read into xdmxconfig,
       the comments in that file will be preserved, but will not be editable.

       The grammar is as follows:
              virtual-list ::= [ virtual-list ] | virtual

              virtual ::= virtual [ name ] [ dim ] { dw-list }

              dw-list ::= [ dw-list ] | dw

              dw ::= display | wall | option

              display ::= display name [ geometry ] [ / geometry ] [ origin  ]

              wall ::= wall [ dim ] [ dim ] name-list ;

              option ::= option name-list ;

              param ::= param name-list ;

              param ::= param { param-list }

              param-list ::= [ param-list ] | name-list ;

              name-list ::= [ name-list ] | name

              name ::= string | double-quoted-string

              dim ::= integer x integer

              geometry ::= [ integer x integer ] [ signed-integer signed-inte-
              ger ]

              origin ::= @ integer x integer

       The name following virtual is used as an identifier for the  configura-
       tion,  and may be passed to Xdmx using the -config command line option.
       The name of a display should be standard X display  name,  although  no
       checking is performed (e.g., "machine:0").

       For  names,  double  quotes are optional unless the name is reserved or
       contains spaces.

       The first dimension following wall is the dimension for  tiling  (e.g.,
       2x4  or  4x4).  The second dimension following wall is the dimension of
       each display in the wall (e.g., 1280x1024).

       The first geometry following display is the geometry of the screen win-
       dow  on  the backend server.  The second geometry, which is always pre-
       ceeded by a slash, is the geometry of the root window.  By default, the
       root window has the same geometry as the screen window.

       The  option line can be used to specify any command-line options (e.g.,
       -input).  (It cannot be used to specify the name of the front-end  dis-
       play.)   The option line is processed once at server startup, just line
       command line options.  This behavior may be unexpected.

       Two displays being used for a desktop may be specified in  any  of  the
       following formats:
              virtual example0 {
                  display d0:0 1280x1024 @0x0;
                  display d1:0 1280x1024 @1280x0;

              virtual example1 {
                  display d0:0 1280x1024;
                  display d1:0 @1280x0;

              virtual example2 {
                  display "d0:0";
                  display "d1:0" @1280x0;

              virtual example3 { wall 2x1 d0:0 d1:0; }
       A  4x4  wall  of 16 total displays could be specified as follows (if no
       tiling dimension is specified, an approximate square is used):
              virtual example4 {
                  wall d0:0 d1:0 d2:0 d3:0
                       d4:0 d5:0 d6:0 d7:0
                       d8:0 d9:0 da:0 db:0
                       dc:0 dd:0 de:0 df:0;

       The font path used by the Xdmx front-end server will be  propagated  to
       each  back-end  server,which  requires  that  each back-end server have
       access to the exact same font paths as the front-end server.  This  can
       be  most easily handled by either using a font server (e.g., xfs) or by
       remotely mounting the font paths on each back-end server, and then set-
       ting  the  Xdmx server's default font path with the -I "-fontpath" com-
       mand line option described above.

       For example, if you specify a font  path  with  the  following  command
              Xdmx  :1  -display  d0:0  -fontpath  /usr/fonts/75dpi/ -fontpath
              /usr/fonts/Type1/ +xinerama
       Then, /usr/fonts/75dpi/ and /usr/fonts/Type1/ must be valid font  paths
       on  the  Xdmx server and all back-end server, which is d0 in this exam-

       Font servers can also be specified  with  the  -fontpath  option.   For
       example, let's assume that a properly configured font server is running
       on host d0.  Then, the following command line
              Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100  +xin-
       will  initialize  the  front-end  Xdmx  server and each of the back-end
       servers to use the font server on d0.

       Some fonts might not be supported by either the front-end or the  back-
       end  servers.   For  example,  let's  assume  the front-end Xdmx server
       includes support Type1 fonts, but one of the back-end servers does not.
       Let's  also  assume  that the default font path for Xdmx includes Type1
       fonts in its font path.  Then, when Xdmx initializes the  default  font
       path  to load the default font, the font path that includes Type1 fonts
       (along with the other default font paths that  are  used  by  the  Xdmx
       server)  is sent to the back-end server that cannot handle Type1 fonts.
       That back-end server then rejects the font path and sends an error back
       to  the  Xdmx  server.   Xdmx  then  prints  an error message and exits
       because it failed to set the default font path and was unable load  the
       default font.

       To  fix  this  error,  the offending font path must be removed from the
       default font path by using a different -fontpath command line option.

       The -fontpath option can also be added to  the  configuration  file  as
       described above.

       The back-end machines are d0 and d1, core input is from the pointer and
       keyboard attached to d0, clients will refer to :1 when opening windows:
              Xdmx :1 -display d0:0 -display d1:0 +xinerama

       As above, except with core input from d1:
              Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama

       As above, except with core input from a console  window  on  the  local
              Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama

       As above, except with core input from the local keyboard and mouse:
              Xdmx  :1  -display d0:0 -display d1:0 -input local,kbd,ps2 +xin-
       Note that local input can be used under Linux while another  X  session
       is  running  on  :0 (assuming the user can access the Linux console tty
       and mouse devices): a new (blank) VC will be used for keyboard input on
       the  local  machine  and  the Ctrl-Alt-F* sequence will be available to
       change to another VC (possibly back to another X session running on the
       local  machine).   Using Ctrl-Alt-Backspace on the blank VC will termi-
       nate the Xdmx session and return to the original VC.

       This example uses the configuration file shown in the previous section:
              Xdmx :1 -input :0 +xinerama -configfile filename  -config  exam-
       With this configuration file line:
              option -input :0 +xinerama;
       the command line can be shortened to:
              Xdmx :1 -configfile filename -config example2

       The  USB  device  drivers  use  the  devices  called /dev/input/event0,
       /dev/input/event1, etc.  under Linux.  These devices are  driven  using
       the  evdev Linux kernel module, which is part of the hid suite.  Please
       note that if you load the mousedev or kbddev Linux kernel modules, then
       USB devices will appear as core Linux input devices and you will not be
       able to select between using the device only as an Xdmx core device  or
       an  Xdmx XInput extension device.  Further, you may be unable to unload
       the mousedev Linux kernel  module  if  XFree86  is  configured  to  use
       /dev/input/mice  as  an  input device (this is quite helpful for laptop
       users and is set up by default  under  some  Linux  distributions,  but
       should be changed if USB devices are to be used with Xdmx).

       The  USB  device drivers search through the Linux devices for the first
       mouse, keyboard, or non-mouse-non-keyboard Linux device  and  use  that

       If  Xdmx was invoked with -xkb or was not compiled to use the XKEYBOARD
       extension, then a keyboard on a backend or console will be  initialized
       using the map that the host X server provides.

       If  the XKEYBOARD extension is used for both Xdmx and the host X server
       for the keyboard (i.e., the backend or console X server), then the type
       of  the  keyboard  will be obtained from the host X server and the key-
       board under Xdmx will be initialized with that information.  Otherwise,
       the  default  type of keyboard will be initialized.  In both cases, the
       map from the host X server will not be used.  This means that different
       initial  behavior  may be noted with and without XKEYBOARD.  Consistent
       and expected results will be  obtained  by  running  XKEYBOARD  on  all
       servers  and by avoiding the use of xmodmap on the backend or console X
       servers prior to starting Xdmx.

       If -xkbmap is specified on the Xdmx command line, then  that  map  will
       currently be used for all keyboards.

       X  was  not designed to support multiple core keyboards.  However, Xdmx
       provides some support for multiple core keyboards.  Best  results  will
       be  obtained if all of the keyboards are of the same type and are using
       the same keyboard map.  Because the X server passes raw key code infor-
       mation  to  the  X client, key symbols for keyboards with different key
       maps would be different if the key code  for  each  keyboard  was  sent
       without  translation  to  the  client.  Therefore, Xdmx will attempt to
       translate the key code from a core keyboard to the key code for the key
       with  the  same  key symbol of the first core keyboard that was loaded.
       If the key symbol appears in both maps, the results will  be  expected.
       Otherwise,  the  second core keyboard will return a NoSymbol key symbol
       for some keys that would have been translated if it was the first  core

       See attributes(7) for descriptions of the following attributes:

       |Availability   | x11/server/xdmx  |
       |Stability      | Volatile         |
       DMX(3),  X(7),  Xserver(1),  xdmxconfig(1),  vdltodmx(1),  xfs(1), xkb-
       comp(1), xkeyboard-config(7)

       Kevin E. Martin <kem@redhat.com>, David H.  Dawes  <dawes@xfree86.org>,
       and Rickard E. (Rik) Faith <faith@redhat.com>.

       Portions   of   Xdmx  are  based  on  code  from  The  XFree86  Project
       (http://www.xfree86.org) and X.Org (http://www.x.org).

       This    software    was    built    from    source     available     at
       https://github.com/oracle/solaris-userland.    The  original  community
       source   was   downloaded   from    https://www.x.org/releases/individ-

       Further information about this software can be found on the open source
       community website at https://www.x.org.

X Version 11                  xorg-server 1.19.5                       Xdmx(1)