X Strike Force XFree86 SVN commit: r1812 - in trunk/debian: . local
Author: branden
Date: 2004-09-13 14:10:51 -0500 (Mon, 13 Sep 2004)
New Revision: 1812
Modified:
trunk/debian/CHANGESETS
trunk/debian/local/FAQ.xhtml
Log:
(cosmetic) Add missing markup.
Modified: trunk/debian/CHANGESETS
===================================================================
--- trunk/debian/CHANGESETS 2004-09-13 18:58:32 UTC (rev 1811)
+++ trunk/debian/CHANGESETS 2004-09-13 19:10:51 UTC (rev 1812)
@@ -9,7 +9,7 @@
files anywhere.)
Miscellaneous cosmetic fixes.
- 1811
+ 1811, 1812
Update Danish debconf template translations (thanks, Claus Hindsgaul)
1806
Modified: trunk/debian/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2004-09-13 18:58:32 UTC (rev 1811)
+++ trunk/debian/local/FAQ.xhtml 2004-09-13 19:10:51 UTC (rev 1812)
@@ -1073,18 +1073,22 @@
a getty on VC 7.</p>
<p>If you have increased your number of virtual consoles, or otherwise require VC
-7 for some purpose, simply edit /etc/X11/xdm/Xservers and change the "vt7"
-argument on the ":0" server line to whatever VC is appropriate for your
-machine (vt8, vt12, etc.). Note that while the XFree86 manual page says that
-if the "vt" argument is not specified, the X server will use the first
-available virtual console, it is not a good idea to omit this parameter when
-starting local X servers with xdm. This is because even though xdm starts at
-the very end of the init sequence, well after the getty processes that manage
-the virtual consoles, some machines get through the init sequence so quickly
-that getty has not yet claimed its VC's before xdm starts. This leads to
-exactly the same kind of console lockup you get as if you deliberately tell
-getty (via /etc/inittab) and xdm (via /etc/X11/xdm/Xservers) to use the same
-virtual console for their respective tasks.</p>
+7 for some purpose, simply edit <code
+class="filespec">/etc/X11/xdm/Xservers</code> and change the "vt7" argument on
+the ":0" server line to whatever VC is appropriate for your machine (vt8, vt12,
+etc.). Note that while the XFree86 manual page says that if the "vt" argument
+is not specified, the X server will use the first available virtual console, it
+is not a good idea to omit this parameter when starting local X servers with
+xdm. This is because even though <code class="command">xdm</code> starts at the
+very end of the <code class="command">init</code> sequence, well after the <code
+class="command">getty</code> processes that manage the virtual consoles, some
+machines get through the init sequence so quickly that getty has not yet claimed
+its VC's before <code class="command">xdm</code> starts. This leads to exactly
+the same kind of console lockup you get as if you deliberately tell <code
+class="command">getty</code> (via <code class="filespec">/etc/inittab</code>)
+and <code class="command">xdm</code> (via <code
+class="filespec">/etc/X11/xdm/Xservers</code>) to use the same virtual console
+for their respective tasks.</p>
<h3><a id="xclientasroot">How do I run an X client as root when the X session
is run by a user?</a></h3>
@@ -1371,22 +1375,23 @@
internally.</li>
<li>Whatever is running in the <code class="command">xterm</code> (like the
shell) can be getting bogus information from the terminfo file for the
- terminal type that xterm is using. If your <var>TERM</var> environment
- variable is not set to <code class="other">xterm</code>, make sure you
- understand why.</li>
+ terminal type that <code class="command">xterm</code> is using. If your
+ <var>TERM</var> environment variable is not set to <code
+ class="other">xterm</code>, make sure you understand why.</li>
<li>If you still haven't found satisfaction, you may have run up against the
stone wall that is inherent in emulation.</li>
</ul>
-<p>For some keys, due to frustrating historical practice, there is simply
-going to be incompatibility with the Linux console. Why? Because xterm
-was initially written to emulate a DEC VT100 terminal. PC keyboards have many
-more keys than a VT100. The PC keyboard resembles a VT220 keyboard much
-more closely. That's why Linus Torvalds based the kernel console driver on
-VT220 emulation. If you want xterm to behave more like the Linux console,
-use the terminal type <code class="other">xterm-vt220</code>. What keys are
-affected by this historical incompatibility, and how do DEC VT220 and PC
-keyboards differ? A lengthy explanation follows.</p>
+<p>For some keys, due to frustrating historical practice, there is simply going
+to be incompatibility with the Linux console. Why? Because <code
+class="command">xterm</code> was initially written to emulate a DEC VT100
+terminal. PC keyboards have many more keys than a VT100. The PC keyboard
+resembles a VT220 keyboard much more closely. That's why Linus Torvalds based
+the kernel console driver on VT220 emulation. If you want <code
+class="command">xterm</code> to behave more like the Linux console, use the
+terminal type <code class="other">xterm-vt220</code>. What keys are affected by
+this historical incompatibility, and how do DEC VT220 and PC keyboards differ?
+A lengthy explanation follows.</p>
<h4>Backspace</h4>
@@ -1414,11 +1419,12 @@
(engraved with "Delete" on VT terminals, Macintoshes, and some other keyboards)
generating ASCII 8 (or control-H) instead of ASCII 127 (or control-?), in
flagrant incompatibility with every DEC VT terminal ever made, one model of
-which (the VT100) xterm was expressly written to emulate from its very inception
-in 1984. The good news is, Thomas Dickey, the upstream xterm maintainer, took
-steps to move everybody back to the Good Side of the Force in XFree86 4.0.
-Debian's Keyboard Policy anticipated that move. So, if people do things
-correctly, there is no incompatibility between the Linux console and <code
+which (the VT100) <code class="command">xterm</code> was expressly written to
+emulate from its very inception in 1984. The good news is, Thomas Dickey, the
+upstream <code class="command">xterm</code> maintainer, took steps to move
+everybody back to the Good Side of the Force in XFree86 4.0. Debian's Keyboard
+Policy anticipated that move. So, if people do things correctly, there is no
+incompatibility between the Linux console and <code
class="command">xterm</code>. (Indeed, in the years since this FAQ entry was
written, the number of complaints about this issue has declined almost to
zero.)</p>
@@ -1499,7 +1505,7 @@
instead.)</p>
<p><code class="other">XTerm.termName</code> is the resource that controls what
-terminal type xterm reports itself as.</p>
+terminal type <code class="command">xterm</code> reports itself as.</p>
<p><code class="other">XTerm.VT100.Translations</code> is the resource that
controls key bindings. Translation table syntax is not the simplest thing in
@@ -2319,8 +2325,9 @@
<p>It is expected that the XFree86 3.x Debian packages will be updated to work as
above but as of this writing they retain the previous behavior, which attempts
-to use debconf markers to ascertain whether the /etc/X11/XF86Config file has
-been customized by the user.</p>
+to use debconf markers to ascertain whether the <code
+class="filespec">/etc/X11/XF86Config</code> file has been customized by the
+user.</p>
<p>People writing installers for the Debian OS should note that
pre-configuration of the XFree86 X server is now as simple as creating an <code
Reply to: