X Strike Force XFree86 SVN commit: r1832 - in trunk/debian: . local
Author: branden
Date: 2004-09-20 15:04:07 -0500 (Mon, 20 Sep 2004)
New Revision: 1832
Modified:
trunk/debian/CHANGESETS
trunk/debian/TODO
trunk/debian/local/FAQ.xhtml
Log:
Tidy up some language in the "new XKB layout" FAQ entry and identify areas
where further clarification is needed.
Modified: trunk/debian/CHANGESETS
===================================================================
--- trunk/debian/CHANGESETS 2004-09-20 12:11:14 UTC (rev 1831)
+++ trunk/debian/CHANGESETS 2004-09-20 20:04:07 UTC (rev 1832)
@@ -51,6 +51,6 @@
Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is
it messed up now? (Closes: #259740)
- 1823
+ 1823, 1832
vim:set ai et sts=4 sw=4 tw=80:
Modified: trunk/debian/TODO
===================================================================
--- trunk/debian/TODO 2004-09-20 12:11:14 UTC (rev 1831)
+++ trunk/debian/TODO 2004-09-20 20:04:07 UTC (rev 1832)
@@ -17,6 +17,7 @@
4.3.0.dfsg.1-8
--------------
+* 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/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2004-09-20 12:11:14 UTC (rev 1831)
+++ trunk/debian/local/FAQ.xhtml 2004-09-20 20:04:07 UTC (rev 1832)
@@ -150,7 +150,7 @@
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 XFree86 4.2,
+<li><a href="#xkbnewlayout">My keyboard configuration worked with XFree86 4.2;
why is it messed up now?</a></li>
</ul>
<h2><a href="#acknowledgements">Acknowledgements</a></h2>
@@ -2675,45 +2675,57 @@
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,
+<h3><a id="xkbnewlayout">My keyboard configuration worked with XFree86 4.2;
why is it messed up now?</a></h3>
-<p>In releases previous to XFree86 4.3, combining several keymaps was
-difficult because keymaps had to be defined for each position. For instance
-<code>us</code> keymap was defined on first, second and third position,
-and this should have been done for all keymaps.</p>
+<p><em>Thanks to Denis Barbier for contributing this entry.</em></p>
-<p>Keymap layouts have been revisited in XFree86 4.3, and new definitions
-can now be used in whatever order so that <code>us,ru</code> and
-<code>ru,us</code> use the same definitions. New definitions have been put
-into <code class="filespec">/etc/X11/xkb/symbols/pc/</code> and old ones are
-still available at the same place, ie. under the
-<code class="filespec">/etc/X11/xkb/symbols/</code> directory,</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>Some keymaps have not been converted to the new layout for any reason,
-and thus can not be combined with other keymaps. They are listed into
-<code class="filespec">/etc/X11/xkb/rules/xfree86</code>. If you have
-trouble combining keymaps, check that you do not try to load a keymap
-listed there.</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>Modifiers have also been affected by these major changes to make this
-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> modifiers.
-By default, <code>mod1</code> and <code>mod4<code> use these fake keys
-instead of real ones. XKB-aware applications can handle those fake
-keys, but several applications get confused and do no more recognize
-your keys as modifiers. Until these applications are fixed, you can
-bind keys explicitly with <code>altwin</code> options, e.g.
-<kbd>Option "altwin:super_win"</kbd> binds your logo keys to
-<code>Super</code> modifiers.</p>
+<p>Keymap 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
+<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
+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 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>
+
<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, and "ulisses" for their contributions to
-this document.</p>
+Dickey, Paul Gotch, Albert Cahalan, Denis Barbier, and "ulisses" for their
+contributions to this document.</p>
<hr />
<p class="x-small">$Id$</p>
Reply to: