Example xorg conf

Example xorg conf DEFAULT

106.1 Lesson 1

Certificate:

LPIC-1

Version:

5.0

Topic:

106 User Interfaces and Desktops

Objective:

106.1 Install and configure X11

Lesson:

1 of 1

Introduction

The X Window System is a software stack that is used to display text and graphics on a screen. The overall look and design of an X client is not dictated by the X Window System, but is instead handled by each individual X client, a window manager (e.g. Window Maker, Tab Window Manager), or a complete desktop environment such as KDE, GNOME, or Xfce. Desktop environments will be covered in a later lesson. This lesson will focus on the underlying architecture and common tools for the X Window System that an administrator would use to configure X.

The X Window System is cross-platform and runs on various operating systems such as Linux, the BSDs, Solaris and other Unix-like systems. There are also implementations available for Apple’s macOS and Microsoft Windows.

The primary version of the X protocol used in modern Linux distributions is X.org version 11, commonly written as X11. The X protocol is the communication mechanism between the X client and X server. The differences between the X client and X server will be discussed below.

Note

The X Window System’s predecessor was a window system called W and was a joint development effort between IBM, DEC and MIT. This software was born out of Project Athena in 1984. When the developers started work on a new display server, they chose the next letter in the English alphabet: “X”. The X Window System’s evolution is currently controlled by the MIT X Consortium.

X Window System Architecture

The X Window System provides the mechanisms for drawing basic two dimensional shapes (and three dimensional shapes through extensions) on a display. It is divided into a client and a server, and in most installations where a graphical desktop is needed both of these components are on the same computer. The client component takes the form of an application, such as a terminal emulator, a game or a web browser. Each client application informs the X server about its window location and size on a computer screen. The client also handles what goes into that window, and the X server puts the requested drawing up on the screen. The X Window System also handles input from devices such as mice, keyboards, trackpads and more.

Basic Structure of an X Window System

image 01

The X Window System is network-capable and multiple X clients from different computers on a network can make drawing requests to a single remote X server. The reasoning behind this is so that an administrator or user can have access to a graphical application on a remote system that may not be available on their local system.

A key feature of the X Window System is that it is modular. Over the course of the X Window System’s existence newer features have been developed and added to its framework. These new components were only added as extensions to the X server, leaving the core X11 protocol intact. These extensions are contained within Xorg library files. Examples of Xorg libraries include: , , , as well as several others, each providing extended functionality to the X server.

A display manager provides a graphical login to a system. This system can either be a local computer or a computer across a network. The display manager is launched after the computer boots and will start an X server session for the authenticated user. The display manager is also responsible for keeping the X server up and running. Example display managers include GDM, SDDM and LightDM.

Each instance of a running X server has a display name to identify it. The display name contains the following:

hostname:displaynumber.screennumber

The display name also instructs a graphical application where it should be rendered and on which host (if using a remote X connection).

The refers to the name of the system that will display the application. If a hostname is missing from the display name, then the local host is assumed.

The references the collection of “screens” that are in use, whether that is a single laptop screen or multiple screens on a workstation. Each running X server session is given a display number starting at .

The default is . This can be the case if only one physical screen or multiple physical screens are configured to work as one screen. When all screens in a multi-monitor setup are combined into one logical screen, application windows can be moved freely between the screens. In situations where each screen is configured to work independently of one another, each screen will house the application windows that open within them and the windows can not be moved from one screen to another. Each independent screen will have its own number assigned to it. If there is only one logical screen in use, then the dot and the screen number are omitted.

The display name of a running X session is stored in the environment variable:

The output details the following:

  1. The X server in use is on the local system, hence there is nothing printed to the left of the colon.

  2. The current X server session is the first as indicated by the immediately following the colon.

  3. There is only one logical screen in use, so a screen number is not visible.

To further illustrate this concept, refer to the following diagram:

Example Display Configurations

image 02b

(A)

A single monitor, with a single display configuration and only one screen.

(B)

Configured as a single display, with two physical monitors configured as one screen. Application windows can be moved freely between the two monitors.

(C)

A single display configuration (as indicated by the ) however each monitor is an independent screen. Both screens will still share the same input devices such as a keyboard and mouse, however an application opened on screen can not be moved to screen and vice versa.

To start an application on a specific screen, assign the screen number to the environment variable prior to launching the application:

$ DISPLAY=:0.1 firefox &

This command would start the Firefox web browser on the screen to the right in the diagram above. Some toolkits also provide command line options to instruct an application to run on a specified screen. See and in the man page for an example.

X Server Configuration

Traditionally, the primary configuration file that is used to configure an X server is the file. On modern Linux distributions, the X server will configure itself at runtime when the X server is started and so no file may exist.

The file is divided up into separate stanzas called sections. Each section begins with the term and following this term is the section name which refers to a component’s configuration. Each is terminated by a corresponding . The typical file contains the following sections:

Used to configure a specific model of keyboard or mouse.

In modern Linux distributions this section is typically found in a separate configuration file located under . The is used to configure a class of hardware devices such as keyboards and mice rather than a specific piece of hardware. Below is an example file:

Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "us" Option "XkbModel" "pc105" EndSection

The option for determines the layout of the keys on a keyboard, such as Dvorak, left or right handed, QWERTY and language. The option for is used to define the type of keyboard in use. A table of models, layouts and their descriptions can be found within . The files associated with keyboard layouts can be found within . An example Greek Polytonic keyboard layout on a Chromebook computer would look like the following:

Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "gr(polytonic)" Option "XkbModel" "chromebook" EndSection

Alternatively, a keyboard’s layout can be modified during a running X session with the command. Here is an example of this command setting up the Greek Polytonic layout on a Chromebook computer:

$ setxkbmap -model chromebook -layout "gr(polytonic)"

This setting will only last as long as the X session in use. To make such changes permanent, modify the file to include the settings required.

Note

The command makes use of the X Keyboard Extension (XKB). This is an example of the additive functionality of the X Window System through its use of extensions.

Modern Linux distributions provide the command via which can also be used to modify a keyboard layout and will automatically create the configuration file. Once more, here is an example setting up a Greek Polytonic keyboard on a Chromebook, this time using the command:

$ localectl --no-convert set-x11-keymap "gr(polytonic)" chromebook

The option is used here to prevent from modifying the host’s console keymap.

The section describes the physical monitor that is used and where it is connected. Here is an example configuration showing a hardware monitor connected to the second display port and is used as the primary monitor.

Section "Monitor" Identifier "DP2" Option "Primary" "true" EndSection

The section describes the physical video card that is used. The section will also contain the kernel module used as the driver for the video card, along with its physical location on the motherboard.

Section "Device" Identifier "Device0" Driver "i915" BusID "PCI:0:2:0" EndSection

The section ties the and sections together. An example section could look like the following;

Section "Screen" Identifier "Screen0" Device "Device0" Monitor "DP2" EndSection

The section groups all of the sections such as mouse, keyboard and screens into one X Window System interface.

Section "ServerLayout" Identifier "Layout-1" Screen "Screen0" 0 0 InputDevice "mouse1" "CorePointer" InputDevice "system-keyboard" "CoreKeyboard" EndSection

Note

Not all sections may be found within a configuration file. In instances where a section is missing, default values are provided by the running X server instance instead.

User-specified configuration files also reside in . Configuration files provided by the distribution are located in . The configuration files located within are parsed prior to the file if it exists on the system.

The command is used on a computer to display information about a running X server instance. Below is sample output from the command:

$ xdpyinfoname of display: :0version number: 11.0vendor string: The X.Org Foundationvendor release number: 12004000X.Org version: 1.20.4 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: None number of extensions: 25 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DRI3 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Present RANDR RECORD RENDER SECURITY SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 3840x1080 pixels (1016x286 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x39e depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x25 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store WHEN MAPPED, save-unders NO largest cursor: 3840x1080 current input event mask: 0xda0033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 270 ...

The more relevant portions of the output are in bold, such as the name of the display (which is the same as the contents of the environment variable), the versioning information of the X server in use, the number and listing of Xorg extensions in use, and further information about the screen itself.

Creating a Basic Xorg Configuration File

Even though X will create its configuration after system startup on modern Linux installations, an file can still be used. To generate a permanent file, run the following command:

Note

If there is already an X session running, you will need to specify a different in your command, for example:

$ sudo Xorg :1 -configure

On some Linux distributions, the command can be used in place of , as is a symbolic link to .

An file will be created in your current working directory. The contents of this file are derived from what the X server has found to be available in hardware and drivers on the local system. To use this file, it will need to be moved to the directory and renamed to :

$ sudo mv xorg.conf.new /etc/X11/xorg.conf

Note

The following manual pages provide further information on components of the X Window System: , , and .

Wayland

Wayland is the newer display protocol designed to replace the X Window System. Many modern Linux distributions are using it as their default display server. It is meant to be lighter on system resources and have a smaller installation footprint than X. The project began in 2010 and is still undergoing active development, including work from active and former X.org developers.

Unlike the X Window System, there is no server instance that runs between the client and kernel. Instead, a client window works with its own code or that of a toolkit (such as Gtk+ or Qt) to provide the rendering. In order to do the rendering, a request is made to the Linux kernel via the Wayland protocol. The kernel forwards the request via the Wayland protocol to the Wayland compositor, which handles device input, window management and composition. The compositor is the part of the system that combines the rendered elements into visual output on the screen.

Most modern toolkits such Gtk+ 3 and Qt 5 have been updated to allow for rendering to either an X Window System or a computer running Wayland. Not all standalone applications have been written to support rendering in Wayland as of yet. For applications and frameworks that are still targeting the X Window System to run, the application can run within XWayland. The XWayland system is a separate X server that runs within a Wayland client and thus renders a client window’s contents within a standalone X server instance.

Just as the X Window System uses a environment variable to keep track of screens in use, the Wayland protocol uses a environment variable. Below is sample output from a system running a Wayland display:

$ echo $WAYLAND_DISPLAY wayland-0

This environment variable is not available on systems running X.

Guided Exercises

  1. What command would you use to determine what Xorg extensions are available on a system?

  2. You have just received a brand new 10-button mouse for your computer, however it will require extra configuration in order to get all of the buttons to function properly. Without modifying the rest of the X server configuration, what directory would you use to create a new configuration file for this mouse, and what specific configuration section would be used in this file?

  3. What component of a Linux installation is responsible for keeping an X server running?

  4. What command line switch is used with the command to create a new configuration file?

Explorational Exercises

  1. What would the contents of the environment variable be on a system named using a single display configuration? Assume that the environment variable is being viewed in a terminal emulator on the third independent screen.

  2. What command can be used to create a keyboard configuration file for use by the X Window System?

  3. On a typical Linux installation a user can switch to a virtual terminal by pressing the kbd:[Ctrl+Alt+F1]-kbd:[F6] keys on a keyboard. You have been asked to set up a kiosk system with a graphical interface and need this feature disabled to prevent unauthorized tampering with the system. You decide to create a configuration file. Using a section (which is used to set global Xorg options on the server), what option would need to be specified? Review the man page to locate the option.

Summary

This lesson covered the X Window System as it is used on Linux. The X Window System is used to draw images and text on screens, as they are defined in various configuration files. The X Window System is often used to configure input devices such as mice and keyboards. This lesson discussed the following points:

  • The X Window System architecture at a high level.

  • What configuration files are used to configure an X Windows System, and their location on the filesystem.

  • How to use the environment variable on a system running X.

  • A brief introduction to the Wayland display protocol.

The commands and configuration files addressed were:

  • Modification of a keyboard’s layout within an Xorg installation with and .

  • The command for creating a new configuration file.

  • The contents of the Xorg configuration files located at: , and .

  • The command for displaying general information about a running X server session.

Answers to Guided Exercises

  1. What command would you use to determine what Xorg extensions are available on a system?

  2. You have just received a brand new 10-button mouse for your computer, however it will require extra configuration in order to get all of the buttons to function properly. Without modifying the rest of the X server configuration, what directory would you use to create a new configuration file for this mouse, and what specific configuration section would be used in this file?

    User-defined configurations should be located in and the specific section needed for this mouse configuration would be .

  3. What component of a Linux installation is responsible for keeping an X server running?

  4. What command line switch is used with the command to create a new configuration file?

    Remember that the command is a symbolic link to the command.

Answers to Explorational Exercises

  1. What would the contents of the environment variable be on a system named using a single display configuration? Assume that the environment variable is being viewed in a terminal emulator on the third independent screen.

    $ echo $DISPLAY lab01:0.2
  2. What command can be used to create a keyboard configuration file for use by the X Window System?

  3. On a typical Linux installation a user can switch to a virtual terminal by pressing the kbd:[Ctrl+Alt+F1]-kbd:[F6] keys on a keyboard. You have been asked to set up a kiosk system with a graphical interface and need this feature disabled to prevent unauthorized tampering with the system. You decide to create a configuration file. Using a section (which is used to set global Xorg options on the server), what option would need to be specified? Review the man page to locate the option.

    Section "ServerFlags" Option "DontVTSwitch" "True" EndSection

Linux Professional Insitute Inc. All rights reserved. Visit the Learning Materials website: https://learning.lpi.org
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Sours: https://learning.lpi.org/en/learning-materials/102-500/106/106.1/106.1_01/

The xorg.conf file is the main configuration file for the X server.

Note
Manually creating xorg.conf should be seen as a last resort option. It is typically desirable to run the X server without any special configuration. If you still can't get a working configuration, then read on.

Configuration

xorg.conf and xorg.conf.d

The X server read the settings from the files in /etc/X11/xorg.conf.d/ directory (recommended) or the legacy /etc/X11/xorg.conf file. In the /etc/X11/xorg.conf.d/ directory, each file is given a unique name and ends in .conf. If the filenames start with a number, then the X server will read the files in numeric order. 10-evdev.conf will be read before 20-synaptics.conf, and so on. You don't have to give them numbers, but it may help you organize them.

The settings in /etc/X11/xorg.conf take precedence over the files in /etc/X11/xorg.conf.d/, which take precedence over the files in /usr/share/X11/xorg.conf.d/, which take precedence over the built-in X server configuration.

x11-base/xorg-server provides example configurations in /usr/share/doc/xorg-server-*/xorg.conf.example.bz2. You can use these to create your own configuration files in /etc/X11/xorg.conf.d/.

Syntax

The configuration is composed of a number of sections. The most common ones include:

  • ServerFlags: Common X server settings
  • InputClass: Settings for input devices
  • Device: Settings for graphics cards
  • Monitor: Settings for displays
  • Screen: Settings for "graphics card / display"-combinations
  • ServerLayout: Settings for "screen / input devices"-combinations

Lines starting with a hash (#) are comments and are ignored by the X server. Each other line in a section define a value to an option. The value can be of the following types:

  • INTEGER: an integer number in decimal, hex or octal, e.g. 1, 2, 3, etc.
  • REAL: a floating point number, e.g. 1.2
  • STRING: a string enclosed in double quote marks ("), e.g. "Hello world!"

Most options and values are case-insensitive. Superfluous white spaces are ignored.

The special option named Option accepts also the additional types:

  • BOOLEAN: a boolean value, e.g. on, true, 1 or yes; off, false, 0 or no.
  • FREQUENCY: in Hz, k, kHz, M or MHz

Note also that the Option values must be enclosed in double quote marks (").

Sections

ServerFlags

An example ServerFlags section looks like this:

FILE

Section"ServerFlags"Option"OffTime" "5"...EndSection

All entries are optional.

The most common options are:

Option Default Description
Option "AutoAddDevices" "BOOLEAN"trueEnables or disables the automatic detection of input devices using udev.
Option "OffTime" "INTEGER"10Turns off the monitor after the given time (in minutes) of inactivity.

For more information see the xorg.confman page.

InputClass

Create for each input device class (keyboard, mouse, etc.) a InputClass section. An example InputClass section looks like this:

FILE

Section"InputClass"Identifier"My Keyboard"MatchIsKeyboard"True"...EndSection

Identifier is mandatory, everything else is optional.

Without specify a matching condition a InputClass section applies to all input devices. Add a matching condition to apply settings only to input devices of the target class or to a single device. The most common conditions are:

Condition Description
MatchIsKeyboard "BOOLEAN"Match only keyboards
MatchIsPointer "BOOLEAN"Match only mice
MatchIsJoystick "BOOLEAN"Match only joysticks
MatchIsTablet "BOOLEAN"Match only tablets
MatchIsTouchpad "BOOLEAN"Match only touchpads
MatchIsTouchscreen "BOOLEAN"Match only touchscreens
MatchProduct "STRING"Match only devices with the given product name.
MatchVendor "STRING"Match only devices with the given vendor name.

The most common options are:

Option Default Description
Identifier "STRING"none Specify an unique name
Driver "STRING"none Specify the input device driver, see the input device articles.
Option "Ignore" "BOOLEAN"falseDisable the input device (useful for e.g. sensors)
Option "XkbLayout" "STRING"enSpecify a keyboard layout.
Option "XkbVariant" "STRING"Specify a keyboard layout variant
Option "XkbOptions" "STRING"Specify keyboard layout options

For more information see the xorg.confman page and the man pages of your input device drivers.

Device

Create for each graphics card a Device section. An example Device section looks like this:

FILE

Section"Device"Identifier"My Graphics Card"Driver"intel"...EndSection

Identifier and Driver is mandatory, everything else is optional.

The most common options are:

Option Default Description
Identifier "STRING"none Specify an unique name
Driver "STRING"none Specify the graphics driver, see the graphics drivers articles.
BusID "STRING"none For multiple graphics cards specify the BusID in the form PCI:bus:device:function provided by scanpci.
Option "Accel" "STRING"driver/card dependent Specify a 2D acceleration system
Option "Monitor-OUTPUT" "STRING"none Force bind a Monitor section to this device. OUTPUT is a connector name, see xrandr, and STRING is the chosen identifier of the Monitor section.

For more information see the xorg.confman page and the man pages of your graphics drivers.

Monitor

Create for each monitor a Monitor section. An example Monitor section looks like this:

FILE

Section"Monitor"Identifier"My Monitor"...EndSection

Identifier is mandatory, everything else is optional.

The most common options are:

Option Default Description
Identifier "STRING"none Specify an unique name
DisplaySize INTEGER INTEGEREDIDSpecify the physical width and height (in millimeters) of the monitor. It will be used to calculate the DPI.
Modeline "STRING" ... EDIDSpecify a new mode entry.
Option "Enable" "BOOLEAN"trueEnables or disables the monitor by default.
Option "PreferredMode" "STRING"none Specify the default mode.

For more information see the xorg.confman page.

Hot-swapping input devices

For input devices override the configuration of xorg.conf by using the xinput command:

⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Synaptics TM3127-001 id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ...

Device 'Synaptics TM3127-001': Device Enabled (146): 1 Coordinate Transformation Matrix (148): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (311): 1 libinput Tapping Enabled Default (312): 0 ...

To change "Tapping Enabled" to 0 (i.e. false), run:

See also

Sours: https://wiki.gentoo.org/wiki/Xorg.conf
  1. Potion making book
  2. Housewarming invitation templates free download
  3. Ultimate pheasant
  4. Duramax ball joints

Xorg

Related articles

From https://www.x.org/wiki/:

The X.Org project provides an open source implementation of the X Window System. The development work is being done in conjunction with the freedesktop.org community. The X.Org Foundation is the educational non-profit corporation whose Board serves this effort, and whose Members lead this work.

Xorg (commonly referred to as simply X) is the most popular display server among Linux users. Its ubiquity has led to making it an ever-present requisite for GUI applications, resulting in massive adoption from most distributions. See the Xorg Wikipedia article or visit the Xorg website for more details.

For the alternative and potential successor, see Wayland.

Installation

Xorg can be installed with the xorg-server package.

Additionally, some packages from the xorg-apps group are necessary for certain configuration tasks. They are pointed out in the relevant sections.

Finally, an xorg group is also available, which includes Xorg server packages, packages from the xorg-apps group and fonts.

Tip: You will typically seek to install a window manager or a desktop environment to supplement X.

Driver installation

The Linux kernel includes open-source video drivers and support for hardware accelerated framebuffers. However, userland support is required for OpenGL and 2D acceleration in X11.

First, identify the graphics card (the Subsystem output shows the specific model):

$ lspci -v | grep -A1 -e VGA -e 3D

Then, install an appropriate driver. You can search the package database for a complete list of open-source video drivers:

$ pacman -Ss xf86-video

Xorg searches for installed drivers automatically:

  • If it cannot find the specific driver installed for the hardware (listed below), it first searches for fbdev (xf86-video-fbdev).
  • If that is not found, it searches for vesa (xf86-video-vesa), the generic driver, which handles a large number of chipsets but does not include any 2D or 3D acceleration.
  • If vesa is not found, Xorg will fall back to kernel mode setting, which includes GLAMOR acceleration (see modesetting(4)).

In order for video acceleration to work, and often to expose all the modes that the GPU can set, a proper video driver is required:

Note:
  • For NVIDIA Optimus enabled laptop which uses an integrated video card combined with a dedicated GPU, see NVIDIA Optimus.
  • For Intel graphics on 4th generation and above, see Intel graphics#Installation for available drivers.

Other video drivers can be found in the xorg-drivers group.

Xorg should run smoothly without closed source drivers, which are typically needed only for advanced features such as fast 3D-accelerated rendering for games. The exceptions to this rule are recent GPUs (especially NVIDIA GPUs) not supported by open source drivers.

AMD

For a translation of model names (e.g. Radeon RX 6800) to GPU architectures (e.g. RDNA 2), see wikipedia:List of AMD graphics processing units.

GPU architectureOpen-source driverProprietary driver
RDNA, RDNA 2AMDGPUAMDGPU PRO
GCN 3, GCN 4, GCN 5
GCN 1, GCN 2AMDGPU* / ATInot available
TeraScale
and older
ATInot available
*: Experimental

Running

The Xorg(1) command is usually not run directly. Instead, the X server is started with either a display manager or xinit.

Configuration

Note: Arch supplies default configuration files in , and no extra configuration is necessary for most setups.

Xorg uses a configuration file called and files ending in the suffix for its initial setup: the complete list of the folders where these files are searched can be found in xorg.conf(5), together with a detailed explanation of all the available options.

Using .conf files

The directory stores host-specific configuration. You are free to add configuration files there, but they must have a suffix: the files are read in ASCII order, and by convention their names start with (two digits and a hyphen, so that for example 10 is read before 20). These files are parsed by the X server upon startup and are treated like part of the traditional configuration file. Note that on conflicting configuration, the file read last will be processed. For this reason, the most generic configuration files should be ordered first by name. The configuration entries in the file are processed at the end.

For option examples to set, see Fedora:Input device configuration#xorg.conf.d.

Using xorg.conf

Xorg can also be configured via or . You can also generate a skeleton for with:

# Xorg :0 -configure

This should create a file in that you can copy over to .

Tip: If you are already running an X server, use a different display, for example .

Alternatively, your proprietary video card drivers may come with a tool to automatically configure Xorg: see the article of your video driver, NVIDIA or AMDGPU PRO, for more details.

Note: Configuration 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.

Input devices

For input devices the X server defaults to the libinput driver (xf86-input-libinput), but xf86-input-evdev and related drivers are available as alternative.[1]

Udev, which is provided as a systemd dependency, will detect hardware and both drivers will act as hotplugging input driver for almost all devices, as defined in the default configuration files and in the directory.

After starting X server, the log file will show which driver hotplugged for the individual devices (note the most recent log file name may vary):

$ grep -e "Using input driver " Xorg.0.log

If both do not support a particular device, install the needed driver from the xorg-drivers group. The same applies, if you want to use another driver.

To influence hotplugging, see #Configuration.

For specific instructions, see also the libinput article, the following pages below, or Fedora:Input device configuration for more examples.

Input identification

See Keyboard input#Identifying keycodes in Xorg.

Mouse acceleration

See Mouse acceleration.

See Mouse buttons.

Touchpad

See libinput or Synaptics.

Touchscreen

See Touchscreen.

Keyboard settings

See Keyboard configuration in Xorg.

Monitor settings

Manual configuration

Note:
  • Newer versions of Xorg are auto-configuring, so manual configuration should not be needed.
  • If Xorg is unable to detect any monitor or to avoid auto-configuring, a configuration file can be used. A common case where this is necessary is a headless system, which boots without a monitor and starts Xorg automatically, either from a virtual console at login, or from a display manager.

For a headless configuration, the xf86-video-dummy driver is necessary; install it and create a configuration file, such as the following:

/etc/X11/xorg.conf.d/10-headless.confSection "Monitor" Identifier "dummy_monitor" HorizSync 28.0-80.0 VertRefresh 48.0-75.0 Modeline "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 EndSection Section "Device" Identifier "dummy_card" VideoRam 256000 Driver "dummy" EndSection Section "Screen" Identifier "dummy_screen" Device "dummy_card" Monitor "dummy_monitor" SubSection "Display" EndSubSection EndSection

Multiple monitors

See main article Multihead for general information.

See also GPU-specific instructions:

More than one graphics card

You must define the correct driver to use and put the bus ID of your graphic cards (in decimal notation).

Section "Device" Identifier "Screen0" Driver "intel" BusID "PCI:0:2:0" EndSection Section "Device" Identifier "Screen1" Driver "nouveau" BusID "PCI:1:0:0" EndSection

To get your bus IDs (in hexadecimal):

$ lspci | grep -e VGA -e 3D00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)

The bus IDs here are 0:2:0 and 1:0:0.

Display size and DPI

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Xorg always sets dpi to 96. See this, this and finally this. (Discuss in Talk:Xorg)

The DPI of the X server is determined in the following manner:

  1. The command line option has highest priority.
  2. If this is not used, the setting in the X config file is used to derive the DPI, given the screen resolution.
  3. If no is given, the monitor size values from DDC are used to derive the DPI, given the screen resolution.
  4. If DDC does not specify a size, 75 DPI is used by default.

In order to get correct dots per inch (DPI) set, the display size must be recognized or set. Having the correct DPI is especially necessary where fine detail is required (like font rendering). Previously, manufacturers tried to create a standard for 96 DPI (a 10.3" diagonal monitor would be 800x600, a 13.2" monitor 1024x768). These days, screen DPIs vary and may not be equal horizontally and vertically. For example, a 19" widescreen LCD at 1440x900 may have a DPI of 89x87. To be able to set the DPI, the Xorg server attempts to auto-detect your monitor's physical screen size through the graphic card with DDC.

To see if your display size and DPI are detected/calculated correctly:

$ xdpyinfo | grep -B2 resolution

Check that the dimensions match your display size. If the Xorg server is not able to correctly calculate the screen size, it will default to 75x75 DPI and you will have to calculate it yourself.

If you have specifications on the physical size of the screen, they can be entered in the Xorg configuration file so that the proper DPI is calculated (adjust identifier to your xrandr output) :

Section "Monitor" Identifier "DVI-D-0" DisplaySize 286 179 # In millimeters EndSection

If you only want to enter the specification of your monitor without creating a full xorg.conf create a new config file. For example ():

Section "Monitor" Identifier "<default monitor>" DisplaySize 286 179 # In millimeters EndSection

Note: If you are using the proprietary NVIDIA driver, you may have to put under or section to make it take effect.

If you do not have specifications for physical screen width and height (most specifications these days only list by diagonal size), you can use the monitor's native resolution (or aspect ratio) and diagonal length to calculate the horizontal and vertical physical dimensions. Using the Pythagorean theorem on a 13.3" diagonal length screen with a 1280x800 native resolution (or 16:10 aspect ratio):

$ echo 'scale=5;sqrt(1280^2+800^2)' | bc # 1509.43698

This will give the pixel diagonal length and with this value you can discover the physical horizontal and vertical lengths (and convert them to millimeters):

$ echo 'scale=5;(13.3/1509)*1280*25.4' | bc # 286.43072 $ echo 'scale=5;(13.3/1509)*800*25.4' | bc # 179.01920

Note: This calculation works for monitors with square pixels; however, there is the seldom monitor that may compress aspect ratio (e.g 16:10 aspect resolution to a 16:9 monitor). If this is the case, you should measure your screen size manually.

Setting DPI manually

Note: While you can set any dpi you like and applications using Qt and GTK will scale accordingly, it's recommended to set it to 96, 120 (25% higher), 144 (50% higher), 168 (75% higher), 192 (100% higher) etc., to reduce scaling artifacts to GUI that use bitmaps. Reducing it below 96 dpi may not reduce size of graphical elements of GUI as typically the lowest dpi the icons are made for is 96.

For RandR compliant drivers (for example the open source ATI driver), you can set it by:

$ xrandr --dpi 144

Note: Applications that comply with the setting will not change immediately. You have to start them anew.

To make it permanent, see Autostarting#On Xorg startup.

Proprietary NVIDIA driver

You can manually set the DPI by adding the option under the or section:

Option "DPI" "96 x 96"
Manual DPI Setting Caveat

GTK very often overrides the server's DPI via the optional Xresource . To find out whether this is happening to you, check with:

$ xrdb -query | grep dpi

With GTK library versions since 3.16, when this variable is not otherwise explicitly set, GTK sets it to 96. To have GTK apps obey the server DPI you may need to explictly set Xft.dpi to the same value as the server. The Xft.dpi resource is the method by which some desktop environments optionally force DPI to a particular value in personal settings. Among these are KDE and TDE.

Display Power Management

DPMS (Display Power Management Signaling) is a technology that allows power saving behaviour of monitors when the computer is not in use. This will allow you to have your monitors automatically go into standby after a predefined period of time.

Composite

The Composite extension for X causes an entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window, or merged by external programs called compositing managers. For more information, see Wikipedia:Compositing window manager.

Some window managers (e.g. Compiz, Enlightenment, KWin, Marco, Metacity, Muffin, Mutter, Xfwm) do compositing on their own. For other window managers, a standalone composite manager can be used.

List of composite managers

  • Picom — Compositor (a fork of Compton)
https://github.com/yshui/picom || picom
  • Xcompmgr — Composite window-effects manager
https://cgit.freedesktop.org/xorg/app/xcompmgr/ || xcompmgr
  • Unagi — Modular compositing manager which aims to be efficient, lightweight and responsive. It is written in C and based on XCB
https://projects.mini-dweeb.org/projects/unagi || unagiAUR

Tips and tricks

Automation

This section lists utilities for automating keyboard / mouse input and window operations (like moving, resizing or raising).

ToolPackageManualKeysym
input
Window
operations
Note
xautomation xautomationxte(1)YesNoAlso contains screen scraping tools. Cannot simulate F13+.
xdo xdoxdo(1)NoYesSmall X utility to perform elementary actions on windows.
xdotool xdotoolxdotool(1)YesYesVery buggy and not in active development, e.g: has broken CLI parsing.[2][3]
xvkbd xvkbdAURxvkbd(1)YesNoVirtual keyboard for Xorg, also has the option for sending characters.
AutoKey autokey-qtAURautokey-gtkAURdocumentationYesYesHigher-level, powerful macro and scripting utility, with both Qt and Gtk front-ends.

See also Clipboard#Tools and an overview of X automation tools.

Nested X session

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: mention xephyr (Discuss in Talk:Xorg)

To run a nested session of another desktop environment:

$ /usr/bin/Xnest :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1

This will launch a Window Maker session in a 1024 by 768 window within your current X session.

This needs the package xorg-server-xnest to be installed.

Starting GUI programs remotely

See main article: OpenSSH#X11 forwarding.

On-demand disabling and enabling of input sources

With the help of xinput you can temporarily disable or enable input sources. This might be useful, for example, on systems that have more than one mouse, such as the ThinkPads and you would rather use just one to avoid unwanted mouse clicks.

Install the xorg-xinput package.

Find the name or ID of the device you want to disable:

$ xinput

For example in a Lenovo ThinkPad T500, the output looks like this:

$ xinput⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]

Disable the device with , where device is the device ID or name of the device you want to disable. In this example we will disable the Synaptics Touchpad, with the ID 10:

$ xinput --disable 10

To re-enable the device, just issue the opposite command:

$ xinput --enable 10

Alternatively using the device name, the command to disable the touchpad would be:

$ xinput --disable "SynPS/2 Synaptics TouchPad"

Killing application with hotkey

Run script on hotkey:

#!/bin/bash windowFocus=$(xdotool getwindowfocus); pid=$(xprop -id $windowFocus | grep PID); kill -9 $pid

Deps: xorg-xprop, xdotool

Block TTY access

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Why would you want to do this? (Discuss in Talk:Xorg)

To block tty access when in an X add the following to xorg.conf:

Section "ServerFlags" Option "DontVTSwitch" "True" EndSection

Prevent a user from killing X

To prevent a user from killing when it is running add the following to xorg.conf:

Section "ServerFlags" Option "DontZap" "True" EndSection

Rootless Xorg

Xorg may run with standard user privileges instead of root (so-called "rootless" Xorg). This is a significant security improvement over running as root. Note that most display managers do not support rootless Xorg.

You can verify which user Xorg is running as with .

See also Xorg.wrap(1), systemd-logind(8), Systemd/User#Xorg as a systemd user service, Fedora:Changes/XorgWithoutRootRights and FS#41257.

Using xinitrc

To configure rootless Xorg using xinitrc:

  • Run startx as a subprocess of the login shell; run directly and do not use .
  • Ensure that Xorg uses virtual terminal for which permissions were set, i.e. passed by logind in via .xserverrc.
  • If using certain proprietary display drivers, kernel mode settingauto-detection will fail. In such cases, you must set in .

Using GDM

GDM will run Xorg without root privileges by default when kernel mode setting is used.

Session log redirection

When Xorg is run in rootless mode, Xorg logs are saved to . However, the stdout and stderr output from the Xorg session is not redirected to this log. To re-enable redirection, start Xorg with the flag and redirect the stdout and stderr output to a file:

startx -- -keeptty >~/.xorg.log 2>&1

Alternatively, copy to , and append . See [4].

Troubleshooting

General

If a problem occurs, view the log stored in either or, for the rootless X default since v1.16, in . GDM users should check the systemd journal. [5]

The logfiles are of the form with being the display number. For a single user machine with default configuration the applicable log is frequently , but otherwise it may vary. To make sure to pick the right file it may help to look at the timestamp of the X server session start and from which console it was started. For example:

$ grep -e Log -e tty Xorg.0.log[ 40.623] (==) Log file: "/home/archuser/.local/share/xorg/Xorg.0.log", Time: Thu Aug 28 12:36:44 2014 [ 40.704] (--) controlling tty is VT number 1, auto-enabling KeepTty
  • In the logfile then be on the lookout for any lines beginning with , which represent errors, and also , which are warnings that could indicate other issues.
  • If there is an empty file in your , either delete or edit it in order for X to start properly. If you do not do this X will show a blank screen with what appears to be no errors in your . Simply deleting it will get it running with a default X environment.
  • If the screen goes black, you may still attempt to switch to a different virtual console (e.g. ), and blindly log in as root. You can do this by typing (press after typing it) and entering the root password (again, press after typing it).
You may also attempt to kill the X server with:
# pkill -x X
If this does not work, reboot blindly with:
# reboot

Black screen, No protocol specified.., Resource temporarily unavailable for all or some users

X creates configuration and temporary files in current user's home directory. Make sure there is free disk space available on the partition your home directory resides in. Unfortunately, X server does not provide any more obvious information about lack of disk space in this case.

DRI with Matrox cards stopped working

If you use a Matrox card and DRI stopped working after upgrading to Xorg, try adding the line:

Option "OldDmaInit" "On"

to the Device section that references the video card in .

Frame-buffer mode problems

X fails to start with the following log messages:

(WW) Falling back to old probe method for fbdev (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 1.6.1, module version=0.0.2 ABI class: X.Org Video Driver, version 5.0 (II) FBDEV(1): using default device Fatal server error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

To correct, uninstall the xf86-video-fbdev package.

Program requests "font '(null)'"

Error message: .

Some programs only work with bitmap fonts. Two major packages with bitmap fonts are available, xorg-fonts-75dpi and xorg-fonts-100dpi. You do not need both; one should be enough. To find out which one would be better in your case, try from xorg-xdpyinfo, like this:

$ xdpyinfo | grep resolution

and use what is closer to the shown value.

Recovery: disabling Xorg before GUI login

If Xorg is set to boot up automatically and for some reason you need to prevent it from starting up before the login/display manager appears (if the system is wrongly configured and Xorg does not recognize your mouse or keyboard input, for instance), you can accomplish this task with two methods.

  • Change default target to rescue.target. See systemd#Change default target to boot into.
  • If you have not only a faulty system that makes Xorg unusable, but you have also set the GRUB menu wait time to zero, or cannot otherwise use GRUB to prevent Xorg from booting, you can use the Arch Linux live CD. Follow the installation guide about how to mount and chroot into the installed Arch Linux. Alternatively try to switch into another tty with + function key (usually from to depending on which is not used by X), login as root and follow steps below.

Depending on setup, you will need to do one or more of these steps:

X clients started with "su" fail

If you are getting "Client is not authorized to connect to server", try adding the line:

session optional pam_xauth.so

to and . will then properly set environment variables and handle keys.

X failed to start: Keyboard initialization failed

If the filesystem (specifically ) is full, will fail. will end with:

(EE) Error compiling keymap (server-0) (EE) XKB: Could not compile keymap (EE) XKB: Failed to load keymap. Loading default keymap instead. (EE) Error compiling keymap (server-0) (EE) XKB: Could not compile keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices. Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (II) AIGLX: Suspending AIGLX clients for VT switch

Make some free space on the relevant filesystem and X will start.

A green screen whenever trying to watch a video

Your color depth is set wrong. It may need to be 24 instead of 16, for example.

SocketCreateListener error

If X terminates with error message "SocketCreateListener() failed", you may need to delete socket files in . This may happen if you have previously run Xorg as root (e.g. to generate an ).

Invalid MIT-MAGIC-COOKIE-1 key when trying to run a program as root

That error means that only the current user has access to the X server. The solution is to give access to root:

$ xhost +si:localuser:root

That line can also be used to give access to X to a different user than root.

Xorg-server Fatal server error: (EE) AddScreen/ScreenInit

If the Xorg server is not working randomly and in the Xorg log you see:

systemd-logind: failed to take device /dev/dri/card0: Operation not permitted ... AddScreen/ScreenInit failed for driver 0

Then, this problem may be caused by systemd issue 13943. Set up early KMS start.

See also

Sours: https://wiki.archlinux.org/title/xorg
How to Fix Screen Tearing by Enabling VSync in Xorg Under Arch Linux (Intel Configuration Example)

The X server is a single binary executable (). Associated configuration files are stored in the directory (as is a symbolic link — X — which points to ). The configuration file for the X server is .

The directory contains X server modules that can be loaded dynamically at runtime. By default, only some modules in are automatically loaded by the X server.

To load optional modules, they must be specified in the X server configuration file, . For more information about loading modules, refer to Section 30.3.1.5, “Module”.

When Red Hat Enterprise Linux 5 is installed, the configuration files for X are created using information gathered about the system hardware during the installation process.

While there is rarely a need to manually edit the file, it is useful to understand the various sections and optional parameters available, especially when troubleshooting.

The file is comprised of many different sections which address specific aspects of the system hardware.

Each section begins with a line (where is the title for the section) and ends with an line. Each section contains lines that include option names and one or more option values. These are sometimes enclosed in double quotes ().

Lines beginning with a hash mark () are not read by the X server and are used for human-readable comments.

Some options within the file accept a boolean switch which turns the feature on or off. Acceptable boolean values are:

  • , , , or — Turns the option on.

  • , , , or — Turns the option off.

The following are some of the more important sections in the order in which they appear in a typical file. More detailed information about the X server configuration file can be found in the man page.

The optional section contains miscellaneous global X server settings. Any settings in this section may be overridden by options placed in the section (refer to Section 30.3.1.3, “ServerLayout” for details).

Each entry within the section is on its own line and begins with the term followed by an option enclosed in double quotation marks ().

The following is a sample section:

The following lists some of the most useful options:

  • — When the value of is set to true, this setting prevents the use of the Ctrl-Alt-Backspace key combination to immediately terminate the X server.

  • — When the value of is set to true, this setting prevents cycling through configured video resolutions using the Ctrl-Alt-Keypad-Plus and Ctrl-Alt-Keypad-Minus key combinations.

The section binds together the input and output devices controlled by the X server. At a minimum, this section must specify one output device and one input device. By default, a monitor (output device) and keyboard (input device) are specified.

The following example illustrates a typical section:

The following entries are commonly used in the section:

  • — Specifies a unique name for this section.

  • — Specifies the name of a section to be used with the X server. More than one option may be present.

    The following is an example of a typical entry:

    The first number in this example entry () indicates that the first monitor connector or head on the video card uses the configuration specified in the section with the identifier .

    An example of a section with the identifier can be found in Section 30.3.1.9, “Screen”.

    If the video card has more than one head, another entry with a different number and a different section identifier is necessary .

    The numbers to the right of give the absolute X and Y coordinates for the upper-left corner of the screen ( by default).

  • — Specifies the name of an section to be used with the X server.

    It is advisable that there be at least two entries: one for the default mouse and one for the default keyboard. The options and indicate that these are the primary mouse and keyboard.

  • — An optional entry which specifies extra parameters for the section. Any options listed here override those listed in the section.

    Replace with a valid option listed for this section in the man page.

It is possible to put more than one section in the file. By default, the server only reads the first one it encounters, however.

If there is an alternative section, it can be specified as a command line argument when starting an X session.

The section sets paths for services vital to the X server, such as the font path. This is an optional section, these paths are normally detected automatically. This section may be used to override any automatically detected defaults.

The following example illustrates a typical section:

The following entries are commonly used in the section:

  • — Specifies the location of the RGB color database. This database defines all valid color names in X and ties them to specific RGB values.

  • — Specifies where the X server must connect to obtain fonts from the font server.

    By default, the is . This tells the X server to obtain font information using UNIX-domain sockets for inter-process communication (IPC) on port 7100.

    Refer to Section 30.4, “Fonts” for more information concerning X and fonts.

  • — An optional parameter which specifies alternate directories which store X server modules.

By default, the X server automatically loads the following modules from the directory:

The default directory for loading these modules can be changed by specifying a different directory with the optional parameter in the section. Refer to Section 30.3.1.4, “Files” for more information on this section.

Adding a section to instructs the X server to load the modules listed in this section instead of the default modules.

For example, the following typical section:

instructs the X server to load the instead of the default modules.

As such, if you add a section to , you will need to specify any default modules you want to load as well as any extra modules.

Each section configures one input device for the X server. Systems typically have at least one section for the keyboard. It is perfectly normal to have no entry for a mouse, as most mouse settings are automatically detected.

The following example illustrates a typical section for a keyboard:

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies the name of the device driver X must load for the device.

  • — Specifies necessary options pertaining to the device.

    A mouse may also be specified to override any autodetected defaults for the device. The following options are typically included when adding a mouse in the :

    • — Specifies the protocol used by the mouse, such as .

    • — Specifies the location of the physical device.

    • — Specifies whether to allow a two-button mouse to act like a three-button mouse when both mouse buttons are pressed simultaneously.

    Consult the man page for a list of valid options for this section.

Each section configures one type of monitor used by the system. This is an optional entry as well, as most monitors are now automatically detected.

The easiest way to configure a monitor is to configure X during the installation process or by using the X Configuration Tool. For more information about using the X Configuration Tool, refer to Chapter 31, X Window System Configuration.

This example illustrates a typical section for a monitor:

Warning

Be careful when manually editing values in the section of . Inappropriate values can damage or destroy a monitor. Consult the monitor's documentation for a listing of safe operating parameters.

The following are commonly entries used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — An optional parameter which specifies the vendor of the monitor.

  • — An optional parameter which specifies the monitor's model name.

  • — An optional parameter which specifies, in millimeters, the physical size of the monitor's picture area.

  • — Specifies the range of horizontal sync frequencies compatible with the monitor in kHz. These values help the X server determine the validity of built-in or specified entries for the monitor.

  • — Specifies the range of vertical refresh frequencies supported by the monitor, in kHz. These values help the X server determine the validity of built in or specified entries for the monitor.

  • — An optional parameter which specifies additional video modes for the monitor at particular resolutions, with certain horizontal sync and vertical refresh resolutions. Refer to the man page for a more detailed explanation of entries.

  • — An optional entry which specifies extra parameters for the section. Replace with a valid option listed for this section in the man page.

Each section configures one video card on the system. While one section is the minimum, additional instances may occur for each video card installed on the machine.

The best way to configure a video card is to configure X during the installation process or by using the X Configuration Tool. For more about using the X Configuration Tool, refer to Chapter 31, X Window System Configuration.

The following example illustrates a typical section for a video card:

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies which driver the X server must load to utilize the video card. A list of drivers can be found in , which is installed with the package.

  • — An optional parameter which specifies the vendor of the video card.

  • — An optional parameter which specifies the name of the video card.

  • — An optional parameter which specifies the amount of RAM available on the video card in kilobytes. This setting is only necessary for video cards the X server cannot probe to detect the amount of video RAM.

  • — An entry which specifies the bus location of the video card. On systems with only one video card a entry is optional and may not even be present in the default file. On systems with more than one video card, however, a entry must be present.

  • — An optional entry which specifies which monitor connector or head on the video card the section configures. This option is only useful for video cards with multiple heads.

    If multiple monitors are connected to different heads on the same video card, separate sections must exist and each of these sections must have a different value.

    Values for the entry must be an integer. The first head on the video card has a value of . The value for each additional head increments this value by one.

  • — An optional entry which specifies extra parameters for the section. Replace with a valid option listed for this section in the man page.

    One of the more common options is (for Display Power Management Signaling, a VESA standard), which activates the Service Star energy compliance setting for the monitor.

Each section binds one video card (or video card head) to one monitor by referencing the section and the section for each. While one section is the minimum, additional instances may occur for each video card and monitor combination present on the machine.

The following example illustrates a typical section:

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies the unique name of a section. This is a required entry.

  • — Specifies the unique name of a section. This is only required if a specific section is defined in the file. Normally, monitors are automatically detected.

  • — Specifies the default color depth in bits. In the previous example, (which provides thousands of colors) is the default. Only one is permitted, although this can be overridden with the Xorg command line option ,where is any additional depth specified.

  • — Specifies the screen modes available at a particular color depth. The section can have multiple subsections, which are entirely optional since screen modes are automatically detected.

    This subsection is normally used to override autodetected modes.

  • — An optional entry which specifies extra parameters for the section. Replace with a valid option listed for this section in the man page.

The optional section specifies parameters for the Direct Rendering Infrastructure (DRI). DRI is an interface which allows 3D software applications to take advantage of 3D hardware acceleration capabilities built into most modern video hardware. In addition, DRI can improve 2D performance via hardware acceleration, if supported by the video card driver.

This section rarely appears, as the DRI Group and Mode are automatically initialized to default values. If a different Group or Mode is desired, then adding this section to the file will override those defaults.

The following example illustrates a typical section:

Since different video cards use DRI in different ways, do not add to this section without first referring to http://dri.sourceforge.net/.

Sours: https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-x-server-configuration.html

Conf example xorg

Today's X rarely requires manual configuration. X now automatically configures itself with reasonable defaults. Both GNOME and KDE provide GUI utilities for customizing settings beyond these defaults if you like.

However, sometimes you need to muck with the configuration manually, beyond what these tools allow.

Quick xorg.conf

Most systems don't ship with an X config file any more, but sometimes you need one. Here's a basic skeleton:

Section "Device" Identifier "Configured Video Device" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" EndSection

Configuring using xorg.conf.d (Ubuntu 10.04 and newer)

Files ending in *.conf in the directory are automatically loaded by X at start prior to reading the xorg.conf. These files can each contain one or more Sections in the same format used by .

Users can continue making custom configuration in /etc/xorg.conf as usual; the .conf snippets are mainly there for the distro or hw vendor to ship default InputClass rules and custom overrides.

Configuration Recipes

General Configuration

Display Configuration

Other Resources


CategoryXTeam

Sours: https://wiki.ubuntu.com/X/Config
Ubuntu: Where is the X.org config file? How do I configure X there?
################################################################################# Filename: /etc/X11/xorg.conf# Purpose: config file for xserver# Bug-Reports: see http://grml.org/bugs/# See also:# /usr/share/doc/xserver-xorg/ and# http://wiki.x.org/wiki/Home and# http://ftp.x.org/pub/X11R7.0/doc/html/index.html for information on Xorg# Refer to the xorg.conf man page and to# http://ftp.x.org/pub/X11R7.0/doc/html/xorg.conf.5.html# for details about the format of this file.## If you would like this file to be automatically reconfigured by debian,# run the following command:# sudo dpkg-reconfigure -phigh xserver-xorg################################################################################Section "ServerLayout" Identifier "XServer Configured" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "USB Mouse" "CorePointer" # InputDevice "PS/2 Mouse" "CorePointer"EndSectionSection "ServerFlags" Option "AllowMouseOpenFail" "true" # allows the server to start up even if the mouse does not work Option "DontVTSwitch" "false" # allow switching between virtual terminal # Option "DontZoom" "true" # disable <Crtl><Alt><KP_+>/<KP_-> (resolution switching)EndSectionSection "Files"# RgbPath "/usr/X11R6/lib/X11/rgb"# ModulePath "/usr/X11R6/lib/modules"# More information: http://ftp.x.org/pub/X11R7.0/doc/html/fonts.html FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi"# True type and type1 fonts are also handled via xftlib, see /etc/X11/XftConfig! FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/share/fonts/ttf/western" FontPath "/usr/share/fonts/ttf/decoratives" FontPath "/usr/share/fonts/truetype/ttf-bitstream-vera" FontPath "/usr/share/fonts/latex-ttf-fonts" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"EndSection# Modules - see /usr/lib/xorg/modules/fonts and /usr/lib/xorg/modules/extensionsSection "Module" Load "dbe" # double buffer extension Load "dri" # direct rendering Load "glx" # 3D layer Load "extmod" # some commonly used server extensions (e.g. shape extension) Load "record" # recording extension Load "evdev" # generic input handling driver on Linux # Load "bitmap" # bitmap fonts # Load "ddc" # ddc probing of monitor # Load "freetype" # font rendering # Load "GLcore" # render OpenGL in software # Load "i2c" # I2C bus # Load "int10" # initialize graphics cards via int10 call to the BIOS # Load "speedo" # font module # Load "type1" # font module # Load "v4l" # Video for Linux # Load "vbe" # Vesa BIOS Extension# Valid entries - see /usr/lib/xorg/modules/[extensions/]# afb bitmap cfb cfb16 cfb24 cfb32 cw damage dbe ddc dri drm extmod fb# fbdevhw freetype GLcore glx i2c int10 int10 layer mfb pcidata rac ramdac# record scanpci shadow shadowfb type1 vbe vgahw xaa xf1bpp xf24_32bpp xf4bpp# xf8_16bpp xf8_32bpp xtrapEndSection# If you'd like to switch the positions of your capslock and control keys, use:# Option "XkbOptions" "ctrl:swapcaps"# Or if you just want both to be control, use:# Option "XkbOptions" "ctrl:nocaps"# More information: http://ftp.x.org/pub/X11R7.0/doc/html/XKB-Config.htmlSection "InputDevice" Identifier "Keyboard0" Option "CoreKeyboard" Driver "kbd" #Option "XkbRules" "xfree86" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" #Option "XkbVariant" "nodeadkeys" #Option "XkbOptions" "ctrl:swapcaps,grp:alt_shift_toggle,grp_led:scroll,compose:menu"EndSection# More information: http://ftp.x.org/pub/X11R6.9.0/doc/html/mouse.htmlSection "InputDevice" Identifier "USB Mouse" Driver "mouse" Option "Device" "/dev/input/mice" Option "Protocol" "auto" Option "ZAxisMapping" "4 5" Option "Buttons" "5" Option "SendCoreEvents" "true"EndSectionSection "InputDevice" Identifier "PS/2 Mouse" Driver "mouse" Option "Device" "/dev/input/mice" # Option "Device" "/dev/psaux" Option "Protocol" "PS/2" Option "Emulate3Buttons" "true" Option "Emulate3Timeout" "70" Option "SendCoreEvents" "true"EndSection# Example for a Elo touchscreen:# Section "InputDevice"# Identifier "touchscreen"# Driver "elographics"# Option "Device" "/dev/ttyS0"# Option "SendCoreEvents" "true"# Option "MinX" "4070"# Option "MaxX" "0"# Option "MinY" "36"# Option "MaxY" "3960"# Option "ScreenNo" "1"# Option "BaudRate" "9600"# Option "StopBits" "1"# Option "DataBits" "8"# Option "Parity" "None"# Option "Vmin" "10"# Option "Vtime" "1"# Option "FlowControl" "None"# Option "PortraitMode" "Portrait"# Option "PortraitMode" "PortraitCCW"# Option "SwapXY" "true"# Option "UntouchDelay" "3"# Option "ReportDelay" "1"# EndSectionSection "Monitor" Identifier "Monitor0"# ModelName "Old Monitor (no DDC)" Option "DPMS" "true"# HorizSync 28.0 - 78.0 # Warning: This may fry very old Monitors# HorizSync 28.0 - 96.0 # Warning: This may fry old Monitors HorizSync 31.0 - 61.0# VertRefresh 50.0 - 76.0 # Very conservative. May flicker.# VertRefresh 50.0 - 60.0 # Extreme conservative. Will flicker. TFT default. VertRefresh 50.0 - 90.0# Need more information?# http://xtiming.sourceforge.net/cgi-bin/xtiming.pl# http://en.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/EndSectionSection "Device" ### Available Driver options are: ## sw_cursor is needed for some ati and radeon cards # Option "sw_cursor" # Option "hw_cursor" # Option "NoAccel" # Option "ShowCache" # Option "ShadowFB" # Option "UseFBDev" # Option "Rotate" ## xorg + nvidia: # Option "RenderAccel" "true" # Option "AllowGLXWithComposite" "true" Identifier "Card0" Driver "vesa" VendorName "All" BoardName "All" ## Workaround for drivers which send output to wrong device: # Option "MonitorLayout" "LVDS, AUTO" # Option "MonitorLayout" "LVDS, CRT" # Option "MonitorLayout" "NONE, STV" # Option "MonitorLayout" "LVDS" ## Specify BusID: # BusID "PCI:1:0:0"EndSectionSection "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultColorDepth 16 SubSection "Display" Depth 1 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 4 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 15 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSection SubSection "Display" Depth 32 Modes "1024x768" "800x600" "640x480" "1600x1200" "1280x1024" "1280x960" EndSubSectionEndSection# Make sure you have the relevant Debian packages on your system# to be able to use DRI (libgl1-mesa-dri for example)Section "DRI" Mode 0666EndSection#Section "Extensions"# Option "Composite" "Enable"#EndSection## END OF FILE #################################################################
Sours: https://github.com/grml/grml-x/blob/master/etc/X11/xorg.conf.example

You will also like:

⁠B.3.3. The File

In previous releases of the X Window System, file was used to store initial setup for X. When a change occurred with the monitor, video card or other device managed by the X server, the file needed to be edited manually. In Fedora, there is rarely a need to manually create and edit the file. Nevertheless, it is still useful to understand various sections and optional parameters available, especially when troubleshooting or setting up unusual hardware configuration.

In the following, some important sections are described in the order in which they appear in a typical file. More detailed information about the X server configuration file can be found in the man page. This section is mostly intended for advanced users as most configuration options described below are not needed in typical configuration scenarios.

⁠B.3.3.1. The section

is a new type of configuration section that does not apply to a single device but rather to a class of devices, including hot-plugged devices. An section's scope is limited by the matches specified; in order to apply to an input device, all matches must apply to the device as seen in the example below:

Section "InputClass" Identifier "touchpad catchall" MatchIsTouchpad "on" Driver "synaptics" EndSection

If this snippet is present in an file or an directory, any touchpad present in the system is assigned the driver.

Note that due to alphanumeric sorting of configuration files in the directory, the setting in the example above overwrites previously set driver options. The more generic the class, the earlier it should be listed.

The match options specify which devices a section may apply to. To match a device, all match options must correspond. The following options are commonly used in the section:

  • , , , , — boolean options to specify a type of a device.

  • — this option matches if the product_name substring occurs in the product name of the device.

  • — this option matches if the vendor_name substring occurs in the vendor name of the device.

  • — this option matches any device if its device path corresponds to the patterns given in the "/path/to/device" template, for example . See the man page for further details.

  • — this option matches if at least one tag assigned by the HAL configuration back end matches the tag_pattern pattern.

A configuration file may have multiple sections. These sections are optional and are used to configure a class of input devices as they are automatically added. An input device can match more than one section. When arranging these sections, it is recommended to put generic matches above specific ones because each input class can override settings from a previous one if an overlap occurs.

⁠B.3.3.2. The section

Each section configures one input device for the X server. Previously, systems typically had at least one section for the keyboard, and most mouse settings were automatically detected.

With Fedora 20, no configuration is needed for most setups, and the xorg-x11-drv-* input driver packages provide the automatic configuration through HAL. The default driver for both keyboards and mice is .

The following example shows a typical section for a keyboard:

Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies the name of the device driver X must load for the device. If the option is enabled (which is the default setting), any input device section with or will be ignored. This is necessary due to conflicts between the legacy mouse and keyboard drivers and the new generic driver. Instead, the server will use the information from the back end for any input devices. Any custom input device configuration in the should be moved to the back end. In most cases, the back end will be HAL and the configuration location will be the directory.

  • — Specifies necessary options pertaining to the device.

    A mouse may also be specified to override any auto-detected values for the device. The following options are typically included when adding a mouse in the file:

    • — Specifies the protocol used by the mouse, such as .

    • — Specifies the location of the physical device.

    • — Specifies whether to allow a two-button mouse to act like a three-button mouse when both mouse buttons are pressed simultaneously.

    Consult the man page for a complete list of valid options for this section.

⁠B.3.3.3. The section

The optional section contains miscellaneous global X server settings. Any settings in this section may be overridden by options placed in the section (refer to Section B.3.3.4, “” for details).

Each entry within the section occupies a single line and begins with the term followed by an option enclosed in double quotation marks ().

The following is a sample section:

Section "ServerFlags" Option "DontZap" "true" EndSection

The following lists some of the most useful options:

  • — When the value of <boolean> is set to , this setting prevents the use of the Ctrl+Alt+Backspace key combination to immediately terminate the X server.

    Even if this option is enabled, the key combination still must be configured in the X Keyboard Extension (XKB) map before it can be used. One way how to add the key combination to the map is to run the following command:
  • — When the value of <boolean> is set to , this setting prevents cycling through configured video resolutions using the Ctrl+Alt+Keypad-Plus and Ctrl+Alt+Keypad-Minus key combinations.

  • — When the value of <boolean> is set to , the server will not hot plug input devices and instead rely solely on devices configured in the file. See Section B.3.3.2, “The section” for more information concerning input devices. This option is enabled by default and HAL (hardware abstraction layer) is used as a back end for device discovery.

The section binds together the input and output devices controlled by the X server. At a minimum, this section must specify one input device and one output device. By default, a monitor (output device) and a keyboard (input device) are specified.

The following example shows a typical section:

Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection

The following entries are commonly used in the section:

  • — Specifies a unique name for this section.

  • — Specifies the name of a section to be used with the X server. More than one option may be present.

    The following is an example of a typical entry:

    Screen 0 "Screen0" 0 0

    The first number in this example entry () indicates that the first monitor connector, or head on the video card, uses the configuration specified in the section with the identifier .

    An example of a section with the identifier can be found in Section B.3.3.8, “The section”.

    If the video card has more than one head, another entry with a different number and a different section identifier is necessary.

    The numbers to the right of give the absolute X and Y coordinates for the upper left corner of the screen ( by default).

  • — Specifies the name of an section to be used with the X server.

    It is advisable that there be at least two entries: one for the default mouse and one for the default keyboard. The options and indicate that these are the primary mouse and keyboard. If the option is enabled, this entry needs not to be specified in the section. If the option is disabled, both mouse and keyboard are auto-detected with the default values.

  • — An optional entry which specifies extra parameters for the section. Any options listed here override those listed in the section.

    Replace <option-name> with a valid option listed for this section in the man page.

It is possible to put more than one section in the file. By default, the server only reads the first one it encounters, however. If there is an alternative section, it can be specified as a command line argument when starting an X session; as in the command.

⁠B.3.3.5. The section

The section sets paths for services vital to the X server, such as the font path. This is an optional section, as these paths are normally detected automatically. This section can be used to override automatically detected values.

The following example shows a typical section:

Section "Files" RgbPath "/usr/share/X11/rgb.txt" FontPath "unix/:7100" EndSection

The following entries are commonly used in the section:

  • — An optional parameter which specifies alternate directories which store X server modules.

⁠B.3.3.6. The section

Each section configures one type of monitor used by the system. This is an optional entry as most monitors are now detected automatically.

This example shows a typical section for a monitor:

Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DDC Probed Monitor - ViewSonic G773-2" DisplaySize 320 240 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 180.0 EndSection

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — An optional parameter which specifies the vendor of the monitor.

  • — An optional parameter which specifies the monitor's model name.

  • — An optional parameter which specifies, in millimeters, the physical size of the monitor's picture area.

  • — Specifies the range of horizontal sync frequencies compatible with the monitor, in kHz. These values help the X server determine the validity of built-in or specified entries for the monitor.

  • — Specifies the range of vertical refresh frequencies supported by the monitor, in kHz. These values help the X server determine the validity of built-in or specified entries for the monitor.

  • — An optional parameter which specifies additional video modes for the monitor at particular resolutions, with certain horizontal sync and vertical refresh resolutions. See the man page for a more detailed explanation of entries.

  • — An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the man page.

⁠B.3.3.7. The section

Each section configures one video card on the system. While one section is the minimum, additional instances may occur for each video card installed on the machine.

The following example shows a typical section for a video card:

Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" VideoRam 8192 Option "dpms" EndSection

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies which driver the X server must load to utilize the video card. A list of drivers can be found in , which is installed with the hwdata package.

  • — An optional parameter which specifies the vendor of the video card.

  • — An optional parameter which specifies the name of the video card.

  • — An optional parameter which specifies the amount of RAM available on the video card, in kilobytes. This setting is only necessary for video cards the X server cannot probe to detect the amount of video RAM.

  • — An entry which specifies the bus location of the video card. On systems with only one video card a entry is optional and may not even be present in the default file. On systems with more than one video card, however, a entry is required.

  • — An optional entry which specifies which monitor connector or head on the video card the section configures. This option is only useful for video cards with multiple heads.

    If multiple monitors are connected to different heads on the same video card, separate sections must exist and each of these sections must have a different value.

    Values for the entry must be an integer. The first head on the video card has a value of . The value for each additional head increments this value by one.

  • — An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the man page.

    One of the more common options is (for Display Power Management Signaling, a VESA standard), which activates the Service Star energy compliance setting for the monitor.

⁠B.3.3.8. The section

Each section binds one video card (or video card head) to one monitor by referencing the section and the section for each. While one section is the minimum, additional instances may occur for each video card and monitor combination present on the machine.

The following example shows a typical section:

Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection

The following entries are commonly used in the section:

  • — Specifies a unique name for this section. This is a required entry.

  • — Specifies the unique name of a section. This is a required entry.

  • — Specifies the unique name of a section. This is only required if a specific section is defined in the file. Normally, monitors are detected automatically.

  • — Specifies the default color depth in bits. In the previous example, (which provides thousands of colors) is the default. Only one entry is permitted, although this can be overridden with the Xorg command line option , where is any additional depth specified.

  • — Specifies the screen modes available at a particular color depth. The section can have multiple subsections, which are entirely optional since screen modes are detected automatically.

    This subsection is normally used to override auto-detected modes.

  • — An optional entry which specifies extra parameters for the section. Replace <option-name> with a valid option listed for this section in the man page.

⁠B.3.3.9. The section

The optional section specifies parameters for the Direct Rendering Infrastructure (DRI). DRI is an interface which allows 3D software applications to take advantage of 3D hardware acceleration capabilities built into most modern video hardware. In addition, DRI can improve 2D performance via hardware acceleration, if supported by the video card driver.

This section is rarely used, as the DRI Group and Mode are automatically initialized to default values. If a different Group or Mode is needed, then adding this section to the file will override the default values.

The following example shows a typical section:

Section "DRI" Group 0 Mode 0666 EndSection

Since different video cards use DRI in different ways, do not add to this section without first referring to http://dri.freedesktop.org/wiki/.

Sours: https://jfearn.fedorapeople.org/fdocs/en-US/Fedora_Draft_Documentation/0.1/html/System_Administrators_Guide/s2-x-server-config-xorg.conf.html


987 988 989 990 991