X Strike Force X.Org X11 SVN commit: r114 - in trunk/debian: . local
Author: dnusinow
Date: 2005-05-16 22:38:54 -0500 (Mon, 16 May 2005)
New Revision: 114
Modified:
trunk/debian/changelog
trunk/debian/local/FAQ.xhtml
Log:
Merge changes from xfree tree to local/FAQ.xhtml
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2005-05-17 03:37:32 UTC (rev 113)
+++ trunk/debian/changelog 2005-05-17 03:38:54 UTC (rev 114)
@@ -24,6 +24,7 @@
- Merge changes from xfree tree to local directory:
- dexconf
- dexconf.1
+ - FAQ.xhtml
- Re-add jisx0208.1983-0.enc.gz to MANIFEST.all's list of font encodings
until I know more about why it was removed.
Modified: trunk/debian/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2005-05-17 03:37:32 UTC (rev 113)
+++ trunk/debian/local/FAQ.xhtml 2005-05-17 03:38:54 UTC (rev 114)
@@ -18,6 +18,7 @@
div.center {text-align: center}
div.left {text-align: left}
p.x-small {font-size: x-small}
+ p.footnote {font-size: x-small}
span.line-through {text-decoration: line-through}
kbd {background: lightgrey}
code.command {color: rgb(96,96,0)}
@@ -155,8 +156,8 @@
my X session exiting abnormally?</a></li>
<li><a href="#radeondualhead">I'm having trouble getting dual-head support to
work on my ATI Radeon card. Can you help?</a></li>
-<li><a href="#xkbnewlayout">My keyboard configuration worked with previous versions of XFree86;
- why is it messed up now? For example, my Windows keys
+<li><a href="#xkbnewlayout">My keyboard configuration worked with previous
+ versions of XFree86; why is it messed up now? For example, my Windows keys
don't work right in Emacs or my window manager anymore.</a></li>
<li><a href="#composeinput">Why does composing characters work in some
applications but not others?</a></li>
@@ -175,7 +176,7 @@
<h2><a id="copyright">Copyright and License</a></h2>
-<p>Copyright © 1998–2004 <a href= "mailto:branden@debian.org";>Branden
+<p>Copyright © 1998–2005 <a href= "mailto:branden@debian.org";>Branden
Robinson</a>.</p>
<p>This is free documentation; you may redistribute it and/or modify it under
@@ -277,12 +278,12 @@
find this FAQ at <a
href="file:///usr/share/doc/xfree86-common/FAQ.xhtml">file:///usr/share/doc/xfree86-common/FAQ.xhtml</a>.</p>
-<p>A copy of this FAQ is also maintained on the Web; you can generally find the
-most up-to-date version at <a
-href="http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml";>http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml</a>.
-(If you're curious, this is from a nightly snapshot of the <a
-href="http://subversion.tigris.org";>Subversion</a> repository where the Debian
-<code class="package">xfree86</code> source package is maintained.)</p>
+<p>The <a
+href="http://necrotic.deadbeast.net/svn/xfree86/trunk/debian/local/FAQ.xhtml";>most
+up-to-date copy of this FAQ</a> is maintained in the <a
+href="http://subversion.tigris.org";>Subversion</a> <a
+href="http://necrotic.deadbeast.net/svn/xfree86/";>repository</a> where the
+Debian <code class="package">xfree86</code> source package is maintained.</p>
<p>The following table summarizes the semantic usage of visual markup in this
document:</p>
@@ -607,16 +608,15 @@
Contract</a>).</p>
<p>Despite the outcry regarding the XFree86 project's decision (which reminded
-some of X.Org's own ill-fated change to its SI's license terms in 1998), it went
-ahead and <a
+some of X.Org's own ill-fated change to its SI's license terms in 1998), the
+XFree86 Project went ahead and <a
href="http://www.mail-archive.com/cvs-commit@xfree86.org/msg03271.html";>applied
the new license to the code in its CVS repository</a> on 13 Feburary 2004. Many
OS distributors, including Debian, elected not to distribute any version of the
XFree86 codebase using the new license. Consequently, those distributors sought
alternatives. As of this writing (March 2005), most of the community appears
-to have settled around the <code>freedesktop.org</code>/X.Org "monolithic"
-release series, the most recent of which is <a
-href="http://www.x.org/X11R6.8.1/";>X11R6.8.1</a>.</p>
+to have settled around the "monolithic" X.Org X11 release series
+release series hosted at <code>freedesktop.org</code>.</p>
<h3><a id="debianplans">What are Debian's plans with respect to X.Org and
XFree86?</a></h3>
@@ -659,13 +659,12 @@
Inc., as an upstream source of code does not mean that we will abandon our
commitment to the users of our production release.</p>
-<p>Futhermore, there was near-consensus that Debian should switch to the <a
-href="http://freedesktop.org/Software/xorg";>X.Org source tree</a>, with the goal
-of migrating to the modularized tree over time. We expect that the monolithic
-X.Org distribution will be modularized in a piecewise fashion; as that happens,
-we will "switch off" the building of packages from the X.Org monolithic tree in
-favor of the modularized components that become available from <code
-class="other">freedesktop.org</code>.</p>
+<p>Futhermore, there was near-consensus that Debian should switch to the X.Org
+source tree, with the goal of migrating to the modularized tree over time. We
+expect that the monolithic X.Org distribution will be modularized in a piecewise
+fashion; as that happens, we will "switch off" the building of packages from the
+X.Org monolithic tree in favor of the modularized components that become
+available from <code class="other">freedesktop.org</code>.</p>
<p>While moving from XFree86's monolithic tree to X.Org's is a relatively simple
technical transition of itself, the transition to a fully-modularized set of
@@ -687,10 +686,10 @@
maintain similar packaging standards, simplify the bug handling on shared
components (like X libraries) and discuss future changes and improvements.</p>
-<p>As of this writing (March 2005), packaging of the X.Org distribution is
-underway in the X Strike Force's <code class="other">xorg</code> Subversion
-repository (<a
-href="http://necrotic.deadbeast.net/cgi-bin/viewcvs.cgi/?root=xorg";>ViewCVS</a>).</p>
+<p>As of this writing (March 2005), packaging of the X.Org X11 distribution is
+underway in the X Strike Force's <a
+href="http://necrotic.deadbeast.net/svn/xorg-x11";><code
+class="other">xorg-x11</code> Subversion repository</a>.</p>
<h3><a id="defxservclient">What are X servers and X clients?</a></h3>
@@ -857,9 +856,10 @@
found in <code class="filespec">/etc/X11/app-defaults</code> (or a localized
subdirectory of <code class="filespec">/etc/X11</code>).</p>
-<p>App-defaults are specified using a class/instance syntax and look very similar
-to X resource files (see next question), but there are three very important
-differences between app-defaults and X resources:</p>
+<p>App-defaults are specified using a class/instance syntax and look very
+similar to X resource files (<a href="#defresourc">see the previous
+question</a>), but there are three very important differences between
+app-defaults and X resources:</p>
<ol>
<li>A client's app-defaults are generally essential for its useful operation,
@@ -1102,9 +1102,8 @@
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0094";>CAN-2004-0094</a>,
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0106";>CAN-2004-0106</a>,
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687";>CAN-2004-0687</a>,
-<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688";>CAN-2004-0688</a>,
and
-<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914";>CAN-2004-0914</a>
+<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688";>CAN-2004-0688</a>
(as indexed by the <a href="http://cve.mitre.org/cve/";>MITRE CVE project</a>),
among other flaws.</p>
@@ -1115,7 +1114,8 @@
<code>xserver-mach8</code>, <code>xserver-mono</code>,
<code>xserver-p9000</code>, <code>xserver-s3</code>, <code>xserver-s3v</code>,
<code>xserver-svga</code>, <code>xserver-tga</code>, <code>xserver-vga16</code>,
-and <code>xserver-w32</code>.</p>
+<code>xserver-w32</code>, <code>xserver-xsun</code>,
+<code>xserver-xsun24</code>, and <code>xserver-xsunmono</code>.</p>
<p>If XFree86 3.<em>x</em> works on your hardware, but XFree86 4.<em>x</em> and
the X.Org X server do not, the Debian Project could use your help in getting the
@@ -1186,8 +1186,8 @@
<h3><a id="changecoldepth">How do I change the color depth of my X
server?</a></h3>
-<p>There are two answers to this question; one for version 3.x XFree86 X servers,
-and one for version 4.x of the XFree86 X server.</p>
+<p>There are two answers to this question; one for version 3.x XFree86 X
+servers, and one for version 4.x of the XFree86 X server.</p>
<p>You can find out which version you are using by running "X -version" (you do
not need to be root to execute this command).</p>
@@ -1370,13 +1370,13 @@
X Window System, use the <code class="command">gpm</code>-based approach,
described below.</p>
-<p>The <code class="command">gpm</code> approach is to feed X with the mouse data
-coming from <code class="command">gpm</code>, a cut-and-paste utility and mouse
-server for virtual consoles. The <code class="command">gpm</code> utility is of
-interest here because it can be configured to handle left-handed mouse devices.
-This approach has the drawback that all the users of the system have to share
-the same <code class="command">gpm</code> configuration, while with <code
-class="command">xmodmap</code> every user could have his or her own <code
+<p>The <code class="command">gpm</code> approach is to feed X with the mouse
+data coming from <code class="command">gpm</code>, a cut-and-paste utility and
+mouse server for virtual consoles. The <code class="command">gpm</code> utility
+is of interest here because it can be configured to handle left-handed mouse
+devices. This approach has the drawback that all the users of the system have
+to share the same <code class="command">gpm</code> configuration, while with
+<code class="command">xmodmap</code> every user could have his or her own <code
class="filespec">.Xmodmap</code> file.</p>
<p>To use the <code class="command">gpm</code> approach, you must modify two
@@ -1447,7 +1447,8 @@
file).</p>
</li>
- <li>I don't want <code class="command">xdm</code> to manage any remote servers.
+ <li>I don't want <code class="command">xdm</code> to manage any remote
+ servers.
<p>Edit <code class="filespec">/etc/X11/xdm/Xservers</code> appropriately.
Note that as this file ships, it does not manage any remote servers, so
unless you have already edited this file (or borrowed someone else's), no
@@ -1470,8 +1471,8 @@
well for people who have changed <code class="filespec">inittab</code> to start
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 <code
+<p>If you have increased your number of virtual consoles, or otherwise require
+VC 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
@@ -1631,7 +1632,8 @@
<p>Move the mouse cursor into the white window, then press and release the "<
>" key. (There will be no visible response to your keystrokes.) Then kill
the X server, either by using <kbd>CTRL-ALT-BACKSPACE</kbd> or by switching back
-to the virtual console from which you ran xinit, and typing <kbd>CTRL-C</kbd>.</p>
+to the virtual console from which you ran xinit, and typing
+<kbd>CTRL-C</kbd>.</p>
<p>Next, use your favorite pager program to view <code
class="command">xev</code>'s output:<br />
@@ -2223,8 +2225,8 @@
<pre> gdk_font_load ("-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*");</pre>
- <p>simply picks the first font in the alphabet that matches the wildcard. With
- the ISO10646-1 fonts present, this will be</p>
+ <p>simply picks the first font in the alphabet that matches the wildcard.
+ With the ISO10646-1 fonts present, this will be</p>
<pre> -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO10646-1</pre>
@@ -2274,10 +2276,10 @@
XFree86 Project, Inc.</a>:</p>
<blockquote>
- <p>The X Window System is a client-server window system. The memory for pixmap
- data resides on the server side instead of the client side. If you have 8
- 1600x1200 32bpp root window images that's 61 Megabytes. It resides in the
- server instead of the client, unless they are shared memory pixmaps, in
+ <p>The X Window System is a client-server window system. The memory for
+ pixmap data resides on the server side instead of the client side. If you
+ have 8 1600x1200 32bpp root window images that's 61 Megabytes. It resides in
+ the server instead of the client, unless they are shared memory pixmaps, in
which case it will be counted on both the server and client side.</p>
<p>Obviously this data has to be stored someplace. It's not like it can just
@@ -2469,8 +2471,8 @@
<li>In some cases, we don't ship them (usually because we cannot, as the
license prevents us from doing so);</li>
<li> they're not part of XFree86, but third-party add-ons;</li>
- <li>(most importantly) we don't have the source code, so we cannot find and fix
- bugs in them — neither can (in general) the authors of XFree86
+ <li>(most importantly) we don't have the source code, so we cannot find and
+ fix bugs in them — neither can (in general) the authors of XFree86
itself.</li>
</ol>
@@ -2763,7 +2765,8 @@
<p>For <code class="filespec">/etc/X11/XF86Config-4</code>, do the following as
root:<br />
-<kbd>md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum<br />
+<kbd>md5sum /etc/X11/XF86Config-4 >
+/var/lib/xfree86/XF86Config-4.md5sum<br />
dpkg-reconfigure xserver-xfree86</kbd></p>
<p>(You may have <code class="package">xserver-xfree86-dbg</code> installed
@@ -2772,8 +2775,9 @@
<p>For <code class="filespec">/etc/X11/Xwrapper.config</code>, do the following
as root:<br />
-<kbd>md5sum /etc/X11/Xwrapper.config > /var/lib/xfree86/Xwrapper.config.md5sum<br />
-dpkg-reconfigure xserver-common</kbd></p>
+<kbd>md5sum /etc/X11/Xwrapper.config >
+/var/lib/xfree86/Xwrapper.config.md5sum<br /> dpkg-reconfigure
+xserver-common</kbd></p>
<p>Another way to accomplish the above is to purge the packages from your system
and reinstall them, but that can be considerably more disruptive.
@@ -2904,11 +2908,11 @@
<h3><a id="nodrinotfatal">The X server log says there was an error and it's
disabling DRI. Is that why the X server won't start?</a></h3>
-<p>No. If DRI (Direct Rendering Infrastructure) is disabled, then 3D-accelerated
-applications such as games may not run satisfactorily or at full speed, but
-this doesn't prevent the X server from working. A disabled DRI doesn't
-prevent your desktop from coming up, or programs like XTerm or Mozilla from
-running.</p>
+<p>No. If DRI (Direct Rendering Infrastructure) is disabled, then
+3D-accelerated applications such as games may not run satisfactorily or at full
+speed, but this doesn't prevent the X server from working. A disabled DRI
+doesn't prevent your desktop from coming up, or programs like XTerm or Mozilla
+from running.</p>
<p>If your X server is failing to start and you think this error message is the
problem, look elsewhere; the problem is something else.</p>
@@ -2996,10 +3000,11 @@
immediately. This can look a lot like a "crash" to the uninitiated, especially
when the clients themselves crash.</p>
-<p>It's easy to determine whether the X server itself works. As root, simply run
-the command <kbd>X</kbd>. If that brings up the little root window weave and the X
-cursor, then <em>you do not have a fatal X server configuration problem</em>.
-The X server is working. Use <kbd>CTRL-ALT-BACKSPACE</kbd> to kill it.</p>
+<p>It's easy to determine whether the X server itself works. As root, simply
+run the command <kbd>X</kbd>. If that brings up the little root window weave
+and the X cursor, then <em>you do not have a fatal X server configuration
+problem</em>. The X server is working. Use <kbd>CTRL-ALT-BACKSPACE</kbd> to
+kill it.</p>
<p>Alternatively, if you're using a display manager and you can see the greeter
(login screen), then the X server is running: <em>you do not have a fatal X
@@ -3059,20 +3064,20 @@
class="other">MonitorLayout</code> line, but I can't think of a physical
mechanism for this actually happening.</p>
-<h3><a id="xkbnewlayout">My keyboard configuration worked with XFree86 4.2;
- why is it messed up now? For example, my Windows keys don't work
+<h3><a id="xkbnewlayout">My keyboard configuration worked with previous versions
+ of XFree86; why is it messed up now? For example, my Windows keys don't work
right in Emacs or my window manager anymore.</a></h3>
<p><em>Thanks to Denis Barbier for contributing much of this entry.</em></p>
-<p><em>Please see the glossary in <a href="#keyboard">"How does the keyboard work
-in the X Window System?"</a> above for explanantions of unfamiliar
+<p><em>Please see the glossary in <a href="#keyboard">"How does the keyboard
+work in the X Window System?"</a> above for explanantions of unfamiliar
terms.</em></p>
-<p>The most significant recent change to keyboard configuration took place to
-XKB layouts in XFree86 4.3; they were significantly revised and updated.
-The most intuitive approach to supporting multiple levels on the keyboard is
-through combining layouts. Prior to XFree86 4.3, though, this was difficult because
+<p>The most significant recent change to keyboard configuration took place to
+XKB layouts in XFree86 4.3; they were significantly revised and updated. The
+most intuitive approach to supporting multiple levels on the keyboard is through
+combining layouts. Prior to XFree86 4.3, though, this was difficult because
keyboard symbols (<em>keysyms</em>) were defined to be specific to a given
group. For example, the <code>us</code> symbols file (in <code
class="filespec">/etc/X11/xkb/symbols/</code>) defined its keycode to keysym
@@ -3084,9 +3089,9 @@
was consequently impossible without modifying the XKB data files directly
— a skill most users do not possess.</p>
-<p>There are now new definitions that are "multi-layout aware"; they can be used in
-arbitrary order so that <code>us,ru</code> and <code>ru,us</code> use the same
-<code>symbols</code> files. The multi-layout-capable definitions have been
+<p>There are now new definitions that are "multi-layout aware"; they can be used
+in arbitrary order so that <code>us,ru</code> and <code>ru,us</code> use the
+same <code>symbols</code> files. The multi-layout-capable definitions have been
placed in <code class="filespec">/etc/X11/xkb/symbols/pc/</code> while the old
ones are still available in their traditional location; that is, directly within
the <code class="filespec">/etc/X11/xkb/symbols/</code> directory.</p>
@@ -3102,24 +3107,34 @@
the system more modular. This is a change that was initially made to XFree86
CVS after XFree86 4.3.0 was released, but has been incorporated into Debian's
packages of XFree86 4.3.0, further refined, and adopted upstream by both XFree86
-and X.Org. One consequence is that <em>fake keys</em> have been
-introduced in XKB data files for <code>Alt</code>, <code>Meta</code>,
-<code>Super</code> and <code>Hyper</code>. (The fake keys are distinguished
-from real keys by not being pair-oriented to the "left" or "right". Even
-keyboards that have only one of a pair of such keys — like laptop
-keyboards — report the keys they do have as being either left or right,
-for compatibility with full-size models.) By default, the modifiers
-<code>mod1</code> and <code>mod4</code> use these fake keys instead of real
-ones. XKB-aware applications can handle those fake keys, but some applications,
-like GNU Emacs, XEmacs, and Sawfish, are buggy — they get confused and
-will not recognize some of your keys as activating the right modifiers.
-(<strong>Update:</strong> Version 21.3+1-8 of the Debian <code
-class="package">emacs21</code> packages fixes this problem for GNU Emacs.) A
-workaround for XEmacs is to set the <code class="other">altwin:super_win</code>
-XKB option. The recommendation of Debian developers to frustrated Sawfish users
-<a href="http://lists.debian.org/debian-x/2004/09/msg00307.html";>appears</a> to
-be to switch to Metacity.</p>
+and X.Org. One consequence is that <em>fake keys</em> have been introduced in
+XKB data files for <code>Alt</code>, <code>Meta</code>, <code>Super</code> and
+<code>Hyper</code>. (The fake keys are distinguished from real keys by not
+being pair-oriented to the "left" or "right". Even keyboards that have only one
+of a pair of such keys — like laptop keyboards — report the keys
+they do have as being either left or right, for compatibility with full-size
+models.) By default, the modifiers <code>mod1</code> and <code>mod4</code> use
+these fake keys instead of real ones. The logo keys (a.k.a. "Windows" keys) are
+often used for one of these modifiers. XKB-aware applications can handle those
+fake keys, but some applications are not XKB-aware — they get confused and
+will not recognize some of your keys as activating the right modifiers.</p>
+<p>GNU Emacs, XEmacs, Openbox, and Sawfish are known to be (or have been) buggy
+in this fashion, but there may be others. In window managers, the consequences
+of this bug vary, but one commonly seen result is that the transient window used
+to navigate workspaces does not go away when the keys that bring it up (such as
+<kbd>Win+Tab</kbd>) are released. The recommendation of Debian developers to
+frustrated Sawfish users <a
+href="http://lists.debian.org/debian-x/2004/09/msg00307.html";>appears</a> to be
+to switch to Metacity.</p>
+
+<p>A workaround you can use if your application has not yet been fixed is to set
+the <code class="other">altwin:super_win</code> XKB option. To try it out, run
+the command <kbd>setxkbmap -option "altwin:super_win"</kbd><sup>*</sup>. To
+make the change permanent, run <kbd>dpkg-reconfigure xserver-xfree86</kbd> as
+root, and add <kbd>altwin:super_win</kbd> to your configured XKB options when
+prompted.</p>
+
<p>For further information, please see:</p>
<ul>
@@ -3164,9 +3179,9 @@
<p>There are several things you can do about the problem. All of them involve
using a different GTK+ input method. You can test these by opening some GTK+
-app that takes input, such as <code class="command">gedit</code>. Right-click on the edit box, and there
-should be a submenu for "Input Methods". The new input method should show up
-in that submenu.</p>
+app that takes input, such as <code class="command">gedit</code>. Right-click
+on the edit box, and there should be a submenu for "Input Methods". The new
+input method should show up in that submenu.</p>
<ul>
<li><p>Get a better GTK+ input method. The <a
@@ -3233,9 +3248,9 @@
class="filespec">80R</code>, etc., that could be a problem — but I think
it's a fairly low probability.</p>
-<p class="footnote"><sup>*</sup> Some day I'll see a bug report from someone who's got a
-1200x1200 <code class="command">xterm</code>, and (with a script of course),
-they'll determine that resize doesn't give the correct result.</p>
+<p class="footnote"><sup>*</sup> Some day I'll see a bug report from someone
+who's got a 1200x1200 <code class="command">xterm</code>, and (with a script of
+course), they'll determine that resize doesn't give the correct result.</p>
<h3><a id="precompiledkeymap">How can I set up my X server or X terminal to use
XKB without any X libraries or XKB data installed?</a></h3>
@@ -3554,11 +3569,11 @@
<p>The author would like to thank Andreas Metzler, Guillem Jover, Ingo Saitz,
Osamu Aoki, Matthew Arnison, Colin Walters, Steve Swales, Adam Jackson, Thomas
Dickey, Paul Gotch, Albert Cahalan, Denis Barbier, Jeff Licquia, Fabio Massimo
-Di Nitto, Andrew Suffield, Frank Murphy, Marc-Aurèle Darche, Michel Dänzer, and "ulisses" for
-their contributions to this document.</p>
+Di Nitto, Andrew Suffield, Frank Murphy, Marc-Aurèle Darche, Michel Dänzer
+and "ulisses" for their contributions to this document.</p>
<hr />
-<p class="x-small">$Id: FAQ.xhtml 1958 2004-10-15 21:36:34Z branden $</p>
+<p class="x-small">$Id: FAQ.xhtml 2222 2005-03-14 01:09:54Z branden $</p>
</body>
</html>
<!-- vim:set ai et sts=2 sw=2 tw=80: -->
Reply to: