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
   protocol, 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
           single 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
               keyboard 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
               keyboard 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-
               separated 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
               extension 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
               display-name  refers to a display that is used as a backend
               display, then a console  window  will  be  opened  on  that
               display  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
               outlines  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
               keycodes,  symbols,  and  geometries  can   be   found   in
               /usr/share/X11/xkb.    Use   of   keycodes,   symbols   and
               geometries for XKB configuration is deprecated in favor  of
               the  rules,  layout,  model,  variant  and options settings
               available 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
           important 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
           configuration file will be ignored.

   -config name
           Specify  a  configuration  to  use.   The name will be the name
           following 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
           microseconds)  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
           dmxstat.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
           optimization  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
           choosing  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
           specifies the default color visual class, to force the use of a
           specific 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
           buffers 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
           commands 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.
           Currently, only parameters dealing with XKEYBOARD configuration
           are  supported.   These  parameters  apply  only  to  the  core
           keyboard.  Parameter values are installation-dependent.  Please
           see /usr/share/X11/xkb or  a  similar  directory  for  complete

                   Defaults  to  "evdev".   Other values may include "sgi"
                   and "sun".

                   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-
          integer ]

          origin ::= @ integer x integer

   The  name  following  virtual  is  used  as  an  identifier   for   the
   configuration, 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
   window  on  the  backend  server.  The second geometry, which is always
   preceeded 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
   display.)   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
   setting  the  Xdmx  server's  default font path with the -I "-fontpath"
   command 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

   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
   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
   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
   terminate 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
   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
   keyboard  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
   information  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


   DMX(3),   X(7),   Xserver(1),   xdmxconfig(1),   vdltodmx(1),   xfs(1),
   xkbcomp(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).


Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.

Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.

Free Software

Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.

Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.

Free Books

The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.

Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.


Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.

Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.