Настройка видеокарты linux через xorg

KEYBOARD

The Xorg
server is normally configured to recognize various special
combinations of key presses that instruct the server to
perform some action, rather than just sending the key press
event to a client application. These actions depend on the
XKB keymap loaded by a particular keyboard device and may or
may not be available on a given configuration.

The following
key combinations are commonly part of the default XKEYBOARD
keymap.
Ctrl+Alt+Backspace

Immediately kills the server —
no questions asked. It can be disabled by setting the
DontZap xorg.conf(5) file option to a TRUE value.

It should be
noted that zapping is triggered by the
Terminate_Server action in the keyboard map. This
action is not part of the default keymaps but can be enabled
with the XKB option
«terminate:ctrl_alt_bksp».

Ctrl+Alt+Keypad-Plus

Change video mode to next one
specified in the configuration file. This can be disabled
with the DontZoom xorg.conf(5) file option.

Ctrl+Alt+Keypad-Minus

Change video mode to previous
one specified in the configuration file. This can be
disabled with the DontZoom xorg.conf(5) file
option.

Ctrl+Alt+F1…F12

For systems with virtual
terminal support, these keystroke combinations are used to
switch to virtual terminals 1 through 12, respectively. This
can be disabled with the DontVTSwitch xorg.conf(5)
file option.

VSYNC

There are several mechanisms involved in tear-free rendering due to limitations in X.

DDX driver options

EnablePageFlip — This option enables the use of pageflipping (switching the display controller’s base address pointer) rather than blits for GL buffer swaps. It only applies to fullscreen GL apps. Pageflipping is always synced to vblank at the moment.
SwapBuffersWait — This option prevents tearing for GL buffer swaps by waiting to update the front buffer until scanout has passed the area of the screen the GL buffer swap is going to blit to.
EXAVSync — This option prevents tearing for EXA operations by waiting to update the front buffer until scanout has passed the area of the screen the EXA operation is going to render to.

Xv Attribute

XV_VSYNC — This option prevents tearing when playing back videos using Xv by waiting to update the video image until scanout has passed the area of the screen displaying the video. It only prevents tearing if Xv is rendering directly to the front buffer. If you are using a compositer, this does not prevent tearing because Xv is rendering to an offscreen buffer and the compositor copied it to the front buffer.

Installation

Xorg can be installed with the package.

Additionally, some packages from the meta-package are necessary for certain configuration tasks, they are pointed out in the relevant sections. Other useful packages are in the group.

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

$ lspci | grep -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 ().
If that is not found, it searches for 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 ).

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:

Brand	Type	Driver	OpenGL	OpenGL (Multilib)	Documentation
AMD/ATI	Open source				AMDGPU
	ATI
Proprietary	AUR	AUR	AUR	AMD Catalyst
Intel	Open source				Intel graphics
Nvidia	Open source				Nouveau
Proprietary				NVIDIA

Note: For NVIDIA Optimus enabled laptop which uses an integrated video card combined with a dedicated GPU, see NVIDIA Optimus or Bumblebee.

Other video drivers can be found in the 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.

AMD

GPU architecture	Radeon cards	Open-source driver	Proprietary driver
GCN 4		AMDGPU
GCN 3		AMDGPU	Catalyst /
GCN 21		AMDGPU / ATI	Catalyst
GCN 11		AMDGPU / ATI	Catalyst
TeraScale 2&3	HD 5000 — HD 6000	ATI	Catalyst
TeraScale 1	HD 2000 — HD 4000	Catalyst legacy
Older	X1000 and older	not available

1: Experimental AMDGPU support

Configuration

Permissions

If the USE flag is enabled globally and ConsoleKit is being used (default for desktop profiles) permissions to video cards will be handled automatically. It is possible to check the permissions using getfacl:

user:larry:rw-

A broader solution is to add the user(s) needing access the video card to the video group:

Note that users will be able to run X without permission to the DRI subsystem, but acceleration will be disabled.

xorg.conf

The X server is designed to work out-of-the-box, with no need to manually edit Xorg’s configuration files. It should detect and configure devices such as displays, keyboards, and mice.

However, the main configuration file of the X server is the xorg.conf.

Использование

Unix и Linux

X.Org Server применяется в качестве реализации X Window System во многих UNIX-подобных операционных системах; для подавляющего большинства современных дистрибутивов Linux и BSD является основным поставляемым вариантом X-сервера.
В Solaris преобладает среди систем с x86-совместимой архитектурой, однако среди систем с архитектурой SPARC был более распространен проприетарный Xsun, поставка которого была прекращена в Oracle Solaris 11.

Microsoft Windows

Для Microsoft Windows существует несколько основанных на X.Org Server реализаций X-сервера, среди которых можно отметить Cygwin/X и Xming.

Apple Mac OS X

Начиная с версии 10.5 («Leopard»), Mac OS X поставляется с XQuartz — X-сервером на основе X.Org Server, позволяющим организовать бесшовный запуск приложений X11 в Aqua.

Authors

Xorg was originally
based on XFree86 4.4rc2. That was originally based on X386 1.2 by Thomas Roell,
which was contributed to the then X Consortium’s X11R5 distribution by SGCS.

Xorg is released by the X.org Foundation.

The project that became XFree86
was originally founded in 1992 by David Dawes, Glenn Lai, Jim Tsillas and
David Wexelblat.

XFree86 was later integrated in the then X Consortium’s
X11R6 release by a group of dedicated XFree86 developers, including the
following:

Xorg source is available from the FTP server <ftp://ftp.x.org/>, and from the
X.org server <http://www.freedesktop.org/cvs/
>. Documentation and other information
can be found from the X.org web site <http://www.x.org/
>.

Documentation

A presentation about R600 for very beginners
AMD R3xx 3D Register Reference
AMD R5xx Acceleration
AMD R6xx/R7xx 3D Register Reference
AMD R6xx/R7xx Acceleration
AMD Evergreen 3D Register Reference
AMD Cayman/Trinity 3D Register Reference
AMD Evergreen/Northern Islands Acceleration
AMD Southern Islands 3D Register Reference
AMD Sea Islands 3D Register Reference
AMD Southern Islands/Sea Islands Acceleration
AMD rv630
AMD rs690
AMD M56
AMD m76
AMD HDA audio verbs
AMD R6xx shader ISA
AMD R7xx shader ISA
AMD Evergreen shader ISA
AMD Cayman/Trinity shader ISA
AMD Southern Islands Series ISA
AMD Sea Islands Series ISA
AMD Volcanic Islands Series ISA
AMD «Vega» Series ISA
AMD «Vega» 7nm Series ISA
AMD «Navi» Series ISA

KMS Power Management Options

Kernel 2.6.35 or newer is required. The pm code supports three basic methods:

«dynpm»
«profile»
«dpm»

You can select the methods via sysfs. Echo «dynpm» or «profile» to /sys/class/drm/card0/device/power_method. «dpm» support, must be selected at boot (via radeon.dpm=1) and is only supported on R6xx and newer asics.

Controlling the fan speed directly is not possible (and would be very dangerous), but it can be lowered by setting lower power profile.

The «dynpm» method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn’t not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.

The «profile» method exposes five profiles that can be selected from:

«default»
«auto»
«low»
«mid»
«high»

Select the profile by echoing the selected profile to /sys/class/drm/card0/device/power_profile.

«default» uses the default clocks and does not change the power state. This is the default behavior.
«auto» selects between «mid» and «high» power states based on the whether the system is on battery power or not. The «low» power state are selected when the monitors are in the dpms off state.
«low» forces the gpu to be in the low power state all the time. Note that «low» can cause display problems on some laptops; this is why auto does not use «low» when displays are active.
«mid» forces the gpu to be in the «mid» power state all the time. The «low» power state is selected when the monitors are in the dpms off state.
«high» forces the gpu to be in the «high» power state all the time. The «low» power state is selected when the monitors are in the dpms off state.
The «profile» method is not as agressive as «dynpm,» but is currently much more stable and flicker free and works with multiple heads active.

The «dpm» method uses hardware on the GPU to dynamically change the clocks and voltage based on GPU load. It also enables clock and power gating.

Power management is supported on all asics (r1xx-evergreen) that include the appropriate power state tables in the vbios; not all boards do (especially older desktop cards). «dpm» is only supported on R6xx and newer asics.

Thermal sensors are implemented via external i2c chips or via the internal thermal sensor (rv6xx-evergreen only; supported in 2.6.36 or newer); not all OEMs implement a thermal sensor. To get the temperature on asics that use i2c chips, you need to load the appropriate hwmon driver for the sensor used on your board (lm63, lm64, etc.). The drm will attempt to load the appropriate hwmon driver. On boards that use the internal thermal sensor, the drm will set up the hwmon interface automatically. When the appropriate driver is loaded, the temperatures can be accessed via lm_sensors tools or via sysfs in /sys/class/hwmon.

ENVIRONMENT VARIABLES

For operating
systems that support local connections other than Unix
Domain sockets (SVR3 and SVR4), there is a compiled-in list
specifying the order in which local connections should be
attempted. This list can be overridden by the XLOCAL
environment variable described below. If the display name
indicates a best-choice connection should be made (e.g.
:0.0), each connection mechanism is tried until a
connection succeeds or no more mechanisms are available.
Note: for these OSs, the Unix Domain socket connection is
treated differently from the other local connection types.
To use it the connection must be made to
unix:0.0.

The
XLOCAL environment variable should contain a list of
one more more of the following:

NAMED
PTS
SCO
ISC

which represent
SVR4 Named Streams pipe, Old-style USL Streams pipe, SCO
XSight Streams pipe, and ISC Streams pipe, respectively. You
can select a single mechanism (e.g. XLOCAL=NAMED), or
an ordered list (e.g.
XLOCAL=»NAMED:PTS:SCO»). his variable
overrides the compiled-in defaults. For SVR4 it is
recommended that NAMED be the first preference
connection. The default setting is
PTS:NAMED:ISC:SCO.

To globally
override the compiled-in defaults, you should define (and
export if using sh or ksh) XLOCAL
globally. If you use startx(1) or xinit(1), the definition
should be at the top of your .xinitrc file. If you
use xdm(1), the definitions should be early on in the
/usr/lib/X11/xdm/Xsession
script.

Configuration

Xorgxorg.confxorg.conf(5x)

Starting with version 4.4, Xorg has a mechanism for automatically
generating a built-in configuration at run-time when no xorg.conf file is
present. The current version of this automatic configuration mechanism
works in three ways.

The first is via enhancements that have made many components
of the xorg.conf file optional. This means that information that can be
probed or reasonably deduced doesn’t need to be specified explicitly, greatly
reducing the amount of built-in configuration information that needs to
be generated at run-time.

The second is to use an external utility called
getconfig(1)
, when available, to use meta-configuration information to generate
a suitable configuration for the primary video device. The meta-configuration
information can be updated to allow an existing installation to get the
best out of new hardware or to work around bugs that are found post-release.

The third is to have «safe» fallbacks for most configuration information.
This maximises the likelihood that the Xorg server will start up in some
usable configuration even when information about the specific hardware
is not available.

The automatic configuration support for Xorg is work in
progress. It is currently aimed at the most popular hardware and software
platforms supported by Xorg. Enhancements are planned for future releases.

Working with git submodules

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit. This section assumes you are comfortable with the similar tasks when performed without git submodules. You might be interested in the Kernel Git Submodule Tutorial.

Cloning a module with submodules

After cloning the module, the git submodule command will clone and initialize the submodules specified in the .gitmodules file. In this example, the submodule path is m4. Git keeps track of which submodule commit to checkout. Later versions of the git clone command have a —recursive option.

git clone git://anongit.freedesktop.org/xcb/util
git submodule update --init

Updating a module

It may be that only the module has changed since the last update, or that both the module and the submodule have changed.

git pull --rebase
git submodule update

It may be that only the submodule has changed and that these changes should be picked-up by the module.

cd m4
git pull origin master
git status
cd ..
git commit -a -s

Rolling back a module

It may happen you need to revert the state of a module and a submodule to a previous point in time. The module should then point to the matching commit of the submodule. The commit numbers are valid, you can run the commands.

git reset --hard 02289ca
git submodule update

You should see this output:

HEAD is now at 02289ca Bump version to 0.3.8
Submodule path 'm4': checked out '55e8069773efd794a91d5fb37bfceeebae2e378a'

The log http://cgit.freedesktop.org/xcb/util/log/m4 will show the commit history for the submodule.

Hooking up a submodule to a module

A submodule has a git repository like any other module. It is only different in the way it gets used. Several modules can include the submodule containing reusable code.

git submodule add git://anongit.freedesktop.org/xcb/util-common-m4 m4
git submodule update --init

You should see this output from git status:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   .gitmodules
#       new file:   m4
#

Detaching a submodule from a module

There is no git submodule remove command. Given our example where the submodule path is m4,

git config --remove-section submodule.m4
git config --file .gitmodules --remove-section submodule.m4
git rm --cached m4
rm -fr m4

Create a commit for the changes incurred by the module and you are done. Note that the submodule still exists at fdo.org, you have only detached and deleted your module copy.

Applying changes to a submodule

Working from within a submodule

To directly modify sources referenced by a submodule, just change to the directory of the submodule and work with it like with a normal repository. Note however, that the state of a submodule is controlled by the supermodule and that under certain conditions it might even be possible to lose unpublished work. For more, see the Gotchas section of the .

Using a local clone of a submodule

It is also possible to separately clone the repository and redirect the upstream URL of the submodule to the local version. For example, the configuration of a submodule m4 in could look like:

        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git://anongit.freedesktop.org/xcb/util-common-m4.git

Simply set the value of to the path of the local repository.

        fetch = +refs/heads/*:refs/remotes/origin/*
        url = /path/to/util-common-m4.git

Note, that we are changing the configuration of the submodule at and not the configuration of the supermodule at .

To use a different location from the start, it is also possible to change the submodule configuration in the supermodule before updating the submodule for the first time. The file specifies the official location of the submodule and changes to it are being tracked. But that file does not need to be changed for our purpose. The following command copies the contents of to the configuration of the supermodule at :

git submodule init

The submodule has not been checked out yet, and so it is possible to select a different location. For example, the configuration in could look like:

        url = git://anongit.freedesktop.org/xcb/util-common-m4.git

Insert the preferred location like above and then update the submodule with:

git submodule update

A git submodule is created just like any other git module. The reasons for using a module as a submodule is beyond the scope of this section. In the XCB example, the goal was code reuse.