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. Option "AllowByteSwappedClients" "boolean"
444 Allow clients with a different byte-order than the server. Dis‐
445 abled by default.
446
448 The Module section is used to specify which Xorg server modules should
449 be loaded. This section is ignored when the Xorg server is built in
450 static form. The type of modules normally loaded in this section are
451 Xorg server extension modules. Most other module types are loaded au‐
452 tomatically when they are needed via other mechanisms. The Module sec‐
453 tion is optional, as are all of the entries that may be specified in
454 it.
455 Entries in this section may be in two forms. The first and most com‐
457 monly used form is an entry that uses the Load keyword, as described
458 here:
459 Load "modulename"
461 This instructs the server to load the module called modulename.
462 The module name given should be the module's standard name, not
463 the module file name. The standard name is case-sensitive, and
464 does not include the “lib” or “cyg” prefixes, or the “.so” or
465 “.dll” suffixes.
466 Example: the DRI extension module can be loaded with the follow‐
468 ing entry:
469 Load "dri"
471 Disable "modulename"
473 This instructs the server to not load the module called module‐
474 name. Some modules are loaded by default in the server, and
475 this overrides that default. If a Load instruction is given for
476 the same module, it overrides the Disable instruction and the
477 module is loaded. The module name given should be the module's
478 standard name, not the module file name. As with the Load in‐
479 struction, the standard name is case-sensitive, and does not in‐
480 clude the "lib" prefix, or the ".a", ".o", or ".so" suffixes.
481 The second form of entry is a SubSection, with the subsection name be‐
483 ing the module name, and the contents of the SubSection being Options
484 that are passed to the module when it is loaded.
485 Example: the extmod module (which contains a miscellaneous group of
487 server extensions) can be loaded, with the XFree86-DGA extension dis‐
488 abled by using the following entry:
489 SubSection "extmod"
491 Option "omit XFree86-DGA"
492 EndSubSection
493 Modules are searched for in each directory specified in the ModulePath
495 search path, and in the drivers, extensions, input, internal, and mul‐
496 timedia subdirectories of each of those directories. In addition to
497 this, operating system specific subdirectories of all the above are
498 searched first if they exist.
499 To see what extension modules are available, check the extensions sub‐
501 directory under:
502 /usr/lib64/xorg/modules
504 The “extmod”, “dbe”, “dri”, “dri2”, “glx”, and “record” extension mod‐
506 ules are loaded automatically, if they are present, unless disabled
507 with "Disable" entries. It is recommended that at very least the
508 “extmod” extension module be loaded. If it isn't, some commonly used
509 server extensions (like the SHAPE extension) will not be available.
510
512 The Extensions section is used to specify which X11 protocol extensions
513 should be enabled or disabled. The Extensions section is optional, as
514 are all of the entries that may be specified in it.
515 Entries in this section are listed as Option statements with the name
517 of the extension as the first argument, and a boolean value as the sec‐
518 ond. The extension name is case-sensitive, and matches the form shown
519 in the output of "Xorg -extension ?".
520 Example: the MIT-SHM extension can be disabled with the follow‐
522 ing entry:
523 Section "Extensions"
525 Option "MIT-SHM" "Disable"
526 EndSection
527
529 The config file may have multiple InputDevice sections. Recent X
530 servers employ HAL or udev backends for input device enumeration and
531 input hotplugging. It is usually not necessary to provide InputDevice
532 sections in the xorg.conf if hotplugging is in use (i.e. AutoAddDevices
533 is enabled). If hotplugging is enabled, InputDevice sections using the
534 mouse, kbd and vmmouse driver will be ignored.
535 If hotplugging is disabled, there will normally be at least two: one
537 for the core (primary) keyboard and one for the core pointer. If ei‐
538 ther of these two is missing, a default configuration for the missing
539 ones will be used. In the absence of an explicitly specified core input
540 device, the first InputDevice marked as CorePointer (or CoreKeyboard)
541 is used. If there is no match there, the first InputDevice that uses
542 the “mouse” (or “kbd”) driver is used. The final fallback is to use
543 built-in default configurations. Currently the default configuration
544 may not work as expected on all platforms.
545 InputDevice sections have the following format:
547 Section "InputDevice"
549 Identifier "name"
550 Driver "inputdriver"
551 options
552 ...
553 EndSection
554 The Identifier and Driver entries are required in all InputDevice sec‐
556 tions. All other entries are optional.
557 The Identifier entry specifies the unique name for this input device.
559 The Driver entry specifies the name of the driver to use for this input
560 device. When using the loadable server, the input driver module "in‐
561 putdriver" will be loaded for each active InputDevice section. An In‐
562 putDevice section is considered active if it is referenced by an active
563 ServerLayout section, if it is referenced by the -keyboard or -pointer
564 command line options, or if it is selected implicitly as the core
565 pointer or keyboard device in the absence of such explicit references.
566 The most commonly used input drivers are evdev(4) on Linux systems, and
567 kbd(4) and mousedrv(4) on other platforms.
568 InputDevice sections recognise some driver-independent Options, which
570 are described here. See the individual input driver manual pages for a
571 description of the device-specific options.
572 Option "AutoServerLayout" "boolean"
574 Always add the device to the ServerLayout section used by this
575 instance of the server. This affects implied layouts as well as
576 explicit layouts specified in the configuration and/or on the
577 command line.
578 Option "CorePointer"
580 Deprecated, see Floating
581 Option "CoreKeyboard"
583 Deprecated, see Floating
584 Option "AlwaysCore" "boolean"
586 Deprecated, see Floating
587 Option "SendCoreEvents" "boolean"
589 Deprecated, see Floating
590 Option "Floating" "boolean"
593 When enabled, the input device is set up floating and does not
594 report events through any master device or control a cursor. The
595 device is only available to clients using the X Input Extension
596 API. This option is disabled by default. The options Core‐
597 Pointer, CoreKeyboard, AlwaysCore, and SendCoreEvents, are the
598 inverse of option Floating (i.e. SendCoreEvents "on" is equiva‐
599 lent to Floating "off" ).
600 This option controls the startup behavior only, a device may be
602 reattached or set floating at runtime.
603 Option "TransformationMatrix" "a b c d e f g h i"
605 Specifies the 3x3 transformation matrix for absolute input de‐
606 vices. The input device will be bound to the area given in the
607 matrix. In most configurations, "a" and "e" specify the width
608 and height of the area the device is bound to, and "c" and "f"
609 specify the x and y offset of the area. The value range is 0 to
610 1, where 1 represents the width or height of all root windows
611 together, 0.5 represents half the area, etc. The values repre‐
612 sent a 3x3 matrix, with the first, second and third group of
613 three values representing the first, second and third row of the
614 matrix, respectively. The identity matrix is "1 0 0 0 1 0 0 0
615 1".
616 POINTER ACCELERATION
618 For pointing devices, the following options control how the pointer is
619 accelerated or decelerated with respect to physical device motion. Most
620 of these can be adjusted at runtime, see the xinput(1) man page for de‐
621 tails. Only the most important acceleration options are discussed here.
622 Option "AccelerationProfile" "integer"
624 Select the profile. In layman's terms, the profile constitutes
625 the "feeling" of the acceleration. More formally, it defines how
626 the transfer function (actual acceleration as a function of cur‐
627 rent device velocity and acceleration controls) is constructed.
628 This is mainly a matter of personal preference.
629 0 classic (mostly compatible)
631 -1 none (only constant deceleration is applied)
632 1 device-dependent
633 2 polynomial (polynomial function)
634 3 smooth linear (soft knee, then linear)
635 4 simple (normal when slow, otherwise accelerated)
636 5 power (power function)
637 6 linear (more speed, more acceleration)
638 7 limited (like linear, but maxes out at threshold)
639 Option "ConstantDeceleration" "real"
641 Makes the pointer go deceleration times slower than normal. Most
642 useful for high-resolution devices. A value between 0 and 1 will
643 speed up the pointer.
644 Option "AdaptiveDeceleration" "real"
646 Allows to actually decelerate the pointer when going slow. At
647 most, it will be adaptive deceleration times slower. Enables
648 precise pointer placement without sacrificing speed.
649 Option "AccelerationScheme" "string"
651 Selects the scheme, which is the underlying algorithm.
652 predictable default algorithm (behaving more predictable)
654 lightweight old acceleration code (as specified in the X protocol spec)
655 none no acceleration or deceleration
656 Option "AccelerationNumerator" "integer"
658 Option "AccelerationDenominator" "integer"
660 Set numerator and denominator of the acceleration factor. The
661 acceleration factor is a rational which, together with thresh‐
662 old, can be used to tweak profiles to suit the users needs. The
663 simple and limited profiles use it directly (i.e. they acceler‐
664 ate by the factor), for other profiles it should hold that a
665 higher acceleration factor leads to a faster pointer. Typically,
666 1 is unaccelerated and values up to 5 are sensible.
667 Option "AccelerationThreshold" "integer"
669 Set the threshold, which is roughly the velocity (usually device
670 units per 10 ms) required for acceleration to become effective.
671 The precise effect varies with the profile however.
672
675 The config file may have multiple InputClass sections. These sections
676 are optional and are used to provide configuration for a class of input
677 devices as they are automatically added. An input device can match more
678 than one InputClass section. Each class can override settings from a
679 previous class, so it is best to arrange the sections with the most
680 generic matches first.
681 InputClass sections have the following format:
683 Section "InputClass"
685 Identifier "name"
686 entries
687 ...
688 options
689 ...
690 EndSection
691 The Identifier entry is required in all InputClass sections. All other
693 entries are optional.
694 The Identifier entry specifies the unique name for this input class.
696 The Driver entry specifies the name of the driver to use for this input
697 device. After all classes have been examined, the "inputdriver" module
698 from the first Driver entry will be enabled when using the loadable
699 server.
700 When an input device is automatically added, its characteristics are
702 checked against all InputClass sections. Each section can contain op‐
703 tional entries to narrow the match of the class. If none of the op‐
704 tional entries appear, the InputClass section is generic and will match
705 any input device. If more than one of these entries appear, they all
706 must match for the configuration to apply.
707 There are two types of match entries used in InputClass sections. The
709 first allows various tokens to be matched against attributes of the de‐
710 vice. An entry can be constructed to match attributes from different
711 devices by separating arguments with a '|' character. Multiple entries
712 of the same type may be supplied to add multiple matching conditions on
713 the same attribute. For example:
714 Section "InputClass"
716 Identifier "My Class"
717 # product string must contain example and
718 # either gizmo or gadget
719 MatchProduct "example"
720 MatchProduct "gizmo|gadget"
721 NoMatchDriver "drivername"
722 ...
723 EndSection
724 MatchProduct "matchproduct"
726 This entry can be used to check if the substring "matchproduct"
727 occurs in the device's product name.
728 MatchVendor "matchvendor"
730 This entry can be used to check if the substring "matchvendor"
731 occurs in the device's vendor name.
732 MatchDevicePath "matchdevice"
734 This entry can be used to check if the device file matches the
735 "matchdevice" pathname pattern.
736 MatchOS "matchos"
738 This entry can be used to check if the operating system matches
739 the case-insensitive "matchos" string. This entry is only sup‐
740 ported on platforms providing the uname(2) system call.
741 MatchPnPID "matchpnp"
743 The device's Plug and Play (PnP) ID can be checked against the
744 "matchpnp" shell wildcard pattern.
745 MatchUSBID "matchusb"
747 The device's USB ID can be checked against the "matchusb" shell
748 wildcard pattern. The ID is constructed as lowercase hexadecimal
749 numbers separated by a ':'. This is the same format as the
750 lsusb(8) program.
751 MatchDriver "matchdriver"
753 Check the case-sensitive string "matchdriver" against the cur‐
754 rently configured driver of the device. Ordering of sections us‐
755 ing this entry is important since it will not match unless the
756 driver has been set by the config backend or a previous Input‐
757 Class section.
758 MatchTag "matchtag"
760 This entry can be used to check if tags assigned by the config
761 backend matches the "matchtag" pattern. A match is found if at
762 least one of the tags given in "matchtag" matches at least one
763 of the tags assigned by the backend.
764 MatchLayout "matchlayout"
766 Check the case-sensitive string "matchlayout" against the cur‐
767 rently active ServerLayout section. The empty string "" matches
768 an implicit layout which appears if no named ServerLayout sec‐
769 tions have been found.
770 The above directives have equivalents for negative matching with the
772 NoMatchProduct, NoMatchVendor, NoMatchDevicePath, NoMatchOS, NoMatchPn‐
773 PID, NoMatchUSBID, NoMatchDriver, NoMatchTag, and NoMatchLayout direc‐
774 tives. These NoMatch directives match if the subsequent match is not
775 met by the device.
776 The second type of entry is used to match device types. These entries
778 take a boolean argument similar to Option entries.
779 MatchIsKeyboard "bool"
781 MatchIsPointer "bool"
783 MatchIsJoystick "bool"
785 MatchIsTablet "bool"
787 MatchIsTabletPad "bool"
789 MatchIsTouchpad "bool"
791 MatchIsTouchscreen "bool"
793 When an input device has been matched to the InputClass section, any
795 Option entries are applied to the device. One InputClass specific Op‐
796 tion is recognized. See the InputDevice section above for a description
797 of the remaining Option entries.
798 Option "Ignore" "boolean"
800 This optional entry specifies that the device should be ignored
801 entirely, and not added to the server. This can be useful when
802 the device is handled by another program and no X events should
803 be generated.
804
806 The config file may have multiple OutputClass sections. These sections
807 are optional and are used to provide configuration for a class of out‐
808 put devices as they are automatically added. An output device can
809 match more than one OutputClass section. Each class can override set‐
810 tings from a previous class, so it is best to arrange the sections with
811 the most generic matches first.
812 OutputClass sections have the following format:
814 Section "OutputClass"
816 Identifier "name"
817 entries
818 ...
819 EndSection
820 The Identifier entry is required in all OutputClass sections. All
822 other entries are optional.
823 The Identifier entry specifies the unique name for this output class.
825 The Driver entry specifies the name of the driver to use for this out‐
826 put device. After all classes have been examined, the "outputdriver"
827 module from the first Driver entry will be enabled when using the load‐
828 able server.
829 When an output device is automatically added, its characteristics are
831 checked against all OutputClass sections. Each section can contain op‐
832 tional entries to narrow the match of the class. If none of the op‐
833 tional entries appear, the OutputClass section is generic and will
834 match any output device. If more than one of these entries appear,
835 they all must match for the configuration to apply.
836 The following list of tokens can be matched against attributes of the
838 device. An entry can be constructed to match attributes from different
839 devices by separating arguments with a '|' character.
840 For example:
842 Section "OutputClass"
844 Identifier "My Class"
845 # kernel driver must be either foo or bar
846 MatchDriver "foo|bar"
847 ...
848 EndSection
849 MatchDriver "matchdriver"
851 Check the case-sensitive string "matchdriver" against the kernel
852 driver of the device.
853 When an output device has been matched to the OutputClass section, any
855 Option entries are applied to the device. One OutputClass specific Op‐
856 tion is recognized. See the Device section below for a description of
857 the remaining Option entries.
858 Option "PrimaryGPU" "boolean"
860 This option specifies that the matched device should be treated
861 as the primary GPU, replacing the selection of the GPU used as
862 output by the firmware. If multiple output devices match an Out‐
863 putClass section with the PrimaryGPU option set, the first one
864 enumerated becomes the primary GPU.
865 A OutputClass Section may contain ModulePath entries. When an output
867 device matches an OutputClass section, any ModulePath entries in that
868 OutputClass are pre-pended to the search path for loadable Xorg server
869 modules. See ModulePath in the Files section for more info.
870
872 The config file may have multiple Device sections. There must be at
873 least one, for the video card being used.
874 Device sections have the following format:
876 Section "Device"
878 Identifier "name"
879 Driver "driver"
880 entries
881 ...
882 EndSection
883 The Identifier and Driver entries are required in all Device sections.
885 All other entries are optional.
886 The Identifier entry specifies the unique name for this graphics de‐
888 vice. The Driver entry specifies the name of the driver to use for
889 this graphics device. When using the loadable server, the driver mod‐
890 ule "driver" will be loaded for each active Device section. A Device
891 section is considered active if it is referenced by an active Screen
892 section.
893 Device sections recognise some driver-independent entries and Options,
895 which are described here. Not all drivers make use of these driver-in‐
896 dependent entries, and many of those that do don't require them to be
897 specified because the information is auto-detected. See the individual
898 graphics driver manual pages for further information about this, and
899 for a description of the device-specific options. Note that most of
900 the Options listed here (but not the other entries) may be specified in
901 the Screen section instead of here in the Device section.
902 BusID "bus-id"
904 This specifies the bus location of the graphics card. For
905 PCI/AGP cards, the bus-id string has the form PCI:bus@domain:de‐
906 vice:function (e.g., “PCI:1@0:0:0” might be appropriate for an
907 AGP card). The "@domain" part can be left out for PCI domain 0.
908 This field is usually optional in single-head configurations
909 when using the primary graphics card. In multi-head configura‐
910 tions, or when using a secondary graphics card in a single-head
911 configuration, this entry is mandatory. Its main purpose is to
912 make an unambiguous connection between the device section and
913 the hardware it is representing. This information can usually
914 be found by running the pciaccess tool scanpci.
915 Screen number
917 This option is mandatory for cards where a single PCI entity can
918 drive more than one display (i.e., multiple CRTCs sharing a sin‐
919 gle graphics accelerator and video memory). One Device section
920 is required for each head, and this parameter determines which
921 head each of the Device sections applies to. The legal values
922 of number range from 0 to one less than the total number of
923 heads per entity. Most drivers require that the primary screen
924 (0) be present.
925 Chipset "chipset"
927 This usually optional entry specifies the chipset used on the
928 graphics board. In most cases this entry is not required be‐
929 cause the drivers will probe the hardware to determine the
930 chipset type. Don't specify it unless the driver-specific docu‐
931 mentation recommends that you do.
932 Ramdac "ramdac-type"
934 This optional entry specifies the type of RAMDAC used on the
935 graphics board. This is only used by a few of the drivers, and
936 in most cases it is not required because the drivers will probe
937 the hardware to determine the RAMDAC type where possible. Don't
938 specify it unless the driver-specific documentation recommends
939 that you do.
940 DacSpeed speed
942 DacSpeed speed-8 speed-16 speed-24 speed-32
944 This optional entry specifies the RAMDAC speed rating (which is
945 usually printed on the RAMDAC chip). The speed is in MHz. When
946 one value is given, it applies to all framebuffer pixel sizes.
947 When multiple values are given, they apply to the framebuffer
948 pixel sizes 8, 16, 24 and 32 respectively. This is not used by
949 many drivers, and only needs to be specified when the speed rat‐
950 ing of the RAMDAC is different from the defaults built in to
951 driver, or when the driver can't auto-detect the correct de‐
952 faults. Don't specify it unless the driver-specific documenta‐
953 tion recommends that you do.
954 Clocks clock ...
956 specifies the pixel that are on your graphics board. The clocks
957 are in MHz, and may be specified as a floating point number.
958 The value is stored internally to the nearest kHz. The ordering
959 of the clocks is important. It must match the order in which
960 they are selected on the graphics board. Multiple Clocks lines
961 may be specified, and each is concatenated to form the list.
962 Most drivers do not use this entry, and it is only required for
963 some older boards with non-programmable clocks. Don't specify
964 this entry unless the driver-specific documentation explicitly
965 recommends that you do.
966 ClockChip "clockchip-type"
968 This optional entry is used to specify the clock chip type on
969 graphics boards which have a programmable clock generator. Only
970 a few Xorg drivers support programmable clock chips. For de‐
971 tails, see the appropriate driver manual page.
972 VideoRam mem
974 This optional entry specifies the amount of video ram that is
975 installed on the graphics board. This is measured in kBytes.
976 In most cases this is not required because the Xorg server
977 probes the graphics board to determine this quantity. The
978 driver-specific documentation should indicate when it might be
979 needed.
980 MemBase baseaddress
982 This optional entry specifies the memory base address of a
983 graphics board's linear frame buffer. This entry is not used by
984 many drivers, and it should only be specified if the driver-spe‐
985 cific documentation recommends it.
986 IOBase baseaddress
988 This optional entry specifies the IO base address. This entry
989 is not used by many drivers, and it should only be specified if
990 the driver-specific documentation recommends it.
991 ChipID id
993 This optional entry specifies a numerical ID representing the
994 chip type. For PCI cards, it is usually the device ID. This
995 can be used to override the auto-detection, but that should only
996 be done when the driver-specific documentation recommends it.
997 ChipRev rev
999 This optional entry specifies the chip revision number. This
1000 can be used to override the auto-detection, but that should only
1001 be done when the driver-specific documentation recommends it.
1002 MatchSeat seat-id
1004 Only apply this Device section if X server was started with
1005 -seat seat-id option.
1006 Option "ModeDebug" "boolean"
1008 Enable printing of additional debugging information about mode‐
1009 setting to the server log.
1010 Option "PreferCloneMode" "boolean"
1012 If enabled, bring up monitors of a screen in clone mode instead
1013 of horizontal extended layout by default. (Defaults to off; the
1014 video driver can change the default value, but this option can
1015 always override it)
1016 Options
1018 Option flags may be specified in the Device sections. These in‐
1019 clude driver-specific options and driver-independent options.
1020 The former are described in the driver-specific documentation.
1021 Some of the latter are described below in the section about the
1022 Screen section, and they may also be included here.
1023
1026 Nobody wants to say how this works. Maybe nobody knows ...
1027
1030 The config file may have multiple Monitor sections. There should nor‐
1031 mally be at least one, for the monitor being used, but a default con‐
1032 figuration will be created when one isn't specified.
1033 Monitor sections have the following format:
1035 Section "Monitor"
1037 Identifier "name"
1038 entries
1039 ...
1040 EndSection
1041 The only mandatory entry in a Monitor section is the Identifier entry.
1043 The Identifier entry specifies the unique name for this monitor. The
1045 Monitor section may be used to provide information about the specifica‐
1046 tions of the monitor, monitor-specific Options, and information about
1047 the video modes to use with the monitor.
1048 With RandR 1.2-enabled drivers, monitor sections may be tied to spe‐
1050 cific outputs of the video card. Using the name of the output defined
1051 by the video driver plus the identifier of a monitor section, one asso‐
1052 ciates a monitor section with an output by adding an option to the De‐
1053 vice section in the following format:
1054 Option "Monitor-outputname" "monitorsection"
1056 (for example, Option "Monitor-VGA" "VGA monitor" for a VGA output)
1058 In the absence of specific association of monitor sections to outputs,
1060 if a monitor section is present the server will associate it with an
1061 output to preserve compatibility for previous single-head configura‐
1062 tions.
1063 Specifying video modes is optional because the server will use the DDC
1065 or other information provided by the monitor to automatically configure
1066 the list of modes available. When modes are specified explicitly in
1067 the Monitor section (with the Mode, ModeLine, or UseModes keywords),
1068 built-in modes with the same names are not included. Built-in modes
1069 with different names are, however, still implicitly included, when they
1070 meet the requirements of the monitor.
1071 The entries that may be used in Monitor sections are described below.
1073 VendorName "vendor"
1075 This optional entry specifies the monitor's manufacturer.
1076 ModelName "model"
1078 This optional entry specifies the monitor's model.
1079 HorizSync horizsync-range
1081 gives the range(s) of horizontal sync frequencies supported by
1082 the monitor. horizsync-range may be a comma separated list of
1083 either discrete values or ranges of values. A range of values
1084 is two values separated by a dash. By default the values are in
1085 units of kHz. They may be specified in MHz or Hz if MHz or Hz
1086 is added to the end of the line. The data given here is used by
1087 the Xorg server to determine if video modes are within the spec‐
1088 ifications of the monitor. This information should be available
1089 in the monitor's handbook. If this entry is omitted, a default
1090 range of 28-33kHz is used.
1091 VertRefresh vertrefresh-range
1093 gives the range(s) of vertical refresh frequencies supported by
1094 the monitor. vertrefresh-range may be a comma separated list of
1095 either discrete values or ranges of values. A range of values
1096 is two values separated by a dash. By default the values are in
1097 units of Hz. They may be specified in MHz or kHz if MHz or kHz
1098 is added to the end of the line. The data given here is used by
1099 the Xorg server to determine if video modes are within the spec‐
1100 ifications of the monitor. This information should be available
1101 in the monitor's handbook. If this entry is omitted, a default
1102 range of 43-72Hz is used.
1103 DisplaySize width height
1105 This optional entry gives the width and height, in millimetres,
1106 of the picture area of the monitor. If given this is used to
1107 calculate the horizontal and vertical pitch (DPI) of the screen.
1108 Gamma gamma-value
1110 Gamma red-gamma green-gamma blue-gamma
1112 This is an optional entry that can be used to specify the gamma
1113 correction for the monitor. It may be specified as either a
1114 single value or as three separate RGB values. The values should
1115 be in the range 0.1 to 10.0, and the default is 1.0. Not all
1116 drivers are capable of using this information.
1117 UseModes "modesection-id"
1119 Include the set of modes listed in the Modes section called mod‐
1120 esection-id. This makes all of the modes defined in that sec‐
1121 tion available for use by this monitor.
1122 Mode "name"
1124 This is an optional multi-line entry that can be used to provide
1125 definitions for video modes for the monitor. In most cases this
1126 isn't necessary because the built-in set of VESA standard modes
1127 will be sufficient. The Mode keyword indicates the start of a
1128 multi-line video mode description. The mode description is ter‐
1129 minated with the EndMode keyword. The mode description consists
1130 of the following entries:
1131 DotClock clock
1133 is the dot (pixel) clock rate to be used for the mode.
1134 HTimings hdisp hsyncstart hsyncend htotal
1136 specifies the horizontal timings for the mode.
1137 VTimings vdisp vsyncstart vsyncend vtotal
1139 specifies the vertical timings for the mode.
1140 Flags "flag" ...
1142 specifies an optional set of mode flags, each of which is a
1143 separate string in double quotes. "Interlace" indicates
1144 that the mode is interlaced. "DoubleScan" indicates a mode
1145 where each scanline is doubled. "+HSync" and "-HSync" can
1146 be used to select the polarity of the HSync signal.
1147 "+VSync" and "-VSync" can be used to select the polarity of
1148 the VSync signal. "Composite" can be used to specify com‐
1149 posite sync on hardware where this is supported. Addition‐
1150 ally, on some hardware, "+CSync" and "-CSync" may be used to
1151 select the composite sync polarity.
1152 HSkew hskew
1154 specifies the number of pixels (towards the right edge of
1155 the screen) by which the display enable signal is to be
1156 skewed. Not all drivers use this information. This option
1157 might become necessary to override the default value sup‐
1158 plied by the server (if any). “Roving” horizontal lines in‐
1159 dicate this value needs to be increased. If the last few
1160 pixels on a scan line appear on the left of the screen, this
1161 value should be decreased.
1162 VScan vscan
1164 specifies the number of times each scanline is painted on
1165 the screen. Not all drivers use this information. Values
1166 less than 1 are treated as 1, which is the default. Gener‐
1167 ally, the "DoubleScan" Flag mentioned above doubles this
1168 value.
1169 ModeLine "name" mode-description
1171 This entry is a more compact version of the Mode entry, and it
1172 also can be used to specify video modes for the monitor. This
1173 is a single line format for specifying video modes. In most
1174 cases this isn't necessary because the built-in set of VESA
1175 standard modes will be sufficient.
1176 The mode-description is in four sections, the first three of
1178 which are mandatory. The first is the dot (pixel) clock. This
1179 is a single number specifying the pixel clock rate for the mode
1180 in MHz. The second section is a list of four numbers specifying
1181 the horizontal timings. These numbers are the hdisp, hsync‐
1182 start, hsyncend, and htotal values. The third section is a list
1183 of four numbers specifying the vertical timings. These numbers
1184 are the vdisp, vsyncstart, vsyncend, and vtotal values. The fi‐
1185 nal section is a list of flags specifying other characteristics
1186 of the mode. Interlace indicates that the mode is interlaced.
1187 DoubleScan indicates a mode where each scanline is doubled.
1188 +HSync and -HSync can be used to select the polarity of the
1189 HSync signal. +VSync and -VSync can be used to select the po‐
1190 larity of the VSync signal. Composite can be used to specify
1191 composite sync on hardware where this is supported. Addition‐
1192 ally, on some hardware, +CSync and -CSync may be used to select
1193 the composite sync polarity. The HSkew and VScan options men‐
1194 tioned above in the Mode entry description can also be used
1195 here.
1196 Option "DPMS" "bool"
1198 This option controls whether the server should enable the DPMS
1199 extension for power management for this screen. The default is
1200 to enable the extension.
1201 Option "SyncOnGreen" "bool"
1203 This option controls whether the video card should drive the
1204 sync signal on the green color pin. Not all cards support this
1205 option, and most monitors do not require it. The default is
1206 off.
1207 Option "Primary" "bool"
1209 This optional entry specifies that the monitor should be treated
1210 as the primary monitor. (RandR 1.2-supporting drivers only)
1211 Option "PreferredMode" "name"
1213 This optional entry specifies a mode to be marked as the pre‐
1214 ferred initial mode of the monitor. (RandR 1.2-supporting driv‐
1215 ers only)
1216 Option "ZoomModes" "name name ..."
1218 This optional entry specifies modes to be marked as zoom modes.
1219 It is possible to switch to the next and previous mode via
1220 Ctrl+Alt+Keypad-Plus and Ctrl+Alt+Keypad-Minus. All these key‐
1221 pad available modes are selected from the screen mode list.
1222 This list is a copy of the compatibility output monitor mode
1223 list. Since this output is the output connected to the lowest
1224 dot-area monitor, as determined from its largest size mode, that
1225 monitor defines the available zoom modes. (RandR 1.2-supporting
1226 drivers only)
1227 Option "Position" "x y"
1229 This optional entry specifies the position of the monitor within
1230 the X screen. (RandR 1.2-supporting drivers only)
1231 Option "LeftOf" "output"
1233 This optional entry specifies that the monitor should be posi‐
1234 tioned to the left of the output (not monitor) of the given
1235 name. (RandR 1.2-supporting drivers only)
1236 Option "RightOf" "output"
1238 This optional entry specifies that the monitor should be posi‐
1239 tioned to the right of the output (not monitor) of the given
1240 name. (RandR 1.2-supporting drivers only)
1241 Option "Above" "output"
1243 This optional entry specifies that the monitor should be posi‐
1244 tioned above the output (not monitor) of the given name. (RandR
1245 1.2-supporting drivers only)
1246 Option "Below" "output"
1248 This optional entry specifies that the monitor should be posi‐
1249 tioned below the output (not monitor) of the given name. (RandR
1250 1.2-supporting drivers only)
1251 Option "Enable" "bool"
1253 This optional entry specifies whether the monitor should be
1254 turned on at startup. By default, the server will attempt to
1255 enable all connected monitors. (RandR 1.2-supporting drivers
1256 only)
1257 Option "DefaultModes" "bool"
1259 This optional entry specifies whether the server should add sup‐
1260 ported default modes to the list of modes offered on this moni‐
1261 tor. By default, the server will add default modes; you should
1262 only disable this if you can guarantee that EDID will be avail‐
1263 able at all times, or if you have added custom modelines which
1264 the server can use. (RandR 1.2-supporting drivers only)
1265 Option "MinClock" "frequency"
1267 This optional entry specifies the minimum dot clock, in kHz,
1268 that is supported by the monitor.
1269 Option "MaxClock" "frequency"
1271 This optional entry specifies the maximum dot clock, in kHz,
1272 that is supported by the monitor.
1273 Option "Ignore" "bool"
1275 This optional entry specifies that the monitor should be ignored
1276 entirely, and not reported through RandR. This is useful if the
1277 hardware reports the presence of outputs that don't exist.
1278 (RandR 1.2-supporting drivers only)
1279 Option "Rotate" "rotation"
1281 This optional entry specifies the initial rotation of the given
1282 monitor. Valid values for rotation are "normal", "left",
1283 "right", and "inverted". (RandR 1.2-supporting drivers only)
1284
1287 The config file may have multiple Modes sections, or none. These sec‐
1288 tions provide a way of defining sets of video modes independently of
1289 the Monitor sections. Monitor sections may include the definitions
1290 provided in these sections by using the UseModes keyword. In most
1291 cases the Modes sections are not necessary because the built-in set of
1292 VESA standard modes will be sufficient.
1293 Modes sections have the following format:
1295 Section "Modes"
1297 Identifier "name"
1298 entries
1299 ...
1300 EndSection
1301 The Identifier entry specifies the unique name for this set of mode de‐
1303 scriptions. The other entries permitted in Modes sections are the Mode
1304 and ModeLine entries that are described above in the Monitor section.
1305
1307 The config file may have multiple Screen sections. There must be at
1308 least one, for the “screen” being used. A “screen” represents the
1309 binding of a graphics device (Device section) and a monitor (Monitor
1310 section). A Screen section is considered “active” if it is referenced
1311 by an active ServerLayout section or by the -screen command line op‐
1312 tion. If neither of those is present, the first Screen section found
1313 in the config file is considered the active one.
1314 Screen sections have the following format:
1316 Section "Screen"
1318 Identifier "name"
1319 Device "devid"
1320 GPUDevice "devid"
1321 Monitor "monid"
1322 entries
1323 ...
1324 SubSection "Display"
1325 entries
1326 ...
1327 EndSubSection
1328 ...
1329 EndSection
1330 The Identifier entry is mandatory. All others are optional.
1332 The Identifier entry specifies the unique name for this screen. The
1334 Screen section provides information specific to the whole screen, in‐
1335 cluding screen-specific Options. In multi-head configurations, there
1336 will be multiple active Screen sections, one for each head. The en‐
1337 tries available for this section are:
1338 Device "device-id"
1340 This entry specifies the Device section to be used for this
1341 screen. When multiple graphics cards are present, this is what
1342 ties a specific card to a screen. The device-id must match the
1343 Identifier of a Device section in the config file.
1344 GPUDevice "device-id"
1346 This entry specifies the Device section to be used as a sec‐
1347 ondary GPU device for this screen. When multiple graphics cards
1348 are present, this is what ties a specific secondary card to a
1349 screen. The device-id must match the Identifier of a Device
1350 section in the config file. This can be specified up to 4 times
1351 for a single screen.
1352 Monitor "monitor-id"
1354 specifies which monitor description is to be used for this
1355 screen. If a Monitor name is not specified, a default configu‐
1356 ration is used. Currently the default configuration may not
1357 function as expected on all platforms.
1358 VideoAdaptor "xv-id"
1360 specifies an optional Xv video adaptor description to be used
1361 with this screen.
1362 DefaultDepth depth
1364 specifies which color depth the server should use by default.
1365 The -depth command line option can be used to override this. If
1366 neither is specified, the default depth is driver-specific, but
1367 in most cases is 8.
1368 DefaultFbBpp bpp
1370 specifies which framebuffer layout to use by default. The
1371 -fbbpp command line option can be used to override this. In
1372 most cases the driver will chose the best default value for
1373 this. The only case where there is even a choice in this value
1374 is for depth 24, where some hardware supports both a packed 24
1375 bit framebuffer layout and a sparse 32 bit framebuffer layout.
1376 MatchSeat seat-id
1378 Only apply this Screen section if X server was started with
1379 -seat seat-id option.
1380 Options
1382 Various Option flags may be specified in the Screen section.
1383 Some are driver-specific and are described in the driver docu‐
1384 mentation. Others are driver-independent, and will eventually
1385 be described here.
1386 Option "Accel"
1388 Enables 2D hardware acceleration. This option is on by default,
1389 but it may be necessary to turn it off if there are bugs in the
1390 driver. There are many options to disable specific accelerated
1391 operations, listed below. Note that disabling an operation will
1392 have no effect if the operation is not accelerated (whether due
1393 to lack of support in the hardware or in the driver).
1394 Option "GlxVendorLibrary" "string"
1396 This option specifies a space-separated list of OpenGL vendor
1397 libraries to use for the screen. This may be used to select an
1398 alternate implementation for development, debugging, or alter‐
1399 nate feature sets. Default: mesa.
1400 Option "InitPrimary" "boolean"
1402 Use the Int10 module to initialize the primary graphics card.
1403 Normally, only secondary cards are soft-booted using the Int10
1404 module, as the primary card has already been initialized by the
1405 BIOS at boot time. Default: false.
1406 Option "NoInt10" "boolean"
1408 Disables the Int10 module, a module that uses the int10 call to
1409 the BIOS of the graphics card to initialize it. Default: false.
1410 Each Screen section may optionally contain one or more Display subsec‐
1412 tions. Those subsections provide depth/fbbpp specific configuration
1413 information, and the one chosen depends on the depth and/or fbbpp that
1414 is being used for the screen. The Display subsection format is de‐
1415 scribed in the section below.
1416
1419 Each Screen section may have multiple Display subsections. The “ac‐
1420 tive” Display subsection is the first that matches the depth and/or
1421 fbbpp values being used, or failing that, the first that has neither a
1422 depth or fbbpp value specified. The Display subsections are optional.
1423 When there isn't one that matches the depth and/or fbbpp values being
1424 used, all the parameters that can be specified here fall back to their
1425 defaults.
1426 Display subsections have the following format:
1428 SubSection "Display"
1430 Depth depth
1431 entries
1432 ...
1433 EndSubSection
1434 Depth depth
1436 This entry specifies what colour depth the Display subsection is
1437 to be used for. This entry is usually specified, but it may be
1438 omitted to create a match-all Display subsection or when wishing
1439 to match only against the FbBpp parameter. The range of depth
1440 values that are allowed depends on the driver. Most drivers
1441 support 8, 15, 16 and 24. Some also support 1 and/or 4, and
1442 some may support other values (like 30). Note: depth means the
1443 number of bits in a pixel that are actually used to determine
1444 the pixel colour. 32 is not a valid depth value. Most hardware
1445 that uses 32 bits per pixel only uses 24 of them to hold the
1446 colour information, which means that the colour depth is 24, not
1447 32.
1448 FbBpp bpp
1450 This entry specifies the framebuffer format this Display subsec‐
1451 tion is to be used for. This entry is only needed when provid‐
1452 ing depth 24 configurations that allow a choice between a 24 bpp
1453 packed framebuffer format and a 32bpp sparse framebuffer format.
1454 In most cases this entry should not be used.
1455 Weight red-weight green-weight blue-weight
1457 This optional entry specifies the relative RGB weighting to be
1458 used for a screen is being used at depth 16 for drivers that al‐
1459 low multiple formats. This may also be specified from the com‐
1460 mand line with the -weight option (see Xorg(1)).
1461 Virtual xdim ydim
1463 This optional entry specifies the virtual screen resolution to
1464 be used. xdim must be a multiple of either 8 or 16 for most
1465 drivers, and a multiple of 32 when running in monochrome mode.
1466 The given value will be rounded down if this is not the case.
1467 Video modes which are too large for the specified virtual size
1468 will be rejected. If this entry is not present, the virtual
1469 screen resolution will be set to accommodate all the valid video
1470 modes given in the Modes entry. Some drivers/hardware combina‐
1471 tions do not support virtual screens. Refer to the appropriate
1472 driver-specific documentation for details.
1473 ViewPort x0 y0
1475 This optional entry sets the upper left corner of the initial
1476 display. This is only relevant when the virtual screen resolu‐
1477 tion is different from the resolution of the initial video mode.
1478 If this entry is not given, then the initial display will be
1479 centered in the virtual display area.
1480 Modes "mode-name" ...
1482 This optional entry specifies the list of video modes to use.
1483 Each mode-name specified must be in double quotes. They must
1484 correspond to those specified or referenced in the appropriate
1485 Monitor section (including implicitly referenced built-in VESA
1486 standard modes). The server will delete modes from this list
1487 which don't satisfy various requirements. The first valid mode
1488 in this list will be the default display mode for startup. The
1489 list of valid modes is converted internally into a circular
1490 list. It is possible to switch to the next mode with
1491 Ctrl+Alt+Keypad-Plus and to the previous mode with Ctrl+Alt+Key‐
1492 pad-Minus. When this entry is omitted, the valid modes refer‐
1493 enced by the appropriate Monitor section will be used. If the
1494 Monitor section contains no modes, then the selection will be
1495 taken from the built-in VESA standard modes.
1496 Visual "visual-name"
1498 This optional entry sets the default root visual type. This may
1499 also be specified from the command line (see the Xserver(1) man
1500 page). The visual types available for depth 8 are (default is
1501 PseudoColor):
1502 StaticGray
1504 GrayScale
1505 StaticColor
1506 PseudoColor
1507 TrueColor
1508 DirectColor
1509 The visual type available for the depths 15, 16 and 24 are (de‐
1511 fault is TrueColor):
1512 TrueColor
1514 DirectColor
1515 Not all drivers support DirectColor at these depths.
1517 The visual types available for the depth 4 are (default is Stat‐
1519 icColor):
1520 StaticGray
1522 GrayScale
1523 StaticColor
1524 PseudoColor
1525 The visual type available for the depth 1 (monochrome) is Stat‐
1527 icGray.
1528 Black red green blue
1530 This optional entry allows the “black” colour to be specified.
1531 This is only supported at depth 1. The default is black.
1532 White red green blue
1534 This optional entry allows the “white” colour to be specified.
1535 This is only supported at depth 1. The default is white.
1536 Options
1538 Option flags may be specified in the Display subsections. These
1539 may include driver-specific options and driver-independent op‐
1540 tions. The former are described in the driver-specific documen‐
1541 tation. Some of the latter are described above in the section
1542 about the Screen section, and they may also be included here.
1543
1545 The config file may have multiple ServerLayout sections. A “server
1546 layout” represents the binding of one or more screens (Screen sections)
1547 and one or more input devices (InputDevice sections) to form a complete
1548 configuration. In multi-head configurations, it also specifies the
1549 relative layout of the heads. A ServerLayout section is considered
1550 “active” if it is referenced by the -layout command line option or by
1551 an Option "DefaultServerLayout" entry in the ServerFlags section (the
1552 former takes precedence over the latter). If those options are not
1553 used, the first ServerLayout section found in the config file is con‐
1554 sidered the active one. If no ServerLayout sections are present, the
1555 single active screen and two active (core) input devices are selected
1556 as described in the relevant sections above.
1557 ServerLayout sections have the following format:
1559 Section "ServerLayout"
1561 Identifier "name"
1562 Screen "screen-id"
1563 ...
1564 InputDevice "idev-id"
1565 ...
1566 options
1567 ...
1568 EndSection
1569 Each ServerLayout section must have an Identifier entry and at least
1571 one Screen entry.
1572 The Identifier entry specifies the unique name for this server layout.
1574 The ServerLayout section provides information specific to the whole
1575 session, including session-specific Options. The ServerFlags options
1576 (described above) may be specified here, and ones given here override
1577 those given in the ServerFlags section.
1578 The entries that may be used in this section are described here.
1580 Screen screen-num "screen-id" position-information
1582 One of these entries must be given for each screen being used in
1583 a session. The screen-id field is mandatory, and specifies the
1584 Screen section being referenced. The screen-num field is op‐
1585 tional, and may be used to specify the screen number in
1586 multi-head configurations. When this field is omitted, the
1587 screens will be numbered in the order that they are listed in.
1588 The numbering starts from 0, and must be consecutive. The posi‐
1589 tion-information field describes the way multiple screens are
1590 positioned. There are a number of different ways that this in‐
1591 formation can be provided:
1592 x y
1594 Absolute x y
1596 These both specify that the upper left corner's coordinates
1597 are (x,y). The Absolute keyword is optional. Some older
1598 versions of XFree86 (4.2 and earlier) don't recognise the
1599 Absolute keyword, so it's safest to just specify the coordi‐
1600 nates without it.
1601 RightOf "screen-id"
1603 LeftOf "screen-id"
1605 Above "screen-id"
1607 Below "screen-id"
1609 Relative "screen-id" x y
1611 These give the screen's location relative to another screen.
1612 The first four position the screen immediately to the right,
1613 left, above or below the other screen. When positioning to
1614 the right or left, the top edges are aligned. When posi‐
1615 tioning above or below, the left edges are aligned. The
1616 Relative form specifies the offset of the screen's origin
1617 (upper left corner) relative to the origin of another
1618 screen.
1619 InputDevice "idev-id" "option" ...
1621 One of these entries should be given for each input device being
1622 used in a session. Normally at least two are required, one each
1623 for the core pointer and keyboard devices. If either of those
1624 is missing, suitable InputDevice entries are searched for using
1625 the method described above in the INPUTDEVICE section. The
1626 idev-id field is mandatory, and specifies the name of the Input‐
1627 Device section being referenced. Multiple option fields may be
1628 specified, each in double quotes. The options permitted here
1629 are any that may also be given in the InputDevice sections.
1630 Normally only session-specific input device options would be
1631 used here. The most commonly used options are:
1632 "CorePointer"
1634 "CoreKeyboard"
1635 "SendCoreEvents"
1636 and the first two should normally be used to indicate the core
1638 pointer and core keyboard devices respectively.
1639 MatchSeat seat-id
1641 Only apply this ServerLayout section if X server was started
1642 with -seat seat-id option.
1643 Options
1645 In addition to the following, any option permitted in the
1646 ServerFlags section may also be specified here. When the same
1647 option appears in both places, the value given here overrides
1648 the one given in the ServerFlags section.
1649 Option "IsolateDevice" "bus-id"
1651 Restrict device resets to the specified bus-id. See the BusID
1652 option (described in DEVICE SECTION, above) for the format of
1653 the bus-id parameter. This option overrides SingleCard, if
1654 specified. At present, only PCI devices can be isolated in this
1655 manner.
1656 Option "SingleCard" "boolean"
1658 As IsolateDevice, except that the bus ID of the first device in
1659 the layout is used.
1660 Here is an example of a ServerLayout section for a dual headed configu‐
1662 ration with two mice:
1663 Section "ServerLayout"
1665 Identifier "Layout 1"
1666 Screen "MGA 1"
1667 Screen "MGA 2" RightOf "MGA 1"
1668 InputDevice "Keyboard 1" "CoreKeyboard"
1669 InputDevice "Mouse 1" "CorePointer"
1670 InputDevice "Mouse 2" "SendCoreEvents"
1671 Option "BlankTime" "5"
1672 EndSection
1673
1675 This optional section is used to provide some information for the Di‐
1676 rect Rendering Infrastructure. Details about the format of this sec‐
1677 tion can be found on-line at <https://dri.freedesktop.org/>.
1678
1680 The optional Vendor section may be used to provide vendor-specific con‐
1681 figuration information. Multiple Vendor sections may be present, and
1682 they may contain an Identifier entry and multiple Option flags. The
1683 data therein is not used in this release.
1684
1686 General: X(7), Xserver(1), Xorg(1), cvt(1), gtf(1).
1687 Not all modules or interfaces are available on all platforms.
1689 Display drivers: apm(4), ati(4), chips(4), cirrus(4), cyrix(4), fb‐
1691 dev(4), glide(4), glint(4), i128(4), i740(4), imstt(4), intel(4),
1692 mga(4), neomagic(4), nv(4), openchrome(4), r128(4), radeon(4), rendi‐
1693 tion(4), savage(4), s3virge(4), siliconmotion(4), sis(4), sisusb(4),
1694 sunbw2(4), suncg14(4), suncg3(4), suncg6(4), sunffb(4), sunleo(4),
1695 suntcx(4), tdfx(4), trident(4), tseng(4), vesa(4), vmware(4),
1696 voodoo(4), wsfb(4), xgi(4), xgixp(4).
1697 Input drivers: acecad(4), citron(4), elographics(4), evdev(4), fpit(4),
1699 joystick(4), kbd(4), libinput(4), mousedrv(4), mutouch(4), penmount(4),
1700 synaptics(4), vmmouse(4), void(4), wacom(4).
1701 Other modules and interfaces: exa(4), fbdevhw(4), v4l(4).
1703
1705 This manual page was largely rewritten by David Dawes
1706 <dawes@xfree86.org>.
1707X Version 11 xorg-server 1.20.14 xorg.conf(5)