X Strike Force XFree86 SVN commit: r1836 - in trunk/debian: . local
Author: branden
Date: 2004-09-21 13:09:32 -0500 (Tue, 21 Sep 2004)
New Revision: 1836
Modified:
trunk/debian/TODO
trunk/debian/changelog
trunk/debian/local/FAQ.xhtml
Log:
Update the "xkbnewlayout" FAQ entry based on clarifications from Denis
Barbier.
Denis, please review this change and let me know if I have said anything
inaccurate or misleading.
Modified: trunk/debian/TODO
===================================================================
--- trunk/debian/TODO 2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/TODO 2004-09-21 18:09:32 UTC (rev 1836)
@@ -19,7 +19,6 @@
* Fix Xpm library stack and integer overflow vulnerabilities. (#272493; woody
security update already in progress)
-* Address BR's confusion in the new "xkbnewlayout" FAQ question.
* Fix for the nv driver breakage, consider backporting the driver from
x.org.
See: #269025, #268759, #271235, #270228, #271071
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/changelog 2004-09-21 18:09:32 UTC (rev 1836)
@@ -29,6 +29,8 @@
altwin:hyper_win. (Closes: #271259)
+ rules/xfree86.{lst,xml}: Synchronize these files.
+ Changes by Denis Barbier and Branden Robinson:
+
* Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is
it messed up now? (Closes: #259740)
@@ -42,7 +44,7 @@
* Create debian/tmp/usr/X11R6/lib/X11/doc when NOT_BUILDING_XFREE86_X_SERVER
is defined. Fixes FTBFS on s390.
- -- Branden Robinson <branden@debian.org> Sun, 12 Sep 2004 23:45:07 -0500
+ -- Branden Robinson <branden@debian.org> Tue, 21 Sep 2004 13:08:05 -0500
xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high
Modified: trunk/debian/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/local/FAQ.xhtml 2004-09-21 18:09:32 UTC (rev 1836)
@@ -2678,28 +2678,60 @@
<h3><a id="xkbnewlayout">My keyboard configuration worked with XFree86 4.2;
why is it messed up now?</a></h3>
-<p><em>Thanks to Denis Barbier for contributing this entry.</em></p>
+<p><em>Thanks to Denis Barbier for contributing much of this entry.</em></p>
-<p><em>[TODO: This entry needs to be more careful with "keymap" versus "layout"
-terminology. Also, I don't understand the first paragraph or the first sentence
-of the second paragraph. Do the mentioned "positions" have to do with shift
-levels? Also, what relationship do shift levels have with groups? —
-BR]</em></p>
+<p>Many users of the X Window System, particularly outside the United States,
+find that they need support for multiple <firstterm>groups</firstterm> 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 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>In releases previous to XFree86 4.3, combining several layouts was difficult
-because keymaps had to be defined for each position. For example,
-<code>us</code> keymap was defined on first, second and third position, and this
-should have been done for all keymaps.</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>Keymap layouts have been revisited in XFree86 4.3, and new definitions can
+<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 <firstterm>combine layouts</firstterm>.</p>
+
+<p>Prior to XFree86 4.3, combining layouts was difficult because keyboard
+symbols (<firstterm>keysyms</firstterm>) 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
+definitions for group 2 and group 3, respectively. In addition to being
+wasteful, alternative group layouts were never copied in this fashion for any
+territory except the U.S. Combining Russian and French layouts, for example,
+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>Some symbols files have not been converted to the new layout, and thus can
-not be combined with other keymaps. These are listed as
+<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
<code>$old_layouts</code> in <code
class="filespec">/etc/X11/xkb/rules/xfree86</code>. If you have trouble
combining layouts, check that you are not trying to load a layout listed
@@ -2711,14 +2743,14 @@
<code>Hyper</code>. (The fake keys are distinguished from real keys by not being
pair-oriented to the "left" or "right". Even keybords 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.) 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
-"altwin:super_win"</kbd> binds your logo keys to <code>Super</code>
-modifiers.</p>
+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 "altwin:super_win"</kbd> binds your logo keys to
+<code>Super</code> modifiers.</p>
<h2><a id="acknowledgements">Acknowledgements</a></h2>
Reply to: