Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
XF86Config(5)		      File Formats Manual		 XF86Config(5)

NAME
       XF86Config - Configuration File for XFree86

INTRODUCTION
       XFree86	supports several mechanisms for	supplying/obtaining configura-
       tion and	run-time parameters: command line options,  environment	 vari-
       ables,  the XF86Config configuration file, auto-detection, and fallback
       defaults.  When the same	information is supplied	in more	than one  way,
       the  highest  precedence	 mechanism is used.  The list of mechanisms is
       ordered from highest precedence to lowest.  Note	that not  all  parame-
       ters  can  be supplied via all methods.	The available command line op-
       tions and environment variables (and some defaults)  are	 described  in
       the  Xserver(1)	and  XFree86(1)	manual pages.  Most configuration file
       parameters, with	their defaults,	are described below.  Driver and  mod-
       ule  specific  configuration  parameters	 are described in the relevant
       driver or module	manual page.

       Starting	with version 4.4, XFree86 has support for generating a	usable
       configuration  at  run-time  when  no XF86Config	file is	provided.  The
       initial version of this automatic configuration support is targeted  at
       the  most popular hardware and software platforms supported by XFree86.
       Some details about how this works can be	found in  the  XFree86(1)  and
       getconfig(1) manual pages.

DESCRIPTION
       XFree86	uses  a	 configuration	file called XF86Config for its initial
       setup.  This configuration file is searched for in the following	places
       when the	server is started as a normal user:

	   /etc/X11/<cmdline>
	   /usr/X11R6/etc/X11/<cmdline>
	   /etc/X11/$XF86CONFIG
	   /usr/X11R6/etc/X11/$XF86CONFIG
	   /etc/X11/XF86Config-4
	   /etc/X11/XF86Config
	   /etc/XF86Config
	   /usr/X11R6/etc/X11/XF86Config.<hostname>
	   /usr/X11R6/etc/X11/XF86Config-4
	   /usr/X11R6/etc/X11/XF86Config
	   /usr/X11R6/lib/X11/XF86Config.<hostname>
	   /usr/X11R6/lib/X11/XF86Config-4
	   /usr/X11R6/lib/X11/XF86Config

       where <cmdline> is a relative path (with	no ".."	components)  specified
       with  the  -xf86config command line option, $XF86CONFIG is the relative
       path (with no ".." components) specified	by that	environment  variable,
       and <hostname> is the machine's hostname	as reported by gethostname(3).

       When  the XFree86 server	is started by the "root" user, the config file
       search locations	are as follows:

	   <cmdline>
	   /etc/X11/<cmdline>
	   /usr/X11R6/etc/X11/<cmdline>
	   $XF86CONFIG
	   /etc/X11/$XF86CONFIG
	   /usr/X11R6/etc/X11/$XF86CONFIG
	   $HOME/XF86Config
	   /etc/X11/XF86Config-4
	   /etc/X11/XF86Config
	   /etc/XF86Config
	   /usr/X11R6/etc/X11/XF86Config.<hostname>
	   /usr/X11R6/etc/X11/XF86Config-4
	   /usr/X11R6/etc/X11/XF86Config
	   /usr/X11R6/lib/X11/XF86Config.<hostname>
	   /usr/X11R6/lib/X11/XF86Config-4
	   /usr/X11R6/lib/X11/XF86Config

       where <cmdline> is the path specified with the -xf86config command line
       option (which may be absolute or	relative),  $XF86CONFIG	 is  the  path
       specified by that environment variable (absolute	or relative), $HOME is
       the  path  specified by that environment	variable (usually the home di-
       rectory), and <hostname>	is the machine's hostname as reported by geth-
       ostname(3).

       The XF86Config file is composed of a number of sections	which  may  be
       present in any order.  Each section has the form:

	   Section  "SectionName"
	       SectionEntry
	       ...
	   EndSection

       The section names are:

	   Files	  File pathnames
	   ServerFlags	  Server flags
	   Module	  Dynamic module loading
	   InputDevice	  Input	device description
	   Device	  Graphics device description
	   VideoAdaptor	  Xv video adaptor description
	   Monitor	  Monitor description
	   Modes	  Video	modes descriptions
	   Screen	  Screen configuration
	   ServerLayout	  Overall layout
	   DRI		  DRI-specific configuration
	   Vendor	  Vendor-specific configuration

       The  following obsolete section names are still recognised for compati-
       bility purposes.	 In new	config files, the InputDevice  section	should
       be used instead.

	   Keyboard	  Keyboard configuration
	   Pointer	  Pointer/mouse	configuration

       The old XInput section is no longer recognised.

       The ServerLayout	sections are at	the highest level.  They bind together
       the input and output devices that will be used in a session.  The input
       devices are described in	the InputDevice	sections.  Output devices usu-
       ally  consist  of  multiple  independent	components (e.g., and graphics
       board and a monitor).  These multiple components	are bound together  in
       the Screen sections, and	it is these that are referenced	by the Server-
       Layout  section.	  Each	Screen section binds together a	graphics board
       and a monitor.  The graphics boards are described in  the  Device  sec-
       tions, and the monitors are described in	the Monitor sections.

       Config  file  keywords are case-insensitive, and	"_" characters are ig-
       nored.  Most strings (including Option names)  are  also	 case-insensi-
       tive, and insensitive to	white space and	"_" characters.

       Each  config  file  entry  usually  takes up a single line in the file.
       They consist of a keyword, which	is possibly followed by	 one  or  more
       arguments,  with	the number and types of	the arguments depending	on the
       keyword.	 The argument types are:

	   Integer     an integer number in decimal, hex or octal
	   Real	       a floating point	number
	   String      a string	enclosed in double quote marks (")

       Note: hex integer values	must be	prefixed with "0x", and	 octal	values
       with "0".

       A  special  keyword called Option may be	used to	provide	free-form data
       to various components of	the server.  The Option	keyword	 takes	either
       one or two string arguments.  The first is the option name, and the op-
       tional  second argument is the option value.  Some commonly used	option
       value types include:

	   Integer     an integer number in decimal, hex or octal
	   Real	       a floating point	number
	   String      a sequence of characters
	   Boolean     a boolean value (see below)
	   Frequency   a frequency value (see below)

       Note that all Option values, not	just  strings,	must  be  enclosed  in
       quotes.

       Boolean	options	 may optionally	have a value specified.	 When no value
       is specified, the option's value	is TRUE.  The following	boolean	option
       values are recognised as	TRUE:

	   1, on, true,	yes

       and the following boolean option	values are recognised as FALSE:

	   0, off, false, no

       If an option name is prefixed with  "No",  then	the  option  value  is
       negated.

       Example:	the following option entries are equivalent:

	   Option "Accel"   "Off"
	   Option "NoAccel"
	   Option "NoAccel" "On"
	   Option "Accel"   "false"
	   Option "Accel"   "no"

       Frequency  option  values  consist  of a	real number that is optionally
       followed	by one of the following	frequency units:

	   Hz, k, kHz, M, MHz

       When the	unit name is omitted, the correct  units  will	be  determined
       from  the  value	 and  the expectations of the appropriate range	of the
       value.  It is recommended that the units	always be specified when using
       frequency option	values to avoid	any errors in determining the value.

FILES SECTION
       The Files section is used to specify some path names  required  by  the
       server.	Some of	these paths can	also be	set from the command line (see
       Xserver(1)  and	XFree86(1)).   The  command line settings override the
       values specified	in the config file.  The Files section is optional, as
       are all of the entries that may appear in it.

       The entries that	can appear in this section are:

       FontPath	"path"
	      sets the search path for fonts.  This path is a comma  separated
	      list of font path	elements which the XFree86 server searches for
	      font databases.  Multiple	FontPath entries may be	specified, and
	      they  will  be concatenated to build up the fontpath used	by the
	      server.  Font path elements may  be  either  absolute  directory
	      paths,  or  a  font  server identifier.  Font server identifiers
	      have the form:

		  <trans>/<hostname>:<port-number>

	      where <trans> is the transport type to use  to  connect  to  the
	      font  server  (e.g.,  unix  for UNIX-domain sockets or tcp for a
	      TCP/IP connection), <hostname> is	the hostname  of  the  machine
	      running  the  font  server, and <port-number> is the port	number
	      that the font server is listening	on (usually 7100).

	      When this	entry is not specified in the config file, the	server
	      falls  back to the compiled-in default font path,	which contains
	      the following font path elements:

		  /usr/X11R6/lib/X11/fonts/misc/
		  /usr/X11R6/lib/X11/fonts/Speedo/
		  /usr/X11R6/lib/X11/fonts/Type1/
		  /usr/X11R6/lib/X11/fonts/CID/
		  /usr/X11R6/lib/X11/fonts/75dpi/
		  /usr/X11R6/lib/X11/fonts/100dpi/

	      The recommended font path	contains the following font path  ele-
	      ments:

		  /usr/X11R6/lib/X11/fonts/local/
		  /usr/X11R6/lib/X11/fonts/misc/
		  /usr/X11R6/lib/X11/fonts/75dpi/:unscaled
		  /usr/X11R6/lib/X11/fonts/100dpi/:unscaled
		  /usr/X11R6/lib/X11/fonts/Type1/
		  /usr/X11R6/lib/X11/fonts/CID/
		  /usr/X11R6/lib/X11/fonts/Speedo/
		  /usr/X11R6/lib/X11/fonts/75dpi/
		  /usr/X11R6/lib/X11/fonts/100dpi/

	      Font path	elements that are found	to be invalid are removed from
	      the font path when the server starts up.

       RGBPath "path"
	      sets  the	path name for the RGB color database.  When this entry
	      is not specified in the config file, the server  falls  back  to
	      the compiled-in default RGB path,	which is:

		  /usr/X11R6/lib/X11/rgb

       Note that an implicit .txt is added to this path	if the server was com-
       piled to	use text rather	than binary format RGB color databases.

       ModulePath "path"
	      sets  the	search path for	loadable XFree86 server	modules.  This
	      path is a	comma separated	list of	directories which the  XFree86
	      server searches for loadable modules loading in the order	speci-
	      fied.   Multiple	ModulePath  entries may	be specified, and they
	      will be concatenated to build the	module search path used	by the
	      server.

SERVERFLAGS SECTION
       The ServerFlags section is used to specify some global  XFree86	server
       options.	  All of the entries in	this section are Options, although for
       compatibility purposes some of the old style entries are	 still	recog-
       nised.  Those old style entries are not documented here,	and using them
       is  discouraged.	  The  ServerFlags section is optional,	as are the en-
       tries that may be specified in it.

       Options specified in this section (with the exception of	the  "Default-
       ServerLayout" Option) may be overridden by Options specified in the ac-
       tive  ServerLayout  section.  Options with command line equivalents are
       overridden when their command line equivalent  is  used.	  The  options
       recognised by this section are:

       Option "DefaultServerLayout"  "layout-id"
	      This  specifies  the  default ServerLayout section to use	in the
	      absence of the -layout command line option.

       Option "NoTrapSignals"  "boolean"
	      This prevents the	XFree86	server from trapping a range of	 unex-
	      pected  fatal signals and	exiting	cleanly.  Instead, the XFree86
	      server will die and drop core where the fault occurred.  The de-
	      fault behaviour is for the XFree86 server	to exit	 cleanly,  but
	      still  drop  a core file.	 In general you	never want to use this
	      option unless you	are debugging an XFree86  server  problem  and
	      know how to deal with the	consequences.

       Option "DontVTSwitch"  "boolean"
	      This  disallows  the  use	 of the	Ctrl+Alt+Fn sequence (where Fn
	      refers to	one of the numbered function keys).  That sequence  is
	      normally used to switch to another "virtual terminal" on operat-
	      ing  systems  that  have	this feature.  When this option	is en-
	      abled, that key sequence has no special meaning and is passed to
	      clients.	Default: off.

       Option "DontZap"	 "boolean"
	      This disallows the use of	the Ctrl+Alt+Backspace sequence.  That
	      sequence is normally used	to terminate the XFree86 server.  When
	      this option is enabled, that key sequence	has no special meaning
	      and is passed to clients.	 Default: off.

       Option "DontZoom"  "boolean"
	      This  disallows  the  use	 of   the   Ctrl+Alt+Keypad-Plus   and
	      Ctrl+Alt+Keypad-Minus  sequences.	 These sequences allows	you to
	      switch between video modes.  When	this option is enabled,	 those
	      key sequences have no special meaning and	are passed to clients.
	      Default: off.

       Option "DisableVidModeExtension"	 "boolean"
	      This  disables  the  parts  of the VidMode extension used	by the
	      xvidtune client that can be used to change the video modes.  De-
	      fault: the VidMode extension is enabled.

       Option "AllowNonLocalXvidtune"  "boolean"
	      This allows the xvidtune client (and other clients that use  the
	      VidMode extension) to connect from another host.	Default: off.

       Option "DisableModInDev"	 "boolean"
	      This  disables  the parts	of the XFree86-Misc extension that can
	      be used to modify	the input device  settings  dynamically.   De-
	      fault: that functionality	is enabled.

       Option "AllowNonLocalModInDev"  "boolean"
	      This  allows  a  client  to connect from another host and	change
	      keyboard and mouse settings in  the  running  server.   Default:
	      off.

       Option "AllowMouseOpenFail"  "boolean"
	      This  allows  the	 server	 to  start up even if the mouse	device
	      can't be opened/initialised.  Default: false.

       Option "VTInit"	"command"
	      Runs command after the VT	used by	the server  has	 been  opened.
	      The  command  string  is passed to "/bin/sh -c", and is run with
	      the real user's id with stdin and	stdout set  to	the  VT.   The
	      purpose of this option is	to allow system	dependent VT initiali-
	      sation commands to be run.  This option should rarely be needed.
	      Default: not set.

       Option "VTSysReq"  "boolean"
	      enables  the  SYSV-style VT switch sequence for non-SYSV systems
	      which support VT switching.  This	sequence is Alt-SysRq followed
	      by a function key	(Fn).  This prevents the XFree86 server	 trap-
	      ping  the	 keys  used  for the default VT	switch sequence, which
	      means that clients can access them.  Default: off.

       Option "XkbDisable" "boolean"
	      disable/enable the XKEYBOARD extension.  The  -kb	 command  line
	      option  overrides	 this config file option.  Default: XKB	is en-
	      abled.

       Option "BlankTime"  "time"
	      sets the inactivity  timeout  for	 the  blanking	phase  of  the
	      screensaver.   time  is  in  minutes.  This is equivalent	to the
	      XFree86 server's `-s' flag, and the value	can be changed at run-
	      time with	xset(1).  Default: 10 minutes.

       Option "StandbyTime"  "time"
	      sets the inactivity timeout for  the  "standby"  phase  of  DPMS
	      mode.   time is in minutes, and the value	can be changed at run-
	      time with	xset(1).  Default: 20 minutes.	This is	only  suitable
	      for  VESA	 DPMS compatible monitors, and may not be supported by
	      all video	drivers.  It is	only enabled for screens that have the
	      "DPMS" option set	(see the MONITOR section below).

       Option "SuspendTime"  "time"
	      sets the inactivity timeout for  the  "suspend"  phase  of  DPMS
	      mode.   time is in minutes, and the value	can be changed at run-
	      time with	xset(1).  Default: 30 minutes.	This is	only  suitable
	      for  VESA	 DPMS compatible monitors, and may not be supported by
	      all video	drivers.  It is	only enabled for screens that have the
	      "DPMS" option set	(see the MONITOR section below).

       Option "OffTime"	 "time"
	      sets the inactivity timeout for the "off"	phase  of  DPMS	 mode.
	      time  is	in  minutes,  and the value can	be changed at run-time
	      with xset(1).  Default: 40 minutes.  This	is only	 suitable  for
	      VESA  DPMS  compatible monitors, and may not be supported	by all
	      video drivers.  It is only enabled for  screens  that  have  the
	      "DPMS" option set	(see the MONITOR section below).

       Option "Pixmap"	"bpp"
	      This sets	the pixmap format to use for depth 24.	Allowed	values
	      for  bpp	are  24	and 32.	 Default: 32 unless driver constraints
	      don't allow this (which is rare).	 Note: some clients don't  be-
	      have well	when this value	is set to 24.

       Option "PC98"  "boolean"
	      Specify  that  the  machine  is  a Japanese PC-98	machine.  This
	      should not be enabled for	anything other than the	 Japanese-spe-
	      cific PC-98 architecture.	 Default: auto-detected.

       Option "NoPM"  "boolean"
	      Disables something to do with power management events.  Default:
	      PM enabled on platforms that support it.

       Option "Xinerama"  "boolean"
	      enable or	disable	XINERAMA extension. Default is disabled.

       Option "AllowDeactivateGrabs" "boolean"
	      This  option  enables  the use of	the Ctrl+Alt+Keypad-Divide key
	      sequence to deactivate any active	keyboard and mouse grabs.  De-
	      fault: off.

       Option "AllowClosedownGrabs" "boolean"
	      This option enables the use of the Ctrl+Alt+Keypad-Multiply  key
	      sequence	to  kill clients with an active	keyboard or mouse grab
	      as well as killing any application  that	may  have  locked  the
	      server,  normally	 using	the XGrabServer(3) Xlib	function.  De-
	      fault: off.
	      Note that	the options AllowDeactivateGrabs  and  AllowClosedown-
	      Grabs  will  allow  users	 to  remove  the  grab	used by	screen
	      saver/locker programs.  An API was written to such cases.	If you
	      enable this option, make sure your screen	 saver/locker  is  up-
	      dated.

       Option "HandleSpecialKeys" "when"
	      This option controls when	the server uses	the builtin handler to
	      process  special	key combinations (such as Ctrl+Alt+Backspace).
	      Normally the XKEYBOARD extension keymaps will  provide  mappings
	      for each of the special key combinations,	so the builtin handler
	      is  not  needed unless the XKEYBOARD extension is	disabled.  The
	      value of when can	be Always, Never, or WhenNeeded.  Default: Use
	      the builtin handler only if needed.  The server  will  scan  the
	      keymap  for a mapping to the Terminate action and, if found, use
	      XKEYBOARD	for processing actions,	otherwise the builtin  handler
	      will be used.

MODULE SECTION
       The  Module  section  is	 used  to specify which	XFree86	server modules
       should be loaded.  This section is ignored when the XFree86  server  is
       built  in  static  form.	  The types of modules normally	loaded in this
       section are XFree86 server extension modules, and font rasteriser  mod-
       ules.   Most  other module types	are loaded automatically when they are
       needed via other	mechanisms.  The Module	section	is  optional,  as  are
       all of the entries that may be specified	in it.

       Entries	in this	section	may be in two forms.   The first and most com-
       monly used form is an entry that	uses the Load  keyword,	 as  described
       here:

       Load  "modulename"
	      This  instructs the server to load the module called modulename.
	      The module name given should be the module's standard name,  not
	      the  module file name.  The standard name	is case-sensitive, and
	      does not include the "lib" prefix, or the	".a", ".o",  or	 ".so"
	      suffixes.

	      Example:	the Type 1 font	rasteriser can be loaded with the fol-
	      lowing entry:

		  Load "type1"

       The second form of entry	is a SubSection, with the subsection name  be-
       ing  the	 module	name, and the contents of the SubSection being Options
       that are	passed to the module when it is	loaded.

       Example:	the extmod module (which contains  a  miscellaneous  group  of
       server  extensions)  can	be loaded, with	the XFree86-DGA	extension dis-
       abled by	using the following entry:

	   SubSection "extmod"
	      Option  "omit XFree86-DGA"
	   EndSubSection

       Modules are searched for	in each	directory specified in the  ModulePath
       search path, and	in the drivers,	input, extensions, fonts, and internal
       subdirectories  of each of those	directories.  In addition to this, op-
       erating system specific subdirectories of all the  above	 are  searched
       first if	they exist.

       To  see	what  font and extension modules are available,	check the con-
       tents of	the following directories:

	   /usr/X11R6/lib/modules/fonts
	   /usr/X11R6/lib/modules/extensions

       The "bitmap" font modules is loaded automatically.  It  is  recommended
       that  at	 very  least  the  "extmod" extension module be	loaded.	 If it
       isn't some commonly used	server extensions (like	the  SHAPE  extension)
       will not	be available.

INPUTDEVICE SECTION
       The  config  file  may  have multiple InputDevice sections.  There will
       normally	be at least two: one for the core (primary) keyboard, and  one
       of the core pointer.  If	either of these	two is missing,	a default con-
       figuration  for	the  missing ones will be used.	 Currently the default
       configuration may not work as expected on all platforms.

       InputDevice sections have the following format:

	   Section "InputDevice"
	       Identifier "name"
	       Driver	  "inputdriver"
	       options
	       ...
	   EndSection

       The Identifier and Driver entries are required in all InputDevice  sec-
       tions.  All other entries are optional.

       The  Identifier	entry specifies	the unique name	for this input device.
       The Driver entry	specifies the name of the driver to use	for this input
       device.	When using the loadable	server,	the input driver  module  "in-
       putdriver"  will	be loaded for each active InputDevice section.	An In-
       putDevice section is considered active if it is referenced by an	active
       ServerLayout section, if	it is referenced by the	-keyboard or  -pointer
       command	line  options,	or  if	it  is selected	implicitly as the core
       pointer or keyboard device in the absence of such explicit  references.
       The most	commonly used input drivers are	"keyboard" and "mouse".

       In  the absence of an explicitly	specified core input device, the first
       InputDevice marked as CorePointer (or CoreKeyboard) is used.  If	 there
       is  no  match  there,  the  first InputDevice that uses the "mouse" (or
       "keyboard" or "kbd") driver is used.  The  final	 fallback  is  to  use
       built-in	default	configurations.

       InputDevice  sections  recognise	some driver-independent	Options, which
       are described here.  See	the individual input driver manual pages for a
       description of the device-specific options.

       Option "CorePointer"
	      When this	is set,	the input device  is  installed	 as  the  core
	      (primary)	 pointer  device.   There  must	 be  exactly  one core
	      pointer.	If this	option is not set here,	or in the ServerLayout
	      section, or from the -pointer  command  line  option,  then  the
	      first  input  device  that  is  capable  of being	used as	a core
	      pointer will be selected as the core pointer.   This  option  is
	      implicitly set when the obsolete Pointer section is used.

       Option "CoreKeyboard"
	      When  this  is  set,  the	input device is	to be installed	as the
	      core (primary) keyboard device.  There must be exactly one  core
	      keyboard.	  If  this option is not set here, in the ServerLayout
	      section, or from the -keyboard command  line  option,  then  the
	      first  input device that is capable of being used	as a core key-
	      board will be selected as	the core keyboard.  This option	is im-
	      plicitly set when	the obsolete Keyboard section is used.

       Option "AlwaysCore"  "boolean"

       Option "SendCoreEvents"	"boolean"
	      Both of these options are	equivalent, and	when enabled cause the
	      input device to always report core events.  This	can  be	 used,
	      for  example,  to	allow an additional pointer device to generate
	      core pointer events (like	moving the cursor, etc).

       Option "HistorySize"  "number"
	   Sets	the motion history size.  Default: 0.

       Option "SendDragEvents"	"boolean"
	      ???

DEVICE SECTION
       The config file may have	multiple Device	sections.  There  must	be  at
       least one, for the video	card being used.

       Device sections have the	following format:

	   Section "Device"
	       Identifier "name"
	       Driver	  "driver"
	       entries
	       ...
	   EndSection

       The  Identifier and Driver entries are required in all Device sections.
       All other entries are optional.

       The Identifier entry specifies the unique name for  this	 graphics  de-
       vice.   The  Driver  entry  specifies the name of the driver to use for
       this graphics device.  When using the loadable server, the driver  mod-
       ule  "driver"  will be loaded for each active Device section.  A	Device
       section is considered active if it is referenced	by  an	active	Screen
       section.

       Device  sections	recognise some driver-independent entries and Options,
       which are described here.  Not all drivers make use of these driver-in-
       dependent entries, and many of those that do don't require them	to  be
       specified because the information is auto-detected.  See	the individual
       graphics	 driver	 manual	 pages for further information about this, and
       for a description of the	device-specific	options.  Note	that  most  of
       the Options listed here (but not	the other entries) may be specified in
       the Screen section instead of here in the Device	section.

       BusID  "bus-id"
	      This  specifies  the  bus	 location  of  the graphics card.  For
	      PCI/AGP cards,  the  bus-id  string  has	the  form  PCI:bus:de-
	      vice:function (e.g., "PCI:1:0:0" might be	appropriate for	an AGP
	      card).  This field is usually optional in	single-head configura-
	      tions  when using	the primary graphics card.  In multi-head con-
	      figurations, or when using a secondary graphics card in  a  sin-
	      gle-head	configuration, this entry is mandatory.	 Its main pur-
	      pose is to make an unambiguous  connection  between  the	device
	      section  and  the	hardware it is representing.  This information
	      can usually be found by running  the  XFree86  server  with  the
	      -scanpci command line option.

       Screen  number
	      This option is mandatory for cards where a single	PCI entity can
	      drive more than one display (i.e., multiple CRTCs	sharing	a sin-
	      gle  graphics accelerator	and video memory).  One	Device section
	      is required for each head, and this parameter  determines	 which
	      head  each  of the Device	sections applies to.  The legal	values
	      of number	range from 0 to	one less  than	the  total  number  of
	      heads  per entity.  Most drivers require that the	primary	screen
	      (0) be present.

       Chipset	"chipset"
	      This usually optional entry specifies the	chipset	 used  on  the
	      graphics	board.	 In  most cases	this entry is not required be-
	      cause the	drivers	will  probe  the  hardware  to	determine  the
	      chipset type.  Don't specify it unless the driver-specific docu-
	      mentation	recommends that	you do.

       Ramdac  "ramdac-type"
	      This  optional  entry  specifies	the type of RAMDAC used	on the
	      graphics board.  This is only used by a few of the drivers,  and
	      in  most cases it	is not required	because	the drivers will probe
	      the hardware to determine	the RAMDAC type	where possible.	 Don't
	      specify it unless	the driver-specific  documentation  recommends
	      that you do.

       DacSpeed	 speed

       DacSpeed	 speed-8 speed-16 speed-24 speed-32
	      This  optional entry specifies the RAMDAC	speed rating (which is
	      usually printed on the RAMDAC chip).  The	speed is in MHz.  When
	      one value	is given, it applies to	all framebuffer	 pixel	sizes.
	      When  multiple  values  are  give, they apply to the framebuffer
	      pixel sizes 8, 16, 24 and	32 respectively.  This is not used  by
	      many drivers, and	only needs to be specified when	the speed rat-
	      ing  of  the  RAMDAC  is different from the defaults built in to
	      driver, or when the driver can't	auto-detect  the  correct  de-
	      faults.	Don't specify it unless	the driver-specific documenta-
	      tion recommends that you do.

       Clocks  clock ...
	      specifies	the pixel that are on your graphics board.  The	clocks
	      are in MHz, and may be specified as  a  floating	point  number.
	      The value	is stored internally to	the nearest kHz.  The ordering
	      of  the  clocks  is important.  It must match the	order in which
	      they are selected	on the graphics	board.	Multiple Clocks	 lines
	      may  be  specified,  and	each is	concatenated to	form the list.
	      Most drivers do not use this entry, and it is only required  for
	      some  older  boards with non-programmable	clocks.	 Don't specify
	      this entry unless	the driver-specific  documentation  explicitly
	      recommends that you do.

       ClockChip  "clockchip-type"
	      This  optional  entry  is	used to	specify	the clock chip type on
	      graphics boards which have a programmable	clock generator.  Only
	      a	few XFree86 drivers support programmable clock chips.  For de-
	      tails, see the appropriate driver	manual page.

       VideoRam	 mem
	      This optional entry specifies the	amount of video	 ram  that  is
	      installed	on the graphics	board. This is measured	in kBytes.  In
	      most  cases  this	 is  not  required  because the	XFree86	server
	      probes the graphics board	to determine this quantity.  The  dri-
	      ver-specific  documentation  should  indicate  when  it might be
	      needed.

       BiosBase	 baseaddress
	      This optional entry specifies the	base address of	the video BIOS
	      for the VGA board.  This address is normally auto-detected,  and
	      should  only  be	specified if the driver-specific documentation
	      recommends it.

       MemBase	baseaddress
	      This optional entry specifies  the  memory  base	address	 of  a
	      graphics board's linear frame buffer.  This entry	is not used by
	      many drivers, and	it should only be specified if the driver-spe-
	      cific documentation recommends it.

       IOBase  baseaddress
	      This  optional  entry specifies the IO base address.  This entry
	      is not used by many drivers, and it should only be specified  if
	      the driver-specific documentation	recommends it.

       ChipID  id
	      This  optional  entry  specifies a numerical ID representing the
	      chip type.  For PCI cards, it is usually the  device  ID.	  This
	      can be used to override the auto-detection, but that should only
	      be done when the driver-specific documentation recommends	it.

       ChipRev	rev
	      This  optional  entry  specifies the chip	revision number.  This
	      can be used to override the auto-detection, but that should only
	      be done when the driver-specific documentation recommends	it.

       TextClockFreq  freq
	      This optional entry specifies the	pixel clock frequency that  is
	      used  for	 the regular text mode.	 The frequency is specified in
	      MHz.  This is rarely used.

       Options
	      Option flags may be specified in the Device sections.  These in-
	      clude driver-specific options  and  driver-independent  options.
	      The  former  are described in the	driver-specific	documentation.
	      Some of the latter are described below in	the section about  the
	      Screen section, and they may also	be included here.

VIDEOADAPTOR SECTION
       Nobody wants to say how this works.  Maybe nobody knows ...

MONITOR	SECTION
       The  config file	may have multiple Monitor sections.  There should nor-
       mally be	at least one, for the monitor being used, but a	 default  con-
       figuration will be created when one isn't specified.

       Monitor sections	have the following format:

	   Section "Monitor"
	       Identifier "name"
	       entries
	       ...
	   EndSection

       The only	mandatory entry	in a Monitor section is	the Identifier entry.

       The  Identifier	entry specifies	the unique name	for this monitor.  The
       Monitor section provides	information about the  specifications  of  the
       monitor,	 monitor-specific  Options,  and  information  about the video
       modes to	use with the monitor.  Specifying video	modes is optional  be-
       cause  the server now has a built-in list of VESA standard modes.  When
       modes are specified explicitly in the Monitor section (with the	Modes,
       ModeLine, or UseModes keywords),	built-in modes with the	same names are
       not  included.  Built-in	modes with different names are,	however, still
       implicitly included.

       The entries that	may be used in Monitor sections	are described below.

       VendorName  "vendor"
	      This optional entry specifies the	monitor's manufacturer.

       ModelName  "model"
	      This optional entry specifies the	monitor's model.

       HorizSync  horizsync-range
	      gives the	range(s) of horizontal sync frequencies	 supported  by
	      the  monitor.   horizsync-range may be a comma separated list of
	      either discrete values or	ranges of values.  A range  of	values
	      is two values separated by a dash.  By default the values	are in
	      units  of	 kHz.  They may	be specified in	MHz or Hz if MHz or Hz
	      is added to the end of the line.	The data given here is used by
	      the XFree86 server to determine if video modes  are  within  the
	      specifications  of  the  monitor.	  This	information  should be
	      available	in the monitor's handbook.  If this entry is  omitted,
	      a	default	range of 28-33kHz is used.

       VertRefresh  vertrefresh-range
	      gives  the range(s) of vertical refresh frequencies supported by
	      the monitor.  vertrefresh-range may be a comma separated list of
	      either discrete values or	ranges of values.  A range  of	values
	      is two values separated by a dash.  By default the values	are in
	      units  of	Hz.  They may be specified in MHz or kHz if MHz	or kHz
	      is added to the end of the line.	The data given here is used by
	      the XFree86 server to determine if video modes  are  within  the
	      specifications  of  the  monitor.	  This	information  should be
	      available	in the monitor's handbook.  If this entry is  omitted,
	      a	default	range of 43-72Hz is used.

       DisplaySize  width height
	      This  optional entry gives the width and height, in millimetres,
	      of the picture area of the monitor. If given  this  is  used  to
	      calculate	the horizontal and vertical pitch (DPI)	of the screen.

       Gamma  gamma-value

       Gamma  red-gamma	green-gamma blue-gamma
	      This  is an optional entry that can be used to specify the gamma
	      correction for the monitor.  It may be  specified	 as  either  a
	      single value or as three separate	RGB values.  The values	should
	      be  in  the  range 0.1 to	10.0, and the default is 1.0.  Not all
	      drivers are capable of using this	information.

       UseModes	 "modesection-id"
	      Include the set of modes listed in the Modes section called mod-
	      esection-id.  This make all of the modes defined in that section
	      available	for use	by this	monitor.

       Mode  "name"
	      This is an optional multi-line entry that	can be used to provide
	      definitions for video modes for the monitor.  In most cases this
	      isn't necessary because the built-in set of VESA standard	 modes
	      will  be	sufficient.  The Mode keyword indicates	the start of a
	      multi-line video mode description.  The mode description is ter-
	      minated with the EndMode keyword.	 The mode description consists
	      of the following entries:

	      DotClock	clock
		  is the dot (pixel) clock rate	to be used for the mode.

	      HTimings	hdisp hsyncstart hsyncend htotal
		  specifies the	horizontal timings for the mode.

	      VTimings	vdisp vsyncstart vsyncend vtotal
		  specifies the	vertical timings for the mode.

	      Flags  "flag" ...
		  specifies an optional	set of mode flags, each	of which is  a
		  separate  string  in	double	quotes.	 "Interlace" indicates
		  that the mode	is interlaced.	"DoubleScan" indicates a  mode
		  where	 each  scanline	is doubled.  "+HSync" and "-HSync" can
		  be  used  to	select	the  polarity  of  the	HSync  signal.
		  "+VSync"  and	"-VSync" can be	used to	select the polarity of
		  the VSync signal.  "Composite" can be	used to	 specify  com-
		  posite  sync on hardware where this is supported.  Addition-
		  ally,	on some	hardware, "+CSync" and "-CSync"	may be used to
		  select the composite sync polarity.

	      HSkew  hskew
		  specifies the	number of pixels (towards the  right  edge  of
		  the  screen)	by  which  the	display	enable signal is to be
		  skewed.  Not all drivers use this information.  This	option
		  might	 become	 necessary  to override	the default value sup-
		  plied	by the server (if any).	 "Roving" horizontal lines in-
		  dicate this value needs to be	increased.  If	the  last  few
		  pixels on a scan line	appear on the left of the screen, this
		  value	should be decreased.

	      VScan  vscan
		  specifies  the  number  of times each	scanline is painted on
		  the screen.  Not all drivers use this	 information.	Values
		  less	than 1 are treated as 1, which is the default.	Gener-
		  ally,	the "DoubleScan" Flag  mentioned  above	 doubles  this
		  value.

       ModeLine	 "name"	mode-description
	      This  entry  is a	more compact version of	the Mode entry,	and it
	      also can be used to specify video	modes for the monitor.	 is  a
	      single  line  format  for	specifying video modes.	 In most cases
	      this isn't necessary because the built-in	set of	VESA  standard
	      modes will be sufficient.

	      The  mode-description  is	 in  four sections, the	first three of
	      which are	mandatory.  The	first is the dot (pixel) clock.	  This
	      is  a single number specifying the pixel clock rate for the mode
	      in MHz.  The second section is a list of four numbers specifying
	      the horizontal timings.  These numbers  are  the	hdisp,	hsync-
	      start, hsyncend, and htotal values.  The third section is	a list
	      of  four numbers specifying the vertical timings.	 These numbers
	      are the vdisp, vsyncstart, vsyncend, and vtotal values.  The fi-
	      nal section is a list of flags specifying	other  characteristics
	      of  the  mode.  Interlace	indicates that the mode	is interlaced.
	      DoubleScan indicates a mode  where  each	scanline  is  doubled.
	      +HSync  and  -HSync  can	be  used to select the polarity	of the
	      HSync signal.  +VSync and	-VSync can be used to select  the  po-
	      larity  of  the  VSync signal.  Composite	can be used to specify
	      composite	sync on	hardware where this is	supported.   Addition-
	      ally,  on	some hardware, +CSync and -CSync may be	used to	select
	      the composite sync polarity.  The	HSkew and VScan	 options  men-
	      tioned  above  in	 the  Modes entry description can also be used
	      here.

       Options
	      Some Option flags	that may be useful to include in Monitor  sec-
	      tions (when needed) include "DPMS", and "SyncOnGreen".

MODES SECTION
       The  config file	may have multiple Modes	sections, or none.  These sec-
       tions provide a way of defining sets of video  modes  independently  of
       the  Monitor  sections.	 Monitor  sections may include the definitions
       provided	in these sections by using  the	 UseModes  keyword.   In  most
       cases  the Modes	sections are not necessary because the built-in	set of
       VESA standard modes will	be sufficient.

       Modes sections have the following format:

	   Section "Modes"
	       Identifier "name"
	       entries
	       ...
	   EndSection

       The Identifier entry specifies the unique name for this set of mode de-
       scriptions.  The	other entries permitted	in Modes sections are the Mode
       and ModeLine entries that are described above in	the Monitor section.

SCREEN SECTION
       The config file may have	multiple Screen	sections.  There  must	be  at
       least  one,  for	 the  "screen"	being used.  A "screen"	represents the
       binding of a graphics device (Device section) and  a  monitor  (Monitor
       section).   A Screen section is considered "active" if it is referenced
       by an active ServerLayout section or by the -screen  command  line  op-
       tion.   If  neither of those is present,	the first Screen section found
       in the config file is considered	the active one.

       Screen sections have the	following format:

	   Section "Screen"
	       Identifier "name"
	       Device	  "devid"
	       Monitor	  "monid"
	       entries
	       ...
	       SubSection "Display"
		  entries
		  ...
	       EndSubSection
	       ...
	   EndSection

       The Identifier and Device entries are mandatory.	 All  others  are  op-
       tional.

       The  Identifier	entry  specifies the unique name for this screen.  The
       Screen section provides information specific to the whole  screen,  in-
       cluding	screen-specific	 Options.  In multi-head configurations, there
       will be multiple	active Screen sections,	one for	each  head.   The  en-
       tries available for this	section	are:

       Device  "device-id"
	      This mandatory entry specifies the Device	section	to be used for
	      this  screen.   This  is what ties a specific graphics card to a
	      screen.  The device-id must match	the  Identifier	 of  a	Device
	      section in the config file.

       Monitor	"monitor-id"
	      specifies	 which	monitor	 description  is  to  be used for this
	      screen.  If a Monitor name is not	specified, a default  configu-
	      ration  is  used.	  Currently  the default configuration may not
	      function as expected on all platforms.

       VideoAdaptor  "xv-id"
	      specifies	an optional Xv video adaptor description  to  be  used
	      with this	screen.

       DefaultDepth  depth
	      specifies	 which	color  depth the server	should use by default.
	      The -depth command line option can be used to override this.  If
	      neither is specified, the	default	depth is driver-specific,  but
	      in most cases is 8.

       DefaultFbBpp  bpp
	      specifies	 which	framebuffer  layout  to	 use  by default.  The
	      -fbbpp command line option can be	used  to  override  this.   In
	      most  cases  the	driver	will  chose the	best default value for
	      this.  The only case where there is even a choice	in this	 value
	      is  for  depth 24, where some hardware supports both a packed 24
	      bit framebuffer layout and a sparse 32 bit framebuffer layout.

       Options
	      Various Option flags may be specified  in	 the  Screen  section.
	      Some  are	 driver-specific and are described in the driver docu-
	      mentation.  Others are driver-independent, and  will  eventually
	      be described here.

       Option "Accel"
	      Enables  XAA  (X	Acceleration  Architecture),  a	mechanism that
	      makes video cards' 2D hardware  acceleration  available  to  the
	      XFree86  server.	 This  option  is on by	default, but it	may be
	      necessary	to turn	it off if there	are bugs in the	driver.	 There
	      are many options to  disable  specific  accelerated  operations,
	      listed below.  Note that disabling an operation will have	no ef-
	      fect if the operation is not accelerated (whether	due to lack of
	      support in the hardware or in the	driver).

       Option "BiosLocation" "address"
	      Set  the	location of the	BIOS for the Int10 module. One may se-
	      lect a BIOS of another card for posting  or  the	legacy	V_BIOS
	      range  located  at  0xc0000 or an	alternative address (BUS_ISA).
	      This is only useful under	very special circumstances and	should
	      be used with extreme care.

       Option "InitPrimary" "boolean"
	      Use  the	Int10  module to initialize the	primary	graphics card.
	      Normally,	only secondary cards are soft-booted using  the	 Int10
	      module,  as the primary card has already been initialized	by the
	      BIOS at boot time.  Default: false.

       Option "NoInt10"	"boolean"
	      Disables the Int10 module, a module that uses the	int10 call  to
	      the BIOS of the graphics card to initialize it. Default: false.

       Option "NoMTRR"
	      Disables MTRR (Memory Type Range Register) support, a feature of
	      modern  processors which can improve video performance by	a fac-
	      tor of up	to 2.5.	 Some hardware has  buggy  MTRR	 support,  and
	      some  video  drivers  have  been	known to exhibit problems when
	      MTRR's are used.

       Option "XaaNoCPUToScreenColorExpandFill"
	      Disables accelerated rectangular	expansion  blits  from	source
	      patterns	stored	in  system memory (using a memory-mapped aper-
	      ture).

       Option "XaaNoColor8x8PatternFillRect"
	      Disables accelerated fills of a rectangular region with a	 full-
	      color pattern.

       Option "XaaNoColor8x8PatternFillTrap"
	      Disables	accelerated fills of a trapezoidal region with a full-
	      color pattern.

       Option "XaaNoDashedBresenhamLine"
	      Disables accelerated dashed Bresenham line draws.

       Option "XaaNoDashedTwoPointLine"
	      Disables accelerated dashed line	draws  between	two  arbitrary
	      points.

       Option "XaaNoImageWriteRect"
	      Disables	accelerated  transfers	of full-color rectangular pat-
	      terns from system	memory to video	memory (using a	 memory-mapped
	      aperture).

       Option "XaaNoMono8x8PatternFillRect"
	      Disables	accelerated fills of a rectangular region with a mono-
	      chrome pattern.

       Option "XaaNoMono8x8PatternFillTrap"
	      Disables accelerated fills of a trapezoidal region with a	 mono-
	      chrome pattern.

       Option "XaaNoOffscreenPixmaps"
	      Disables	accelerated  draws  into  pixmaps  stored in offscreen
	      video memory.

       Option "XaaNoPixmapCache"
	      Disables caching of patterns in offscreen	video memory.

       Option "XaaNoScanlineCPUToScreenColorExpandFill"
	      Disables accelerated rectangular	expansion  blits  from	source
	      patterns stored in system	memory (one scan line at a time).

       Option "XaaNoScanlineImageWriteRect"
	      Disables	accelerated  transfers	of full-color rectangular pat-
	      terns from system	memory to video	memory (one  scan  line	 at  a
	      time).

       Option "XaaNoScreenToScreenColorExpandFill"
	      Disables	accelerated  rectangular  expansion  blits from	source
	      patterns stored in offscreen video memory.

       Option "XaaNoScreenToScreenCopy"
	      Disables accelerated copies of rectangular regions from one part
	      of video memory to another part of video memory.

       Option "XaaNoSolidBresenhamLine"
	      Disables accelerated solid Bresenham line	draws.

       Option "XaaNoSolidFillRect"
	      Disables accelerated solid-color fills of	rectangles.

       Option "XaaNoSolidFillTrap"
	      Disables accelerated solid-color fills of	Bresenham trapezoids.

       Option "XaaNoSolidHorVertLine"
	      Disables accelerated solid horizontal and	vertical line draws.

       Option "XaaNoSolidTwoPointLine"
	      Disables accelerated solid  line	draws  between	two  arbitrary
	      points.

       Each  Screen section may	optionally contain one or more Display subsec-
       tions.  Those subsections provide  depth/fbbpp  specific	 configuration
       information,  and the one chosen	depends	on the depth and/or fbbpp that
       is being	used for the screen.  The Display  subsection  format  is  de-
       scribed in the section below.

DISPLAY	SUBSECTION
       Each  Screen  section  may have multiple	Display	subsections.  The "ac-
       tive" Display subsection	is the first that  matches  the	 depth	and/or
       fbbpp  values being used, or failing that, the first that has neither a
       depth or	fbbpp value specified.	The Display subsections	are  optional.
       When  there  isn't one that matches the depth and/or fbbpp values being
       used, all the parameters	that can be specified here fall	back to	 their
       defaults.

       Display subsections have	the following format:

	       SubSection "Display"
		   Depth  depth
		   entries
		   ...
	       EndSubSection

       Depth  depth
	      This entry specifies what	colour depth the Display subsection is
	      to  be used for.	This entry is usually specified, but it	may be
	      omitted to create	a match-all Display subsection or when wishing
	      to match only against the	FbBpp parameter.  The range  of	 depth
	      values that are allowed depends on the driver.  Most driver sup-
	      port  8,	15, 16 and 24.	Some also support 1 and/or 4, and some
	      may support other	values (like 30).  Note: depth means the  num-
	      ber  of  bits in a pixel that are	actually used to determine the
	      pixel colour.  32	is not a valid	depth  value.	Most  hardware
	      that  uses  32  bits  per	pixel only uses	24 of them to hold the
	      colour information, which	means that the colour depth is 24, not
	      32.

       FbBpp  bpp
	      This entry specifies the framebuffer format this Display subsec-
	      tion is to be used for.  This entry is only needed when  provid-
	      ing depth	24 configurations that allow a choice between a	24 bpp
	      packed framebuffer format	and a 32bpp sparse framebuffer format.
	      In most cases this entry should not be used.

       Weight  red-weight green-weight blue-weight
	      This  optional  entry specifies the relative RGB weighting to be
	      used for a screen	is being used at depth 16 for drivers that al-
	      low multiple formats.  This may also be specified	from the  com-
	      mand line	with the -weight option	(see XFree86(1)).

       Virtual	xdim ydim
	      This  optional  entry specifies the virtual screen resolution to
	      be used.	xdim must be a multiple	of either 8  or	 16  for  most
	      drivers,	and  a multiple	of 32 when running in monochrome mode.
	      The given	value will be rounded down if this is  not  the	 case.
	      Video  modes  which are too large	for the	specified virtual size
	      will be rejected.	 If this entry is  not	present,  the  virtual
	      screen resolution	will be	set to accommodate all the valid video
	      modes  given in the Modes	entry.	Some drivers/hardware combina-
	      tions do not support virtual screens.  Refer to the  appropriate
	      driver-specific documentation for	details.

       ViewPort	 x0 y0
	      This  optional  entry  sets the upper left corner	of the initial
	      display.	This is	only relevant when the virtual screen  resolu-
	      tion is different	from the resolution of the initial video mode.
	      If  this	entry  is  not given, then the initial display will be
	      centered in the virtual display area.

       Modes  "mode-name" ...
	      This optional entry specifies the	list of	video  modes  to  use.
	      Each  mode-name  specified  must be in double quotes.  They must
	      correspond to those specified or referenced in  the  appropriate
	      Monitor  section	(including implicitly referenced built-in VESA
	      standard modes).	The server will	delete modes  from  this  list
	      which  don't satisfy various requirements.  The first valid mode
	      in this list will	be the default display mode for	startup.   The
	      list  of	valid  modes  is  converted internally into a circular
	      list.   It  is  possible	to  switch  to	the  next  mode	  with
	      Ctrl+Alt+Keypad-Plus and to the previous mode with Ctrl+Alt+Key-
	      pad-Minus.   When	 this entry is omitted,	the valid modes	refer-
	      enced by the appropriate Monitor section will be used.   If  the
	      Monitor  section	contains  no modes, then the selection will be
	      taken from the built-in VESA standard modes.

       Visual  "visual-name"
	      This optional entry sets the default root	visual type.  This may
	      also be specified	from the command line (see the Xserver(1)  man
	      page).   The  visual types available for depth 8 are (default is
	      PseudoColor):

		  StaticGray
		  GrayScale
		  StaticColor
		  PseudoColor
		  TrueColor
		  DirectColor

	      The visual type available	for the	depths 15, 16 and 24 are  (de-
	      fault is TrueColor):

		  TrueColor
		  DirectColor

	      Not all drivers support DirectColor at these depths.

	      The visual types available for the depth 4 are (default is Stat-
	      icColor):

		  StaticGray
		  GrayScale
		  StaticColor
		  PseudoColor

	      The  visual type available for the depth 1 (monochrome) is Stat-
	      icGray.

       Black  red green	blue
	      This optional entry allows the "black" colour to	be  specified.
	      This is only supported at	depth 1.  The default is black.

       White  red green	blue
	      This  optional  entry allows the "white" colour to be specified.
	      This is only supported at	depth 1.  The default is white.

       Options
	      Option flags may be specified in the Display subsections.	 These
	      may include driver-specific options and  driver-independent  op-
	      tions.  The former are described in the driver-specific documen-
	      tation.	Some  of the latter are	described above	in the section
	      about the	Screen section,	and they may also be included here.

SERVERLAYOUT SECTION
       The config file may have	multiple  ServerLayout	sections.   A  "server
       layout" represents the binding of one or	more screens (Screen sections)
       and one or more input devices (InputDevice sections) to form a complete
       configuration.	In  multi-head	configurations,	 it also specifies the
       relative	layout of the heads.  A	 ServerLayout  section	is  considered
       "active"	 if  it	is referenced by the -layout command line option or by
       an Option "DefaultServerLayout" entry in	the ServerFlags	 section  (the
       former  takes  precedence  over	the latter).  If those options are not
       used, the first ServerLayout section found in the config	file  is  con-
       sidered	the  active one.  If no	ServerLayout sections are present, the
       single active screen and	two active (core) input	devices	 are  selected
       as described in the relevant sections above.

       ServerLayout sections have the following	format:

	   Section "ServerLayout"
	       Identifier   "name"
	       Screen	    "screen-id"
	       ...
	       InputDevice  "idev-id"
	       ...
	       options
	       ...
	   EndSection

       Each  ServerLayout  section  must have an Identifier entry and at least
       one Screen entry.

       The Identifier entry specifies the unique name for this server  layout.
       The  ServerLayout  section  provides  information specific to the whole
       session,	including session-specific Options.  The  ServerFlags  options
       (described  above)  may be specified here, and ones given here override
       those given in the ServerFlags section.

       The entries that	may be used in this section are	described here.

       Screen  screen-num "screen-id" position-information
	      One of these entries must	be given for each screen being used in
	      a	session.  The screen-id	field is mandatory, and	specifies  the
	      Screen  section  being  referenced.  The screen-num field	is op-
	      tional, and may be used to specify the screen number  in	multi-
	      head  configurations.   When  this field is omitted, the screens
	      will be numbered in the order that they are listed in.  The num-
	      bering starts from 0, and	must be	consecutive.  The position-in-
	      formation	field describes	the way	 multiple  screens  are	 posi-
	      tioned.  There are a number of different ways that this informa-
	      tion can be provided:

	      x	y

	      Absolute	x y
		  These	 both specify that the upper left corner's coordinates
		  are (x,y).  The Absolute keyword is  optional.   Some	 older
		  versions  of	XFree86	 (4.2 and earlier) don't recognise the
		  Absolute keyword, so it's safest to just specify the coordi-
		  nates	without	it.

	      RightOf	"screen-id"

	      LeftOf	"screen-id"

	      Above	"screen-id"

	      Below	"screen-id"

	      Relative	"screen-id" x y
		  These	give the screen's location relative to another screen.
		  The first four position the screen immediately to the	right,
		  left,	above or below the other screen.  When positioning  to
		  the  right  or  left,	the top	edges are aligned.  When posi-
		  tioning above	or below, the left  edges  are	aligned.   The
		  Relative  form  specifies  the offset	of the screen's	origin
		  (upper left  corner)	relative  to  the  origin  of  another
		  screen.

       InputDevice  "idev-id" "option" ...
	      One of these entries should be given for each input device being
	      used in a	session.  Normally at least two	are required, one each
	      for  the	core pointer and keyboard devices.  If either of those
	      is missing, suitable InputDevice entries are searched for	 using
	      the  method  described  above  in	 the INPUTDEVICE section.  The
	      idev-id field is mandatory, and specifies	the name of the	Input-
	      Device section being referenced.	Multiple option	fields may  be
	      specified,  each	in  double quotes.  The	options	permitted here
	      are any that may also be	given  in  the	InputDevice  sections.
	      Normally	only  session-specific	input  device options would be
	      used here.  The most commonly used options are:

		  "CorePointer"
		  "CoreKeyboard"
		  "SendCoreEvents"

	      and the first two	should normally	be used	to indicate  the  core
	      pointer and core keyboard	devices	respectively.

       Options
	      Any  option  permitted  in  the  ServerFlags section may also be
	      specified	here.  When the	same option appears  in	 both  places,
	      the  value given here overrides the one given in the ServerFlags
	      section.

       Here is an example of a ServerLayout section for	a dual headed configu-
       ration with two mice:

	   Section "ServerLayout"
	       Identifier  "Layout 1"
	       Screen	   "MGA	1"
	       Screen	   "MGA	2" RightOf "MGA	1"
	       InputDevice "Keyboard 1"	"CoreKeyboard"
	       InputDevice "Mouse 1"	"CorePointer"
	       InputDevice "Mouse 2"	"SendCoreEvents"
	       Option	   "BlankTime"	"5"
	   EndSection

DRI SECTION
       This optional section is	used to	provide	some information for  the  Di-
       rect  Rendering	Infrastructure.	 Details about the format of this sec-
       tion can	be found in the	README.DRI document, which is  also  available
       on-line at <http://www.xfree86.org/current/DRI.html>.

VENDOR SECTION
       The optional Vendor section may be used to provide vendor-specific con-
       figuration  information.	  Multiple Vendor sections may be present, and
       they may	contain	an Identifier entry and	multiple  Option  flags.   The
       data therein is not used	in this	release.

FILES
       For  an	example	 of  an	 XF86Config  file,  see	 the file installed as
       /usr/X11R6/lib/X11/XF86Config.eg.

SEE ALSO
       X(7), Xserver(1), XFree86(1), apm(4),  chips(4),	 cirrus(4),  cyrix(4),
       fbdev(4),  glide(4),  glint(4),	i128(4),  i740(4),  i810(4), imstt(4),
       mga(4),	 neomagic(4),	nv(4),	 r128(4),   rendition(4),   savage(4),
       s3virge(4), siliconmotion(4), sis(4), sunbw2(4),	suncg14(4), suncg3(4),
       suncg6(4),  sunffb(4),  sunleo(4),  suntcx(4),  tdfx(4),	 tga(4),  tri-
       dent(4),	tseng(4), v4l(4), vesa(4), vga(4), vmware(4),
       README <http://www.xfree86.org/current/README.html>,
       RELNOTES	<http://www.xfree86.org/current/RELNOTES.html>,
       README.mouse <http://www.xfree86.org/current/mouse.html>,
       README.DRI <http://www.xfree86.org/current/DRI.html>,
       Status <http://www.xfree86.org/current/Status.html>,
       Install <http://www.xfree86.org/current/Install.html>.

AUTHORS
       This manual page	was largely rewritten for XFree86 4.0 by  David	 Dawes
       <dawes@xfree86.org>.

XFree86				 Version 4.4.0			 XF86Config(5)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=XF86Config&sektion=5&manpath=XFree86+4.4.0>

home | help