diff options
| -rw-r--r-- | README.config | 198 | ||||
| -rw-r--r-- | README.enhancing | 511 | ||||
| -rw-r--r-- | compat.h | 8 |
3 files changed, 717 insertions, 0 deletions
diff --git a/README.config b/README.config new file mode 100644 index 0000000..d4d289a --- /dev/null +++ b/README.config @@ -0,0 +1,198 @@ + The XKB Configuration Guide + + Kamil Toman, Ivan U. Pascal + + 25 November 2002 + + 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. + +1. Overview + +The XKB configuration is decomposed into a number of components. Selecting +proper parts and combining them back you can achieve most of configurations +you might need. Unless you have a completely atypical keyboard you really +don't need to touch any of xkb configuration files. + +2. Selecting XKB Configuration + +The easiest and the most natural way how to specify a keyboard mapping is tu +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- +fill your needs. + +The parameters are: + + o XkbRules - files of rules to be used for keyboard mapping composition + + o XkbModel - name of model of your keyboard type + + o XkbLayout - layout(s) you intend to use + + o XkbVariant - variant(s) of layout you intend to use + + o 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). + +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): + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "pc104" + Option "XkbLayout" "us" + Option "XKbOptions" "" + EndSection + +The values of parameters XkbModel and XkbLayout are really not surprising. +The parameters XkbOptions has been explicitly set to empty set of parameters. +The parameter XkbVariant has been left out. That means the default variant +named basic is loaded. + +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 "" + +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. + +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 +german (in this order), and that you are used to Alt-Shift combination for +switching among them. + +Then the configuration snippet could look like this: + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XKbOptions" "grp:alt_shift_toggle" + EndSection + +Of course, this can be also done at runtime using utility setxkbmap. Shell +command loading the same keyboard mapping would look like: + + setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -option "grp:alt_shift_toggle" + +2.3 Even More Advanced Configuration + +Okay, let's say you are more demanding. You do like the example above but you +want it to change a bit. Let's imagine you want the czech keyboard mapping to +use another variant but basic. The configuration snippet then changes into: + + Section "InputDevice" + Identifier "Keyboard1" + Driver "Keyboard" + + Option "XkbModel" "logicordless" + Option "XkbLayout" "us,cz,de" + Option "XkbVariant" ",bksl," + Option "XKbOptions" "grp:alt_shift_toggle" + EndSection + +That's seems tricky but it is not. The logic for settings of variants is the +same as for layouts, that means the first and the third variant settings are +left out (set to basic), the second is set to bksl (a special variant with an +enhanced definition of the backslash key). + +Analogically, the loading runtime will change to: + + setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \ + -variant ",bksl," -option "grp:alt_shift_toggle" + +2.4 Basic Global Options + +See rules/*.lst files. + +3. Direct XKB Configuration + +Generally, you can directly prescribe what configuration of each of basic xkb +components should be used to form the resulting keyboard mapping. This +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? + +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 + into a suitable symbolic form + + o types - a specification of what various combinations of modifiers pro- + duce + + o key symbols - a translation of symbolic key codes into actual symbols + + o geometry - a description of physical keyboard geometry + + o 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 + +Look at the following example: + + Section "InputDevice" + Identifier "Keyboard0" + Driver "Keyboard" + + Option "XkbKeycodes" "xfree86" + 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- +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- +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. + +4. Keymap XKB Configuration + +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- +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.2 2003/02/25 19:31:02 dawes Exp $ + + +$XFree86: xc/programs/xkbcomp/README.config,v 1.3 2003/02/25 21:32:33 dawes Exp $ diff --git a/README.enhancing b/README.enhancing new file mode 100644 index 0000000..a711d72 --- /dev/null +++ b/README.enhancing @@ -0,0 +1,511 @@ + How to further enhance XKB configuration + + Kamil Toman, Ivan U. Pascal + + 25 November 2002 + + Abstract + + 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. + +1. Overview + +The developer of a new layout should read the xkb protocol specification (The +X Keyboard Extension: Protocol Specification <URL:http://www.x- +docs.org/XKB/XKBproto.pdf>) at least to clarify for himself some xkb-specific +terms used in this document and elsewhere in xkb configuration. Also it shows +wise to understand how the X server and a client digest their keyboard inputs +(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- +ment. + +Note that this document covers only enhancements which are to be made to +XFree86 version 4.3.x and above. + +2. The Basics + +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- +selves, for them it is invisible. Usually, it is started upon X server +startup. + +As you probably already know, the xkb configuration consists of five main +modules: + + 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- + 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- + bolic names (always four bytes long): + + o 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- + 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- + 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- + rately described in xkb specification) to key events. This is + also the place where LED-indicators behaviour is defined. + + Symbols + For i18n purposes, this is the most important table. It defines + what values (=symbols) are assigned to what keycodes (represented + by their symbolic name, see above). There may be defined more + than one value for each key and then it depends on a key type and + on modifiers state (respective compat component) which value will + be the resulting one. + + Geometry + 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- +directories with the same names (usually in /usr/lib/X11/xkb). + +3. Enhancing XKB Configuration + +Most of xkb enhancements concerns a need to define new output symbols for the +some input key events. In other words, a need to define a new symbol map (for +a new language, standard or just to feel more comfortable when typing text). + +What do you need to do? Generally, you have to define following things: + + o the map of symbols itself + + o the rules to allow users to select the new mapping + + o 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 +there is nothing similar you may get some ideas about basic concepts and used +tricks. + +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. + +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- +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). + +You can think of the X server's symbol table as of a irregular table where +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- +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, +page 1)) this mapping can be changed as well. + +Unlike the original X protocol the XKB approach is far more flexible. It is +comfortable to add one additional XKB term - group. You can think of a group +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 +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 + tables - groups (logically different symbol sets) + + o 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 + + o different groups of one keycode can have different number of shift lev- + els + + o the current group number is tracked by X server + +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- +defined symbol tables. To keep it fully functional you have to: + + o define all symbols only in the first group + + o (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- +cal/en/xkb/internals.html> for explanation of used xkb terms and problems +addressed by XKB extension. + +See Common notes about XKB configuration files language +<URL:http://www.tsu.ru/~pascal/en/xkb/gram-common.html> for more precise +explanation of syntax of xkb configuration files. + +4.1 Predefined XKB Symbol Sets + +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- +ride a few keys. Let's take a simple U.K. keyboard as an example (defined in +pc/gb): + + partial default alphanumeric_keys + xkb_symbols "basic" { + include "pc/latin" + + name[Group1]="Great Britain"; + + key <AE02> { [ 2, quotedbl, twosuperior, oneeighth ] }; + key <AE03> { [ 3, sterling, threesuperior, sterling ] }; + key <AC11> { [apostrophe, at, dead_circumflex, dead_caron] }; + key <TLDE> { [ grave, notsign, bar, bar ] }; + key <BKSL> { [numbersign, asciitilde, dead_grave, dead_breve ] }; + key <RALT> { type[Group1]="TWO_LEVEL", + [ ISO_Level3_Shift, Multi_key ] }; + + modifier_map Mod5 { <RALT> }; + }; + +It defines a new layout in basic variant as an extension of common latin +alphabet layout. The layout (symbol set) name is set to "Great Britain". +Then there are redefinitions of a few keycodes and a modifiers binding. As +you can see the number of shift levels is the same for <AE02>, <AE03>, +<AC11>, <TLDE> and <BKSL> keys but it differs from number of shift levels of +<RALT>. + +Note that the <RALT> key itself is a binding key for Mod5 and that it serves +like a shift modifier for LevelThree, together with Shift as a multi-key. It +is a good habit to respect this rule in a new similar layout. + +Okay, you could now define more variants of your new layout besides basic +simply by including (augmenting/overriding/...) the basic definition and +altering what may be needed. + +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. + +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 +xkb component's subdirectory. + +The most used schemes are: + + ONE_LEVEL + The key does not depend on any modifiers. The symbol from first + level is always chosen. + + 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- + 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- + italization rules are applied (and usually have no effect). + + ALPHABETIC + The key uses modifiers Shift and Lock. It may have two possible + values. The second level may be chosen by Shift modifier. When + Lock modifier applies, the symbol from the first level is taken + and further processed using system-specific capitalization rules. + If both Shift+Lock modifier apply the symbol from the first level + is taken and no capitalization rules applied. This is often + called shift-cancels-caps behaviour. + + THREE_LEVEL + Is the same as TWO_LEVEL but it considers an extra modifier - + LevelThree which can be used to gain the symbol value from the + 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- + fier is active capitalization rules are applied on the resulting + symbol. + + FOUR_LEVEL + Is the same as THREE_LEVEL but unlike LEVEL_THREE if both + Shift+LevelThree modifiers apply the symbol is taken from the + fourth level. + + FOUR_LEVEL_ALPHABETIC + Is similar to FOUR_LEVEL but also defines shift-cancels-caps + behaviour as in ALPHABETIC. If Lock+LevelThree apply the symbol + from the third level is taken and the capitalization rules are + applied. If Lock+Shift+LevelThree apply the symbol from the + third level is taken and no capitalization rules are applied. + + KEYPAD + As the name suggest this scheme is primarily used for numeric + keypads. The scheme considers two modifiers - Shift and NumLock. + If none of modifiers applies the symbol from the first level is + taken. If either Shift or NumLock modifiers apply the symbol from + the second level is taken. If both Shift+NumLock modifiers apply + the symbol from the first level is taken. Again, shift-cancels- + caps variant. + + FOUR_LEVEL_KEYPAD + 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- + Lock+LevelThree modifiers apply the symbol from the third level + is taken. This also, shift-cancels-caps variant. + +Besides that, there are several schemes for special purposes: + + 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- + 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- + 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- + fiers apply the symbol from the second level is chosen. + + SHIFT+ALT + The key uses modifiers Shift and Alt. It may have two possible + values. If only one modifier (Alt or Shift) applies the symbol + from the first level is chosen. Only if both Alt+Shift modifiers + apply the symbol from the second level is chosen. + +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- +ingly. Possible redefinitions are: + + o internal + + o internal_nocancel + + o shift + + o 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- +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- +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 +explicitly listed are NOT taken into account when the resulting shift level +is computed. If some combination is omitted the program (subroutine) should +choose the first level for this combination (a quite reasonable behavior). + +Lets consider an example with two modifiers ModOne and ModTwo: + + type "..." { + modifiers = ModOne+ModTwo; + map[None] = Level1; + map[ModOne] = Level2; + }; + +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. + +But in the case the type described as: + + type "..." { + modifiers = ModOne; + map[None] = Level1; + map[ModOne] = Level2; + }; + +the ModTwo will not be taken into account and the resulting level depends on +the ModOne state only. That means, ModTwo alone produces the Level1 but the +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- +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 +accordingly to he first modifier - and this can be the symbol from the first +as well as from the second level. + +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- +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 +whether it has been used for a shift level calculation or not. + +Any key type description can use both real and virtual modifiers. Since real +modifiers always have standard names it is not necessary to explicitly +declare them. Virtual modifiers can have arbitrary names and can be declared +(prior using them) directly in key type definition: + + virtual_modifiers <comma-separated list of modifiers> ; + +as seen in for example basic, pc or mousekeys key type definitions. + +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- +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- +gantly allow substitutions of various local configurations into predefined +templates. + +A pattern in a rules file (often located in /usr/lib/X11/xkb/rules) can be +parameterized with four other arguments: Model, Layout, Variant and Options. +For most cases parameters model and layout should be sufficient for choosing +a functional keyboard mapping. + +The rules file itself is composed of pattern lines and lines with rules. The +pattern line starts with an exclamation mark ('!') and describes how will the +xkb interpret the following lines (rules). A sample rules file looks like +this: + + ! model = keycodes + macintosh_old = macintosh + ... + * = xfree86 + + ! model = symbols + hp = +inet(%m) + microsoftpro = +inet(%m) + geniuscomfy = +inet(%m) + + ! model layout[1] = symbols + macintosh us = macintosh/us%(v[1]) + * * = pc/pc(%m)+pc/%l[1]%(v[1]) + + ! model layout[2] = symbols + macintosh us = +macintosh/us[2]%(v[2]):2 + * * = +pc/%l[2]%(v[2]):2 + + ! option = types + caps:internal = +caps(internal) + caps:internal_nocancel = +caps(internal_nocancel) + +Each rule defines what certain combination of values on the left side of +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. + +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- +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- +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- +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- +bols in appropriate variants as a default. + +4.4 Descriptive Files of Rules + +Now you just need to add a detailed description to <rules>.xml description +file so the other users (and external programs which often parse this file) +know what is your work about. + +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- +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- +verted to old format '.lst'. + +For each parameter of rules file should be described its meaning. For the +rules file described above the .lst file could look like: + + ! model + pc104 Generic 104-key PC + microsoft Microsoft Natural + pc98 PC-98xx Series + macintosh Original Macintosh + ... + + ! layout + us U.S. English + cz Czech + de German + ... + + ! option + caps:internal uses internal capitalization. Shift cancels Caps + caps:internal_nocancel uses internal capitalization. Shift doesn't cancel Caps + +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 2003/02/25 19:31:02 dawes Exp $ + + +$XFree86: xc/programs/xkbcomp/README.enhancing,v 1.3 2003/02/25 21:32:33 dawes Exp $ diff --git a/compat.h b/compat.h new file mode 100644 index 0000000..0d47b69 --- /dev/null +++ b/compat.h @@ -0,0 +1,8 @@ +/* $XFree86: xc/programs/xkbcomp/compat.h,v 1.1 2002/06/05 00:00:37 dawes Exp $ */ + +#ifndef COMPAT_H +#define COMPAT_H 1 + +extern LookupEntry groupNames[]; + +#endif /* COMPAT_H */ |