[xorg-commit-diffs] xc/programs/xkbcomp README.config, 1.1.4.1.6.1,
1.1.4.1.6.2 README.enhancing, 1.1.4.1.6.1, 1.1.4.1.6.2
Egbert Eich
xorg-commit at pdx.freedesktop.org
Tue Apr 6 15:56:36 PDT 2004
Committed by: eich
Update of /cvs/xorg/xc/programs/xkbcomp
In directory pdx:/tmp/cvs-serv4043/programs/xkbcomp
Modified Files:
Tag: XORG-RELEASE-1
README.config README.enhancing
Log Message:
2004-04-07 Egbert Eich <eich at freedesktop.org>
* programs/Xserver/hw/xfree86/doc/sgml/defs.ent:
Fixing release/branch tag names.
Index: README.config
===================================================================
RCS file: /cvs/xorg/xc/programs/xkbcomp/README.config,v
retrieving revision 1.1.4.1.6.1
retrieving revision 1.1.4.1.6.2
diff -u -d -r1.1.4.1.6.1 -r1.1.4.1.6.2
--- a/README.config 4 Mar 2004 17:49:08 -0000 1.1.4.1.6.1
+++ b/README.config 6 Apr 2004 22:56:33 -0000 1.1.4.1.6.2
@@ -6,9 +6,9 @@
Abstract
- This document describes how to configure XFree86 XKB from a user's
- point a few. It converts basic configuration syntax and gives also
- a few examples.
+ This document describes how to configure X11R6.7.0 XKB from a
+ user's point a few. It converts basic configuration syntax and
+ gives also a few examples.
1. Overview
@@ -23,32 +23,32 @@
use rules component. As its name suggests it describes a number of general
rules how to combine all bits and pieces into a valid and useful keyboard
mapping. All you need to do is to select a suitable rules file and then to
-feed it with a few parameters that will adjust the keyboard behaviour to ful-
+feed it with a few parameters that will adjust the keyboard behaviour to ful
fill your needs.
The parameters are:
- o XkbRules - files of rules to be used for keyboard mapping composition
+ · XkbRules - files of rules to be used for keyboard mapping composition
- o XkbModel - name of model of your keyboard type
+ · XkbModel - name of model of your keyboard type
- o XkbLayout - layout(s) you intend to use
+ · XkbLayout - layout(s) you intend to use
- o XkbVariant - variant(s) of layout you intend to use
+ · XkbVariant - variant(s) of layout you intend to use
- o XkbOptions - extra xkb configuration options
+ · XkbOptions - extra xkb configuration options
The proper rules file depends on your vendor. In reality, the commonest file
-of rules is xfree86. For each rules file there is a description file named
-<vendor-rules>.lst, for instance xfree86.lst which is located in xkb configu-
-ration subdirectory rules (for example /etc/X11/xkb/rules).
+of rules is xorg. For each rules file there is a description file named <ven
+dor-rules>.lst, for instance xorg.lst which is located in xkb configuration
+subdirectory rules (for example /etc/X11/xkb/rules).
2.1 Basic Configuration
Let's say you want to configure a PC style America keyboard with 104 keys as
-described in xfree86.lst. It can be done by simply writing several lines from
-below to you XFree86 configuration file (often found as /etc/X11/XF86Config-4
-or /etc/X11/XF86Config):
+described in xorg.lst. It can be done by simply writing several lines from
+below to you xorg.conf configuration file (previously known as
+/etc/X11/XF86Config-4 or /etc/X11/XF86Config):
Section "InputDevice"
Identifier "Keyboard1"
@@ -67,18 +67,18 @@
Of course, this can be also done at runtime using utility setxkbmap. Shell
command loading the same keyboard mapping would look like:
- setxkbmap -rules xfree86 -model pc104 -layout us -option ""
+ setxkbmap -rules xorg -model pc104 -layout us -option ""
The configuration and the shell command would be very analogical for most
other layouts (internationalized mappings).
2.2 Advanced Configuration
-Since XFree86 4.3.x you can use multi-layouts xkb configuration. What does
-it mean? Basically it allows to load up to four different keyboard layouts at
-a time. Each such layout would reside in its own group. The groups (unlike
-complete keyboard remapping) can be switched very fast from one to another by
-a combination of keys.
+You can use multi-layouts xkb configuration. What does it mean? Basically it
+allows to load up to four different keyboard layouts at a time. Each such
+layout would reside in its own group. The groups (unlike complete keyboard
+remapping) can be switched very fast from one to another by a combination of
+keys.
Let's say you want to configure your new Logitech cordless desktop keyboard,
you intend to use three different layouts at the same time - us, czech and
@@ -99,7 +99,7 @@
Of course, this can be also done at runtime using utility setxkbmap. Shell
command loading the same keyboard mapping would look like:
- setxkbmap -rules xfree86 -model logicordless -layout "us,cz,de" \
+ setxkbmap -rules xorg -model logicordless -layout "us,cz,de" \
-option "grp:alt_shift_toggle"
2.3 Even More Advanced Configuration
@@ -125,7 +125,7 @@
Analogically, the loading runtime will change to:
- setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \
+ setxkmap -rules xorg -model logicordless -layout "us,cz,de" \
-variant ",bksl," -option "grp:alt_shift_toggle"
2.4 Basic Global Options
@@ -139,25 +139,25 @@
method is rather "brute force". You precisely need to know the structure and
the meaning of all of used configuration components.
-This method also exposes all xkb configuration details directly into XFree86
-configuration file which is a not very fortunate fact. In rare occasions it
-may be needed, though. So how does it work?
+This method also exposes all xkb configuration details directly into
+xorg.conf configuration file which is a not very fortunate fact. In rare
+occasions it may be needed, though. So how does it work?
3.1 Basic Components
There are five basic components used to form a keyboard mapping:
- o key codes - a translation of the scan codes produced by the keyboard
+ · key codes - a translation of the scan codes produced by the keyboard
into a suitable symbolic form
- o types - a specification of what various combinations of modifiers pro-
+ · types - a specification of what various combinations of modifiers pro
duce
- o key symbols - a translation of symbolic key codes into actual symbols
+ · key symbols - a translation of symbolic key codes into actual symbols
- o geometry - a description of physical keyboard geometry
+ · geometry - a description of physical keyboard geometry
- o compatibility maps - a specification of what action should each key pro-
+ · compatibility maps - a specification of what action should each key pro
duce in order to preserve compatibility with XKB-unware clients
3.2 Example Configuration
@@ -168,18 +168,18 @@
Identifier "Keyboard0"
Driver "Keyboard"
- Option "XkbKeycodes" "xfree86"
+ Option "XkbKeycodes" "xorg"
Option "XkbTypes" "default"
Option "XkbSymbols" "en_US(pc104)+de+swapcaps"
Option "XkbGeometry" "pc(pc104)"
Option "XkbCompat" "basic+pc+iso9995"
EndSection
-This configuration sets the standard XFree86 default interpretation of key-
-board keycodes, sets the default modificator types. The symbol table is com-
+This configuration sets the standard X server default interpretation of key
+board keycodes, sets the default modificator types. The symbol table is com
posed of extended US keyboard layout in its variant for pc keyboards with 104
keys plus all keys for german layout are redefined respectively. Also the
-logical meaning of Caps-lock and Control keys is swapped. The standard key-
+logical meaning of Caps-lock and Control keys is swapped. The standard key
board geometry (physical look) is set to pc style keyboard with 104 keys. The
compatibility map is set to allow basic shifting, to allow Alt keys to be
interpreted and also to allow iso9995 group shifting.
@@ -188,11 +188,11 @@
It is the formerly used way to configure xkb. The user included a special
keymap file which specified the direct xkb configuration. This method has
-been obsoleted by previously described rules files which are far more flexi-
+been obsoleted by previously described rules files which are far more flexi
ble and allow simpler and more intuitive syntax. It is preserved merely for
compatibility reasons. Avoid using it if it is possible.
- Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml,v 1.4 dawes Exp $
+ $Id$
-$XFree86: $
+$XFree86$
Index: README.enhancing
===================================================================
RCS file: /cvs/xorg/xc/programs/xkbcomp/README.enhancing,v
retrieving revision 1.1.4.1.6.1
retrieving revision 1.1.4.1.6.2
diff -u -d -r1.1.4.1.6.1 -r1.1.4.1.6.2
--- a/README.enhancing 4 Mar 2004 17:49:08 -0000 1.1.4.1.6.1
+++ b/README.enhancing 6 Apr 2004 22:56:33 -0000 1.1.4.1.6.2
@@ -6,7 +6,7 @@
Abstract
- This guide is aimed to relieve one's labour to create a new (inter-
+ This guide is aimed to relieve one's labour to create a new (inter
nationalized) keyboard layout. Unlike other documents this guide
accents the keymap developer's point of view.
@@ -20,21 +20,21 @@
(with and without xkb).
A useful source is also Ivan Pascal's text about xkb configuration
-<URL:http://www.tsu.ru/~pascal/en/xkb> often referenced throughout this docu-
+<URL:http://www.tsu.ru/~pascal/en/xkb> often referenced throughout this docu
ment.
Note that this document covers only enhancements which are to be made to
-XFree86 version 4.3.x and above.
+XFree86 version 4.3 and X11R6.7.0 and above.
2. The Basics
-At the startup (or at later at user's command) X server starts its xkb key-
+At the startup (or at later at user's command) X server starts its xkb key
board module extension and reads data from a compiled configuration file.
This compiled configuration file is prepared by the program xkbcomp which
behaves altogether as an ordinary compiler (see man xkbcomp). Its input are
human readable xkb configuration files which are verified and then composed
-into a useful xkb configuration. Users don't need to mess with xkbcomp them-
+into a useful xkb configuration. Users don't need to mess with xkbcomp them
selves, for them it is invisible. Usually, it is started upon X server
startup.
@@ -43,28 +43,28 @@
Keycodes
Tables that defines translation from keyboard scan codes into
- reasonable symbolic names, maximum, minimum legal keycodes, sym-
- bolic aliases and description of physically present LED-indica-
+ reasonable symbolic names, maximum, minimum legal keycodes, sym
+ bolic aliases and description of physically present LED-indica
tors. The primary sence of this component is to allow definitions
- of maps of symbols (see below) to be independent of physical key-
- board scancodes. There are two main naming conventions for sym-
+ of maps of symbols (see below) to be independent of physical key
+ board scancodes. There are two main naming conventions for sym
bolic names (always four bytes long):
- o names which express some traditional meaning like <SPCE>
+ · names which express some traditional meaning like <SPCE>
(stands for space bar) or
- o names which express some relative positioning on a key-
- board, for example <AE01> (an exclamation mark on US key-
+ · names which express some relative positioning on a key
+ board, for example <AE01> (an exclamation mark on US key
boards), on the right there are keys <AE02>, <AE03> etc.
Types
- Types describe how the produced key is changed by active modi-
- fiers (like Shift, Control, Alt, ...). There are several prede-
+ Types describe how the produced key is changed by active modi
+ fiers (like Shift, Control, Alt, ...). There are several prede
fined types which cover most of used combinations.
Compat
Compatibility component defines internal behaviour of modifiers.
- Using compat component you can assign various actions (elabo-
+ Using compat component you can assign various actions (elabo
rately described in xkb specification) to key events. This is
also the place where LED-indicators behaviour is defined.
@@ -80,7 +80,7 @@
Geometry files aren't used by xkb itself but they may be used by
some external programs to depict a keyboard image.
-All these components have the files located in xkb configuration tree in sub-
+All these components have the files located in xkb configuration tree in sub
directories with the same names (usually in /usr/lib/X11/xkb).
3. Enhancing XKB Configuration
@@ -91,11 +91,11 @@
What do you need to do? Generally, you have to define following things:
- o the map of symbols itself
+ · the map of symbols itself
- o the rules to allow users to select the new mapping
+ · the rules to allow users to select the new mapping
- o the description of the new layout
+ · the description of the new layout
First of all, it is good to go through existing layouts and to examine them
if there is something you could easily adjust to fit your needs. Even if
@@ -104,14 +104,14 @@
3.1 Levels And Groups
-Since XFree86 4.3.0 you can use multi-layout concept of xkb configuration.
-Though it is still in boundaries of xkb protocol and general ideas, the
-keymap designer must obey new rules when creating new maps. In exchange we
-get a more powerful and cleaner configuration system.
+Since XFree86 4.3.0 and X11R6.7.0 you can use multi-layout concept of xkb
+configuration. Though it is still in boundaries of xkb protocol and general
+ideas, the keymap designer must obey new rules when creating new maps. In
+exchange we get a more powerful and cleaner configuration system.
Remember that it is the application which must decide which symbol matches
which keycode according to effective modifier state. The X server itself
-sends only an input event message to. Of course, usually the general inter-
+sends only an input event message to. Of course, usually the general inter
pretation is processed by Xlib, Xaw, Motif, Qt, Gtk and similar libraries.
The X server only supplies its mapping table (usually upon an application
startup).
@@ -120,11 +120,11 @@
each keycode has its row and where each combination of modifiers determines
exactly one column. The resulting cell then gives the proper symbolic value.
Not all keycodes need to bind different values for different combination of
-modifiers. <ENTER> key, for instance, usually doesn't depend on any modi-
+modifiers. <ENTER> key, for instance, usually doesn't depend on any modi
fiers so it its row has only one column defined.
Note that in XKB there is no prior assumption that certain modifiers are
-bound to certain columns. By editing proper files (see keytypes (section 4.2,
+bound to certain columns. By editing proper files (see refnam (section 4.2,
page 1)) this mapping can be changed as well.
Unlike the original X protocol the XKB approach is far more flexible. It is
@@ -132,45 +132,45 @@
as of a vector of columns per each keycode (naturally the dimension of this
vector may differ for different keycodes). What is it good for? The group is
not very useful unless you intend to use more than one logically different
-set of symbols (like more than one alphabet) defined in a single mapping ta-
-ble. But then, the group has a natural meaning - each symbol set has its own
-group and changing it means selecting a different one. XKB approach allows
-up to four different groups. The columns inside each group are called (shift)
-levels. The X server knows the current group and reports it together with
-modifier set and with a keycode in key events.
+set of symbols (like more than one alphabet) defined in a single mapping
+table. But then, the group has a natural meaning - each symbol set has its
+own group and changing it means selecting a different one. XKB approach
+allows up to four different groups. The columns inside each group are called
+(shift) levels. The X server knows the current group and reports it together
+with modifier set and with a keycode in key events.
To sum it up:
- o for each keycode XKB keyboard map contains up to four one-dimensional
+ · for each keycode XKB keyboard map contains up to four one-dimensional
tables - groups (logically different symbol sets)
- o for each group of a keycode XKB keyboard map contains some columns -
+ · for each group of a keycode XKB keyboard map contains some columns -
shift levels (values reached by combinations of Shift, Ctrl, Alt, ...
modifiers)
- o different keycodes can have different number of groups
+ · different keycodes can have different number of groups
- o different groups of one keycode can have different number of shift lev-
+ · different groups of one keycode can have different number of shift lev
els
- o the current group number is tracked by X server
+ · the current group number is tracked by X server
-It is clear that if you sanely define levels, groups and sanely bind modi-
+It is clear that if you sanely define levels, groups and sanely bind modi
fiers and associated actions you can have simultaneously loaded up to four
different symbol sets where each of them would reside in its own group.
The multi-layout concept provides a facility to manipulate xkb groups and
-symbol definitions in a way that allows almost arbitrary composition of pre-
+symbol definitions in a way that allows almost arbitrary composition of pre
defined symbol tables. To keep it fully functional you have to:
- o define all symbols only in the first group
+ · define all symbols only in the first group
- o (re)define any modifiers with extra care to avoid strange (anisometric)
+ · (re)define any modifiers with extra care to avoid strange (anisometric)
behaviour
4. Defining New Layouts
-See Some Words About XKB internals <URL:http://www.tsu.ru/~pas-
+See Some Words About XKB internals <URL:http://www.tsu.ru/~pas
cal/en/xkb/internals.html> for explanation of used xkb terms and problems
addressed by XKB extension.
@@ -183,7 +183,7 @@
If you are about to define some European symbol map extension, you might want
to use on of four predefined latin alphabet layouts.
-Okay, let's assume you want extend an existing keymap and you want to over-
+Okay, let's assume you want extend an existing keymap and you want to over
ride a few keys. Let's take a simple U.K. keyboard as an example (defined in
pc/gb):
@@ -221,11 +221,11 @@
4.2 Key Types
-The differences in the number of columns (shift levels) are caused by a dif-
-ferent types of keys (see the types definition in section basics). Most key-
-codes have implicitly set the keytype in the included "pc/latin" file to
-"FOUR_LEVEL_ALPHABETIC". The only exception is <RALT> keycode which is
-explicitly set "TWO_LEVEL" keytype.
+The differences in the number of columns (shift levels) are caused by a dif
+ferent types of keys (see the types definition in section basics). Most key
+codes have implicitly set the keytype in the included 'pc/latin' file to
+'FOUR_LEVEL_ALPHABETIC'. The only exception is <RALT> keycode which is
+explicitly set 'TWO_LEVEL' keytype.
All those names refer to pre-defined shift level schemes. Usually you can
choose a suitable shift level scheme from default types scheme list in proper
@@ -239,10 +239,10 @@
TWO_LEVEL
The key uses a modifier Shift and may have two possible values.
- The second level may be chosen by Shift modifier. If Lock modi-
+ The second level may be chosen by Shift modifier. If Lock modi
fier (usually Caps-lock) applies the symbol is further processed
using system-specific capitalization rules. If both Shift+Lock
- modifier apply the symbol from the second level is taken and cap-
+ modifier apply the symbol from the second level is taken and cap
italization rules are applied (and usually have no effect).
ALPHABETIC
@@ -260,7 +260,7 @@
third level. If both Shift+LevelThree modifiers apply the value
from the third level is also taken. As in TWO_LEVEL, the Lock
modifier doesn't influence the resulting level. Only Shift and
- LevelThree are taken into that consideration. If the Lock modi-
+ LevelThree are taken into that consideration. If the Lock modi
fier is active capitalization rules are applied on the resulting
symbol.
@@ -286,10 +286,10 @@
caps variant.
FOUR_LEVEL_KEYPAD
- Is similar to KEYPAD scheme but considers also LevelThree modi-
+ Is similar to KEYPAD scheme but considers also LevelThree modi
fier. If LevelThree modifier applies the symbol from the third
level is taken. If Shift+LevelThree or NumLock+LevelThree apply
- the symbol from the fourth level is taken. If all Shift+Num-
+ the symbol from the fourth level is taken. If all Shift+Num
Lock+LevelThree modifiers apply the symbol from the third level
is taken. This also, shift-cancels-caps variant.
@@ -297,18 +297,18 @@
PC_BREAK
It is similar to TWO_LEVEL scheme but it considers the Control
- modifier rather than Shift. That means, the symbol from the sec-
+ modifier rather than Shift. That means, the symbol from the sec
ond level is chosen by Control rather than by Shift.
PC_SYSRQ
- It is similar to TWO_LEVEL scheme but it considers the Alt modi-
+ It is similar to TWO_LEVEL scheme but it considers the Alt modi
fier rather than Shift. That means, the symbol from the second
level is chosen by Alt rather than by Shift.
CTRL+ALT
The key uses modifiers Alt and Control. It may have two possible
values. If only one modifier (Alt or Control) applies the symbol
- from the first level is chosen. Only if both Alt+Control modi-
+ from the first level is chosen. Only if both Alt+Control modi
fiers apply the symbol from the second level is chosen.
SHIFT+ALT
@@ -319,27 +319,27 @@
If needed, special caps schemes may be used. They redefine the standard
behaviour of all *ALPHABETIC types. The layouts (maps of symbols) with keys
-defined in respective types then automatically change their behaviour accord-
+defined in respective types then automatically change their behaviour accord
ingly. Possible redefinitions are:
- o internal
+ · internal
- o internal_nocancel
+ · internal_nocancel
- o shift
+ · shift
- o shift_nocancel
+ · shift_nocancel
None of these schemes should be used directly. They are defined merely for
'caps:' xkb options (used to globally change the layouts behaviour).
-Don't alter any of existing key types. If you need a different behaviour cre-
+Don't alter any of existing key types. If you need a different behaviour cre
ate a new one.
4.2.1 More On Definitions Of Types
-When the XKB software deals with a separate type description it gets a com-
-plete list of modifiers that should be taken into account from the 'modi-
+When the XKB software deals with a separate type description it gets a com
+plete list of modifiers that should be taken into account from the 'modi
fiers=<list of modifiers>' list and expects that a set of 'map[<combination
of modifiers>]=<list of modifiers>' instructions that contain the mapping for
each combination of modifiers mentioned in that list. Modifiers that are not
@@ -355,7 +355,7 @@
map[ModOne] = Level2;
};
-In this case the map statements for ModTwo only and ModOne+ModTwo are omit-
+In this case the map statements for ModTwo only and ModOne+ModTwo are omit
ted. It means that if the ModTwo is active the subroutine can't found
explicit mapping for such combination an will use the default level i.e.
Level1.
@@ -373,7 +373,7 @@
combination ModOne+ModTwo produces the Level2 as well as ModOne alone.
What does it mean if the second modifier is the Lock? It means that in the
-first case (the Lock itself is included in the list of modifiers but combina-
+first case (the Lock itself is included in the list of modifiers but combina
tions with this modifier aren't mentioned in the map statements) the internal
capitalization rules will be applied to the symbol from the first level. But
in the second case the capitalization will be applied to the symbol chosen
@@ -383,7 +383,7 @@
Usually, all modifiers introduced in 'modifiers=<list of modifiers>' list are
used for shift level calculation and then discarded. Sometimes this is not
desirable. If you want to use a modifier for shift level calculation but you
-don't want to discard it, you may list in 'preserve[<combination of modi-
+don't want to discard it, you may list in 'preserve[<combination of modi
fiers>]=<list of modifiers>'. That means, for a given combination all listed
modifiers will be preserved. If the Lock modifier is preserved then the
resulting symbol is passed to internal capitalization routine regardless
@@ -401,12 +401,12 @@
4.3 Rules
Once you are finished with your symbol map you need to add it to rules file.
-The rules file describes how all the five basic keycodes, types, compat, sym-
+The rules file describes how all the five basic keycodes, types, compat, sym
bols and geometry components should be composed to give a sensible resulting
xkb configuration.
The main advantage of rules over formerly used keymaps is a possibility to
-simply parameterize (once) fixed patterns of configurations and thus to ele-
+simply parameterize (once) fixed patterns of configurations and thus to ele
gantly allow substitutions of various local configurations into predefined
templates.
@@ -423,7 +423,7 @@
! model = keycodes
macintosh_old = macintosh
...
- * = xfree86
+ * = xorg
! model = symbols
hp = +inet(%m)
@@ -446,26 +446,26 @@
equal sign ('=') results in. For example a (keyboard) model macintosh_old
instructs xkb to take definitions of keycodes from file keycodes/macintosh
while the rest of models (represented by a wild card '*') instructs it to
-take them from file keycodes/xfree86. The wild card represents all possible
-values on the left side which were not found in any of the previous rules.
-The more specialized (more complete) rules have higher precedence than gen-
-eral ones, i.e. the more general rules supply reasonable default values.
+take them from file keycodes/xorg. The wild card represents all possible val
+ues on the left side which were not found in any of the previous rules. The
+more specialized (more complete) rules have higher precedence than general
+ones, i.e. the more general rules supply reasonable default values.
As you can see some lines contain substitution parameters - the parameters
preceded by the percent sign ('%'). The first alphabetical character after
the percent sign expands to the value which has been found on the left side.
For example +%l%(v) expands into +cz(bksl) if the respective values on the
-left side were cz layout in its bksl variant. More, if the layout resp. vari-
+left side were cz layout in its bksl variant. More, if the layout resp. vari
ant parameter is followed by a pair of brackets ('[', ']') it means that xkb
-should place the layout resp. variant into specified xkb group. If the brack-
+should place the layout resp. variant into specified xkb group. If the brack
ets are omitted the first group is the default value.
So the second block of rules enhances symbol definitions for some particular
-keyboard models with extra keys (for internet, multimedia, ...) . Other mod-
-els are left intact. Similarly, the last block overrides some key type defi-
+keyboard models with extra keys (for internet, multimedia, ...) . Other mod
+els are left intact. Similarly, the last block overrides some key type defi
nitions, so the common global behaviour ''shift cancels caps'' or ''shift
doesn't cancel caps'' can be selected. The rest of rules produces special
-symbols for each variant us layout of macintosh keyboard and standard pc sym-
+symbols for each variant us layout of macintosh keyboard and standard pc sym
bols in appropriate variants as a default.
4.4 Descriptive Files of Rules
@@ -477,10 +477,10 @@
4.4.1 Old Descriptive Files
The formerly used descriptive files were named <rules>.lst Its structure is
-very simple and quite self descriptive but such simplicity had also some cav-
+very simple and quite self descriptive but such simplicity had also some cav
ities, for example there was no way how to describe local variants of layouts
and there were problems with the localization of descriptions. To preserve
-compatibility with some older programs, new XML descriptive files can be con-
+compatibility with some older programs, new XML descriptive files can be con
verted to old format '.lst'.
For each parameter of rules file should be described its meaning. For the
@@ -505,7 +505,7 @@
And that should be it. Enjoy creating your own xkb mapping.
- Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Enhancing.sgml,v 1.2 dawes Exp $
+ $Id$
-$XFree86: $
+$XFree86$
More information about the xorg-commit-diffs
mailing list