Xdmx man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

Xdmx(1)								       Xdmx(1)

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 pro‐
       tocol, 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 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:

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

	       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 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
		   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 key‐
		   codes,  symbols,   and   geometries	 can   be   found   in
		   /usr/local/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.

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

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

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

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

       -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.	  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/local/share/X11/xkb or a similar  directory  for  com‐
	       plete information.

	       XkbRules
		       Defaults to "base".  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-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.

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 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
       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 exam‐
       ple.

       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‐
	      erama
       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 +xin‐
	      erama
       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‐
	      ple2
       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 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.

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

SEE ALSO
       DMX(3),	X(7),  Xserver(1),  xdmxconfig(1),  vdltodmx(1),  xfs(1), xkb‐
       comp(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).

X Version 11		      xorg-server 1.17.4		       Xdmx(1)
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net