Xorg conf отсутствует debian

Обновлено: 09.01.2025

Файл настройки X-сервера /etc/X11/xorg.conf потихоньку выпилили из всех дистрибутивов Linux. Считается, что драйвера видеокарточек уже настолько хорошо справляются со своим конфигурированием, что файл настройки X-сервера уже не нужен.

На практике же пользователь все время сталкивается с проблемами первоначального конфигурирования оконной системы. То DPI монитора определился напрвильно, то кулер на видеокарточке крутится с бешенной скоростью, то частота обновления не соответствует аппаратным возможностями дисплея. Что делать в этом случае?

В интернетах подсказывают два варианта:

1. Вручную создать файл /etc/X11/xorg.conf , При старте оконной подсистемы он должен считаться и настройки из него должны примениться. Этот файл можно создать автоматически, на основе лога журнала загрузки оконной системы. Делается это так:

cp /var/log/Xorg.0.log /var/log/Xorg.1.log

Xorg -configure :1

cp xorg.conf.new /etc/X11/xorg.conf

После чего можно перегрузить компьютер. Если с автосгенерированным конфигом иксы не работают, для владельцев карточек NVidia есть еще один вариант создать базовый конфиг. Для этого надо установить в систему пакет nvidia-xconfig . После чего появится возможность запустить консольную утилиту nvidia-xconfig . Чаще всего, после работы этой утилиты, конфиг генерируется достаточно правильный, и есть возможность запустить иксы.

Примечание: для того, чтобы иметь возможность устанавливать драйвера NVIDIA и утилиты для конфигурирования видеокарточки, в файл

следует прописать non-free репозитарии:

После чего надо сделать обновление кеша репозитария:

2. Для того, чтобы внести корректировки в конфигурацию современного Xorg, требуется создавать файлы в каталоге /etc/X11/xorg.conf.d . Файлы будут загружаться в алфавитном порядке. Сложившаяся практика именования таких файлов — "две цифры_суть.conf", например 50_display.conf. В каждом файле могут находиться синтаксически верные настоечные секции, одна либо более.

Проблема в том, что в некоторых дистрибутивах такого каталога нет, и он не поддерживается. Тогда надо попробовать найти каталог:

Xorg is the default X Window server since Debian 4.0 (etch). It replaces XFree86 and is maintained in Debian by the XStrikeForce.

Current Status
Version numbers
Installing Xorg
Configure X
Edit xorg.conf
1. How can I edit my xorg config file?
2. What if I do not have a xorg config file?
Current Status

Version numbers

Xorg version numbering has changed since xorg 7.0. Nowadays, Xorg is released with a version number (like 7.4). This release is composed of various modules which have their own version number (each module started at version "1.0" when Xorg 7.0 development cycle started). For instance, Xorg 7.3 was shipped with Xserver version v1.4, xf86-input-evdev v1.1.5, xf86-video-intel v2.1.1, etc.. If you want to learn more about Xorg releases/versions, see this blog.

Debian version number follows upstream convention. The module's version may be different (The maintainers sometimes cherry-pick more recent and stable modules). Reminder: Debian package version sometimes starts with a digit followed by a column, like 1:7.3.1-2. That part (1:) is Debian-specific. Also, anything after the dash (-2) is the Debian packaging version.

Installing Xorg

Installing Xorg is simple as:

or for just the X11 server itself without drivers and utilities:

Note that with the latter you won't have the startx command (provided by bin:xinit but if you install it directly it'll pull all video drivers) and therefore will have troubles to start any graphical display.

If you wish to have a proper graphic session starter, you should consider running

where xxx is to be replaced by the name of your video driver.

Configure X

To reconfigure keyboard settings in Squeeze (and later) run as root in a terminal:

Edit xorg.conf

Some settings are only accessible through editing xorg.conf by hand.

How can I edit my xorg config file?

Open a terminal (or console) as root, then run :

What if I do not have a xorg config file?

If xorg.conf is missing for some reason, Xorg will probe your hardware on every startup. Though this works fine in most cases, some settings remain inaccessible. To create a starting point for customization, do the following.

Switch to a console as root (not a terminal emulator in X), then run:

Alternatively, reboot the machine in single user mode, then run:

Follow the on-screen instructions. This should give you something to work with.

Question: what should be done if generating this file fails, giving the message, 'Number of created screens does not match the number of detected devices'?

Anyway, probably, this is unnecessary. Per this comment and this advice, it seems best to create the directory /etc/X11/xorg.conf.d and place in it a few files in order to tweak sections of the implicit xorg.conf, as for example is done here.

Xorg reads vendor configuration information from the directory /usr/share/X11/xorg.conf.d, as stated by man xorg.conf.d.

Rather than in xorg.conf, another quite useful way to adjust X settings is on the fly, in a desktop environment's list of scripts to run at startup.

Run X

After installation run:

KDE users should use kdm. Others might use xdm, gdm3, lightdm.

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. The available command line options and environment variables (and some defaults) are described in the Xserver(1) and Xorg(1) manual pages. Most configuration file parameters, with their defaults, are described below. Driver and module specific configuration parameters are described in the relevant driver or module manual page.

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:

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

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

where <cmdline> is a relative path (with no “..” components) specified with the -configdir command line option.

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

where <cmdline> is the path specified with the -configdir command line option (which may be absolute or relative).

Finally, configuration files will also be searched for in a directory reserved for system use. This is to separate configuration files from the vendor or 3rd party packages from those of local administration. These files are found in the following directory:

The xorg.conf and xorg.conf.d files are composed of a number of sections which may be present in any order, or omitted to use default configuration values. Each section has the form:

The following obsolete section names are still recognised for compatibility purposes. In new config files, the InputDevice section should be used instead.

The old XInput section is no longer recognised.

The ServerLayout sections are at the highest level. They bind together the input and output devices that will be used in a session. The input devices are described in the InputDevice sections. Output devices usually consist of multiple independent components (e.g., a graphics board and a monitor). These multiple components are bound together in the Screen sections, and it is these that are referenced by the ServerLayout section. Each Screen section binds together a graphics board and a monitor. The graphics boards are described in the Device sections, and the monitors are described in the Monitor sections.

Config file keywords are case-insensitive, and “_” characters are ignored. Most strings (including Option names) are also case-insensitive, and insensitive to white space and “_” characters.

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.

and the following boolean option values are recognised as FALSE:

Example: the following option entries are equivalent:

Frequency option values consist of a real number that is optionally followed by one of the following frequency units:

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 is used to specify some path names required by the server. Some of these paths can also be set from the command line (see Xserver(1) and Xorg(1)). 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.
Catalogue directories can be specified using the prefix catalogue: before the directory name. The directory can then be populated with symlinks pointing to the real font directories, using the following syntax in the symlink name:
where <identifier> is an alphanumeric identifier, [attribute] is an attribute which will be passed to the underlying FPE and <priority> is a number used to order the fontfile FPEs. Examples:

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

where <trans> is the transport type to use to connect to the font server (e.g., unix for UNIX-domain sockets or tcp for a TCP/IP connection), <hostname> is the hostname of the machine running the font server, and <port-number> is the port number that the font server is listening on (usually 7100).

When this entry is not specified in the config file, the server falls back to the compiled-in default font path, which contains the following font path elements (which can be set inside a catalogue directory):

Font path elements that are found to be invalid are removed from the font path when the server starts up.

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 recognised. 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.

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.
Example: the DRI extension module can be loaded with the following entry:
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:

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:

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.
Example: the MIT-SHM extension can be disabled with the following entry:
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:

The Identifier and Driver entries are required in all InputDevice sections. All other entries are optional.

InputDevice sections recognise some driver-independent Options, which are described here. See the individual input driver manual pages for a description of the device-specific options.

This option controls the startup behavior only, a device may be reattached or set floating at runtime.

POINTER ACCELERATION¶

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, see the xinput(1) man page for details. Only the most important acceleration options are discussed here.

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:

The Identifier entry is required in all InputClass sections. All other entries are optional.

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.

The above directives have equivalents for negative matching with the NoMatchProduct, NoMatchVendor, NoMatchDevicePath, NoMatchOS, NoMatchPnPID, NoMatchUSBID, NoMatchDriver, NoMatchTag, and NoMatchLayout directives. These NoMatch directives match if the subsequent match is not met by the device.

The second type of entry is used to match device types. These entries take a boolean argument similar to Option entries.

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 config file may have multiple OutputClass sections. These sections are optional and are used to provide configuration for a class of output devices as they are automatically added. An output device can match more than one OutputClass section. Each class can override settings from a previous class, so it is best to arrange the sections with the most generic matches first.

OutputClass sections have the following format:

The Identifier entry is required in all OutputClass sections. All other entries are optional.

When an output device is automatically added, its characteristics are checked against all OutputClass sections. Each section can contain optional entries to narrow the match of the class. If none of the optional entries appear, the OutputClass section is generic and will match any output device. If more than one of these entries appear, they all must match for the configuration to apply.

When an output device has been matched to the OutputClass section, any Option entries are applied to the device. One OutputClass specific Option is recognized. See the Device section below for a description of the remaining Option entries.

A OutputClass Section may contain ModulePath entries. When an output device matches an OutputClass section, any ModulePath entries in that OutputClass are pre-pended to the search path for loadable Xorg server modules. See ModulePath in the Files section for more info.

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:

The Identifier and Driver entries are required in all Device sections. All other entries are optional.

Nobody wants to say how this works. Maybe nobody knows .

Monitor sections have the following format:

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:

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 mode-description is in four sections, the first three of which are mandatory. The first is the dot (pixel) clock. This is a single number specifying the pixel clock rate for the mode in MHz. The second section is a list of four numbers specifying the horizontal timings. These numbers are the hdisp, hsyncstart, hsyncend, and htotal values. The third section is a list of four numbers specifying the vertical timings. These numbers are the vdisp, vsyncstart, vsyncend, and vtotal values. The final section is a list of flags specifying other characteristics of the mode. Interlace indicates that the mode is interlaced. DoubleScan indicates a mode where each scanline is doubled. +HSync and -HSync can be used to select the polarity of the HSync signal. +VSync and -VSync can be used to select the polarity of the VSync signal. Composite can be used to specify composite sync on hardware where this is supported. Additionally, on some hardware, +CSync and -CSync may be used to select the composite sync polarity. The HSkew and VScan options mentioned above in the Mode entry description can also be used here.
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:

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

The Identifier entry is mandatory. All others are optional.

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.

Display subsections have the following format:
The visual type available for the depths 15, 16 and 24 are (default is TrueColor):
Not all drivers support DirectColor at these depths.

The visual types available for the depth 4 are (default is StaticColor):

The visual type available for the depth 1 (monochrome) is StaticGray.
Black red green blue This optional entry allows the “black” colour to be specified. This is only supported at depth 1. The default is black. White red green blue This optional entry allows the “white” colour to be specified. This is only supported at depth 1. The default is white. Options Option flags may be specified in the Display subsections. These may include driver-specific options and driver-independent options. The former are described in the driver-specific documentation. Some of the latter are described above in the section about the Screen section, and they may also be included here.
ServerLayout sections have the following format:

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.
and the first two should normally be used to indicate the core pointer and core keyboard devices respectively.
Here is an example of a ServerLayout section for a dual headed configuration with two mice:

The optional Vendor section may be used to provide vendor-specific configuration information. Multiple Vendor sections may be present, and they may contain an Identifier entry and multiple Option flags. The data therein is not used in this release.

Not all modules or interfaces are available on all platforms.

Other modules and interfaces: exa(4), fbdevhw(4), v4l(4).

Я каким-то образом умудрился сломать xorg в gentoo с kde. Стояло разрешение 1280х1024, однако ж после 48 дней аптайма я решил ребутнуться, и внезапно теперь разрешение 1024х768 и выше его сделать не получается. В настройках kde максимум - 1024, есть еще 800х600 и 640х480; файла xorg.conf в системе нет.

Что делать? Как решить проблему?

я что-то пропустил?

Так и должно быть

А вообще попробуй пересобрать модуль видеокарты x11-drivers/xf86-video-*

Блин, забыл указать.

Пересобрал. Не помогло.

module-rebuild populate && module-rebuild rebuild

xorg.conf нет, зато есть замечательный каталог xorg.conf.d, разрешение можно прописать там.

Такого тоже не нашел.

Так посмотри какие разрешения доступны:

Если нужного нет, создай его, например вот так:

Директорию /etc/X11/xorg/conf.d/ нужно создать.
kostik87 ★★★★★ ( 17.10.12 12:24:49 )
Последнее исправление: kostik87 17.10.12 12:25:36 (всего исправлений: 2)

Сдаётся мне, у Вас используется драйвер не intel, а vesa.
Покажите выхлоп этого:

Так. Не понял. Где строка Kernel driver in use: bla-bla-bla?

Я не брал :) . Ядро собирал генкернелом, если это как-то поможет.

Тогда давайте полный выхлоп:

Думаю, стоит попробовать какое-либо другое ядро, в котором модуль intel 100% рабочий. Мне кажется, в этом ядре тупо что-то сломано / отсутствует.

У вас используется драйвер не Intel, а vesa.

Однако, интеловый у меня тоже установлен. Каким-то образом можно указать, чтобы использовался не веса, а интел. Или vesa можно просто --unmerge?

Каким-то образом можно указать, чтобы использовался не веса, а интел

Создайте xorg.conf или директорию xorg.conf.d и явно укажите используемый драйвер.

Можете так же попробовать удалить vesa.

Насчет AGP - не удивляйся, так и должно быть

unmerge vesa можно если не боитесь посидеть в консоли без иксов..

Он же как-то Gentoo поставил, так что должен уметь сидеть )

У тебя используется vesa драйвер.

Хорошо, сейчас попробую создать вручную.

Thero , kostik87 Да, на стадии установки там сидел изрядно, пугаться нечего :)

Воспользовался статьей, на данный момент что имею:

И все равно на выбор только 640х480, 800х600 и 1024х768. Modeline вычислял с помощью калькулятора.

Второе, драйверы xorg-server`а пересобирали после обновления xorg-server ?
kostik87 ★★★★★ ( 17.10.12 16:04:26 )
Последнее исправление: kostik87 17.10.12 16:06:02 (всего исправлений: 1)

1. Вот в таком виде:

Тьфу, я вам удаление написал, извиняюсь, вам же сказали, что пакеты будут удаляться:

Нужно было без ключа '-c'

У вас xorg-server собран без udev ? Если да то xf86-input-evdev не нужен, иначе ставьте заново.

А секцию screen кто будет описывать ?
kostik87 ★★★★★ ( 17.10.12 16:44:32 )
Последнее исправление: kostik87 17.10.12 16:45:36 (всего исправлений: 1)

Я думал, для дела надо :)

При емерженьи списка вылезла вот такая штука:

А секцию screen кто будет описывать ?

Не поднимается xorg после перезапуска.

Читаем внимательно раздел с описанием конфигурации ядра для видеокарт intel.

Если у вас указанная опция собрана модулем то тоже должно всё работать.

Спасибо, внимательно прочитал, исправил ошибки (они там были), пересобрал и поставил ядро. Драйвер vesa вообще из ядра убрал от греха подальше, интел собрал не как модуль, а включил прям в ядро.

Теперь загрузка происходит все равно в 1024х786, однако в настройках КДЕ появилась возможность выбрать вожделенные 1280х1024.

xorg.conf на данный момент:

И еще забыл сказать, после перезагрузки 1024х768 возвращается на свое место, т.е. по умолчанию загружаюсь опять с таким разрешением.

Кто будет внимательно читать то, что написано в предложенной статье ?

экран начинает моргать, и показывать экран кусками, еще и реагируя на движения мишки

Сам как-то не догадался, а прямого указания на это в статье не увидел. Исправил свой xorg.conf, сделал так:

Сам не совсем понял, в чем проблема, однако случайно нашел решение - если после применения нового разрешения ввести комп с моргающим экраном в ждущий режим, то выйдет он из ждущего режима уже в приятном 1280х1024 и без моргания. После перезагрузки тоже все работает.

Спасибо всем, кто помогал, а kostik87 отдельное спасибо за терпеливые разъяснения! Теперь Xorg стал для меня гораздо более понятным зверем, нежели раньше :)

Ставлю solved, проблема решена.

kir64

Сам как-то не догадался, а прямого указания на это в статье не увидел.

Явно написано не было, но если внимательно читать, то всё понятно:

. Если это способ по каким-либо причинам не устраивает, можно вычислить нужную modeline и прописать ее. Узнать нужную modeline можно с помощью стандартной утилиты gtf или онлайн калькулятора. В любом случае результат должен быть таким:
Его и вписываем в в xorg.conf в раздел Monitor, чтобы получилось примерно так:

Читайте также: