On Unix-like operating systems, Xorg is the executable of the X Window System server, developed by the X.org foundation.
Description
Xorg is a full-featured X server that was originally designed for Unix and Unix-like operating systems, such as Linux, running on Intel x86 hardware. It now runs on a wider range of platforms.
- Description
- Syntax
- Examples
- Related commands
- Linux commands help
Syntax
Xorg [:display] [option …]
Options
Keyboard
The Xorg server is normally configured to recognize various special combinations of key presses that instruct the server to perform some action, rather than just sending the key press event to a client application. These actions depend on the XKB keymap loaded by a particular keyboard device and may or may not be available on a given configuration.
The following key combinations are commonly part of the default XKEYBOARD keymap.
Configuration
Xorg typically uses a configuration file called xorg.conf and configuration files with the suffix .conf in a directory called xorg.conf.d for its initial setup. Refer to the xorg.conf section below for information about the format of this file.
Xorg has a mechanism for automatically generating a built-in configuration at run time when no xorg.conf file or xorg.conf.d files are present. The current version of this automatic configuration mechanism works in two ways.
The first is via enhancements that have made many components of the xorg.conf file optional. This means that information that can be probed or reasonably deduced doesn’t need to be specified explicitly, greatly reducing the amount of built-in configuration information that needs to be generated at run time.
The second is to have “safe” fallbacks for most configuration information. This maximises the likelihood that the Xorg server will start up in some usable configuration even when information about the specific hardware is not available.
The automatic configuration support for Xorg is work in progress. It is currently aimed at the most popular hardware and software platforms supported by Xorg. Enhancements are planned for future releases.
Files used by xorg
Xorg configuration
Xorg supports several mechanisms for supplying/obtaining configuration and run time parameters: command line options, environment variables, the xorg.conf and xorg.conf.d configuration files, auto-detection, and fallback defaults. When the same information is supplied in more than one way, the highest precedence mechanism is used. The list of mechanisms is ordered from highest precedence to lowest. Note that not all parameters can be supplied via all methods. Most configuration file parameters, with their defaults, are described here. Xorg uses a configuration file called xorg.conf and files ending in the suffix .conf from the directory xorg.conf.d for its initial setup. The xorg.conf configuration file is searched for in the following places when the server is started as a normal user:
/etc/X11/
where
When the Xorg server is started by the root user, the config file search locations are as follows:
where
Additional configuration files are searched for in the following directories when the server is started as a normal user:
/etc/X11/
where
When the Xorg server is started by the root user, the config directory search locations are as follows:
where
Finally, configuration files will also be searched for in directories reserved for system use. These are to separate configuration files from the vendor or 3rd party packages from those of local administration. These files are found in the following directories:
/usr/share/X11/xorg.conf.d /usr/share/X11/xorg.conf.d
The xorg.conf and xorg.conf.d files are composed of many sections which may be present in any order, or omitted to use default configuration values. Each section has the form:
Section “SectionName” SectionEntry … EndSection
The section names are:
The following obsolete section names are still recognised for compatibility purposes. In new config files, the InputDevice section should be used instead.
(The old XInput section from previous versions is no longer recognized.)
The ServerLayout sections are at the highest level. They bind together the input and output devices that will be used in a session. The input devices are described in the InputDevice sections. Output devices usually consist of multiple independent components (e.g., a graphics board and a monitor). These multiple components are bound together in the Screen sections, and it is these that are referenced by the ServerLayout section. Each Screen section binds together a graphics board and a monitor. The graphics boards are described in the Device sections, and the monitors are described in the Monitor sections.
Config file keywords are case-insensitive, and “” characters are ignored. Most strings (including Option names) are also case-insensitive, and insensitive to white space and “” characters.
Each config file entry usually takes up a single line in the file. They consist of a keyword, which is possibly followed by one or more arguments, with the number and types of the arguments depending on the keyword. The argument types are:
Note: hex integer values must be prefixed with “0x”, and octal values with “0”.
A special keyword called Option may be used to provide free-form data to various components of the server. The Option keyword takes either one or two string arguments. The first is the option name, and the optional second argument is the option value. Some commonly used option value types include:
Note that all Option values, not just strings, must be enclosed in quotes.
Boolean options may optionally have a value specified. When no value is specified, the option’s value is TRUE. The following boolean option values are recognised as TRUE:
1 on true yes
and the following boolean option values are recognised as FALSE:
0 off false no
If an option name is prefixed with “No”, then the option value is negated.
Example: the following option entries are equivalent:
Option “Accel” “Off”
Option “NoAccel”
Option “NoAccel” “On”
Option “Accel” “false”
Option “Accel” “no”
Frequency option values consist of a real number that is optionally followed by one of the following frequency units:
Hz k kHz M MHz
When the unit name is omitted, the correct units will be determined from the value and the expectations of the appropriate range of the value. It is recommended that the units always be specified when using frequency option values to avoid any errors in determining the value.
The files section
The Files section is used to specify some path names required by the server. Some of these paths can also be set from the command line. The command line settings override the values specified in the config file. The Files section is optional, as are all of the entries that may appear in it.
The entries that can appear in this section are:
The ServerFlags section
In addition to options specific to this section (described below), the ServerFlags section is used to specify some global Xorg server options. All of the entries in this section are Options, although for compatibility purposes some of the old style entries are still recognized. Those old style entries are not documented here, and using them is discouraged. The ServerFlags section is optional, as are the entries that may be specified in it.
Catalogue directories can be specified using the prefix catalogue: before the directory name. The directory can then be populated with symlinks pointing to the real font directories, using the following syntax in the symlink name:
Where
75dpi:unscaled:pri=20 -> /usr/share/X11/fonts/75dpi gscript:pri=60 -> /usr/share/fonts/default/ghostscript misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc
Font server identifiers have the form:
Where
When this entry is not specified in the config file, the server falls back to the compiled-in default font path, which contains the following font path elements (which can be set inside a catalogue directory):
/usr/share/fonts/X11/misc/ /usr/share/fonts/X11/TTF/ /usr/share/fonts/X11/OTF/ /usr/share/fonts/X11/Type1/ /usr/share/fonts/X11/100dpi/ /usr/share/fonts/X11/75dpi/
Font path elements that are found to be invalid are removed from the font path when the server starts up.
Options specified in this section (except for the “DefaultServerLayout” Option) may be overridden by Options specified in the active ServerLayout section. Options with command line equivalents are overridden when their command line equivalent is used. The options recognized by this section are:
The Module section
The Module section is used to specify which Xorg server modules should be loaded. This section is ignored when the Xorg server is built in static form. The type of modules normally loaded in this section are Xorg server extension modules. Most other module types are loaded automatically when they are needed via other mechanisms. The Module section is optional, as are all of the entries that may be specified in it.
Entries in this section may be in two forms. The first and most commonly used form is an entry that uses the Load keyword, as described here:
The second form of entry is a SubSection, with the subsection name being the module name, and the contents of the SubSection being Options that are passed to the module when it is loaded.
Example: the DRI extension module can be loaded with the following entry:
Load “dri”
Example: the extmod module (which contains a miscellaneous group of server extensions) can be loaded, with the XFree86-DGA extension disabled, using the following entry:
SubSection “extmod” Option “omit XFree86-DGA” EndSubSection
Modules are searched for in each directory specified in the ModulePath search path, and in the drivers, extensions, input, internal, and multimedia subdirectories of each of those directories. In addition to this, operating system specific subdirectories of all the above are searched first if they exist.
To see what extension modules are available, check the extensions subdirectory under /usr/lib/xorg/modules.
The “extmod”, “dbe”, “dri”, “dri2”, “glx”, and “record” extension modules are loaded automatically, if they are present, unless disabled with “Disable” entries. It is recommended that at very least the “extmod” extension module be loaded. If it isn’t, some commonly used server extensions (like the SHAPE extension) will not be available.
Extensions section
The Extensions section is used to specify which X11 protocol extensions should be enabled or disabled. The Extensions section is optional, as are all of the entries that may be specified in it.
Entries in this section are listed as Option statements with the name of the extension as the first argument, and a boolean value as the second. The extension name is case-sensitive, and matches the form shown in the output of “Xorg -extension ?”.
Example: the MIT-SHM extension can be disabled with the following entry:
Section “Extensions” Option “MIT-SHM” “Disable” EndSection
The InputDevice section
The config file may have multiple InputDevice sections. Recent X servers employ HAL or udev backends for input device enumeration and input hotplugging. It is usually not necessary to provide InputDevice sections in the xorg.conf if hotplugging is in use (i.e., AutoAddDevices is enabled). If hotplugging is enabled, InputDevice sections using the mouse, kbd and vmmouse driver will be ignored.
If hotplugging is disabled, there will normally be at least two: one for the core (primary) keyboard and one for the core pointer. If either of these two is missing, a default configuration for the missing ones will be used. In the absence of an explicitly specified core input device, the first InputDevice marked as CorePointer (or CoreKeyboard) is used. If there is no match there, the first InputDevice that uses the “mouse” (or “kbd”) driver is used. The final fallback is to use built-in default configurations. Currently the default configuration may not work as expected on all platforms. InputDevice sections have the following format:
Section “InputDevice” Identifier “name” Driver “inputdriver” options … EndSection
The Identifier and Driver entries are required in all InputDevice sections. All other entries are optional.
The Identifier entry specifies the unique name for this input device. The Driver entry specifies the name of the driver to use for this input device. When using the loadable server, the input driver module “inputdriver” will be loaded for each active InputDevice section. An InputDevice section is considered active if it is referenced by an active ServerLayout section, if it is referenced by the -keyboard or -pointer command line options, or if it is selected implicitly as the core pointer or keyboard device in the absence of such explicit references. The most commonly used input drivers are evdev on Linux systems, and kbd and mousedrv on other platforms.
InputDevice sections recognise some driver-independent Options, which are described here.
Pointer acceleration options
For pointing devices, the following options control how the pointer is accelerated or decelerated with respect to physical device motion. Most of these can be adjusted at runtime with xinput. Only the most important acceleration options are discussed here.
This option controls the startup behavior only, a device may be reattached or set floating at runtime.
The InputClass section
The config file may have multiple InputClass sections. These sections are optional and are used to provide configuration for a class of input devices as they are automatically added. An input device can match more than one InputClass section. Each class can override settings from a previous class, so it is best to arrange the sections with the most generic matches first.
Option “AccelerationDenominator” “integer”
InputClass sections have the following format:
Section “InputClass” Identifier “name” entries … options … EndSection
The Identifier entry is required in all InputClass sections. All other entries are optional.
The Identifier entry specifies the unique name for this input class. The Driver entry specifies the name of the driver to use for this input device. After all classes have been examined, the “inputdriver” module from the first Driver entry will be enabled when using the loadable server.
When an input device is automatically added, its characteristics are checked against all InputClass sections. Each section can contain optional entries to narrow the match of the class. If none of the optional entries appear, the InputClass section is generic and will match any input device. If more than one of these entries appear, they all must match for the configuration to apply.
There are two types of match entries used in InputClass sections. The first allows various tokens to be matched against attributes of the device. An entry can be constructed to match attributes from different devices by separating arguments with a ‘|’ character. Multiple entries of the same type may be supplied to add multiple matching conditions on the same attribute. For example:
Section “InputClass” Identifier “My Class” # product string must contain example and # either gizmo or gadget MatchProduct “example” MatchProduct “gizmo|gadget” … EndSection
The second type of entry is used to match device types. These entries take a boolean argument similar to Option entries.
MatchIsKeyboard “bool"MatchIsPointer “bool"MatchIsJoystick “bool"MatchIsTablet “bool"MatchIsTouchpad “bool"MatchIsTouchscreen “bool”
When an input device has been matched to the InputClass section, any Option entries are applied to the device. One InputClass specific Option is recognized. See the InputDevice section above for a description of the remaining Option entries.
The Device section
The config file may have multiple Device sections. There must be at least one, for the video card being used.
Device sections have the following format:
Section “Device” Identifier “name” Driver “driver” entries … EndSection
The Identifier and Driver entries are required in all Device sections. All other entries are optional.
The Identifier entry specifies the unique name for this graphics device. The Driver entry specifies the name of the driver to use for this graphics device. When using the loadable server, the driver module “driver” will be loaded for each active Device section. A Device section is considered active if it is referenced by an active Screen section.
Device sections recognise some driver-independent entries and Options, which are described here. Not all drivers make use of these driver-independent entries, and many of those that do don’t require them to be specified because the information is auto-detected. See the individual graphics driver manual pages for further information about this, and for a description of the device-specific options. Note that most of the Options listed here (but not the other entries) may be specified in the Screen section instead of here in the Device section.
The VideoAdapter section
Either nobody knows how this section works, or no one will divulge the information. This section is a complete mystery to the entire world. Therefore, this section can safely be ignored.
The Monitor section
The config file may have multiple Monitor sections. There should normally be at least one, for the monitor being used, but a default configuration will be created when one isn’t specified.
Monitor sections have the following format:
Section “Monitor” Identifier “name” entries … EndSection
The only mandatory entry in a Monitor section is the Identifier entry.
The Identifier entry specifies the unique name for this monitor. The Monitor section may be used to provide information about the specifications of the monitor, monitor-specific Options, and information about the video modes to use with the monitor.
With RandR 1.2-enabled drivers, monitor sections may be tied to specific outputs of the video card. Using the name of the output defined by the video driver plus the identifier of a monitor section, one associates a monitor section with an output by adding an option to the Device section in the following format:
Option “Monitor-outputname” “monitorsection”
(for example, Option “Monitor-VGA” “VGA monitor” for a VGA output)
In the absence of specific association of monitor sections to outputs, if a monitor section is present the server will associate it with an output to preserve compatibility for previous single-head configurations.
Specifying video modes is optional because the server will use the DDC or other information provided by the monitor to automatically configure the list of modes available. When modes are specified explicitly in the Monitor section (with the Mode, ModeLine, or UseModes keywords), built-in modes with the same names are not included. Built-in modes with different names are, however, still implicitly included, when they meet the requirements of the monitor.
The entries that may be used in Monitor sections are described below.
The Modes section
The config file may have multiple Modes sections, or none. These sections provide a way of defining sets of video modes independently of the Monitor sections. Monitor sections may include the definitions provided in these sections using the UseModes keyword. In most cases, the Modes sections are not necessary because the built-in set of VESA standard modes are sufficient.
Modes sections have the following format:
Section “Modes” Identifier “name” entries … EndSection
The Identifier entry specifies the unique name for this set of mode descriptions. The other entries permitted in Modes sections are the Mode and ModeLine entries that are described above in the Monitor section.
The Screen section
The config file may have multiple Screen sections. There must be at least one, for the “screen” being used. A “screen” represents the binding of a graphics device (Device section) and a monitor (Monitor section). A Screen section is considered “active” if it is referenced by an active ServerLayout section or by the -screen command line option. If neither of those is present, the first Screen section found in the config file is considered the active one.
Screen sections have the following format:
Section “Screen” Identifier “name” Device “devid” Monitor “monid” entries … SubSection “Display” entries … EndSubSection … EndSection
The Identifier entry is mandatory. All others are optional.
The Identifier entry specifies the unique name for this screen. The Screen section provides information specific to the whole screen, including screen-specific Options. In multi-head configurations, there will be multiple active Screen sections, one for each head. The entries available for this section are:
Each Screen section may optionally contain one or more Display subsections. Those subsections provide depth/fbbpp specific configuration information, and the one chosen depends on the depth and/or fbbpp that is being used for the screen. The Display subsection format is described in the section below.
The Display subsection
Each Screen section may have multiple Display subsections. The “active” Display subsection is the first that matches the depth and/or fbbpp values being used, or failing that, the first that has neither a depth or fbbpp value specified. The Display subsections are optional. When there isn’t one that matches the depth and/or fbbpp values being used, all the parameters that can be specified here fall back to their defaults.
Display subsections have the following format:
SubSection “Display” Depth depth entries … EndSubSection
The ServerLayout section
The config file may have multiple ServerLayout sections. A “server layout” represents the binding of one or more screens (Screen sections) and one or more input devices (InputDevice sections) to form a complete configuration. In multi-head configurations, it also specifies the relative layout of the heads. A ServerLayout section is considered “active” if it is referenced by the -layout command line option or by an Option “DefaultServerLayout” entry in the ServerFlags section (the former takes precedence over the latter). If those options are not used, the first ServerLayout section found in the config file is considered the active one. If no ServerLayout sections are present, the single active screen and two active (core) input devices are selected as described in the relevant sections above.
StaticGrayGrayScaleStaticColorPseudoColorTrueColorDirectColor
The visual type available for the depths 15, 16 and 24 are (default is TrueColor):
TrueColorDirectColor
Not all drivers support DirectColor at these depths.
The visual types available for the depth 4 are (default is StaticColor):
StaticGrayGrayScaleStaticColorPseudoColor
The visual type available for the depth 1 (monochrome) is StaticGray.
ServerLayout sections have the following format:
Section “ServerLayout” Identifier “name” Screen “screen-id” … InputDevice “idev-id” … options … EndSection
Each ServerLayout section must have an Identifier entry and at least one Screen entry.
The Identifier entry specifies the unique name for this server layout. The ServerLayout section provides information specific to the whole session, including session-specific Options. The ServerFlags options (described above) may be specified here, and ones given here override those given in the ServerFlags section.
The entries that may be used in this section are described here.
Here is an example of a ServerLayout section for a dual headed configuration with two mice:
Absolute x y
LeftOf “screen-id”
Above “screen-id”
Below “screen-id”
Relative “screen-id” x y
“CorePointer”
“CoreKeyboard”
“SendCoreEvents”
and the first two should normally be used to indicate the core pointer and core keyboard devices respectively.
Section “ServerLayout” Identifier “Layout 1” Screen “MGA 1” Screen “MGA 2” RightOf “MGA 1” InputDevice “Keyboard 1” “CoreKeyboard” InputDevice “Mouse 1” “CorePointer” InputDevice “Mouse 2” “SendCoreEvents” Option “BlankTime” “5” EndSection
Sample xorg.conf file
The following is an example xorg.conf file, standard for many Linux systems:
/etc/X11/xorg.conf (xorg X Window System server configuration file)
Super hand tuned Xorg file by DMc
Currently runs triple display on two dual head nvidia cards
Copyright 2008 McPond Software
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This file is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
1.0 Start from base file, rip out wacom tablet stuff, I dont have one
Reorder sections, add dual head setup
»> Gives
Fatal server error:
Requested Entity already in use!
1.1 Reading further… TwinView mode on nv open source driver
1.2 After Feisty upgrade will not start on nVidia, change back to nv
until can get it running, then recheck with tools
and of course nv doesnt support Twinview?
1.3 Add more button support for Razor Copperhead
1.4 Envy for Fiesty with help from nvidia-xconfig
1.5 Enable dual head again
1.6 Change to 20” Viewsonic
1.7 Kernel update to 2.6.20 breaks nvidia again.
Change to nv to get started
Run envy, then change back to unaltered xorg file
1.8 New nVidia 8600GT graphics card with dual DVI output
Required latest nVidia drivers 100.41.100
1.9 New Samsung SyncMaster 226BW 22” wide screen LCD
2.0 Hardy Heron 8.04 major upgrade. New envyng 1.1.1
New nvidia installer 173 version
2.1 Kernel update 2.6.24-18 Wont start after
Disabled two empty font paths, disabled type1 as it wasnt loading
Ran envy but boot crashes with Fatal server error Caught signal 4
server aborting libGLcore.so.1
Envy only reporting installer v169. It wont do 173 as thats beta
Yes, installed 173 manually. Seems 169 does not work on this system
Run NVIDIA(blah).run to setup
2.2 Add Asus Geforce 7200GS card in second PCI-E 16x slot
Needed help from nvidia-xconfig to get both to run
The screen IDs are not accumulative, that means, for each physical
card, the screen ID starts with 0 again.
It treats the 7200 as ‘primary’ probably because it has a lower bus number
meaning you have to login to that screen. Tool panel can be moved to any screen.
2.3 Attempting to get Compiz to run
Composite extension not found
You must use XOrg >= 6.8 for translucency and shadows to work
Index:
ServerLayout
Vendor
InputDevice - Keyboard
InputDevice - Mouse
Device - Left
Device - Right
Monitor - Left
Monitor - Right
Screen - Left
Screen - Right
Files
Module
Extensions
Notes:
Server Flags must go before Server Layout
Server layout ties it all together
Section “ServerLayout” Identifier “TripleHeadLayout” Screen 0 “CentreScreen” 0 0 # was rightof, now changed to leftof Screen 1 “RightScreen” RightOf “CentreScreen” # Dont use LeftOf Same twice, you get two screens doing the same thing. Screen 2 “LeftScreen” LeftOf “CentreScreen” # Changed this from 0 to 2 Option “Xinerama” “On” InputDevice “Ergonomic4000” InputDevice “Razer Copperhead” EndSection
Microsoft Ergonomic 4000 Keyboard
Section “InputDevice” Identifier “Ergonomic4000” Driver “kbd” Option “CoreKeyboard” Option “XkbRules” “xorg” Option “XkbModel” “pc105” Option “XkbLayout” “us” Option “XkbOptions” “lv3:ralt_switch” # Would be nice if the top ribbon web buttons worked # and the Zoom slider in the centre # and back/forward buttons EndSection
Razer Copperhead and KVM based PS2
Section “InputDevice” Identifier “Razer Copperhead” Driver “mouse” Option “CorePointer” Option “Device” “/dev/input/mice” Option “Protocol” “ExplorerPS/2” Option “ZAxisMapping” “4 5” # ZAxis mapping is the scrolling. Exclude from list below Option “Emulate3Buttons” “true” Option “Buttons” “9” Option “ButtonMapping” “1 2 3 6 7 8 9” # 3 is the wheel click # 6 & 7 and 8 & 9 are on the sides of the mouse - and hard to press EndSection
Graphics device description
nVidia GeForce 8600GT
Device section is for the video card
One section per head
Section “Device” Identifier “Left nVidia 8600GT” Driver “nvidia”
For use after kernel upgrades kills nVidia proprietory
Also turn off RightScreen
Driver “nv”
VendorName "NVIDIA Corporation"
BoardName "GeForce 8600 GT"
PCI-Express 16x bus
BusID "PCI:7:0:0"
Appears as PCI:4 on other machines
BusID “PCI:1:0:0” this is AGP
Screen 0
# Options...
EndSection Section “Device” Identifier “Right nVidia 8600GT” Driver “nvidia” VendorName “NVIDIA Corporation” BoardName “GeForce 8600 GT” BusID “PCI:7:0:0” Screen 1
# Options…
EndSection Section “Device” Identifier “Left nVidia 7200” Driver “nvidia” VendorName “NVIDIA Corporation” BoardName “GeForce 7200 GS” # Outer PCI-Express 16x Bus BusID “PCI:2:0:0” Screen 0
# Options…
EndSection
Samsung SyncMaster 226BW - Right
Section “Monitor” Identifier “SyncMaster-226BW” VendorName “Samsung” HorizSync 30.0 - 81.0 VertRefresh 56.0 - 75.0 Option “DPMS”
More Options…
EndSection
Sony SDM-HS95P - Moved to another machine
#Section “Monitor”
Identifier “SDM-HS95P”
VendorName “Sony”
HorizSync 28.0 - 65.0
VertRefresh 57.0 - 63.0
Option “DPMS”
More Options…
#EndSection Section “Monitor” Identifier “VG2021m” Option “DPMS” HorizSync 28-65 VertRefresh 57-63 VendorName “Viewsonic”
More Options…
EndSection Section “Monitor” Identifier “SyncMaster-245B” Option “DPMS” HorizSync 30-81 VertRefresh 56-75 VendorName “Samsung”
More Options…
EndSection Section “Screen” Identifier “CentreScreen” Device “Left nVidia 8600GT” Monitor “VG2021m” # Compositing manager Option “RenderAccel” “true” Option “TripleBuffer” “true”
Not needed on modern X servers Option “AllowGLXWithComposite”
Option "DPMS" "true"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1400x1050"
EndSubSection
EndSection Section “Screen” Identifier “RightScreen” Device “Right nVidia 8600GT” Monitor “SyncMaster-226BW” # Compositing manager Option “RenderAccel” “true” Option “TripleBuffer” “true” Option “AllowGLXWithComposite” Option “DPMS” “true” DefaultDepth 24 SubSection “Display” Depth 24 Modes “1680x1050” EndSubSection # Even though the SyncMaster and the Viewsonic are 1050, the # Viewsonic is 10mm taller. Syncmaster has a finer dot pitch, # but less physical real estate EndSection Section “Screen” Identifier “LeftScreen” Device “Left nVidia 7200” Monitor “SyncMaster-245B” # Compositing manager Option “RenderAccel” “true” Option “TripleBuffer” “true” Option “AllowGLXWithComposite” Option “DPMS” “true” DefaultDepth 24 SubSection “Display” Depth 24 Modes “1920x1200” EndSubSection EndSection
File path names
Section “Files”
These folders do not exist
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/100dpi"
No files in here FontPath “/usr/share/X11/fonts/75dpi”
removed this tail /:unscaled”
No files here either FontPath “/usr/share/X11/fonts/Type1”
path to defoma fonts
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
RgbPath "/usr/X11R6/lib/X11/rgb"
EndSection
Dynamic module loading
Section “Module” Load “bitmap” Load “dbe” Load “ddc” Load “extmod” Load “freetype” Load “glx” Load “int10”
Module does not exist on disk Load “type1”
Load "vbe"
EndSection Section “ServerFlags” Option “Xinerama” “1” EndSection Section “Extensions”
Compositing manager for xcompmgr
Option "Composite" "Enable"
EndSection
Examples
Xorg -configure
This command will instruct Xorg to probe all current devices and write an xorg.conf configuration file appropriate for the system.
Related commands
startx — Start an X Window System session.
