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>
