Provided by: xdmx_1.11.4-0ubuntu10_amd64 bug

NAME

       Xdmx - Distributed Multi-head X server

SYNOPSIS

       Xdmx [:display] [option ...]

DESCRIPTION

       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.

OPTIONS

       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:

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

               local
                   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.

               display-name
                   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 input.)

                   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.

       -shadowfb
               This option turns on (legacy) support for the shadow frame buffer.

       -noshadowfb
               This  option  turns  off  (legacy) support for the shadow frame buffer.  Note that
               this option has been deprecated and will be removed in the next release.

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

       -fontpath
               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.

       -nooffscreenopt
               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.

       -nowindowopt
               This option disables the lazy window creation optimization.

       -nosubdivprims
               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 XKB.)

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

       -norender
               This option disables the RENDER extension.

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

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

       -glxsyncswap
               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.

       -glxfinishswap
               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.

       -ignorebadfontpaths
               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.

       -addremovescreens
               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 information.

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

               XkbModel
                       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".

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

               XkbVariant
                       Defaults to "".

               XkbOptions
                       Defaults to "".

CONFIGURATION FILE GRAMMAR

       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.

CONFIGURATION FILE EXAMPLES

       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;
              }

FONT PATHS

       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 line:
              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 example.

       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 +xinerama
       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.

COMMAND-LINE EXAMPLES

       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 display:
              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 +xinerama
       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 example2
       With this configuration file line:
              option -input :0 +xinerama;
       the command line can be shortened to:
              Xdmx :1 -configfile filename -config example2

USING THE USB DEVICE DRIVERS

       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 device.

KEYBOARD INITIALIZATION

       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.

MULTIPLE CORE 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 keyboard.

SEE ALSO

       DMX(3), X(7),  Xserver(1),  xdmxconfig(1),  vdltodmx(1),  xfs(1),  xkbcomp(1),  xkeyboard-
       config(7)

AUTHORS

       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).