1xorg.conf(5) File Formats Manual xorg.conf(5)
2
6 xorg.conf, xorg.conf.d - configuration files for Xorg X server
7
9 Xorg supports several mechanisms for supplying/obtaining configuration
10 and run-time parameters: command line options, environment variables,
11 the xorg.conf and xorg.conf.d configuration files, auto-detection, and
12 fallback defaults. When the same information is supplied in more than
13 one way, the highest precedence mechanism is used. The list of mecha‐
14 nisms is ordered from highest precedence to lowest. Note that not all
15 parameters can be supplied via all methods. The available command line
16 options and environment variables (and some defaults) are described in
17 the Xserver(1) and Xorg(1) manual pages. Most configuration file param‐
18 eters, with their defaults, are described below. Driver and module spe‐
19 cific configuration parameters are described in the relevant driver or
20 module manual page.
21
23 Xorg uses a configuration file called xorg.conf and files ending in the
24 suffix .conf from the directory xorg.conf.d for its initial setup. The
25 xorg.conf configuration file is searched for in the following places
26 when the server is started as a normal user:
27 /etc/X11/<cmdline>
29 /usr/etc/X11/<cmdline>
30 /etc/X11/$XORGCONFIG
31 /usr/etc/X11/$XORGCONFIG
32 /etc/X11/xorg.conf
33 /etc/xorg.conf
34 /usr/etc/X11/xorg.conf.<hostname>
35 /usr/etc/X11/xorg.conf
36 /usr/lib/X11/xorg.conf.<hostname>
37 /usr/lib/X11/xorg.conf
38 where <cmdline> is a relative path (with no “..” components) specified
40 with the -config command line option, $XORGCONFIG is the relative path
41 (with no “..” components) specified by that environment variable, and
42 <hostname> is the machine's hostname as reported by gethostname(3).
43 When the Xorg server is started by the “root” user, the config file
45 search locations are as follows:
46 <cmdline>
48 /etc/X11/<cmdline>
49 /usr/etc/X11/<cmdline>
50 $XORGCONFIG
51 /etc/X11/$XORGCONFIG
52 /usr/etc/X11/$XORGCONFIG
53 /etc/X11/xorg.conf
54 /etc/xorg.conf
55 /usr/etc/X11/xorg.conf.<hostname>
56 /usr/etc/X11/xorg.conf
57 /usr/lib/X11/xorg.conf.<hostname>
58 /usr/lib/X11/xorg.conf
59 where <cmdline> is the path specified with the -config command line op‐
61 tion (which may be absolute or relative), $XORGCONFIG is the path spec‐
62 ified by that environment variable (absolute or relative), $HOME is the
63 path specified by that environment variable (usually the home direc‐
64 tory), and <hostname> is the machine's hostname as reported by gethost‐
65 name(3).
66 Additional configuration files are searched for in the following direc‐
68 tories when the server is started as a normal user:
69 /etc/X11/<cmdline>
71 /etc/X11/<cmdline>
72 /etc/X11/xorg.conf.d
73 /etc/X11/xorg.conf.d
74 where <cmdline> is a relative path (with no “..” components) specified
76 with the -configdir command line option.
77 When the Xorg server is started by the “root” user, the config direc‐
79 tory search locations are as follows:
80 <cmdline>
82 /etc/X11/<cmdline>
83 /etc/X11/<cmdline>
84 /etc/X11/xorg.conf.d
85 /etc/X11/xorg.conf.d
86 where <cmdline> is the path specified with the -configdir command line
88 option (which may be absolute or relative).
89 Finally, configuration files will also be searched for in a directory
91 reserved for system use. This is to separate configuration files from
92 the vendor or 3rd party packages from those of local administration.
93 These files are found in the following directory:
94 /usr/share/X11/xorg.conf.d
96 The xorg.conf and xorg.conf.d files are composed of a number of sec‐
98 tions which may be present in any order, or omitted to use default con‐
99 figuration values. Each section has the form:
100 Section "SectionName"
102 SectionEntry
103 ...
104 EndSection
105 The section names are:
107 Files File pathnames
109 ServerFlags Server flags
110 Module Dynamic module loading
111 Extensions Extension enabling
112 InputDevice Input device description
113 InputClass Input class description
114 OutputClass Output class description
115 Device Graphics device description
116 VideoAdaptor Xv video adaptor description
117 Monitor Monitor description
118 Modes Video modes descriptions
119 Screen Screen configuration
120 ServerLayout Overall layout
121 DRI DRI-specific configuration
122 Vendor Vendor-specific configuration
123 The following obsolete section names are still recognised for compati‐
125 bility purposes. In new config files, the InputDevice section should
126 be used instead.
127 Keyboard Keyboard configuration
129 Pointer Pointer/mouse configuration
130 The old XInput section is no longer recognised.
132 The ServerLayout sections are at the highest level. They bind together
134 the input and output devices that will be used in a session. The input
135 devices are described in the InputDevice sections. Output devices usu‐
136 ally consist of multiple independent components (e.g., a graphics board
137 and a monitor). These multiple components are bound together in the
138 Screen sections, and it is these that are referenced by the ServerLay‐
139 out section. Each Screen section binds together a graphics board and a
140 monitor. The graphics boards are described in the Device sections, and
141 the monitors are described in the Monitor sections.
142 Config file keywords are case-insensitive, and “_” characters are ig‐
144 nored. Most strings (including Option names) are also case-insensi‐
145 tive, and insensitive to white space and “_” characters.
146 Each config file entry usually takes up a single line in the file.
148 They consist of a keyword, which is possibly followed by one or more
149 arguments, with the number and types of the arguments depending on the
150 keyword. The argument types are:
151 Integer an integer number in decimal, hex or octal
153 Real a floating point number
154 String a string enclosed in double quote marks (")
155 Note: hex integer values must be prefixed with “0x”, and octal values
157 with “0”.
158 A special keyword called Option may be used to provide free-form data
160 to various components of the server. The Option keyword takes either
161 one or two string arguments. The first is the option name, and the op‐
162 tional second argument is the option value. Some commonly used option
163 value types include:
164 Integer an integer number in decimal, hex or octal
166 Real a floating point number
167 String a sequence of characters
168 Boolean a boolean value (see below)
169 Frequency a frequency value (see below)
170 Note that all Option values, not just strings, must be enclosed in
172 quotes.
173 Boolean options may optionally have a value specified. When no value
175 is specified, the option's value is TRUE. The following boolean option
176 values are recognised as TRUE:
177 1, on, true, yes
179 and the following boolean option values are recognised as FALSE:
181 0, off, false, no
183 If an option name is prefixed with "No", then the option value is
185 negated.
186 Example: the following option entries are equivalent:
188 Option "Accel" "Off"
190 Option "NoAccel"
191 Option "NoAccel" "On"
192 Option "Accel" "false"
193 Option "Accel" "no"
194 Frequency option values consist of a real number that is optionally
196 followed by one of the following frequency units:
197 Hz, k, kHz, M, MHz
199 When the unit name is omitted, the correct units will be determined
201 from the value and the expectations of the appropriate range of the
202 value. It is recommended that the units always be specified when using
203 frequency option values to avoid any errors in determining the value.
204
206 The Files section is used to specify some path names required by the
207 server. Some of these paths can also be set from the command line (see
208 Xserver(1) and Xorg(1)). The command line settings override the values
209 specified in the config file. The Files section is optional, as are
210 all of the entries that may appear in it.
211 The entries that can appear in this section are:
213 FontPath "path"
215 sets the search path for fonts. This path is a comma separated
216 list of font path elements which the Xorg server searches for
217 font databases. Multiple FontPath entries may be specified, and
218 they will be concatenated to build up the fontpath used by the
219 server. Font path elements can be absolute directory paths,
220 catalogue directories or a font server identifier. The formats
221 of the later two are explained below:
222 Catalogue directories:
224 Catalogue directories can be specified using the prefix cat‐
226 alogue: before the directory name. The directory can then be
227 populated with symlinks pointing to the real font directo‐
228 ries, using the following syntax in the symlink name:
229 <identifier>:[attribute]:pri=<priority>
231 where <identifier> is an alphanumeric identifier, [attri‐
233 bute] is an attribute which will be passed to the underlying
234 FPE and <priority> is a number used to order the fontfile
235 FPEs. Examples:
236 75dpi:unscaled:pri=20 -> /usr/share/X11/fonts/75dpi
238 gscript:pri=60 -> /usr/share/fonts/default/ghostscript
239 misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc
240 Font server identifiers:
242 Font server identifiers have the form:
244 <trans>/<hostname>:<port-number>
246 where <trans> is the transport type to use to connect to the
248 font server (e.g., unix for UNIX-domain sockets or tcp for a
249 TCP/IP connection), <hostname> is the hostname of the ma‐
250 chine running the font server, and <port-number> is the port
251 number that the font server is listening on (usually 7100).
252 When this entry is not specified in the config file, the server
254 falls back to the compiled-in default font path, which contains
255 the following font path elements (which can be set inside a cat‐
256 alogue directory):
257 /usr/share/fonts/X11/misc/
259 /usr/share/fonts/X11/TTF/
260 /usr/share/fonts/X11/OTF/
261 /usr/share/fonts/X11/Type1/
262 /usr/share/fonts/X11/100dpi/
263 /usr/share/fonts/X11/75dpi/
264 Font path elements that are found to be invalid are removed from
266 the font path when the server starts up.
267 ModulePath "path"
269 sets the search path for loadable Xorg server modules. This
270 path is a comma separated list of directories which the Xorg
271 server searches for loadable modules loading in the order speci‐
272 fied. Multiple ModulePath entries may be specified, and they
273 will be concatenated to build the module search path used by the
274 server. The default module path is
275 /usr/lib64/xorg/modules
277 XkbDir "path"
279 sets the base directory for keyboard layout files. The -xkbdir
280 command line option can be used to override this. The default
281 directory is
282 /usr/share/X11/xkb
284
286 In addition to options specific to this section (described below), the
287 ServerFlags section is used to specify some global Xorg server options.
288 All of the entries in this section are Options, although for compati‐
289 bility purposes some of the old style entries are still recognised.
290 Those old style entries are not documented here, and using them is dis‐
291 couraged. The ServerFlags section is optional, as are the entries that
292 may be specified in it.
293 Options specified in this section (with the exception of the "Default‐
295 ServerLayout" Option) may be overridden by Options specified in the ac‐
296 tive ServerLayout section. Options with command line equivalents are
297 overridden when their command line equivalent is used. The options
298 recognised by this section are:
299 Option "Debug" "string"
301 This comma-separated list provides a way to control various de‐
302 bugging switches from the config file. At the moment the only
303 defined value is dmabuf_capable which instructs glamor to enable
304 some unstable buffer management code.
305 Option "DefaultServerLayout" "layout-id"
307 This specifies the default ServerLayout section to use in the
308 absence of the -layout command line option.
309 Option "NoTrapSignals" "boolean"
311 This prevents the Xorg server from trapping a range of unex‐
312 pected fatal signals and exiting cleanly. Instead, the Xorg
313 server will die and drop core where the fault occurred. The de‐
314 fault behaviour is for the Xorg server to exit cleanly, but
315 still drop a core file. In general you never want to use this
316 option unless you are debugging an Xorg server problem and know
317 how to deal with the consequences.
318 Option "DontVTSwitch" "boolean"
320 This disallows the use of the Ctrl+Alt+Fn sequence (where Fn
321 refers to one of the numbered function keys). That sequence is
322 normally used to switch to another "virtual terminal" on operat‐
323 ing systems that have this feature. When this option is en‐
324 abled, that key sequence has no special meaning and is passed to
325 clients. Default: off.
326 Option "DontZap" "boolean"
328 This disallows the use of the Terminate_Server XKB action (usu‐
329 ally on Ctrl+Alt+Backspace, depending on XKB options). This ac‐
330 tion is normally used to terminate the Xorg server. When this
331 option is enabled, the action has no effect. Default: off.
332 Option "DontZoom" "boolean"
334 This disallows the use of the Ctrl+Alt+Keypad-Plus and
335 Ctrl+Alt+Keypad-Minus sequences. These sequences allows you to
336 switch between video modes. When this option is enabled, those
337 key sequences have no special meaning and are passed to clients.
338 Default: off.
339 Option "DisableVidModeExtension" "boolean"
341 This disables the parts of the VidMode extension used by the
342 xvidtune client that can be used to change the video modes. De‐
343 fault: the VidMode extension is enabled.
344 Option "AllowNonLocalXvidtune" "boolean"
346 This allows the xvidtune client (and other clients that use the
347 VidMode extension) to connect from another host. Default: off.
348 Option "AllowMouseOpenFail" "boolean"
350 This tells the mousedrv(4) and vmmouse(4) drivers to not report
351 failure if the mouse device can't be opened/initialised. It has
352 no effect on the evdev(4) or other drivers. Default: false.
353 Option "BlankTime" "time"
355 sets the inactivity timeout for the blank phase of the screen‐
356 saver. time is in minutes. This is equivalent to the Xorg
357 server's -s flag, and the value can be changed at run-time with
358 xset(1). Default: 10 minutes.
359 Option "StandbyTime" "time"
361 sets the inactivity timeout for the standby phase of DPMS mode.
362 time is in minutes, and the value can be changed at run-time
363 with xset(1). Default: 10 minutes. This is only suitable for
364 VESA DPMS compatible monitors, and may not be supported by all
365 video drivers. It is only enabled for screens that have the
366 "DPMS" option set (see the MONITOR section below).
367 Option "SuspendTime" "time"
369 sets the inactivity timeout for the suspend phase of DPMS mode.
370 time is in minutes, and the value can be changed at run-time
371 with xset(1). Default: 10 minutes. This is only suitable for
372 VESA DPMS compatible monitors, and may not be supported by all
373 video drivers. It is only enabled for screens that have the
374 "DPMS" option set (see the MONITOR section below).
375 Option "OffTime" "time"
377 sets the inactivity timeout for the off phase of DPMS mode.
378 time is in minutes, and the value can be changed at run-time
379 with xset(1). Default: 10 minutes. This is only suitable for
380 VESA DPMS compatible monitors, and may not be supported by all
381 video drivers. It is only enabled for screens that have the
382 "DPMS" option set (see the MONITOR section below).
383 Option "MaxClients" "integer"
385 Set the maximum number of clients allowed to connect to the X
386 server. Acceptable values are 64, 128, 256 or 512.
387 Option "NoPM" "boolean"
389 Disables something to do with power management events. Default:
390 PM enabled on platforms that support it.
391 Option "Xinerama" "boolean"
393 enable or disable XINERAMA extension. Default is disabled.
394 Option "IndirectGLX" "boolean"
396 enable or disable indirect GLX contexts. Indirect GLX contexts
397 are disabled by default.
398 Option "DRI2" "boolean"
400 enable or disable DRI2. DRI2 is disabled by default.
401 Option "GlxVisuals" "string"
403 This option controls how many GLX visuals the GLX modules sets
404 up. The default value is typical, which will setup up a typical
405 subset of the GLXFBConfigs provided by the driver as GLX visu‐
406 als. Other options are minimal, which will set up the minimal
407 set allowed by the GLX specification and all which will setup
408 GLX visuals for all GLXFBConfigs.
409 Option "UseDefaultFontPath" "boolean"
411 Include the default font path even if other paths are specified
412 in xorg.conf. If enabled, other font paths are included as well.
413 Enabled by default.
414 Option "IgnoreABI" "boolean"
416 Allow modules built for a different, potentially incompatible
417 version of the X server to load. Disabled by default.
418 Option "AutoAddDevices" "boolean"
420 If this option is disabled, then no devices will be added from
421 the HAL or udev backends. Enabled by default.
422 Option "AutoEnableDevices" "boolean"
424 If this option is disabled, then the devices will be added (and
425 the DevicePresenceNotify event sent), but not enabled, thus
426 leaving policy up to the client. Enabled by default.
427 Option "AutoAddGPU" "boolean"
429 If this option is disabled, then no GPU devices will be added
430 from the udev backend. Enabled by default. (May need to be dis‐
431 abled to setup Xinerama).
432 Option "AutoBindGPU" "boolean"
434 If enabled then secondary GPUs will be automatically set up as
435 output-sinks and offload-sources. Making e.g. laptop outputs
436 connected only to the secondary GPU directly available for use
437 without needing to run "xrandr --setprovideroutputsource". En‐
438 abled by default.
439 Option "Log" "string"
441 This option controls whether the log is flushed and/or synced to
442 disk after each message. Possible values are flush or sync.
443 Unset by default.
444
446 The Module section is used to specify which Xorg server modules should
447 be loaded. This section is ignored when the Xorg server is built in
448 static form. The type of modules normally loaded in this section are
449 Xorg server extension modules. Most other module types are loaded au‐
450 tomatically when they are needed via other mechanisms. The Module sec‐
451 tion is optional, as are all of the entries that may be specified in
452 it.
453 Entries in this section may be in two forms. The first and most com‐
455 monly used form is an entry that uses the Load keyword, as described
456 here:
457 Load "modulename"
459 This instructs the server to load the module called modulename.
460 The module name given should be the module's standard name, not
461 the module file name. The standard name is case-sensitive, and
462 does not include the “lib” or “cyg” prefixes, or the “.so” or
463 “.dll” suffixes.
464 Example: the DRI extension module can be loaded with the follow‐
466 ing entry:
467 Load "dri"
469 Disable "modulename"
471 This instructs the server to not load the module called module‐
472 name. Some modules are loaded by default in the server, and
473 this overrides that default. If a Load instruction is given for
474 the same module, it overrides the Disable instruction and the
475 module is loaded. The module name given should be the module's
476 standard name, not the module file name. As with the Load in‐
477 struction, the standard name is case-sensitive, and does not in‐
478 clude the "lib" prefix, or the ".a", ".o", or ".so" suffixes.
479 The second form of entry is a SubSection, with the subsection name be‐
481 ing the module name, and the contents of the SubSection being Options
482 that are passed to the module when it is loaded.
483 Example: the extmod module (which contains a miscellaneous group of
485 server extensions) can be loaded, with the XFree86-DGA extension dis‐
486 abled by using the following entry:
487 SubSection "extmod"
489 Option "omit XFree86-DGA"
490 EndSubSection
491 Modules are searched for in each directory specified in the ModulePath
493 search path, and in the drivers, extensions, input, internal, and mul‐
494 timedia subdirectories of each of those directories. In addition to
495 this, operating system specific subdirectories of all the above are
496 searched first if they exist.
497 To see what extension modules are available, check the extensions sub‐
499 directory under:
500 /usr/lib64/xorg/modules
502 The “extmod”, “dbe”, “dri”, “dri2”, “glx”, and “record” extension mod‐
504 ules are loaded automatically, if they are present, unless disabled
505 with "Disable" entries. It is recommended that at very least the
506 “extmod” extension module be loaded. If it isn't, some commonly used
507 server extensions (like the SHAPE extension) will not be available.
508
510 The Extensions section is used to specify which X11 protocol extensions
511 should be enabled or disabled. The Extensions section is optional, as
512 are all of the entries that may be specified in it.
513 Entries in this section are listed as Option statements with the name
515 of the extension as the first argument, and a boolean value as the sec‐
516 ond. The extension name is case-sensitive, and matches the form shown
517 in the output of "Xorg -extension ?".
518 Example: the MIT-SHM extension can be disabled with the follow‐
520 ing entry:
521 Section "Extensions"
523 Option "MIT-SHM" "Disable"
524 EndSection
525
527 The config file may have multiple InputDevice sections. Recent X
528 servers employ HAL or udev backends for input device enumeration and
529 input hotplugging. It is usually not necessary to provide InputDevice
530 sections in the xorg.conf if hotplugging is in use (i.e. AutoAddDevices
531 is enabled). If hotplugging is enabled, InputDevice sections using the
532 mouse, kbd and vmmouse driver will be ignored.
533 If hotplugging is disabled, there will normally be at least two: one
535 for the core (primary) keyboard and one for the core pointer. If ei‐
536 ther of these two is missing, a default configuration for the missing
537 ones will be used. In the absence of an explicitly specified core input
538 device, the first InputDevice marked as CorePointer (or CoreKeyboard)
539 is used. If there is no match there, the first InputDevice that uses
540 the “mouse” (or “kbd”) driver is used. The final fallback is to use
541 built-in default configurations. Currently the default configuration
542 may not work as expected on all platforms.
543 InputDevice sections have the following format:
545 Section "InputDevice"
547 Identifier "name"
548 Driver "inputdriver"
549 options
550 ...
551 EndSection
552 The Identifier and Driver entries are required in all InputDevice sec‐
554 tions. All other entries are optional.
555 The Identifier entry specifies the unique name for this input device.
557 The Driver entry specifies the name of the driver to use for this input
558 device. When using the loadable server, the input driver module "in‐
559 putdriver" will be loaded for each active InputDevice section. An In‐
560 putDevice section is considered active if it is referenced by an active
561 ServerLayout section, if it is referenced by the -keyboard or -pointer
562 command line options, or if it is selected implicitly as the core
563 pointer or keyboard device in the absence of such explicit references.
564 The most commonly used input drivers are evdev(4) on Linux systems, and
565 kbd(4) and mousedrv(4) on other platforms.
566 InputDevice sections recognise some driver-independent Options, which
568 are described here. See the individual input driver manual pages for a
569 description of the device-specific options.
570 Option "AutoServerLayout" "boolean"
572 Always add the device to the ServerLayout section used by this
573 instance of the server. This affects implied layouts as well as
574 explicit layouts specified in the configuration and/or on the
575 command line.
576 Option "CorePointer"
578 Deprecated, see Floating
579 Option "CoreKeyboard"
581 Deprecated, see Floating
582 Option "AlwaysCore" "boolean"
584 Deprecated, see Floating
585 Option "SendCoreEvents" "boolean"
587 Deprecated, see Floating
588 Option "Floating" "boolean"
591 When enabled, the input device is set up floating and does not
592 report events through any master device or control a cursor. The
593 device is only available to clients using the X Input Extension
594 API. This option is disabled by default. The options Core‐
595 Pointer, CoreKeyboard, AlwaysCore, and SendCoreEvents, are the
596 inverse of option Floating (i.e. SendCoreEvents "on" is equiva‐
597 lent to Floating "off" ).
598 This option controls the startup behavior only, a device may be
600 reattached or set floating at runtime.
601 Option "TransformationMatrix" "a b c d e f g h i"
603 Specifies the 3x3 transformation matrix for absolute input de‐
604 vices. The input device will be bound to the area given in the
605 matrix. In most configurations, "a" and "e" specify the width
606 and height of the area the device is bound to, and "c" and "f"
607 specify the x and y offset of the area. The value range is 0 to
608 1, where 1 represents the width or height of all root windows
609 together, 0.5 represents half the area, etc. The values repre‐
610 sent a 3x3 matrix, with the first, second and third group of
611 three values representing the first, second and third row of the
612 matrix, respectively. The identity matrix is "1 0 0 0 1 0 0 0
613 1".
614 POINTER ACCELERATION
616 For pointing devices, the following options control how the pointer is
617 accelerated or decelerated with respect to physical device motion. Most
618 of these can be adjusted at runtime, see the xinput(1) man page for de‐
619 tails. Only the most important acceleration options are discussed here.
620 Option "AccelerationProfile" "integer"
622 Select the profile. In layman's terms, the profile constitutes
623 the "feeling" of the acceleration. More formally, it defines how
624 the transfer function (actual acceleration as a function of cur‐
625 rent device velocity and acceleration controls) is constructed.
626 This is mainly a matter of personal preference.
627 0 classic (mostly compatible)
629 -1 none (only constant deceleration is applied)
630 1 device-dependent
631 2 polynomial (polynomial function)
632 3 smooth linear (soft knee, then linear)
633 4 simple (normal when slow, otherwise accelerated)
634 5 power (power function)
635 6 linear (more speed, more acceleration)
636 7 limited (like linear, but maxes out at threshold)
637 Option "ConstantDeceleration" "real"
639 Makes the pointer go deceleration times slower than normal. Most
640 useful for high-resolution devices. A value between 0 and 1 will
641 speed up the pointer.
642 Option "AdaptiveDeceleration" "real"
644 Allows to actually decelerate the pointer when going slow. At
645 most, it will be adaptive deceleration times slower. Enables
646 precise pointer placement without sacrificing speed.
647 Option "AccelerationScheme" "string"
649 Selects the scheme, which is the underlying algorithm.
650 predictable default algorithm (behaving more predictable)
652 lightweight old acceleration code (as specified in the X protocol spec)
653 none no acceleration or deceleration
654 Option "AccelerationNumerator" "integer"
656 Option "AccelerationDenominator" "integer"
658 Set numerator and denominator of the acceleration factor. The
659 acceleration factor is a rational which, together with thresh‐
660 old, can be used to tweak profiles to suit the users needs. The
661 simple and limited profiles use it directly (i.e. they acceler‐
662 ate by the factor), for other profiles it should hold that a
663 higher acceleration factor leads to a faster pointer. Typically,
664 1 is unaccelerated and values up to 5 are sensible.
665 Option "AccelerationThreshold" "integer"
667 Set the threshold, which is roughly the velocity (usually device
668 units per 10 ms) required for acceleration to become effective.
669 The precise effect varies with the profile however.
670
673 The config file may have multiple InputClass sections. These sections
674 are optional and are used to provide configuration for a class of input
675 devices as they are automatically added. An input device can match more
676 than one InputClass section. Each class can override settings from a
677 previous class, so it is best to arrange the sections with the most
678 generic matches first.
679 InputClass sections have the following format:
681 Section "InputClass"
683 Identifier "name"
684 entries
685 ...
686 options
687 ...
688 EndSection
689 The Identifier entry is required in all InputClass sections. All other
691 entries are optional.
692 The Identifier entry specifies the unique name for this input class.
694 The Driver entry specifies the name of the driver to use for this input
695 device. After all classes have been examined, the "inputdriver" module
696 from the first Driver entry will be enabled when using the loadable
697 server.
698 When an input device is automatically added, its characteristics are
700 checked against all InputClass sections. Each section can contain op‐
701 tional entries to narrow the match of the class. If none of the op‐
702 tional entries appear, the InputClass section is generic and will match
703 any input device. If more than one of these entries appear, they all
704 must match for the configuration to apply.
705 There are two types of match entries used in InputClass sections. The
707 first allows various tokens to be matched against attributes of the de‐
708 vice. An entry can be constructed to match attributes from different
709 devices by separating arguments with a '|' character. Multiple entries
710 of the same type may be supplied to add multiple matching conditions on
711 the same attribute. For example:
712 Section "InputClass"
714 Identifier "My Class"
715 # product string must contain example and
716 # either gizmo or gadget
717 MatchProduct "example"
718 MatchProduct "gizmo|gadget"
719 NoMatchDriver "drivername"
720 ...
721 EndSection
722 MatchProduct "matchproduct"
724 This entry can be used to check if the substring "matchproduct"
725 occurs in the device's product name.
726 MatchVendor "matchvendor"
728 This entry can be used to check if the substring "matchvendor"
729 occurs in the device's vendor name.
730 MatchDevicePath "matchdevice"
732 This entry can be used to check if the device file matches the
733 "matchdevice" pathname pattern.
734 MatchOS "matchos"
736 This entry can be used to check if the operating system matches
737 the case-insensitive "matchos" string. This entry is only sup‐
738 ported on platforms providing the uname(2) system call.
739 MatchPnPID "matchpnp"
741 The device's Plug and Play (PnP) ID can be checked against the
742 "matchpnp" shell wildcard pattern.
743 MatchUSBID "matchusb"
745 The device's USB ID can be checked against the "matchusb" shell
746 wildcard pattern. The ID is constructed as lowercase hexadecimal
747 numbers separated by a ':'. This is the same format as the
748 lsusb(8) program.
749 MatchDriver "matchdriver"
751 Check the case-sensitive string "matchdriver" against the cur‐
752 rently configured driver of the device. Ordering of sections us‐
753 ing this entry is important since it will not match unless the
754 driver has been set by the config backend or a previous Input‐
755 Class section.
756 MatchTag "matchtag"
758 This entry can be used to check if tags assigned by the config
759 backend matches the "matchtag" pattern. A match is found if at
760 least one of the tags given in "matchtag" matches at least one
761 of the tags assigned by the backend.
762 MatchLayout "matchlayout"
764 Check the case-sensitive string "matchlayout" against the cur‐
765 rently active ServerLayout section. The empty string "" matches
766 an implicit layout which appears if no named ServerLayout sec‐
767 tions have been found.
768 The above directives have equivalents for negative matching with the
770 NoMatchProduct, NoMatchVendor, NoMatchDevicePath, NoMatchOS, NoMatchPn‐
771 PID, NoMatchUSBID, NoMatchDriver, NoMatchTag, and NoMatchLayout direc‐
772 tives. These NoMatch directives match if the subsequent match is not
773 met by the device.
774 The second type of entry is used to match device types. These entries
776 take a boolean argument similar to Option entries.
777 MatchIsKeyboard "bool"
779 MatchIsPointer "bool"
781 MatchIsJoystick "bool"
783 MatchIsTablet "bool"
785 MatchIsTabletPad "bool"
787 MatchIsTouchpad "bool"
789 MatchIsTouchscreen "bool"
791 When an input device has been matched to the InputClass section, any
793 Option entries are applied to the device. One InputClass specific Op‐
794 tion is recognized. See the InputDevice section above for a description
795 of the remaining Option entries.
796 Option "Ignore" "boolean"
798 This optional entry specifies that the device should be ignored
799 entirely, and not added to the server. This can be useful when
800 the device is handled by another program and no X events should
801 be generated.
802
804 The config file may have multiple OutputClass sections. These sections
805 are optional and are used to provide configuration for a class of out‐
806 put devices as they are automatically added. An output device can
807 match more than one OutputClass section. Each class can override set‐
808 tings from a previous class, so it is best to arrange the sections with
809 the most generic matches first.
810 OutputClass sections have the following format:
812 Section "OutputClass"
814 Identifier "name"
815 entries
816 ...
817 EndSection
818 The Identifier entry is required in all OutputClass sections. All
820 other entries are optional.
821 The Identifier entry specifies the unique name for this output class.
823 The Driver entry specifies the name of the driver to use for this out‐
824 put device. After all classes have been examined, the "outputdriver"
825 module from the first Driver entry will be enabled when using the load‐
826 able server.
827 When an output device is automatically added, its characteristics are
829 checked against all OutputClass sections. Each section can contain op‐
830 tional entries to narrow the match of the class. If none of the op‐
831 tional entries appear, the OutputClass section is generic and will
832 match any output device. If more than one of these entries appear,
833 they all must match for the configuration to apply.
834 The following list of tokens can be matched against attributes of the
836 device. An entry can be constructed to match attributes from different
837 devices by separating arguments with a '|' character.
838 For example:
840 Section "OutputClass"
842 Identifier "My Class"
843 # kernel driver must be either foo or bar
844 MatchDriver "foo|bar"
845 ...
846 EndSection
847 MatchDriver "matchdriver"
849 Check the case-sensitive string "matchdriver" against the kernel
850 driver of the device.
851 When an output device has been matched to the OutputClass section, any
853 Option entries are applied to the device. One OutputClass specific Op‐
854 tion is recognized. See the Device section below for a description of
855 the remaining Option entries.
856 Option "PrimaryGPU" "boolean"
858 This option specifies that the matched device should be treated
859 as the primary GPU, replacing the selection of the GPU used as
860 output by the firmware. If multiple output devices match an Out‐
861 putClass section with the PrimaryGPU option set, the first one
862 enumerated becomes the primary GPU.
863 A OutputClass Section may contain ModulePath entries. When an output
865 device matches an OutputClass section, any ModulePath entries in that
866 OutputClass are pre-pended to the search path for loadable Xorg server
867 modules. See ModulePath in the Files section for more info.
868
870 The config file may have multiple Device sections. There must be at
871 least one, for the video card being used.
872 Device sections have the following format:
874 Section "Device"
876 Identifier "name"
877 Driver "driver"
878 entries
879 ...
880 EndSection
881 The Identifier and Driver entries are required in all Device sections.
883 All other entries are optional.
884 The Identifier entry specifies the unique name for this graphics de‐
886 vice. The Driver entry specifies the name of the driver to use for
887 this graphics device. When using the loadable server, the driver mod‐
888 ule "driver" will be loaded for each active Device section. A Device
889 section is considered active if it is referenced by an active Screen
890 section.
891 Device sections recognise some driver-independent entries and Options,
893 which are described here. Not all drivers make use of these driver-in‐
894 dependent entries, and many of those that do don't require them to be
895 specified because the information is auto-detected. See the individual
896 graphics driver manual pages for further information about this, and
897 for a description of the device-specific options. Note that most of
898 the Options listed here (but not the other entries) may be specified in
899 the Screen section instead of here in the Device section.
900 BusID "bus-id"
902 This specifies the bus location of the graphics card. For
903 PCI/AGP cards, the bus-id string has the form PCI:bus@domain:de‐
904 vice:function (e.g., “PCI:1@0:0:0” might be appropriate for an
905 AGP card). The "@domain" part can be left out for PCI domain 0.
906 This field is usually optional in single-head configurations
907 when using the primary graphics card. In multi-head configura‐
908 tions, or when using a secondary graphics card in a single-head
909 configuration, this entry is mandatory. Its main purpose is to
910 make an unambiguous connection between the device section and
911 the hardware it is representing. This information can usually
912 be found by running the pciaccess tool scanpci.
913 Screen number
915 This option is mandatory for cards where a single PCI entity can
916 drive more than one display (i.e., multiple CRTCs sharing a sin‐
917 gle graphics accelerator and video memory). One Device section
918 is required for each head, and this parameter determines which
919 head each of the Device sections applies to. The legal values
920 of number range from 0 to one less than the total number of
921 heads per entity. Most drivers require that the primary screen
922 (0) be present.
923 Chipset "chipset"
925 This usually optional entry specifies the chipset used on the
926 graphics board. In most cases this entry is not required be‐
927 cause the drivers will probe the hardware to determine the
928 chipset type. Don't specify it unless the driver-specific docu‐
929 mentation recommends that you do.
930 Ramdac "ramdac-type"
932 This optional entry specifies the type of RAMDAC used on the
933 graphics board. This is only used by a few of the drivers, and
934 in most cases it is not required because the drivers will probe
935 the hardware to determine the RAMDAC type where possible. Don't
936 specify it unless the driver-specific documentation recommends
937 that you do.
938 DacSpeed speed
940 DacSpeed speed-8 speed-16 speed-24 speed-32
942 This optional entry specifies the RAMDAC speed rating (which is
943 usually printed on the RAMDAC chip). The speed is in MHz. When
944 one value is given, it applies to all framebuffer pixel sizes.
945 When multiple values are given, they apply to the framebuffer
946 pixel sizes 8, 16, 24 and 32 respectively. This is not used by
947 many drivers, and only needs to be specified when the speed rat‐
948 ing of the RAMDAC is different from the defaults built in to
949 driver, or when the driver can't auto-detect the correct de‐
950 faults. Don't specify it unless the driver-specific documenta‐
951 tion recommends that you do.
952 Clocks clock ...
954 specifies the pixel that are on your graphics board. The clocks
955 are in MHz, and may be specified as a floating point number.
956 The value is stored internally to the nearest kHz. The ordering
957 of the clocks is important. It must match the order in which
958 they are selected on the graphics board. Multiple Clocks lines
959 may be specified, and each is concatenated to form the list.
960 Most drivers do not use this entry, and it is only required for
961 some older boards with non-programmable clocks. Don't specify
962 this entry unless the driver-specific documentation explicitly
963 recommends that you do.
964 ClockChip "clockchip-type"
966 This optional entry is used to specify the clock chip type on
967 graphics boards which have a programmable clock generator. Only
968 a few Xorg drivers support programmable clock chips. For de‐
969 tails, see the appropriate driver manual page.
970 VideoRam mem
972 This optional entry specifies the amount of video ram that is
973 installed on the graphics board. This is measured in kBytes.
974 In most cases this is not required because the Xorg server
975 probes the graphics board to determine this quantity. The
976 driver-specific documentation should indicate when it might be
977 needed.
978 MemBase baseaddress
980 This optional entry specifies the memory base address of a
981 graphics board's linear frame buffer. This entry is not used by
982 many drivers, and it should only be specified if the driver-spe‐
983 cific documentation recommends it.
984 IOBase baseaddress
986 This optional entry specifies the IO base address. This entry
987 is not used by many drivers, and it should only be specified if
988 the driver-specific documentation recommends it.
989 ChipID id
991 This optional entry specifies a numerical ID representing the
992 chip type. For PCI cards, it is usually the device ID. This
993 can be used to override the auto-detection, but that should only
994 be done when the driver-specific documentation recommends it.
995 ChipRev rev
997 This optional entry specifies the chip revision number. This
998 can be used to override the auto-detection, but that should only
999 be done when the driver-specific documentation recommends it.
1000 MatchSeat seat-id
1002 Only apply this Device section if X server was started with
1003 -seat seat-id option.
1004 Option "ModeDebug" "boolean"
1006 Enable printing of additional debugging information about mode‐
1007 setting to the server log.
1008 Option "PreferCloneMode" "boolean"
1010 If enabled, bring up monitors of a screen in clone mode instead
1011 of horizontal extended layout by default. (Defaults to off; the
1012 video driver can change the default value, but this option can
1013 always override it)
1014 Options
1016 Option flags may be specified in the Device sections. These in‐
1017 clude driver-specific options and driver-independent options.
1018 The former are described in the driver-specific documentation.
1019 Some of the latter are described below in the section about the
1020 Screen section, and they may also be included here.
1021
1024 Nobody wants to say how this works. Maybe nobody knows ...
1025
1028 The config file may have multiple Monitor sections. There should nor‐
1029 mally be at least one, for the monitor being used, but a default con‐
1030 figuration will be created when one isn't specified.
1031 Monitor sections have the following format:
1033 Section "Monitor"
1035 Identifier "name"
1036 entries
1037 ...
1038 EndSection
1039 The only mandatory entry in a Monitor section is the Identifier entry.
1041 The Identifier entry specifies the unique name for this monitor. The
1043 Monitor section may be used to provide information about the specifica‐
1044 tions of the monitor, monitor-specific Options, and information about
1045 the video modes to use with the monitor.
1046 With RandR 1.2-enabled drivers, monitor sections may be tied to spe‐
1048 cific outputs of the video card. Using the name of the output defined
1049 by the video driver plus the identifier of a monitor section, one asso‐
1050 ciates a monitor section with an output by adding an option to the De‐
1051 vice section in the following format:
1052 Option "Monitor-outputname" "monitorsection"
1054 (for example, Option "Monitor-VGA" "VGA monitor" for a VGA output)
1056 In the absence of specific association of monitor sections to outputs,
1058 if a monitor section is present the server will associate it with an
1059 output to preserve compatibility for previous single-head configura‐
1060 tions.
1061 Specifying video modes is optional because the server will use the DDC
1063 or other information provided by the monitor to automatically configure
1064 the list of modes available. When modes are specified explicitly in
1065 the Monitor section (with the Mode, ModeLine, or UseModes keywords),
1066 built-in modes with the same names are not included. Built-in modes
1067 with different names are, however, still implicitly included, when they
1068 meet the requirements of the monitor.
1069 The entries that may be used in Monitor sections are described below.
1071 VendorName "vendor"
1073 This optional entry specifies the monitor's manufacturer.
1074 ModelName "model"
1076 This optional entry specifies the monitor's model.
1077 HorizSync horizsync-range
1079 gives the range(s) of horizontal sync frequencies supported by
1080 the monitor. horizsync-range may be a comma separated list of
1081 either discrete values or ranges of values. A range of values
1082 is two values separated by a dash. By default the values are in
1083 units of kHz. They may be specified in MHz or Hz if MHz or Hz
1084 is added to the end of the line. The data given here is used by
1085 the Xorg server to determine if video modes are within the spec‐
1086 ifications of the monitor. This information should be available
1087 in the monitor's handbook. If this entry is omitted, a default
1088 range of 28-33kHz is used.
1089 VertRefresh vertrefresh-range
1091 gives the range(s) of vertical refresh frequencies supported by
1092 the monitor. vertrefresh-range may be a comma separated list of
1093 either discrete values or ranges of values. A range of values
1094 is two values separated by a dash. By default the values are in
1095 units of Hz. They may be specified in MHz or kHz if MHz or kHz
1096 is added to the end of the line. The data given here is used by
1097 the Xorg server to determine if video modes are within the spec‐
1098 ifications of the monitor. This information should be available
1099 in the monitor's handbook. If this entry is omitted, a default
1100 range of 43-72Hz is used.
1101 DisplaySize width height
1103 This optional entry gives the width and height, in millimetres,
1104 of the picture area of the monitor. If given this is used to
1105 calculate the horizontal and vertical pitch (DPI) of the screen.
1106 Gamma gamma-value
1108 Gamma red-gamma green-gamma blue-gamma
1110 This is an optional entry that can be used to specify the gamma
1111 correction for the monitor. It may be specified as either a
1112 single value or as three separate RGB values. The values should
1113 be in the range 0.1 to 10.0, and the default is 1.0. Not all
1114 drivers are capable of using this information.
1115 UseModes "modesection-id"
1117 Include the set of modes listed in the Modes section called mod‐
1118 esection-id. This makes all of the modes defined in that sec‐
1119 tion available for use by this monitor.
1120 Mode "name"
1122 This is an optional multi-line entry that can be used to provide
1123 definitions for video modes for the monitor. In most cases this
1124 isn't necessary because the built-in set of VESA standard modes
1125 will be sufficient. The Mode keyword indicates the start of a
1126 multi-line video mode description. The mode description is ter‐
1127 minated with the EndMode keyword. The mode description consists
1128 of the following entries:
1129 DotClock clock
1131 is the dot (pixel) clock rate to be used for the mode.
1132 HTimings hdisp hsyncstart hsyncend htotal
1134 specifies the horizontal timings for the mode.
1135 VTimings vdisp vsyncstart vsyncend vtotal
1137 specifies the vertical timings for the mode.
1138 Flags "flag" ...
1140 specifies an optional set of mode flags, each of which is a
1141 separate string in double quotes. "Interlace" indicates
1142 that the mode is interlaced. "DoubleScan" indicates a mode
1143 where each scanline is doubled. "+HSync" and "-HSync" can
1144 be used to select the polarity of the HSync signal.
1145 "+VSync" and "-VSync" can be used to select the polarity of
1146 the VSync signal. "Composite" can be used to specify com‐
1147 posite sync on hardware where this is supported. Addition‐
1148 ally, on some hardware, "+CSync" and "-CSync" may be used to
1149 select the composite sync polarity.
1150 HSkew hskew
1152 specifies the number of pixels (towards the right edge of
1153 the screen) by which the display enable signal is to be
1154 skewed. Not all drivers use this information. This option
1155 might become necessary to override the default value sup‐
1156 plied by the server (if any). “Roving” horizontal lines in‐
1157 dicate this value needs to be increased. If the last few
1158 pixels on a scan line appear on the left of the screen, this
1159 value should be decreased.
1160 VScan vscan
1162 specifies the number of times each scanline is painted on
1163 the screen. Not all drivers use this information. Values
1164 less than 1 are treated as 1, which is the default. Gener‐
1165 ally, the "DoubleScan" Flag mentioned above doubles this
1166 value.
1167 ModeLine "name" mode-description
1169 This entry is a more compact version of the Mode entry, and it
1170 also can be used to specify video modes for the monitor. This
1171 is a single line format for specifying video modes. In most
1172 cases this isn't necessary because the built-in set of VESA
1173 standard modes will be sufficient.
1174 The mode-description is in four sections, the first three of
1176 which are mandatory. The first is the dot (pixel) clock. This
1177 is a single number specifying the pixel clock rate for the mode
1178 in MHz. The second section is a list of four numbers specifying
1179 the horizontal timings. These numbers are the hdisp, hsync‐
1180 start, hsyncend, and htotal values. The third section is a list
1181 of four numbers specifying the vertical timings. These numbers
1182 are the vdisp, vsyncstart, vsyncend, and vtotal values. The fi‐
1183 nal section is a list of flags specifying other characteristics
1184 of the mode. Interlace indicates that the mode is interlaced.
1185 DoubleScan indicates a mode where each scanline is doubled.
1186 +HSync and -HSync can be used to select the polarity of the
1187 HSync signal. +VSync and -VSync can be used to select the po‐
1188 larity of the VSync signal. Composite can be used to specify
1189 composite sync on hardware where this is supported. Addition‐
1190 ally, on some hardware, +CSync and -CSync may be used to select
1191 the composite sync polarity. The HSkew and VScan options men‐
1192 tioned above in the Mode entry description can also be used
1193 here.
1194 Option "DPMS" "bool"
1196 This option controls whether the server should enable the DPMS
1197 extension for power management for this screen. The default is
1198 to enable the extension.
1199 Option "SyncOnGreen" "bool"
1201 This option controls whether the video card should drive the
1202 sync signal on the green color pin. Not all cards support this
1203 option, and most monitors do not require it. The default is
1204 off.
1205 Option "Primary" "bool"
1207 This optional entry specifies that the monitor should be treated
1208 as the primary monitor. (RandR 1.2-supporting drivers only)
1209 Option "PreferredMode" "name"
1211 This optional entry specifies a mode to be marked as the pre‐
1212 ferred initial mode of the monitor. (RandR 1.2-supporting driv‐
1213 ers only)
1214 Option "ZoomModes" "name name ..."
1216 This optional entry specifies modes to be marked as zoom modes.
1217 It is possible to switch to the next and previous mode via
1218 Ctrl+Alt+Keypad-Plus and Ctrl+Alt+Keypad-Minus. All these key‐
1219 pad available modes are selected from the screen mode list.
1220 This list is a copy of the compatibility output monitor mode
1221 list. Since this output is the output connected to the lowest
1222 dot-area monitor, as determined from its largest size mode, that
1223 monitor defines the available zoom modes. (RandR 1.2-supporting
1224 drivers only)
1225 Option "Position" "x y"
1227 This optional entry specifies the position of the monitor within
1228 the X screen. (RandR 1.2-supporting drivers only)
1229 Option "LeftOf" "output"
1231 This optional entry specifies that the monitor should be posi‐
1232 tioned to the left of the output (not monitor) of the given
1233 name. (RandR 1.2-supporting drivers only)
1234 Option "RightOf" "output"
1236 This optional entry specifies that the monitor should be posi‐
1237 tioned to the right of the output (not monitor) of the given
1238 name. (RandR 1.2-supporting drivers only)
1239 Option "Above" "output"
1241 This optional entry specifies that the monitor should be posi‐
1242 tioned above the output (not monitor) of the given name. (RandR
1243 1.2-supporting drivers only)
1244 Option "Below" "output"
1246 This optional entry specifies that the monitor should be posi‐
1247 tioned below the output (not monitor) of the given name. (RandR
1248 1.2-supporting drivers only)
1249 Option "Enable" "bool"
1251 This optional entry specifies whether the monitor should be
1252 turned on at startup. By default, the server will attempt to
1253 enable all connected monitors. (RandR 1.2-supporting drivers
1254 only)
1255 Option "DefaultModes" "bool"
1257 This optional entry specifies whether the server should add sup‐
1258 ported default modes to the list of modes offered on this moni‐
1259 tor. By default, the server will add default modes; you should
1260 only disable this if you can guarantee that EDID will be avail‐
1261 able at all times, or if you have added custom modelines which
1262 the server can use. (RandR 1.2-supporting drivers only)
1263 Option "MinClock" "frequency"
1265 This optional entry specifies the minimum dot clock, in kHz,
1266 that is supported by the monitor.
1267 Option "MaxClock" "frequency"
1269 This optional entry specifies the maximum dot clock, in kHz,
1270 that is supported by the monitor.
1271 Option "Ignore" "bool"
1273 This optional entry specifies that the monitor should be ignored
1274 entirely, and not reported through RandR. This is useful if the
1275 hardware reports the presence of outputs that don't exist.
1276 (RandR 1.2-supporting drivers only)
1277 Option "Rotate" "rotation"
1279 This optional entry specifies the initial rotation of the given
1280 monitor. Valid values for rotation are "normal", "left",
1281 "right", and "inverted". (RandR 1.2-supporting drivers only)
1282
1285 The config file may have multiple Modes sections, or none. These sec‐
1286 tions provide a way of defining sets of video modes independently of
1287 the Monitor sections. Monitor sections may include the definitions
1288 provided in these sections by using the UseModes keyword. In most
1289 cases the Modes sections are not necessary because the built-in set of
1290 VESA standard modes will be sufficient.
1291 Modes sections have the following format:
1293 Section "Modes"
1295 Identifier "name"
1296 entries
1297 ...
1298 EndSection
1299 The Identifier entry specifies the unique name for this set of mode de‐
1301 scriptions. The other entries permitted in Modes sections are the Mode
1302 and ModeLine entries that are described above in the Monitor section.
1303
1305 The config file may have multiple Screen sections. There must be at
1306 least one, for the “screen” being used. A “screen” represents the
1307 binding of a graphics device (Device section) and a monitor (Monitor
1308 section). A Screen section is considered “active” if it is referenced
1309 by an active ServerLayout section or by the -screen command line op‐
1310 tion. If neither of those is present, the first Screen section found
1311 in the config file is considered the active one.
1312 Screen sections have the following format:
1314 Section "Screen"
1316 Identifier "name"
1317 Device "devid"
1318 GPUDevice "devid"
1319 Monitor "monid"
1320 entries
1321 ...
1322 SubSection "Display"
1323 entries
1324 ...
1325 EndSubSection
1326 ...
1327 EndSection
1328 The Identifier entry is mandatory. All others are optional.
1330 The Identifier entry specifies the unique name for this screen. The
1332 Screen section provides information specific to the whole screen, in‐
1333 cluding screen-specific Options. In multi-head configurations, there
1334 will be multiple active Screen sections, one for each head. The en‐
1335 tries available for this section are:
1336 Device "device-id"
1338 This entry specifies the Device section to be used for this
1339 screen. When multiple graphics cards are present, this is what
1340 ties a specific card to a screen. The device-id must match the
1341 Identifier of a Device section in the config file.
1342 GPUDevice "device-id"
1344 This entry specifies the Device section to be used as a sec‐
1345 ondary GPU device for this screen. When multiple graphics cards
1346 are present, this is what ties a specific secondary card to a
1347 screen. The device-id must match the Identifier of a Device
1348 section in the config file. This can be specified up to 4 times
1349 for a single screen.
1350 Monitor "monitor-id"
1352 specifies which monitor description is to be used for this
1353 screen. If a Monitor name is not specified, a default configu‐
1354 ration is used. Currently the default configuration may not
1355 function as expected on all platforms.
1356 VideoAdaptor "xv-id"
1358 specifies an optional Xv video adaptor description to be used
1359 with this screen.
1360 DefaultDepth depth
1362 specifies which color depth the server should use by default.
1363 The -depth command line option can be used to override this. If
1364 neither is specified, the default depth is driver-specific, but
1365 in most cases is 8.
1366 DefaultFbBpp bpp
1368 specifies which framebuffer layout to use by default. The
1369 -fbbpp command line option can be used to override this. In
1370 most cases the driver will chose the best default value for
1371 this. The only case where there is even a choice in this value
1372 is for depth 24, where some hardware supports both a packed 24
1373 bit framebuffer layout and a sparse 32 bit framebuffer layout.
1374 MatchSeat seat-id
1376 Only apply this Screen section if X server was started with
1377 -seat seat-id option.
1378 Options
1380 Various Option flags may be specified in the Screen section.
1381 Some are driver-specific and are described in the driver docu‐
1382 mentation. Others are driver-independent, and will eventually
1383 be described here.
1384 Option "Accel"
1386 Enables 2D hardware acceleration. This option is on by default,
1387 but it may be necessary to turn it off if there are bugs in the
1388 driver. There are many options to disable specific accelerated
1389 operations, listed below. Note that disabling an operation will
1390 have no effect if the operation is not accelerated (whether due
1391 to lack of support in the hardware or in the driver).
1392 Option "GlxVendorLibrary" "string"
1394 This option specifies a space-separated list of OpenGL vendor
1395 libraries to use for the screen. This may be used to select an
1396 alternate implementation for development, debugging, or alter‐
1397 nate feature sets. Default: mesa.
1398 Option "InitPrimary" "boolean"
1400 Use the Int10 module to initialize the primary graphics card.
1401 Normally, only secondary cards are soft-booted using the Int10
1402 module, as the primary card has already been initialized by the
1403 BIOS at boot time. Default: false.
1404 Option "NoInt10" "boolean"
1406 Disables the Int10 module, a module that uses the int10 call to
1407 the BIOS of the graphics card to initialize it. Default: false.
1408 Each Screen section may optionally contain one or more Display subsec‐
1410 tions. Those subsections provide depth/fbbpp specific configuration
1411 information, and the one chosen depends on the depth and/or fbbpp that
1412 is being used for the screen. The Display subsection format is de‐
1413 scribed in the section below.
1414
1417 Each Screen section may have multiple Display subsections. The “ac‐
1418 tive” Display subsection is the first that matches the depth and/or
1419 fbbpp values being used, or failing that, the first that has neither a
1420 depth or fbbpp value specified. The Display subsections are optional.
1421 When there isn't one that matches the depth and/or fbbpp values being
1422 used, all the parameters that can be specified here fall back to their
1423 defaults.
1424 Display subsections have the following format:
1426 SubSection "Display"
1428 Depth depth
1429 entries
1430 ...
1431 EndSubSection
1432 Depth depth
1434 This entry specifies what colour depth the Display subsection is
1435 to be used for. This entry is usually specified, but it may be
1436 omitted to create a match-all Display subsection or when wishing
1437 to match only against the FbBpp parameter. The range of depth
1438 values that are allowed depends on the driver. Most drivers
1439 support 8, 15, 16 and 24. Some also support 1 and/or 4, and
1440 some may support other values (like 30). Note: depth means the
1441 number of bits in a pixel that are actually used to determine
1442 the pixel colour. 32 is not a valid depth value. Most hardware
1443 that uses 32 bits per pixel only uses 24 of them to hold the
1444 colour information, which means that the colour depth is 24, not
1445 32.
1446 FbBpp bpp
1448 This entry specifies the framebuffer format this Display subsec‐
1449 tion is to be used for. This entry is only needed when provid‐
1450 ing depth 24 configurations that allow a choice between a 24 bpp
1451 packed framebuffer format and a 32bpp sparse framebuffer format.
1452 In most cases this entry should not be used.
1453 Weight red-weight green-weight blue-weight
1455 This optional entry specifies the relative RGB weighting to be
1456 used for a screen is being used at depth 16 for drivers that al‐
1457 low multiple formats. This may also be specified from the com‐
1458 mand line with the -weight option (see Xorg(1)).
1459 Virtual xdim ydim
1461 This optional entry specifies the virtual screen resolution to
1462 be used. xdim must be a multiple of either 8 or 16 for most
1463 drivers, and a multiple of 32 when running in monochrome mode.
1464 The given value will be rounded down if this is not the case.
1465 Video modes which are too large for the specified virtual size
1466 will be rejected. If this entry is not present, the virtual
1467 screen resolution will be set to accommodate all the valid video
1468 modes given in the Modes entry. Some drivers/hardware combina‐
1469 tions do not support virtual screens. Refer to the appropriate
1470 driver-specific documentation for details.
1471 ViewPort x0 y0
1473 This optional entry sets the upper left corner of the initial
1474 display. This is only relevant when the virtual screen resolu‐
1475 tion is different from the resolution of the initial video mode.
1476 If this entry is not given, then the initial display will be
1477 centered in the virtual display area.
1478 Modes "mode-name" ...
1480 This optional entry specifies the list of video modes to use.
1481 Each mode-name specified must be in double quotes. They must
1482 correspond to those specified or referenced in the appropriate
1483 Monitor section (including implicitly referenced built-in VESA
1484 standard modes). The server will delete modes from this list
1485 which don't satisfy various requirements. The first valid mode
1486 in this list will be the default display mode for startup. The
1487 list of valid modes is converted internally into a circular
1488 list. It is possible to switch to the next mode with
1489 Ctrl+Alt+Keypad-Plus and to the previous mode with Ctrl+Alt+Key‐
1490 pad-Minus. When this entry is omitted, the valid modes refer‐
1491 enced by the appropriate Monitor section will be used. If the
1492 Monitor section contains no modes, then the selection will be
1493 taken from the built-in VESA standard modes.
1494 Visual "visual-name"
1496 This optional entry sets the default root visual type. This may
1497 also be specified from the command line (see the Xserver(1) man
1498 page). The visual types available for depth 8 are (default is
1499 PseudoColor):
1500 StaticGray
1502 GrayScale
1503 StaticColor
1504 PseudoColor
1505 TrueColor
1506 DirectColor
1507 The visual type available for the depths 15, 16 and 24 are (de‐
1509 fault is TrueColor):
1510 TrueColor
1512 DirectColor
1513 Not all drivers support DirectColor at these depths.
1515 The visual types available for the depth 4 are (default is Stat‐
1517 icColor):
1518 StaticGray
1520 GrayScale
1521 StaticColor
1522 PseudoColor
1523 The visual type available for the depth 1 (monochrome) is Stat‐
1525 icGray.
1526 Black red green blue
1528 This optional entry allows the “black” colour to be specified.
1529 This is only supported at depth 1. The default is black.
1530 White red green blue
1532 This optional entry allows the “white” colour to be specified.
1533 This is only supported at depth 1. The default is white.
1534 Options
1536 Option flags may be specified in the Display subsections. These
1537 may include driver-specific options and driver-independent op‐
1538 tions. The former are described in the driver-specific documen‐
1539 tation. Some of the latter are described above in the section
1540 about the Screen section, and they may also be included here.
1541
1543 The config file may have multiple ServerLayout sections. A “server
1544 layout” represents the binding of one or more screens (Screen sections)
1545 and one or more input devices (InputDevice sections) to form a complete
1546 configuration. In multi-head configurations, it also specifies the
1547 relative layout of the heads. A ServerLayout section is considered
1548 “active” if it is referenced by the -layout command line option or by
1549 an Option "DefaultServerLayout" entry in the ServerFlags section (the
1550 former takes precedence over the latter). If those options are not
1551 used, the first ServerLayout section found in the config file is con‐
1552 sidered the active one. If no ServerLayout sections are present, the
1553 single active screen and two active (core) input devices are selected
1554 as described in the relevant sections above.
1555 ServerLayout sections have the following format:
1557 Section "ServerLayout"
1559 Identifier "name"
1560 Screen "screen-id"
1561 ...
1562 InputDevice "idev-id"
1563 ...
1564 options
1565 ...
1566 EndSection
1567 Each ServerLayout section must have an Identifier entry and at least
1569 one Screen entry.
1570 The Identifier entry specifies the unique name for this server layout.
1572 The ServerLayout section provides information specific to the whole
1573 session, including session-specific Options. The ServerFlags options
1574 (described above) may be specified here, and ones given here override
1575 those given in the ServerFlags section.
1576 The entries that may be used in this section are described here.
1578 Screen screen-num "screen-id" position-information
1580 One of these entries must be given for each screen being used in
1581 a session. The screen-id field is mandatory, and specifies the
1582 Screen section being referenced. The screen-num field is op‐
1583 tional, and may be used to specify the screen number in
1584 multi-head configurations. When this field is omitted, the
1585 screens will be numbered in the order that they are listed in.
1586 The numbering starts from 0, and must be consecutive. The posi‐
1587 tion-information field describes the way multiple screens are
1588 positioned. There are a number of different ways that this in‐
1589 formation can be provided:
1590 x y
1592 Absolute x y
1594 These both specify that the upper left corner's coordinates
1595 are (x,y). The Absolute keyword is optional. Some older
1596 versions of XFree86 (4.2 and earlier) don't recognise the
1597 Absolute keyword, so it's safest to just specify the coordi‐
1598 nates without it.
1599 RightOf "screen-id"
1601 LeftOf "screen-id"
1603 Above "screen-id"
1605 Below "screen-id"
1607 Relative "screen-id" x y
1609 These give the screen's location relative to another screen.
1610 The first four position the screen immediately to the right,
1611 left, above or below the other screen. When positioning to
1612 the right or left, the top edges are aligned. When posi‐
1613 tioning above or below, the left edges are aligned. The
1614 Relative form specifies the offset of the screen's origin
1615 (upper left corner) relative to the origin of another
1616 screen.
1617 InputDevice "idev-id" "option" ...
1619 One of these entries should be given for each input device being
1620 used in a session. Normally at least two are required, one each
1621 for the core pointer and keyboard devices. If either of those
1622 is missing, suitable InputDevice entries are searched for using
1623 the method described above in the INPUTDEVICE section. The
1624 idev-id field is mandatory, and specifies the name of the Input‐
1625 Device section being referenced. Multiple option fields may be
1626 specified, each in double quotes. The options permitted here
1627 are any that may also be given in the InputDevice sections.
1628 Normally only session-specific input device options would be
1629 used here. The most commonly used options are:
1630 "CorePointer"
1632 "CoreKeyboard"
1633 "SendCoreEvents"
1634 and the first two should normally be used to indicate the core
1636 pointer and core keyboard devices respectively.
1637 MatchSeat seat-id
1639 Only apply this ServerLayout section if X server was started
1640 with -seat seat-id option.
1641 Options
1643 In addition to the following, any option permitted in the
1644 ServerFlags section may also be specified here. When the same
1645 option appears in both places, the value given here overrides
1646 the one given in the ServerFlags section.
1647 Option "IsolateDevice" "bus-id"
1649 Restrict device resets to the specified bus-id. See the BusID
1650 option (described in DEVICE SECTION, above) for the format of
1651 the bus-id parameter. This option overrides SingleCard, if
1652 specified. At present, only PCI devices can be isolated in this
1653 manner.
1654 Option "SingleCard" "boolean"
1656 As IsolateDevice, except that the bus ID of the first device in
1657 the layout is used.
1658 Here is an example of a ServerLayout section for a dual headed configu‐
1660 ration with two mice:
1661 Section "ServerLayout"
1663 Identifier "Layout 1"
1664 Screen "MGA 1"
1665 Screen "MGA 2" RightOf "MGA 1"
1666 InputDevice "Keyboard 1" "CoreKeyboard"
1667 InputDevice "Mouse 1" "CorePointer"
1668 InputDevice "Mouse 2" "SendCoreEvents"
1669 Option "BlankTime" "5"
1670 EndSection
1671
1673 This optional section is used to provide some information for the Di‐
1674 rect Rendering Infrastructure. Details about the format of this sec‐
1675 tion can be found on-line at <https://dri.freedesktop.org/>.
1676
1678 The optional Vendor section may be used to provide vendor-specific con‐
1679 figuration information. Multiple Vendor sections may be present, and
1680 they may contain an Identifier entry and multiple Option flags. The
1681 data therein is not used in this release.
1682
1684 General: X(7), Xserver(1), Xorg(1), cvt(1), gtf(1).
1685 Not all modules or interfaces are available on all platforms.
1687 Display drivers: apm(4), ati(4), chips(4), cirrus(4), cyrix(4), fb‐
1689 dev(4), glide(4), glint(4), i128(4), i740(4), imstt(4), intel(4),
1690 mga(4), neomagic(4), nv(4), openchrome(4), r128(4), radeon(4), rendi‐
1691 tion(4), savage(4), s3virge(4), siliconmotion(4), sis(4), sisusb(4),
1692 sunbw2(4), suncg14(4), suncg3(4), suncg6(4), sunffb(4), sunleo(4),
1693 suntcx(4), tdfx(4), trident(4), tseng(4), vesa(4), vmware(4),
1694 voodoo(4), wsfb(4), xgi(4), xgixp(4).
1695 Input drivers: acecad(4), citron(4), elographics(4), evdev(4), fpit(4),
1697 joystick(4), kbd(4), libinput(4), mousedrv(4), mutouch(4), penmount(4),
1698 synaptics(4), vmmouse(4), void(4), wacom(4).
1699 Other modules and interfaces: exa(4), fbdevhw(4), v4l(4).
1701
1703 This manual page was largely rewritten by David Dawes
1704 <dawes@xfree86.org>.
1705X Version 11 xorg-server 1.20.11 xorg.conf(5)