X Strike Force XFree86 SVN commit: r1993 - in branches/ubuntu/debian: . local scripts
Author: fabbione
Date: 2004-10-30 00:47:08 -0500 (Sat, 30 Oct 2004)
New Revision: 1993
Modified:
branches/ubuntu/debian/changelog
branches/ubuntu/debian/local/FAQ.xhtml
branches/ubuntu/debian/scripts/locale-munger
branches/ubuntu/debian/xserver-xfree86.config.in
Log:
Import 4.3.0.dfsg.1-6ubuntu17 release.
Modified: branches/ubuntu/debian/changelog
===================================================================
--- branches/ubuntu/debian/changelog 2004-10-30 05:46:15 UTC (rev 1992)
+++ branches/ubuntu/debian/changelog 2004-10-30 05:47:08 UTC (rev 1993)
@@ -1,3 +1,12 @@
+xfree86 (4.3.0.dfsg.1-6ubuntu17) warty; urgency=low
+
+ * Fix framebuffer detection again. (Closes #1176)
+ * Import from Debian trunk:
+ + cosmetic fix to debian/scripts/locale-munger
+ + update FAQ.
+
+ -- Fabio M. Di Nitto <fabbione@fabbione.net> Tue, 14 Sep 2004 06:47:11 +0200
+
xfree86 (4.3.0.dfsg.1-6ubuntu16) warty; urgency=low
* Fix framebuffer detection. (Closes #1176)
Modified: branches/ubuntu/debian/local/FAQ.xhtml
===================================================================
--- branches/ubuntu/debian/local/FAQ.xhtml 2004-10-30 05:46:15 UTC (rev 1992)
+++ branches/ubuntu/debian/local/FAQ.xhtml 2004-10-30 05:47:08 UTC (rev 1993)
@@ -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
Modified: branches/ubuntu/debian/scripts/locale-munger
===================================================================
--- branches/ubuntu/debian/scripts/locale-munger 2004-10-30 05:46:15 UTC (rev 1992)
+++ branches/ubuntu/debian/scripts/locale-munger 2004-10-30 05:47:08 UTC (rev 1993)
@@ -1,6 +1,6 @@
#!/usr/bin/python
-# $Id: locale-munger 1731 2004-08-12 08:29:56Z branden $
+# $Id: locale-munger 1731M 2004-09-14 06:13:26Z (local) $
# This program compares X11 locale information from an unpacked source tree to
# what the installed version of the GNU C Library claims it supports. Some
@@ -221,7 +221,7 @@
print "ERROR: X11 does not support glibc locale %s" % (locale,)
else:
if RUNTIME_DEBUG:
- print "GOOD NEWS: X111 supports glibc locale %s" % (locale,)
+ print "GOOD NEWS: X11 supports glibc locale %s" % (locale,)
# Now see if locale values that include an explicit (but redundant) character
# set are supported by X11.
Modified: branches/ubuntu/debian/xserver-xfree86.config.in
===================================================================
--- branches/ubuntu/debian/xserver-xfree86.config.in 2004-10-30 05:46:15 UTC (rev 1992)
+++ branches/ubuntu/debian/xserver-xfree86.config.in 2004-10-30 05:47:08 UTC (rev 1993)
@@ -840,7 +840,7 @@
# use fbcon kernel functions?
case "$ARCH" in
- alpha|hurd-i386|i386)
+ alpha|hurd-i386|i386|amd64)
USE_FBDEV=false
;;
*)
@@ -859,6 +859,8 @@
USE_FBDEV=true
fi
fi
+else
+ USE_FBDEV=false
fi
db_get xserver-xfree86/config/device/use_fbdev || debug_report_status "db_get xserver-xfree86/config/device/use_fbdev"
Reply to: