source: x/installing/xorg-config.xml@ df5c5e0

10.1 11.0 ken/refactor-virt lazarus qt5new trunk upgradedb xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since df5c5e0 was df5c5e0, checked in by Xi Ruoyao <xry111@…>, 11 months ago

xorg testing: add sysrq as a precaution if Xorg hangs

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@24254 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 13.7 KB
Line 
1<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
2 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
3 <!ENTITY % general-entities SYSTEM "../../general.ent">
4 %general-entities;
5]>
6
7<sect1 id="xorg-config">
8 <?dbhtml filename="xorg-config.html"?>
9
10 <sect1info>
11 <othername>$LastChangedBy$</othername>
12 <date>$Date$</date>
13 </sect1info>
14
15 <title>Xorg-&xorg-version; Testing and Configuration</title>
16
17 <indexterm zone="xorg-config">
18 <primary sortas="g-configuring-xorg">Configuring Xorg</primary>
19 </indexterm>
20
21 <sect2 id='X11-testing' xreflabel="Testing Xorg">
22 <title>Testing Xorg</title>
23
24 <note>
25 <para>
26 Before starting Xorg for the first time, is is useful to
27 rebuild the library cache by running <userinput>ldconfig</userinput>
28 as the <systemitem class="username">root</systemitem> user.
29 </para>
30 </note>
31
32 <note>
33 <para>
34 Before starting Xorg for the first time, is is often needed to
35 reboot the system to ensure all appropriate daemons are started
36 and approprite security issues are properly set.
37 As an alternative, logging out and logging back in may work, but as
38 of this writing has not been tested.
39 </para>
40 </note>
41
42 <warning>
43 <para>
44 If Xorg hangs for some reason (for example, lacking a proper
45 input driver), the system may stop responsing to any user input.
46 As a precaution, you can enable a magic <keycap>SysRq</keycap> key
47 before testing Xorg. As the
48 <systemitem class="username">root</systemitem> user, issue:
49 </para>
50
51<screen><userinput>echo 4 > /proc/sys/kernel/sysrq</userinput></screen>
52
53 <para>
54 Then if Xorg hangs, it's possible to use
55 <keycombo>
56 <keycap>Alt</keycap>
57 <keycap>SysRq</keycap>
58 <keycap>R</keycap>
59 </keycombo>
60 to reset the keyboard mode. Now it should be able to use
61 <keycombo>
62 <keycap>Ctrl</keycap>
63 <keycap>Alt</keycap>
64 <keycap>Fx</keycap>
65 </keycombo>
66 (replace x with a VT number) to switch to another VT.
67 If it works, login and kill Xorg using command line in the new VT.
68 </para>
69 </warning>
70
71 <para>
72 To test the <application>Xorg</application> installation, issue
73 <command>startx</command>. This command brings up a rudimentary window
74 manager called <emphasis>twm</emphasis> with three xterm windows and one
75 xclock window. The xterm window in the upper left is a login terminal and
76 running <emphasis>exit</emphasis> from this terminal will exit the
77 <application>X Window</application> session. The third xterm window may
78 be obscured on your system by the other two xterms.
79 </para>
80
81 <note>
82 <para>
83 When testing <application>Xorg</application> with the
84 <application>twm</application> window manager, there will be several
85 warnings in the Xorg log file, <!--<filename revision="sysv">
86 /var/log/Xorg.0.log</filename><filename revision="systemd">-->
87 $HOME/.local/share/xorg/Xorg.0.log<!--</filename>-->, about missing font
88 files. In addition, there will be several warnings on the text mode
89 terminal (usually tty1) about missing fonts. These warnings do not
90 affect functionality, but can be removed if desired by installing
91 the <xref linkend="xorg7-legacy"/>.
92 </para>
93 </note>
94
95 <para>
96 Generally, there is no specific configuration required for
97 <application>Xorg</application>, but customization is possible. For
98 details, see <xref linkend='xconfig'/> below.
99 </para>
100
101 </sect2>
102
103 <sect2 role="configuration" id="checking-dri" xreflabel="Checking the DRI
104 installation">
105 <title>Checking the Direct Rendering Infrastructure (DRI)
106 Installation</title>
107
108 <para>
109 DRI is a framework for allowing software to access graphics hardware in
110 a safe and efficient manner. It is installed in
111 <application>X</application> by default (using
112 <application>Mesa</application>) if you have a supported video card.
113 </para>
114
115 <para>
116 To check if DRI drivers are installed properly, check the log file
117 <filename>$HOME/.local/share/xorg/Xorg.0.log</filename> (or
118 <filename>/var/log/Xorg.0.log</filename> if you have
119 built <xref linkend="xorg-server"/> with the suid bit) for
120 statements such as:
121 </para>
122
123<screen><literal>(II) intel(0): direct rendering: DRI2 Enabled</literal></screen>
124
125 <para>or</para>
126
127<screen><literal>(II) NOUVEAU(0): Loaded DRI module</literal></screen>
128
129 <note>
130 <para>
131 DRI configuration may differ if you are using alternate drivers, such
132 as those from
133 <ulink url="http://www.nvidia.com/page/home.html">NVIDIA</ulink> or
134 <ulink url="http://www.amd.com/">AMD</ulink>.
135 </para>
136 </note>
137
138<!-- With elogind, this is not needed anymore
139 <para>
140 Although all users can use software acceleration, any hardware
141 acceleration (DRI2) is only available to <systemitem
142 class="username">root</systemitem> and members of the <systemitem
143 class="groupname">video</systemitem> group, but
144 <phrase revision="sysv"><emphasis>ConsoleKit2</emphasis></phrase>
145 <phrase revision="systemd"><emphasis>systemd-logind</emphasis></phrase>
146 takes care of adding any logged in user to the user ACL's of
147 <filename>/dev/dri/card*</filename>, the special file(s) allowing access
148 to hardware acceleration.<phrase revision="systemd"> So, no further
149 configuration is needed.</phrase>
150 </para>
151
152 <para revision="sysv">
153 If your driver is supported and <emphasis>ConsoleKit2</emphasis> is not
154 installed, add any users that might use X to the <systemitem
155 class="groupname">video</systemitem> group:
156 </para>
157
158<screen role="root" revision="sysv"><userinput>usermod -a -G video <replaceable>&lt;username&gt;</replaceable></userinput></screen>
159-->
160 <para>
161 Another way to determine if DRI is working properly is to use one of the
162 two optionally installed OpenGL demo programs in <xref
163 linkend="mesa"/>. From an X terminal, run <command>glxinfo</command>
164 and look for the phrase:
165 </para>
166
167<screen><computeroutput>name of display: :0
168display: :0 screen: 0
169direct rendering: Yes</computeroutput></screen>
170
171 <para>
172 If direct rendering is enabled, you can add verbosity by running
173 <command>LIBGL_DEBUG=verbose glxinfo</command>. This will show the
174 drivers, device nodes and files used by the DRI system.
175 </para>
176
177 <para>
178 To confirm that DRI2 hardware acceleration is working, you can (still in
179 the X terminal) run the command <command>glxinfo | egrep "(OpenGL
180 vendor|OpenGL renderer|OpenGL version)"</command>.
181 If that reports something <emphasis>other than</emphasis>
182 <literal>Software Rasterizer</literal> then you have working
183 acceleration for the user who ran the command.
184 </para>
185
186 <para>
187 If your hardware does not have any DRI2 driver available, it will use a
188 Software Rasterizer for Direct Rendering. In such cases, you can use a
189 new, LLVM-accelerated, Software Rasterizer called LLVMPipe. In order to
190 build LLVMPipe just make sure that <xref linkend="llvm"/> is present at
191 Mesa build time. Note that all decoding is done on the CPU instead of
192 the GPU, so the display will run slower than with hardware acceleration.
193 To check if you are using LLVMpipe, review the output of the glxinfo
194 command above. An example of the output using the Software Rasterizer
195 is shown below:
196 </para>
197
198<screen><computeroutput>OpenGL vendor string: VMware, Inc.
199OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
200OpenGL version string: 3.0 Mesa 10.4.5</computeroutput></screen>
201
202 <para>
203 You can also force LLVMPipe by exporting the
204 <envar>LIBGL_ALWAYS_SOFTWARE=1</envar> environment variable when
205 starting Xorg.
206 </para>
207
208 <para>
209 Again, if you have built the Mesa OpenGL demos, you can also run the test
210 program <command>glxgears</command>. This program brings up a window with
211 three gears turning. The X terminal will display how many frames were
212 drawn every five seconds, so this will give a rough benchmark. The window
213 is scalable, and the frames drawn per second is highly dependent on the
214 size of the window. On some hardware, <command>glxgears</command> will
215 run synchronized with the vertical refresh signal and the frame rate will
216 be approximately the same as the monitor refresh rate.
217 </para>
218
219 </sect2>
220
221 <sect2 role="configuration" id="hybrid-graphics" xreflabel="Hybrid Graphics">
222 <title>Hybrid Graphics</title>
223
224 <para>
225 Hybrid Graphics is still in experimental state for Linux. Xorg Developers
226 have developed a technology called PRIME that can be used for switching
227 between integrated and muxless discrete GPU at will. Automatic switching
228 is not possible at the moment.
229 </para>
230
231 <para>
232 In order to use PRIME for GPU switching, make sure that you are using
233 Linux Kernel 3.4 or later (recommended). You will need latest DRI and
234 DDX drivers for your hardware and <application>Xorg Server</application>
235 1.13 or later.
236 </para>
237
238 <para>
239 <application>Xorg Server</application> should load both GPU drivers
240 automaticaly. You can check that by running:
241 </para>
242
243<screen><userinput>xrandr --listproviders</userinput></screen>
244
245 <para>
246 There should be two (or more) providers listed, for example:
247 </para>
248
249<screen><computeroutput>Providers: number : 2
250Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel
251Provider 1: id: 0x56 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 1 associated providers: 1 name:radeon</computeroutput></screen>
252
253 <para>
254 In order to be able to run a GLX application on a discrete GPU, you will
255 need to run the following command, where &lt;provider&gt; is the more
256 powerful discrete card, and &lt;sink&gt; is the card which has a display
257 connected:
258 </para>
259
260<screen><userinput>xrandr --setprovideroffloadsink <replaceable>&lt;provider&gt; &lt;sink&gt;</replaceable></userinput></screen>
261
262 <note>
263 <para>
264 With newer <application>Xorg</application> drivers, such as modesetting
265 or intel, which are DRI3 capable, the above command is no longer
266 necessary. It does no harm however.
267 </para>
268 </note>
269
270 <para>
271 Then, you will need to export the <envar>DRI_PRIME=1</envar> environment
272 variable each time you want the powerful GPU to be used. For example,
273
274<screen><userinput>DRI_PRIME=1 glxinfo | egrep "(OpenGL vendor|OpenGL renderer|OpenGL version)"</userinput></screen>
275
276 will show OpenGL vendor, renderer and version for the discrete GPU.
277 </para>
278
279 <para>
280 If the last command reports same OpenGL renderer with and without
281 <envar>DRI_PRIME=1</envar>, you will need to check your installation.
282 </para>
283
284 </sect2>
285
286 <sect2 role="configuration" id='xconfig'>
287 <title>Setting up Xorg Devices</title>
288
289 <para>
290 For most hardware configurations, modern Xorg will automatically
291 get the server configuration correct without any user intervention. There
292 are, however, some cases where auto-configuration will be incorrect.
293 Following are some example manual configuration items that may be of use
294 in these instances.
295 </para>
296
297 <sect3 id="xinput">
298 <title>Setting up X Input Devices</title>
299 <para>
300 For most input devices, no additional configuration will be
301 necessary. This section is provided for informational purposes only.
302 </para>
303
304 <para>
305 A sample default XKB setup could look like the following (executed as
306 the <systemitem class="username">root</systemitem> user):
307 </para>
308
309<screen role="root"><userinput>cat &gt; /etc/X11/xorg.conf.d/xkb-defaults.conf &lt;&lt; "EOF"
310<literal>Section "InputClass"
311 Identifier "XKB Defaults"
312 MatchIsKeyboard "yes"
313 Option "XkbLayout" "fr"
314 Option "XkbOptions" "terminate:ctrl_alt_bksp"
315EndSection</literal>
316EOF</userinput></screen>
317
318 <para>
319 The <quote>XkbLayout</quote> line is an example for a French (AZERTY)
320 keyboard. Change it to your keyboard model. That line is not needed for
321 a QWERTY (US) keyboard.
322 </para>
323 </sect3>
324
325 <sect3 id="xdisplay">
326 <title>Fine Tuning Display Settings</title>
327
328 <para>
329 Again, with modern Xorg, little or no additional configuration is
330 necessary. If you should need extra options passed to your video driver,
331 for instance, you could use something like the following (again,
332 executed as the <systemitem class="username">root</systemitem> user):
333 </para>
334
335<screen role="root"><userinput>cat &gt; /etc/X11/xorg.conf.d/videocard-0.conf &lt;&lt; "EOF"
336<literal>Section "Device"
337 Identifier "Videocard0"
338 Driver "radeon"
339 VendorName "Videocard vendor"
340 BoardName "ATI Radeon 7500"
341 Option "NoAccel" "true"
342EndSection</literal>
343EOF</userinput></screen>
344
345 <para>
346 Another common setup is having multiple server layouts for use in
347 different environments. Though the server will automatically detect the
348 presence of another monitor, it may get the order incorrect:
349 </para>
350
351<screen role="root"><userinput>cat &gt; /etc/X11/xorg.conf.d/server-layout.conf &lt;&lt; "EOF"
352<literal>Section "ServerLayout"
353 Identifier "DefaultLayout"
354 Screen 0 "Screen0" 0 0
355 Screen 1 "Screen1" LeftOf "Screen0"
356 Option "Xinerama"
357EndSection</literal>
358EOF</userinput></screen>
359
360 </sect3>
361 </sect2>
362</sect1>
Note: See TracBrowser for help on using the repository browser.