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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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