Comando Linux Xorg

Em sistemas operacionais do tipo Unix, o Xorg é o executável do servidor X Window System , desenvolvido pela fundação X.org .

Descrição

O Xorg é um servidor X com todos os recursos que foi originalmente projetado para sistemas operacionais Unix e similares ao Unix , como o Linux , executando no hardware Intel x86 . Agora ele roda em uma ampla variedade de plataformas .

Sintaxe

Xorg [: display ] [ opção ...]

Opções

Teclado

O servidor Xorg é normalmente configurado para reconhecer várias combinações especiais de pressionamentos de tecla que instruem o servidor a executar alguma ação, em vez de apenas enviar o evento de pressionamento de tecla para um aplicativo cliente. Essas ações dependem do mapa de teclas XKB carregado por um dispositivo de teclado específico e podem ou não estar disponíveis em uma determinada configuração.

As seguintes combinações de teclas geralmente fazem parte do mapa de teclas padrão do XKEYBOARD.

Configuração

O Xorg normalmente usa um arquivo de configuração chamado xorg.conf e arquivos de configuração com o sufixo .conf em um diretório chamado xorg.conf.d para sua configuração inicial. Consulte a seção xorg.conf abaixo para obter informações sobre o formato deste arquivo.

Xorg tem um mecanismo para gerar automaticamente uma configuração built-in no tempo de execução quando não há xorg.conf arquivo ou xorg.conf.d arquivos estão presentes. A versão atual desse mecanismo de configuração automática funciona de duas maneiras.

A primeira é através de aprimoramentos que tornaram muitos componentes do arquivo xorg.conf opcionais. Isso significa que as informações que podem ser analisadas ou deduzidas razoavelmente não precisam ser especificadas explicitamente, reduzindo bastante a quantidade de informações de configuração internas que precisam ser geradas em tempo de execução.

O segundo é ter fallbacks “seguros” para a maioria das informações de configuração. Isso maximiza a probabilidade de o servidor Xorg iniciar em alguma configuração utilizável, mesmo quando as informações sobre o hardware específico não estão disponíveis.

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/<cmdline>
/usr/etc/X11/<cmdline>
/etc/X11/$XORGCONFIG
/usr/etc/X11/$XORGCONFIG
/etc/X11/xorg.conf
/etc/xorg.conf
/usr/etc/X11/xorg.conf.<hostname>
/usr/etc/X11/xorg.conf
/usr/lib/X11/xorg.conf.<hostname>
/usr/lib/X11/xorg.conf

where <cmdline> is a relative path (with no “..” components) specified with the -config command line option, $XORGCONFIG is the relative path (with no “..” components) specified by that environment variable, and <hostname> is the machine’s hostname as reported by gethostname.

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

<cmdline>
/etc/X11/<cmdline>
/usr/etc/X11/<cmdline>
$XORGCONFIG
/etc/X11/$XORGCONFIG
/usr/etc/X11/$XORGCONFIG
/etc/X11/xorg.conf
/etc/xorg.conf
/usr/etc/X11/xorg.conf.<hostname>
/usr/etc/X11/xorg.conf
/usr/lib/X11/xorg.conf.<hostname>
/usr/lib/X11/xorg.conf

where <cmdline> is the path specified with the -config command line option (which may be absolute or relative), $XORGCONFIG is the path specified by that environment variable (absolute or relative), $HOME is the path specified by that environment variable (usually the home directory), and <hostname> is the machine’s hostname as reported by gethostname.

Additional configuration files are searched for in the following directories when the server is started as a normal user:

/etc/X11/<cmdline>
/etc/X11/<cmdline>
/etc/X11/xorg.conf.d
/etc/X11/xorg.conf.d

onde <cmdline> é um caminho relativo (sem componentes ” .. “) especificado com a opção de linha de comando -configdir .

Quando o servidor Xorg é iniciado pelo usuário root, os locais de pesquisa no diretório de configuração são os seguintes:

<cmdline>
/ etc / X11 / <cmdline>
/ etc / X11 / <cmdline>
/etc/X11/xorg.conf.d
/etc/X11/xorg.conf.d

onde <cmdline> é o caminho especificado com a opção de linha de comando -configdir (que pode ser absoluta ou relativa).

Por fim, os arquivos de configuração também serão pesquisados ​​em diretórios reservados para uso do sistema. Estes são para separar os arquivos de configuração do fornecedor ou dos pacotes de terceiros dos da administração local. Esses arquivos são encontrados nos seguintes diretórios:

/usr/share/X11/xorg.conf.d
/usr/share/X11/xorg.conf.d

Os xorg.conf e xorg.conf.d arquivos são compostos de muitas seções que podem estar presentes em qualquer ordem, ou omitido de usar valores de configuração padrão. Cada seção tem o formato:

Seção "SectionName"
    SectionEntry
    ...
EndSection

Os nomes das seções são:

Os seguintes nomes de seções obsoletos ainda são reconhecidos para fins de compatibilidade. Nos novos arquivos de configuração, a seção InputDevice deve ser usada.

(A seção antiga XInput das versões anteriores não é mais reconhecida.)

As seções ServerLayout estão no nível mais alto. Eles unem os dispositivos de entrada e saída que serão usados ​​em uma sessão. Os dispositivos de entrada são descritos nas seções InputDevice . Os dispositivos de saída geralmente consistem em vários componentes independentes (por exemplo, uma placa gráfica e um monitor). Esses vários componentes são unidos nas seções Tela , e são esses que são referenciados pela seção ServerLayout . Cada seção da tela une uma placa gráfica e um monitor. As placas gráficas são descritas nas seções Dispositivo e os monitores nas seções Monitor .

As palavras-chave do arquivo de configuração não diferenciam maiúsculas de minúsculas e os caracteres ” _ ” são ignorados. A maioria das seqüências de caracteres (incluindo os nomes das Opções) também não diferenciam maiúsculas de minúsculas e não diferenciam espaço em branco e caracteres ” _ “.

Cada entrada do arquivo de configuração geralmente ocupa uma única linha no arquivo. Eles consistem em uma palavra-chave, que é possivelmente seguida por um ou mais argumentos, com o número e os tipos dos argumentos, dependendo da palavra-chave. Os tipos de argumento são:

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:

<identifier>:[attribute]:pri=<priority>

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

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

/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/

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.

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:

Load "dri"

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 extmod module (which contains a miscellaneous group of server extensions) can be loaded, with the XFree86-DGA extension disabled by using the following entry:

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

Modules are searched for in each directory specified in the ModulePath search path, and in the drivers, 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.

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.

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 by using the UseModes keyword. In most cases the Modes sections are not necessary because the built-in set of VESA standard modes will be sufficient.

Modes sections have the following format:

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

The Identifier entry specifies the unique name for this set of mode 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.

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.

Aqui está um exemplo de uma seção ServerLayout para uma configuração de duas cabeças com dois mouses:

Seção "ServerLayout"
    Identificador "Layout 1"
    Tela "MGA 1"
    Tela "MGA 2" RightOf "MGA 1"
    InputDevice "Keyboard 1" "CoreKeyboard"
    InputDevice "Mouse 1" "CorePointer"
    InputDevice "Mouse 2" "SendCoreEvents"
    Opção "BlankTime" "5"
EndSection

Arquivo xorg.conf de amostra

A seguir, é apresentado um exemplo de arquivo xorg.conf , padrão para muitos sistemas Linux:

# /etc/X11/xorg.conf (arquivo de configuração do servidor xorg X Window System)
#
# Arquivo Xorg super afinado à mão por DMc
#
# Atualmente, executa exibição tripla em duas placas nvidia de cabeça dupla
#
# Copyright 2008 McPond Software  
#
# Este arquivo é um software gratuito: você pode redistribuí-lo e / ou modificar
# nos termos da Licença Pública Geral GNU, publicada por
# a Free Software Foundation, versão 3 da licença ou
# (a seu critério) em qualquer versão posterior.
#
# Este arquivo é distribuído na esperança de que seja útil,
# mas SEM QUALQUER GARANTIA; sem sequer a garantia implícita de
# COMERCIABILIDADE ou ADEQUAÇÃO A UM OBJETIVO ESPECÍFICO. Veja o
# GNU General Public License para mais detalhes.
#
# 1.0 Iniciar a partir do arquivo base, extrair o material do tablet wacom, eu não tenho um
# Reordene seções, adicione configuração de cabeça dupla
# >>> Dá 
# Erro fatal no servidor:
# Entidade solicitada já em uso!
# 1.1 Lendo mais ... Modo TwinView no driver de código aberto nv
# 1.2 Após a atualização do Feisty não iniciar na nVidia, volte para nv
# até conseguir rodar e verifique novamente com as ferramentas
# e, claro, nv não suporta Twinview?
# 1.3 Adicione mais suporte a botões para o Razor Copperhead
# 1.4 Inveja do Fiesty com a ajuda da nvidia-xconfig
# 1.5 Ative a cabeça dupla novamente
# 1.6 Altere para 20 "Viewsonic
# 1.7 A atualização do kernel para 2.6.20 quebra a nvidia novamente. 
# Altere para nv para começar
# Execute a inveja e mude novamente para o arquivo inalterado do xorg
# 1.8 Nova placa gráfica nVidia 8600GT com saída DVI dupla
# Drivers mais recentes necessários da nVidia 100.41.100
# 1.9 Novo LCD de tela ampla Samsung SyncMaster 226BW 22 "
# 2.0 Atualização principal do Hardy Heron 8.04. Novo envyng 1.1.1
# Nova versão do instalador da nvidia 173
# 2.1 Atualização do kernel 2.6.24-18 Não inicia depois
# Desabilitou dois caminhos de fonte vazios, desabilitou o type1, pois não estava carregando
# Ran inveja, mas a inicialização travou com erro fatal do servidor Sinal travado 4 
# server aborting libGLcore.so.1
# Inveja apenas o instalador de relatórios v169. Não vai fazer 173 como isso é beta
# Sim, instalado 173 manualmente. Parece 169 não funciona neste sistema
# Execute NVIDIA (blah) .run para configurar
# 2.2 Adicionar placa Asus Geforce 7200GS no segundo slot PCI-E 16x
# Necessário ajuda da nvidia-xconfig para que ambos rodem
# Os IDs da tela não são acumulativos, ou seja, para cada físico 
# card, o ID da tela começa com 0 novamente.
# Ele trata o 7200 como 'primário' provavelmente porque tem um número de barramento mais baixo
# significa que você precisa fazer login na tela. O painel de ferramentas pode ser movido para qualquer tela.
# 2.3 Tentativa de executar o Compiz
# Extensão composta não encontrada
# Você deve usar o XOrg> = 6.8 para que a translucidez e as sombras funcionem
#
# Índice:
# ServerLayout
# Fornecedor
# InputDevice - Teclado
# InputDevice - Mouse
# Dispositivo - Esquerda
# Dispositivo - Direito
# Monitor - Esquerda
# Monitor - Direito
# Tela - esquerda
# Tela - Direita
# Arquivos
# Module
# Extensões
#
#
# Notas:
# Os sinalizadores de servidor devem ir antes do layout do servidor
# O layout do servidor une tudo
Seção "ServerLayout"
    Identificador "TripleHeadLayout"
    Tela 0 "CentreScreen" 0 0
    # estava à direita, agora alterado para esquerda
    Tela 1 "RightScreen" RightOf "CentreScreen"
    # Não use LeftOf Same duas vezes, você tem duas telas fazendo a mesma coisa.
    Tela 2 "LeftScreen" EsquerdaDe "CentreScreen"
    # Alterou isso de 0 para 2
    Opção "Xinerama" "On"
    InputDevice "Ergonomic4000"
    InputDevice "Razer Copperhead"
EndSection
# Teclado Microsoft Ergonomic 4000
Seção "InputDevice"
    Identificador "Ergonomic4000"
    Driver "kbd"
    Opção "CoreKeyboard"
    Opção "XkbRules" "xorg"
    Opção "XkbModel" "pc105"
    Opção "XkbLayout" "nos"
    Opção "XkbOptions" "lv3: ralt_switch"
    # Seria bom se os principais botões da faixa de opções funcionassem
    # e o controle deslizante Zoom no centro
    botões # e voltar / avançar
EndSection
# Razer Copperhead e PS2 baseado em KVM
Seção "InputDevice"
    Identificador "Razer Copperhead"
    Driver "mouse"
    Opção "CorePointer"
    Opção "Dispositivo" "/ dev / input / mice"
    Opção "Protocolo" "ExplorerPS / 2"
    Opção "ZAxisMapping" "4 5"
        # O mapeamento do ZAxis é a rolagem. Excluir da lista abaixo
    Opção "Emulate3Buttons" "true"
    Opção "Botões" "9"
    Opção "ButtonMapping" "1 2 3 6 7 8 9"
        # 3 é o clique da roda
        # 6 e 7 e 8 e 9 estão nas laterais do mouse - e é difícil pressionar
EndSection
# Descrição do dispositivo gráfico
# nVidia GeForce 8600GT    
A seção # Device é para a placa de vídeo
# Uma seção por cabeça
Seção "Dispositivo"
    Identificador "nVidia 8600GT esquerdo"
    Driver "nvidia"
# Para uso após atualizações do kernel, mata a propriedade da nVidia
# Desative também a tela direita
# Driver "nv"
    Nome do fornecedor "NVIDIA Corporation"
    Nome da placa "GeForce 8600 GT"
# Barramento PCI-Express 16x
    BusID "PCI: 7: 0: 0"
# Aparece como PCI: 4 em outras máquinas
# BusID "PCI: 1: 0: 0" este é AGP
    Tela 0
        # Opções ...
EndSection
Seção "Dispositivo"
    Identificador "Right nVidia 8600GT"
    Driver "nvidia"
    Nome do fornecedor "NVIDIA Corporation"
    Nome da placa "GeForce 8600 GT"
    BusID "PCI: 7: 0: 0"
    Tela 1
# # Opções ...
EndSection
Seção "Dispositivo"
    Identificador "Left nVidia 7200"
    Driver "nvidia"
    Nome do fornecedor "NVIDIA Corporation"
    Nome da placa "GeForce 7200 GS"
    # Barramento PCI-Express 16x externo
    BusID "PCI: 2: 0: 0"
    Tela 0
# # Opções ...
EndSection
# Samsung SyncMaster 226BW - Direito
Seção "Monitor"
    Identificador "SyncMaster-226BW"
    Nome do fornecedor "Samsung"
    HorizSync 30.0 - 81.0
    VertRefresh 56.0 - 75.0
    Opção "DPMS"
# Mais opções...
EndSection
# Sony SDM-HS95P - Movido para outra máquina
#Seção "Monitor"
# Identificador "SDM-HS95P"
# Nome do fornecedor "Sony"
# HorizSync 28.0 - 65.0
# VertRefresh 57,0 - 63,0
# Opção "DPMS"
# Mais opções...
#EndSection
Seção "Monitor"
	Identificador "VG2021m"
	Opção "DPMS"
	HorizSync 28-65
	VertRefresh 57-63
        Nome do fornecedor "Viewsonic"
# Mais opções...
EndSection
Seção "Monitor"
	Identificador "SyncMaster-245B"
	Opção "DPMS"
        HorizSync 30-81
	VertRefresh 56-75
        Nome do fornecedor "Samsung"
# Mais opções...
EndSection
Seção "Tela"
	Identificador "CentreScreen"
	Dispositivo "nVidia 8600GT esquerdo"
	Monitor "VG2021m"
	# Gerente de composição
	Opção "RenderAccel" "true"
	Opção "TripleBuffer" "true"
# Não é necessário nos servidores X modernos Opção "AllowGLXWithComposite"
	Opção "DPMS" "true"
	PadrãoDepth 24
	Subseção "Exibição"
		Profundidade 24
		Modos "1400x1050"
	EndSubSection
EndSection
Seção "Tela"
	Identificador "RightScreen"
	Dispositivo "nVidia 8600GT certo"
	Monitor "SyncMaster-226BW"
	# Gerente de composição
	Opção "RenderAccel" "true"
	Opção "TripleBuffer" "true"
	Opção "AllowGLXWithComposite"
	Opção "DPMS" "true"
	PadrãoDepth 24
	Subseção "Exibição"
		Profundidade 24
		Modos "1680x1050"
	EndSubSection
        # Embora o SyncMaster e o Viewsonic sejam 1050, o 
        # Viewsonic é 10 mm mais alto. O Syncmaster possui uma afinação de pontos mais fina,
        # mas menos espaço físico
EndSection
Seção "Tela"
	Identificador "LeftScreen"
	Dispositivo "nVidia 7200 esquerdo"
	Monitor "SyncMaster-245B"
	# Gerente de composição
	Opção "RenderAccel" "true"
	Opção "TripleBuffer" "true"
	Opção "AllowGLXWithComposite"
	Opção "DPMS" "true"
	PadrãoDepth 24
	Subseção "Exibição"
		Profundidade 24
		Modos "1920x1200"
	EndSubSection
EndSection
# Nomes de caminho do arquivo
Seção "Arquivos"
# Essas pastas não existem
    FontPath "/ usr / share / fontes / X11 / misc"
    FontPath "/ usr / share / fonts / X11 / 100dpi"
# Nenhum arquivo aqui FontPath "/ usr / share / X11 / fonts / 75dpi"
# removeu esta cauda /: unscaled "
# Nenhum arquivo aqui também FontPath "/ usr / share / X11 / fonts / Type1"
# caminho para fontes defoma
    FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    RgbPath "/ usr / X11R6 / lib / X11 / rgb"
EndSection
# Carregamento de módulo dinâmico
Seção "Módulo"
    Carregar "bitmap"
    Carregar "dbe"
    Carregar "ddc"
    Carregar "extmod"
    Carregar "tipo livre"
    Carregar "glx"
    Carregar "int10"
# O módulo não existe no disco. Carregue "type1"
    Carregar "vbe"
EndSection
Seção "ServerFlags"
    Opção "Xinerama" "1"
EndSection
Seção "Extensões"
# Gerenciador de composição para xcompmgr
    Opção "Composto" "Ativar"
EndSection

Exemplos

Xorg -configure

Este comando instruirá o Xorg a analisar todos os dispositivos atuais e escrever um arquivo de configuração xorg.conf apropriado para o sistema.

Comandos relacionados

startx – inicia uma sessão do sistema X Window.