X Strike Force XFree86 SVN commit: r2001 - in branches/ubuntu/debian: . local patches
Author: fabbione
Date: 2004-10-30 01:16:12 -0500 (Sat, 30 Oct 2004)
New Revision: 2001
Added:
branches/ubuntu/debian/patches/099l_xxf86vm_increase_verbosity.diff
Modified:
branches/ubuntu/debian/CHANGESETS
branches/ubuntu/debian/TODO
branches/ubuntu/debian/changelog
branches/ubuntu/debian/copyright
branches/ubuntu/debian/local/FAQ.xhtml
branches/ubuntu/debian/xserver-xfree86.postinst.in
branches/ubuntu/debian/xserver-xfree86.templates
Log:
Import 4.3.0.dfsg.1-6ubuntu25 release.
Modified: branches/ubuntu/debian/CHANGESETS
===================================================================
--- branches/ubuntu/debian/CHANGESETS 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/CHANGESETS 2004-10-30 06:16:12 UTC (rev 2001)
@@ -47,4 +47,11 @@
locales. (Closes: #235574)
1937
+Update "Further Information" section of FAQ.
+ 1947
+
+Add FAQ entry: What are Debian's plans with respect to X.Org and
+XFree86?
+ 1948, 1949
+
vim:set ai et sts=4 sw=4 tw=80:
Modified: branches/ubuntu/debian/TODO
===================================================================
--- branches/ubuntu/debian/TODO 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/TODO 2004-10-30 06:16:12 UTC (rev 2001)
@@ -52,7 +52,6 @@
users to use 'gb' [BR]
+ Use /proc/hardware on m68k architecture to set a reasonable default mouse
port. See <URL: http://lists.debian.org/debian-68k/2004/08/msg00392.html>.
-* Add FAQ entry describing Debian's plans in the X department.
* Add Debian-specific patch to uxterm to call validlocale(8) before trying to
launch xterm, per recommendation from Recai Oktas. If a valid locale isn't
set, bail out (would resolve #246398). (This patch would be Debian-specific
Modified: branches/ubuntu/debian/changelog
===================================================================
--- branches/ubuntu/debian/changelog 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/changelog 2004-10-30 06:16:12 UTC (rev 2001)
@@ -1,3 +1,48 @@
+xfree86 (4.3.0.dfsg.1-6ubuntu25) warty; urgency=low
+
+ Imported from Debian trunk:
+
+ * Update "Further Information" section of FAQ.
+
+ * Add FAQ entry: What are Debian's plans with respect to X.Org and
+ XFree86?
+
+ * Add FAQ entry: What are Debian's plans with respect to X.Org and
+ XFree86?
+
+ * Add FAQ entry: Sometimes I get garbage characters like 1;2c in my xterm
+ windows; what's happening?
+
+ * Update FAQ entry: My keyboard configuration worked with XFree86 4.2; why
+ is it messed up now?
+
+ * Update FAQ entry: How does the keyboard work in the X Window System?
+
+ * Add copyright and (MIT/X11 style) license for Bitstream Type1 fonts to
+ copyright file. Thanks to Ben Harris for pointing this out.
+ (Closes: #274018)
+
+ Changes by Fabio M. Di Nitto:
+
+ * Fix 1152x768 @ 60 Hz mode. (Closes: #2328)
+
+ * Fix a nasty bug in frequencies detection logic to get a better
+ clue if the resolution is not in the mode-list template and respect
+ selection-method user value on reconfiguration.
+ This fix will catch all the unknown resolutions without projecting the
+ users back in time to a 640x480@60Hz view of the world, both at
+ installation time and during upgrades/reconfigurations.
+
+ Changes by Daniel Stone:
+
+ * debian/patches/099l_xxf86vm_decrease_verbosity.diff:
+ + Take patch from X.Org (http://freedesktop.org/bugzilla/show_bug.cgi?id=1552)
+ and Red Hat (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128305)
+ to decrease Xxf86vm verbosity, so the hard drive does not spin up every
+ time xscreensaver activates.
+
+ -- Fabio M. Di Nitto <fabbione@fabbione.net> Wed, 13 Oct 2004 13:42:39 +0200
+
xfree86 (4.3.0.dfsg.1-6ubuntu24) warty; urgency=low
Imported from Debian trunk:
@@ -22,6 +67,8 @@
* Fix missing-word typo in xnest's package description. Thanks to Roland
Stigge for catching this. (Closes: #268997)
+ Changes by Denis Barbier and Fabio M. Di Nitto:
+
* Add several multi-layout aware layouts:
+ ca (Canada) contains several variants: "fr" is meant as a replacement
for ca_enhanced, "fr-legacy" is another variant, and "multi" is an
Modified: branches/ubuntu/debian/copyright
===================================================================
--- branches/ubuntu/debian/copyright 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/copyright 2004-10-30 06:16:12 UTC (rev 2001)
@@ -1130,6 +1130,7 @@
XFree86's LICENSE document does not appear to be completely
comprehensive.
+--------------------------------------------------------------------------------
Many files appear to be licensed under the "SGI FREE SOFTWARE
LICENSE B (Version 1.1 [02/22/2000])":
@@ -1396,4 +1397,20 @@
appear in the Notice in the Original Code under the heading "Additional
Notice Provisions"]
+--------------------------------------------------------------------------------
+The Bitstream Type 1 fonts are under the following license:
+
+(c) Copyright 1989-1992, Bitstream Inc., Cambridge, MA.
+
+You are hereby granted permission under all Bitstream propriety rights
+to use, copy, modify, sublicense, sell, and redistribute the 4 Bitstream
+Charter (r) Type 1 outline fonts and the 4 Courier Type 1 outline fonts
+for any purpose and without restriction; provided, that this notice is
+left intact on all copies of such fonts and that Bitstream's trademark
+is acknowledged as shown below on all unmodified copies of the 4 Charter
+Type 1 fonts.
+
+BITSTREAM CHARTER is a registered trademark of Bitstream Inc.
+--------------------------------------------------------------------------------
+
vim:set ai et sw=4 sts=4 tw=72:
Modified: branches/ubuntu/debian/local/FAQ.xhtml
===================================================================
--- branches/ubuntu/debian/local/FAQ.xhtml 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/local/FAQ.xhtml 2004-10-30 06:16:12 UTC (rev 2001)
@@ -49,6 +49,8 @@
<li><a href="#xorg">What is X.Org?</a></li>
<li><a href="#xfree86fork">What is the story with XFree86 being forked?</a></li>
<li><a href="#xfree86license">What is the story with XFree86's license?</a></li>
+<li><a href="#debianplans">What are Debian's plans with respect to X.Org and
+ XFree86?</a></li>
<li><a href="#defxservclient">What are X servers and X clients?</a></li>
<li><a href="#xservbackw">Why is the X usage of "server" and "client"
backwards from everyone else's?</a></li>
@@ -155,7 +157,10 @@
<li><a href="#xkbnewlayout">My keyboard configuration worked with XFree86 4.2;
why is it messed up now?</a></li>
<li><a href="#composeinput">Why does composing characters work in some
- applications but not others?<a></li>
+ applications but not others?</a></li>
+<li><a href="#xtermresizenoise">Sometimes I get garbage characters like
+ <code class="other">1;2c</code> in my <code class="command">xterm</code>
+ windows; what's happening?</a></li>
</ul>
<h2><a href="#acknowledgements">Acknowledgements</a></h2>
@@ -210,8 +215,17 @@
<h2><a id="moreinfo">Further Information</a></h2>
-<p>By its nature, this document is not complete. If your question is not
-answered here, try <code
+<p>The most recent version of this FAQ, as well as the latest news about Debian
+X Window System package development, future plans, and information about how you
+can help improve the quality of Debian's X Window System packages can be found
+via the <a href="http://people.debian.org/~branden/xsf/";>X Strike Force web
+site</a>.</p>
+
+<p>By its nature, this document is not comprehensive. It attempts to address
+the questions that are most frequently asked of Debian Developers regarding the
+X Window System. It also covers some broad and fundamental concepts that are
+useful to explain some of the answers given. If your question is not answered
+here, try <code
class="filespec">/usr/share/doc/<var>packagename</var>/README.Debian</code> (and
other files in the package's <code class="filespec">doc</code> directory),
manual pages, and the <code class="other">debian-user</code> mailing list. See
@@ -232,14 +246,11 @@
<p>(There used to be an XFree86 FAQ, which was published by the XFree86 project,
but unfortunately it has not been maintained for quite some time.)</p>
-<p>Like all other documentation, these FAQs are in
-<code class="filespec">/usr/share/doc/<var>packagename</var>/</code>.</p>
+<p>As is standard in the Debian system, these FAQs are found in <code
+class="filespec">/usr/share/doc/<var>packagename</var>/</code>. The Debian X
+FAQ is part of the <code class="package">xfree86-common</code> package, and the
+XTerm FAQ is part of the <code class="package">xterm</code> package.</p>
-<p>Finally, for the latest news about Debian XFree86 packaging development,
-future plans, or to find out how you can help improve the quality of
-Debian's XFree86 packages, check out the <a
-href="http://people.debian.org/~branden/xsf/";>X Strike Force</a>.</p>
-
<h2><a id="howto">How to Use this Document</a></h2>
<p>As with many similar documents, this FAQ uses visual markup to indicate words
@@ -594,6 +605,80 @@
community will coalesce around a single X Window System SI as it did around
XFree86, or whether the environment will be competitive.</p>
+<h3><a id="debianplans">What are Debian's plans with respect to X.Org and
+ XFree86?</a></h3>
+
+<p><em>Thanks to Fabio Massimo Di Nitto for contributing much of this
+entry.</em></p>
+
+<p>Because the XFree86 relicensing came at a time when Debian was trying to
+stabilize its XFree86 packages for the <code class="other">sarge</code> release,
+there was some question among Debian's X Window System package maintenance team
+(the "X Strike Force") — and much speculation among Debian's users —
+as to what direction Debian would take.</p>
+
+<p>There was never a serious proposal to attempt to ship anything other than
+XFree86 4.3.0 in <code class="other">sarge</code>, so work on that continued
+while discussion on the <code class="other">debian-x</code> mailing list took
+place. The following represents the <a
+href="http://lists.debian.org/debian-x/2004/08/msg00235.html";>consensus reached
+by the X Strike Force</a>, without objection from the mailing list subscribers
+(among whom number many interested Debian developers and users).</p>
+
+<p>In June 2004, Fabio Massimo Di Nitto, the XFree86 package release manager for
+Debian <code class="other">sarge</code> and <code class="other">sid</code>,
+started a <a
+href="http://lists.debian.org/debian-x/2004/06/msg00411.html";>thread</a> to
+discuss the future of X Window System packages in Debian for an open discussion
+between users and the Debian package maintainers.</p>
+
+<p>The discussion spanned nearly one hundred messages from over a dozen
+participants, practically all of it constructive and very useful to the Debian
+maintenance team. The outcome of the thread was farly clear to everyone: Debian
+will move away from the XFree86 tree as soon as possible after
+the <a href="http://www.debian.org/releases/sarge/";>upcoming stable release</a>
+due to its license issues (<a href="#xfree86license">see above</a>).</p>
+
+<p>The XFree86 package maintainers are committed to providing support and
+assistance to the <a href="http://www.debian.org/security/";>Debian Security
+Team</a> for the XFree86 4.3.0-based packages than Debian will ship in <code
+class="other">sarge</code>. That is, our abandonment of the XFree86 Project,
+Inc., as an upstream source of code does not mean that we will abandon our
+committment to the user of our production release.</p>
+
+<p>Futhermore, there was near-consensus that Debian should switch to the <a
+href="http://www.freedesktop.org/XOrg/CvsPage";>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>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
+packages will take longer — indeed, an unknown amount of time which
+depends on the speed of upstream's progress — but we expect the process
+will bring the packages' quality to a higher level, thanks to the introduction
+of a fast release cycle for each single component. We expect to "modularize"
+two parts of the X.Org distribution immediately: XTerm and Xprt (the XPRINT
+server). XTerm is independently maintained by Thomas Dickey, and the <code
+class="other">xprint.org</code> version of Xprt is already separately packaged
+in Debian.</p>
+
+<p>With these changes, it will also be easier for the Debian user community to
+have a broader choice in X servers. At present, the Debian XFree86 package
+maintainers intend to support only the XOrg X server (which is based on
+XFree86's). The X Strike Force does not plan to discourage other people from
+packaging others. Debian developers that file intent-to-package notices (ITPs)
+for other X servers are asked to strictly cooperate with the X Strike Force to
+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 (October 2004), 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>
+
<h3><a id="defxservclient">What are X servers and X clients?</a></h3>
<p>This is the most important, and probably the first, concept a newcomer to
@@ -796,15 +881,20 @@
-->
<p><em>It will take some time to write a comprehensive entry on this subject,
-but in the meantime it is hoped that the following glossary is useful.</em></p>
+but in the meantime it is hoped that the information presented here is useful.
+Thanks to Denis Barbier and Andrew Suffield for their patience and
+explanations.</em></p>
+<h4>Glossary</h4>
+
<dl>
<dt><strong>compose key</strong></dt>
<dd>a key which causes the next two keys pressed to be treated specially
such that they cause a single character to be printed (this is implemented
- in software); for example, pressing <kbd>Compose + A + E</kbd> would produce
- the ae ligature (æ); valid compose sequences are defined in
- locale-specific data files such as <code
+ in software); for example, pressing and releasing <kbd>Compose</kbd>,
+ <kbd>A</kbd>, and then <kbd>E</kbd> in sequence would produce the ae
+ ligature (æ); valid compose sequences are defined in locale-specific
+ data files such as <code
class="filespec">/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose</code>; the X
Window System's <strong>keysym</strong> for this key is
<code>Multi_key</code></dd>
@@ -925,6 +1015,55 @@
class="command">setxkbmap</code> command, which in turn depends on <code
class="command">xkbcomp</code>, the XKB data files, and the X libraries.</p>
+<p>Many users of the X Window System, particularly outside the United States,
+find that they need support for multiple <em>group</em>s on their keyboards.
+A group a set of two keyboard symbols paired so that pressing an unshifted key
+gets you the first symbol in the group, and pressing the same key with the
+<code>Shift</code> key held down give you the second symbol in the group.</p>
+
+<p>A U.S. keyboard has only one group — this is sufficient to type all of
+the symbols in the ASCII character set. Elsewhere in the world, however,
+keyboards frequently have keys engraved with more than two glyphs. A third and
+often a fourth glyph appear. These comprise the <em>alternate group</em>, which
+is usually accessed with a modifier key not found on most U.S. keyboards:
+<code>AltGr</code>. When the <code>AltGr</code> key is pressed, the third and
+fourth glyphs on the keycap can be entered: <kbd>AltGr + <em>key</em></kbd>
+gives you the third, and if a fourth is engraved, it is entered with <kbd>AltGr
++ Shift + <em>key</em></kbd>. For example, on many European keyboards, one can
+press <kbd>AltGr + E</kbd> to produce the Euro sign (€). Sometimes the
+<code>Alt</code> key on the right-hand side of the keyboard is used as
+<code>AltGr</code> if there is no key actually engraved with
+<code>AltGr</code>.</p>
+
+<p>If even an alternate group does not suffice to let users type all of the
+symbols they need to, the entire keyboard mapping can be switched out with a
+single keystroke using what the X KEYBOARD Extension (XKB) refers to as a
+"level". This is typically done with a <code>Mode Switch</code> key, which is
+somewhat analogous to <code>Caps Lock</code>. When this key is pressed, the X
+Window System toggles the second level. This approach is often taken with
+keyboards that need to type in both the Cyrillic and Latin alphabets. A Russian
+user, for example, might use a French keyboard layout (complete with alternate
+group symbols) on the first level to correspond with Western European friends
+via email, but then press <code>Mode Switch</code> to change to the second
+level, featuring Cyrillic letters, to write messages to Russian friends.</p>
+
+<p>XKB supports up to four keysyms per level (two groups of two symbols each),
+and up to four levels. In such situations, rather than having a <code>Mode
+Switch</code> key, there might be <code>Next Mode</code> and <code>Previous
+Mode</code> keys that cycle through the available levels.</p>
+
+<p>A U.S. keyboard, even if keys are remapped so that <code>AltGr</code> and/or
+<code>Mode Switch</code> keys are available, does not acquire much meaningful
+additional functionality unless an alternate group and/or multiple levels are
+defined in software, so that "the keys know what to do" when the alternate group
+is activated or the level is changed.</p>
+
+<p>A separate approach to typing symbols not engraved on the keyboard is to use
+the <code>Multi_key</code>. This enables you to use two keys to type any symbol
+defined by Compose sequences for your locale. For most layouts, the
+<code>Multi_key</code> keysym is bound to <kbd>Shift + AltGr</kbd>. Note that
+<kbd>AltGr + Shift</kbd> means something else; see above.</p>
+
<h2><a id="specquest" class="bigtext">Specific Questions</a></h2>
<h3><a id="custxsess">How do I customize my X session?</a></h3>
@@ -2827,40 +2966,11 @@
in the X Window System?"</a> above for explanantions of unfamiliar
terms.</em></p>
-<p>Many users of the X Window System, particularly outside the United States,
-find that they need support for multiple <em>groups</em> on their keyboards.
-One or more of the keys on their keyboards are engraved with more than two
-glyphs. On a typical U.S. keyboard, there are at most two glyphs on each keycap
-— one is accessed with a <code>Shift</code> or <code>Caps Lock</code> key,
-and one without. Many keyboards outside the United States enable access to
-glyphs beyond the third with modifier keys not found on most U.S. keyboards.
-One approach is with an <code>AltGr</code> (alternate group) key, which is
-analogous to <code>Shift</code>. The other approach is with a <code>Mode
-Switch</code> key, which is analogous to <code>Caps Lock</code>. When either of
-these keys are pressed, the X Window System needs to know to switch to an
-alternative key layout — preferably one which corresponds to the
-engravings on the user's keyboard. A U.S. keyboard, even if keys are remapped
-so that <code>AltGr</code> and/or <code>Mode Switch</code> keys are available,
-does not acquire much meaningful additional functionality unless and alternate
-group is defined in software, so that "the keys know what to do" when the
-alternate group is enabled.</p>
-
-<p>Sometimes a key layout for a given territory (such as <code>gb</code> for the
-United Kingdom or <code>fr</code> for France) defines what should be in the
-alternate group. For example, on many European keyboards, one can press
-<kbd>AltGr + E</kbd> to produce the Euro sign (€). This approach is often
-taken when most keys don't need an symbol defined for the alternate group,
-because most keys are engraved with two or fewer glyphs. </p>
-
-<p>Other times, however, most or all of the printing keys on the keyboard are
-engraved with primary group <em>and</em> alternate group glyphs. Russian
-keyboards, for example, because they must support both the Latin and Cyrillic
-alphabets, often work this way. As a consequence, users of the X Window System
-need a way to <em>combine layouts</em>.</p>
-
-<p>Prior to XFree86 4.3, combining layouts 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
+<p>First of all, XKB layouts have been revisited in XFree86 4.3.
+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 the its keycode to keysym
mappings specifically for group 1 — the primary group. The
<code>us_group2</code> and <code>us_group3</code> files repeated these
@@ -2870,12 +2980,12 @@
was consequently impossible without modifying the XKB data files directly
— a skill most users do not possess.</p>
-<p>XKB layouts have been revisited in XFree86 4.3, and new definitions can now
-be used in arbitrary order so that <code>us,ru</code> and <code>ru,us</code> use
-the same <code>symbols</code> files. The new 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>
+<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>
<p>Some symbols files have not been converted to the new multi-layout approach,
and thus can not be combined with others. These are listed as
@@ -2884,31 +2994,44 @@
combining layouts, check that you are not trying to load a layout listed
there.</p>
-<p>Modifiers have also been affected by these changes to make the system more
-modular. A 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 <application>GNU Emacs</application>, get
-confused and will not recognize your keys as modifiers. Until these
-applications are fixed, you can bind keys explicitly with <code>altwin</code>
-XKB options; for example, <kbd>Option "XkbOptions" "altwin:super_win"</kbd>
-binds your logo keys to <code>Super</code> modifiers.</p>
+<p>Secondly, modifiers also been affected by the multi-layout changes to make
+the system more modular. 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. 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
+appears to be to switch to Metacity.</p>
+<p>Futher reading:</p>
+
+<ul>
+ <li><a
+ href="http://lists.debian.org/debian-emacsen/2004/09/msg00019.html";>description
+ of Emacs modifer problem</a></li>
+ <li><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274103";>Debian
+ <code class="package">emacs21</code> bug report</a></li>
+ <li><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263073";>Debian
+ <code class="package">sawfish</code> bug report</a></li>
+</ul>
+
<h3><a id="composeinput">Why does composing characters work in some applications
- but not others?<a></h3>
+ but not others?</a></h3>
<p><em>Thanks to Jeff Licquia for contributing much of this entry.</em></p>
<p>People sometimes find that they can use their <code>Compose</code> key as
-expected in some applications -- for instance, <code
+expected in some applications — for instance, <code
class="command">uxterm</code>, <code class="command">xterm</code>, and
-OpenOffice.Org Writer -- but not in others, such as Mozilla, Galeon, or <code
-class="command">gnome-terminal</code>.</p>
+OpenOffice.Org Writer — but not in others, such as Mozilla, Galeon, or
+<code class="command">gnome-terminal</code>.</p>
<p>The difference is that the latter group of applications use the GTK+ input
method framework, and the former group does not.</p>
@@ -2940,7 +3063,7 @@
class="package">scim-gtk2-immodule</code>, and <code
class="package">uim-gtk2.0</code> in Debian testing or unstable. Most of
these, though, are aimed at non-Latin issues, so whether they're appropriate
- for you depends on your needs.</li></p>
+ for you depends on your needs.</p></li>
<li><p>GTK+ ships with a XIM shim module. This is the solution many Debian
developers use.</p></li>
</ul>
@@ -2953,12 +3076,57 @@
class="filespec">.profile</code>, <code class="filespec">.bashrc</code>, or
whatever your shell uses as an initialization file.</p>
+<h3><a id="xtermresizenoise">Sometimes I get garbage characters like
+ <code class="other">1;2c</code> in my <code class="command">xterm</code>
+ windows; what's happening?</a></h3>
+
+<p><em>Thanks to Thomas Dickey for contributing much of this entry.</em></p>
+
+<p>Occasionally people are concerned that this is a security problem —
+they fear that some rogue application may be trying to inject keystrokes at
+their shell prompt, for example. While <code class="command">xterm</code> and
+other terminal emulators have had bugs like that in the past (see <a
+href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0063";>MITRE's CVE
+candidate CAN-2003-0063</a>), this is not such a situation.</p>
+
+<p>What you're seeing is part of the VT100 escape sequence that uses the cursor
+position of the lower-right corner to determine the screen size. You're only
+seeing part of it because the "wrong" application had eaten part of the
+response. (I get that sort of thing if I log into certain machines from the
+FreeBSD console — it doesn't respond as a VT100 would).</p>
+
+<p>Normally I'd see this only due to a misconfiguration and/or combination with
+a timeout. It's annoying but relatively harmless. It's not like the answerback
+or title strings — the response is determined by the terminal geometry and
+can't contain arbitrary text.</p>
+
+<p>If <code class="command">resize</code> cannot get useful information by a
+system call, it positions the cursor far right/down, and then asks the terminal
+where it really got to. Real VT100 terminals won't wrap when positioning the
+cursor to (999,999), but will just move it in that direction until it
+stops<sup>*</sup>.</p>
+
+<p>The response looks like:</p>
+
+<p><code class="other">ESC [ <em>row</em> ; <em>column</em> R</code></p>
+
+<p>where <em>row</em> and <em>column</em> are positive decimal integers. If one
+is in the habit of filling up their <code class="filespec">bin</code> directory
+with malicious scripts named <code class="filespec">79R</code>, <code
+class="filespec">80R</code>, etc., that could be a problem — but I think
+it's a fairly low probability.</p>
+
+<p><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>
+
<h2><a id="acknowledgements">Acknowledgements</a></h2>
<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, and "ulisses"
-for their contributions to this document.</p>
+Dickey, Paul Gotch, Albert Cahalan, Denis Barbier, Jeff Licquia, Fabio Massimo
+Di Nitto, Andrew Suffield, and "ulisses" for their contributions to this
+document.</p>
<hr />
<p class="x-small">$Id$</p>
Added: branches/ubuntu/debian/patches/099l_xxf86vm_increase_verbosity.diff
===================================================================
--- branches/ubuntu/debian/patches/099l_xxf86vm_increase_verbosity.diff 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/patches/099l_xxf86vm_increase_verbosity.diff 2004-10-30 06:16:12 UTC (rev 2001)
@@ -0,0 +1,146 @@
+--- xc/programs/Xserver/Xext/xf86vmode.c.orig 2004-10-12 21:35:04.243233336 +1000
++++ xc/programs/Xserver/Xext/xf86vmode.c 2004-10-12 21:38:09.543063480 +1000
+@@ -51,6 +51,8 @@
+ #include "xf86_ansic.h"
+ #endif
+
++#define DEFAULT_XF86VIDMODE_VERBOSITY 3
++
+ static int VidModeErrorBase;
+ static int VidModeGeneration = 0;
+ static int VidModeClientPrivateIndex;
+@@ -466,7 +468,7 @@
+ rep.vtotal = VidModeGetModeValue(mode, VIDMODE_V_TOTAL);
+ rep.flags = VidModeGetModeValue(mode, VIDMODE_FLAGS);
+
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("GetModeLine - scrn: %d clock: %d\n",
+ stuff->screen, rep.dotclock);
+ ErrorF("GetModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -674,7 +676,7 @@
+ stuff->after_vtotal = oldstuff->after_vtotal;
+ stuff->after_flags = oldstuff->after_flags;
+ }
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("AddModeLine - scrn: %d clock: %d\n",
+ stuff->screen, stuff->dotclock);
+ ErrorF("AddModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -783,7 +785,7 @@
+
+ VidModeAddModeline(stuff->screen, mode);
+
+- if (xf86GetVerbosity() > 1)
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY)
+ ErrorF("AddModeLine - Succeeded\n");
+ return client->noClientException;
+ }
+@@ -820,7 +822,7 @@
+ stuff->flags = oldstuff->flags;
+ stuff->privsize = oldstuff->privsize;
+ }
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("DeleteModeLine - scrn: %d clock: %d\n",
+ stuff->screen, stuff->dotclock, stuff->dotclock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -839,7 +841,7 @@
+ len = client->req_len - (sizeof(xXF86VidModeDeleteModeLineReq) >> 2);
+ }
+ if (len != stuff->privsize) {
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("req_len = %d, sizeof(Req) = %d, privsize = %d, len = %d, length = %d\n",
+ client->req_len, sizeof(xXF86VidModeDeleteModeLineReq)>>2, stuff->privsize, len, stuff->length);
+ }
+@@ -852,7 +854,7 @@
+ if (!VidModeGetCurrentModeline(stuff->screen, &mode, &dotClock))
+ return BadValue;
+
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("Checking against clock: %d (%d)\n",
+ VidModeGetModeValue(mode, VIDMODE_CLOCK), dotClock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -875,7 +877,7 @@
+ return BadValue;
+
+ do {
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("Checking against clock: %d (%d)\n",
+ VidModeGetModeValue(mode, VIDMODE_CLOCK), dotClock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -893,7 +895,7 @@
+ if ((VidModeGetDotClock(stuff->screen, stuff->dotclock) == dotClock) &&
+ MODEMATCH(mode, stuff)) {
+ VidModeDeleteModeline(stuff->screen, mode);
+- if (xf86GetVerbosity())
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY)
+ ErrorF("DeleteModeLine - Succeeded\n");
+ return(client->noClientException);
+ }
+@@ -933,7 +935,7 @@
+ stuff->flags = oldstuff->flags;
+ stuff->privsize = oldstuff->privsize;
+ }
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("ModModeLine - scrn: %d hdsp: %d hbeg: %d hend: %d httl: %d\n",
+ stuff->screen, stuff->hdisplay, stuff->hsyncstart,
+ stuff->hsyncend, stuff->htotal);
+@@ -1016,7 +1018,7 @@
+ VidModeSetCrtcForMode(stuff->screen, mode);
+ VidModeSwitchMode(stuff->screen, mode);
+
+- if (xf86GetVerbosity() > 1)
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY)
+ ErrorF("ModModeLine - Succeeded\n");
+ return(client->noClientException);
+ }
+@@ -1054,7 +1056,7 @@
+ stuff->flags = oldstuff->flags;
+ stuff->privsize = oldstuff->privsize;
+ }
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("ValidateModeLine - scrn: %d clock: %d\n",
+ stuff->screen, stuff->dotclock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -1131,7 +1133,7 @@
+ swapl(&rep.status, n);
+ }
+ WriteToClient(client, sizeof(xXF86VidModeValidateModeLineReply), (char *)&rep);
+- if (xf86GetVerbosity() > 1)
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY)
+ ErrorF("ValidateModeLine - Succeeded (status = %d)\n", status);
+ return(client->noClientException);
+ }
+@@ -1185,7 +1187,7 @@
+ stuff->flags = oldstuff->flags;
+ stuff->privsize = oldstuff->privsize;
+ }
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("SwitchToMode - scrn: %d clock: %d\n",
+ stuff->screen, stuff->dotclock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -1220,7 +1222,7 @@
+ return BadValue;
+
+ do {
+- if (xf86GetVerbosity() > 1) {
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY) {
+ ErrorF("Checking against clock: %d (%d)\n",
+ VidModeGetModeValue(mode, VIDMODE_CLOCK), dotClock);
+ ErrorF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+@@ -1241,7 +1243,7 @@
+ if (!VidModeSwitchMode(stuff->screen, mode))
+ return BadValue;
+
+- if (xf86GetVerbosity() > 1)
++ if (xf86GetVerbosity() > DEFAULT_XF86VIDMODE_VERBOSITY)
+ ErrorF("SwitchToMode - Succeeded\n");
+ return(client->noClientException);
+ }
Modified: branches/ubuntu/debian/xserver-xfree86.postinst.in
===================================================================
--- branches/ubuntu/debian/xserver-xfree86.postinst.in 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/xserver-xfree86.postinst.in 2004-10-30 06:16:12 UTC (rev 2001)
@@ -293,32 +293,34 @@
db_subst xserver-xfree86/config/monitor/selection-method choices "Simple, Medium, Advanced"
db_subst xserver-xfree86/config/monitor/selection-method default "Medium"
- if [ -n "$HORIZ_SYNC" ] && [ -n "$VERT_REFRESH" ]; then
- # monitor frequencies detected, we set them as defaults and we switch to Advanced mode.
- # there is no need to get crazy feeding "Medium"
- db_set xserver-xfree86/config/monitor/horiz-sync "$HORIZ_SYNC"
- db_set xserver-xfree86/config/monitor/vert-refresh "$VERT_REFRESH"
- db_set xserver-xfree86/config/monitor/selection-method "Advanced"
- else
- # if we are here we did not detect the frequencies, but we have the resolution.
- # get the highest resolution.
- db_get xserver-xfree86/config/display/modes
- MAXRES=$(echo $RET | sed -e 's/,//g')
- MAXRES=$(for i in $MAXRES; do echo $i; done | sort -unr | head -n 1)
- # set a sane default for mode-list
- MAXRES="$MAXRES @ 60Hz"
- db_set xserver-xfree86/config/monitor/mode-list "$MAXRES"
- # apparently all the known resolution/horiz-sync combinantion have a ratio that
- # can go from 19 to 21. Only one exception was 18. We can safely assume a ratio of 20
- # for default setup. DDC should do the rest.
- HMAX=$(echo "$MAXRES" | cut -d "x" -f 1)
- HMAX=$(expr "$HMAX" / 20)
- # set sane defaults as fallback, in case there is no mode-list match otherwise we
- # prefer a well known match.
- db_set xserver-xfree86/config/monitor/horiz-sync "28-$HMAX"
- db_set xserver-xfree86/config/monitor/vert-refresh "43-60"
- # since we are guessing it's a good idea to set the level to Medium
- db_set xserver-xfree86/config/monitor/selection-method "Medium"
+ if [ -z "$NOPROBE" ]; then
+ if [ -n "$HORIZ_SYNC" ] && [ -n "$VERT_REFRESH" ]; then
+ # monitor frequencies detected, we set them as defaults and we switch to Advanced mode.
+ # there is no need to get crazy feeding "Medium"
+ db_set xserver-xfree86/config/monitor/horiz-sync "$HORIZ_SYNC"
+ db_set xserver-xfree86/config/monitor/vert-refresh "$VERT_REFRESH"
+ db_set xserver-xfree86/config/monitor/selection-method "Advanced"
+ else
+ # if we are here we did not detect the frequencies, but we have the resolution.
+ # get the highest resolution.
+ db_get xserver-xfree86/config/display/modes
+ MAXRES=$(echo $RET | sed -e 's/,//g')
+ MAXRES=$(for i in $MAXRES; do echo $i; done | sort -unr | head -n 1)
+ # set a sane default for mode-list
+ MAXRES="$MAXRES @ 60Hz"
+ db_set xserver-xfree86/config/monitor/mode-list "$MAXRES"
+ # apparently all the known resolution/horiz-sync combinantion have a ratio that
+ # can go from 19 to 21. Only one exception was 18. We can safely assume a ratio of 20
+ # for default setup. DDC should do the rest.
+ HMAX=$(echo "$MAXRES" | cut -d "x" -f 1)
+ HMAX=$(expr "$HMAX" / 20)
+ # set sane defaults as fallback, in case there is no mode-list match otherwise we
+ # prefer a well known match.
+ db_set xserver-xfree86/config/monitor/horiz-sync "28-$HMAX"
+ db_set xserver-xfree86/config/monitor/vert-refresh "43-60"
+ # since we are guessing it's a good idea to set the level to Medium
+ db_set xserver-xfree86/config/monitor/selection-method "Medium"
+ fi
fi
db_input low xserver-xfree86/config/monitor/selection-method || true
@@ -356,7 +358,11 @@
Medium)
db_input low xserver-xfree86/config/monitor/mode-list || true
db_go
- db_get xserver-xfree86/config/monitor/mode-list
+ if [ -n "$MAXRES" ]; then
+ RET="$MAXRES"
+ else
+ db_get xserver-xfree86/config/monitor/mode-list
+ fi
case "$RET" in
"640x480 @ 60Hz")
db_set xserver-xfree86/config/monitor/horiz-sync "28-33"
Modified: branches/ubuntu/debian/xserver-xfree86.templates
===================================================================
--- branches/ubuntu/debian/xserver-xfree86.templates 2004-10-30 06:13:56 UTC (rev 2000)
+++ branches/ubuntu/debian/xserver-xfree86.templates 2004-10-30 06:16:12 UTC (rev 2001)
@@ -438,7 +438,7 @@
Template: xserver-xfree86/config/monitor/mode-list
Type: select
-Choices: 640x480 @ 60Hz, 640x480 @ 72Hz, 800x600 @ 60Hz, 800x600 @ 72Hz, 800x600 @ 85Hz, 832x624 @ 75Hz, 1024x768 @ 60Hz, 1024x768 @ 70Hz, 1024x768 @ 75Hz, 1152x768 @ 54.8Hz, 1152x864 @ 75Hz, 1280x960 @ 60Hz, 1280x960 @ 85Hz, 1280x1024 @ 60Hz, 1400x1050 @ 60Hz, 1400x1050 @ 75Hz, 1600x1024 @ 60Hz, 1600x1200 @ 60Hz, 1600x1200 @ 75Hz, 1600x1200 @ 85Hz, 1680x1050 @ 75Hz, 1792x1344 @ 60Hz, 1792x1344 @ 75Hz, 1856x1392 @ 60Hz, 1856x1392 @ 75Hz, 1920x1440 @ 60Hz, 1920x1440 @ 75Hz, 1920x1440 @ 85Hz, 2048x1536 @ 60Hz, 2048x1536 @ 75Hz, 2048x1536 @ 85Hz
+Choices: 640x480 @ 60Hz, 640x480 @ 72Hz, 800x600 @ 60Hz, 800x600 @ 72Hz, 800x600 @ 85Hz, 832x624 @ 75Hz, 1024x768 @ 60Hz, 1024x768 @ 70Hz, 1024x768 @ 75Hz, 1152x768 @ 54.8Hz, 1152x768 @ 60Hz, 1152x864 @ 75Hz, 1280x960 @ 60Hz, 1280x960 @ 85Hz, 1280x1024 @ 60Hz, 1400x1050 @ 60Hz, 1400x1050 @ 75Hz, 1600x1024 @ 60Hz, 1600x1200 @ 60Hz, 1600x1200 @ 75Hz, 1600x1200 @ 85Hz, 1680x1050 @ 75Hz, 1792x1344 @ 60Hz, 1792x1344 @ 75Hz, 1856x1392 @ 60Hz, 1856x1392 @ 75Hz, 1920x1440 @ 60Hz, 1920x1440 @ 75Hz, 1920x1440 @ 85Hz, 2048x1536 @ 60Hz, 2048x1536 @ 75Hz, 2048x1536 @ 85Hz
Default: 1024x768 @ 60Hz
_Description: Please select your monitor's best video mode.
Choose the "best" resolution and refresh rate you believe your monitor
Reply to: