X keyboard extension

X KeyBoard 拡張 (XKB) はキーボードのコードを X でどうやって管理するかを定義して、内部変換表を使えるようにします。X で複数のキーボードレイアウトが利用できるようにしている基本的な仕組みです。

ある程度の実践がないと XKB を理解するのは厳しいので、このページではまず XKB でキーマップを変更する方法を説明します。XKB の全ての機能を網羅したコンプリートガイドではありません。厄介なところはすっとばして、実用的なことを先に紹介します。

キーボードを設定するシンプルな方法を探してここに辿り着いた場合は、まず最初に Xorg でのキーボード設定を見てください。

訳注：このページは基本的には X KeyBoard extension - Arch Wiki の翻訳ですが、扱っている機能が言語に依存するものであり適宜日本語ユーザーに必要と思われる補足を入れていくことにします。

用心と準備

XKB を弄っていると、キーボードの特定のキーが現在の X セッションで使えなくなってしまう可能性があります (そしてそれはよくあることです)。使えなくなるキーというのは、修飾キーや方向キー、エンターキー、あるいは C-A-Backspace や C-A-Fx などのキーの組み合わせも含まれます。キーボードを使わなくてもセッションを終了できる何らかの手段を確保してください。

非常に稀ですが、XKB の設定を変更することで X サーバーがフリーズしたりクラッシュすることもあります。対処できるように用意してください。X を killall したりリモートからホストを再起動できるようになっていれば安心です。

xxkb や他のレイアウト変更アプリケーションを停止してください。xxkb は頻繁に XKB の状態を変更します。xxkb を有効にしながら両方を操るのは大変です。

最後に、警告をしておきます: カスタムレイアウトに慣れるのはとても簡単です。

XKB レイアウトの取得と設定

ルールを使う

/usr/share/X11/xkb/rules/ の中の *.lst ファイルや XKB のホームページ にルールの設定方法が載っています。あなたの設定は /etc/X11/xorg.conf.d/ に保存することができます。

例えば Caps Lock キーを Escape にリマップしたい場合:

90-custom-kbd.conf

Section "InputClass"
    Identifier "keyboard defaults"
    MatchIsKeyboard "on"

    Option "XKbOptions" "caps:escape"
EndSection

キーマップを使う (廃止予定にて非推奨*)

• 訳注：非推奨と言いながらこのページはほとんどキーマップを用いたキーカスタマイズに関する話です。

(xorg-xkbcomp パッケージに入っている) xkbcomp を使って XKB のデータを操作します。現在の設定を確認するには、次を実行:

$ xkbcomp $DISPLAY output.xkb

サーバーにデータをアップロードするには、次を実行:

$ xkbcomp input.xkb $DISPLAY

$DISPLAY 引数を付けないと xkbcomp は .xkb ファイルから (ほとんど役に立たない) .xkm ファイルへのコンパイルを始めるので注意してください。サーバーには何もアップロードされません。ただし、構文のチェックが行われてエラーを報告してきます。

レイアウトの用意ができたら、~/.Xkeymap として保存して ~/.xinitrc から起動時にロードするようにしてください:

$ test -f ~/.Xkeymap && xkbcomp ~/.Xkeymap $DISPLAY

実際のファイル名は何でもかまいません。システム全体で共通の設定である xorg.conf とは違って、ユーザー個別のキーマップになります。さらに、X が実行している間に XKB 設定を変更しても全く問題ありません。

XKB の基本的な情報

XKB のコア機能はとても単純です。キーマップを使い始める前に、仕組みについてある程度知る必要があります。

ツールと値

キーコードを取得したりキーマップが問題ないか確認するときは (xorg-xev パッケージに入っている) xev を使います。出力例:

KeyPress event, serial 45, synthetic NO, window 0x2200001,
    root 0xad, subw 0x0, time 183176240, (796,109), root:(867,413),
    state 0x1, keycode 21 (keysym 0x2b, plus), same_screen YES,
    XLookupString gives 1 bytes: (2b) "+"
    XmbLookupString gives 1 bytes: (2b) "+"
    XFilterEvent returns: False

keycode 21, state 0x1, keysym 0x2b, plus に着目してください。keycode 21 は入力デバイスが X に送信した値で、物理的なキーのインデックスです。state は修飾キーを表しており、0x01 は Shift です。キーコードと状態の値は XKeyEvent(3) で X からアプリケーションに送信されます。キーシムと対応する文字は、クライアントが XLookupString(3) などを使って取得します。

state フィールドのビットはあらかじめ名前が定義されています: 下から Shift, Lock, Control, Mod1, Mod2, Mod3, Mod4, Mod5 です。従って、Ctrl+Shift は 0x05 となります。クライアントアプリケーションは基本的に必要なビットしか確認しません。そのため通常のキーボード入力でアプリケーションを使うときに Ctrl+key ショートカットは Control と Control+Mod3 を区別しないのが普通です。

キーシムも数字です。/usr/include/X11/keysymdef.h で KP_ によって定義されているように、ほとんどに名前が付けられています。ただし、数字はクライアントが実際に受け取るものです。方向キーや Enter、Backspace や F キー、あるいは様々なショートカットなど、アプリケーションが特定の値を使うときだけキーシムは意味を持ちます。他の場合は、文字が使われます。

キーコードの翻訳

XKB は多くの場合 XLookupString ステージで動きます。 XLookupString ステージでは入力されたキーコードがその内部状態にもとづきキーシムに変換されます。 ここで内部状態とはグループ（group）および状態（state）の値の対のことです。

(keycode, group, state) → keysym

ここでのグループは典型的には US-EnglishだとかFrench-AZWERTY, ロシア語、ギリシャ語などといった「レイアウト」 情報を表しています。 グループは最大で４種類の値を持つことができます.

内部的には、上述の変換は以下の様な追加のステップから構成されています:

(keycode [, group]) → type
(state, type) → level
(keycode, group, level) → S[keycode][group][level]

ここで S は変換表です（実際には以下に述べるxkb_symbolsを呼び出しています)。

型(Types)はどの修飾子がどのキーに影響を及ぼしているかの情報を含んでいます（ここで修飾子およびキーは一般に複数です）;　 基本的にはこれがSの三次元目の変数 level の範囲を狭める方法です。　 例えば, 典型的な英数キーはShiftキーのみから影響を受けます。; その場合型はTWO_LEVELにセットされ,

(state, TWO_LEVEL) → level = ((state >> 0) & 0x01) = state & 0x01

となり、レベルは0または1となります。 したがって、このケースの変換表はS[keycode][0..4][0..1]となりシフトキーを押さない場合のS[keycode][0..4][0..256]よりも狭まります。

キーシムと状態

X termsでは, aおよびCtrl+aは状態は異なるがキーシムは同じです。 一方aおよびAはキーシム自体が異なっています.

XKBのタスクとしてはキーシムの変換のみを行い、 状態自体は個々のアプリケーションにおける後段処理で扱うということが一般的です。

また、XKB における状態は幾分遅れて作用します。 つまり、それはユーザーがキーを押す前に状態をセットしておかなくてはならないということです。

例: Ctrl+hrxvt内のアプリケーション設定によってはバックスペースとして機能するようにできます。 この場合、rxvtはControlのビットが値としてセットされた状態と同時にhキーシムを受け取ります。 これはBackspaceキーシムと明らかに異なるものです。 それとは違って、XKBを使えばCtrl+hの組み合わせからControlビットを値として持つ状態とともにBackspaceキーシムを生成することができます。 この場合、 rxvtはCtrlキーが押されている限り物理的なBackspaceキーとhキーを異なるキーとして区別することができません。 XKBを用いてCtrl+hの組み合わせからControlビットが設定されていないBackspaceキーシムを生成することもできますが、 それはControl+Backspaceを実装するよりも難しいです。

アクション

上述の変換表から得られたキーシムはなにがしかのアクションを引き起こすことができます。

(keysym, state) → action

XKBにおいては、修飾ビットの設定およびロックは、コンソールのスイッチングやサーバーの終了、ポインターの移動などのあらゆるXサーバー上のインタラクションと同様の意味で、アクションなのです。 アクションは一般にはキーシムに影響を及ぼしませんし、キーシムを生成することはアクションではありません。

(keysym, state)ペア一つにつき一つだけ可能なアクションが一つだけ存在します。

レイアウトの編集

まずはサーバーのデフォルト設定から始めます。できるかぎり、少しずつ変更を加えてテストするようにしてください。

xkbcomp によって生成される .xkb ファイルはシンプルなテキストファイルです。C++ 風のコメント (// で行末までコメントにする) が使えます。xkb_keycodes の "name-here" にあるように、セクション名はこの段階ではあまり意味がないので省いてもかまいません。

xkb_keycodes

キーコードの定義。ファイルの残りの部分では数字のキーコードは使わず、このセクションで定義した記号のキーラベルだけを用います。

It's a good idea to leave only those keys the keyboard in question actually has here.

試訳：実際に問題となるキーのみを残しておくと言うのは良いアイデアです（この一文は原文から意味を取りづらいですが、以下のような状況をさしてアドバイスしている可能性があると考えました。例えば evdev を見るとF24キーに相当する<FK24>が有りますが、たいていのキーボードにはそこまで高い番号のファンクションキーは無いので後段の　xkb_symbols でキーシムが設定されず xkbcomp で対応するキーシムがないと言う無害な警告がたくさん出てきます。この段階で消しておけばそのような実際には意味のない警告に悩まされずにすむということだろうと思います。）。

ラベル自体は任意です。後ろに続くの xkb_symbols セクションではこれらのラベルのみが使用されます。

xkb_types

このセクションは xkb_symbols の前にあります（すなわちより低レイヤーということです）。したがって英数キーで閉じた使い方をするときは見るだけにとどめて、変更はしないほうが賢明でしょう（訳注：しかしながらシフトとCapsLockで大文字小文字が切り替わる英数キーのような典型的なタイプ以外のものを使用したい場合は自分で書く必要があります。）。 標準的なタイプは後述の仮想修飾キーにその多くを依存しています。 今のところ、あなたが必要なタイプを探すに留めるようにしてください。 まずは次のタイプからはじめましょう：ONE_LEVEL, TWO_LEVEL, ALPAHBETIC。

ONE_LEVEL キーは修飾キーの影響を受けません：典型的なものを挙げると、エンター、スペース、Fキー、 Shift/Alt/Ctrl キーなどです。. TWO_LEVEL及びALPHABETICキーはシフトの状態に依存して異なるキーシムを生成します。 全ての英数キーこのようにShiftの影響を受けます. ALPHABETICタイプは更にCapsLockの影響を受けます。

タイプの記述自身は極めてシンプルです。次の行

modifiers= Shift+NumLock+LevelThree;

はこのタイプがShiftとNumLockそしてLevelThreeのビットのみの影響を受けることを意味しています。 マップ行

map[Shift+LevelThree]= Level4;

はどの組み合わせがどのレベルに対応するかを定義しています。 xkbcomp はデータを「LevelN」という表記をデータをダンプするときに遣いますが、 より短くて便利な「N」という表記もよく使われます。 level_name行は重要ではなく無視することができます。

xkb_compatibility

このセクションではとりわけ、アクションの定義 (interpret) 及びキーボードについているLED(indicator)を扱います。 持っていないものや使用しないもの、例えばキーパッドアクションやマウスコントロールや追加修飾キーなど、は削除してしまっても構いません。

key+AnyOfOrNone(all)は単にkeyと同等ですが、keyのほうがはるかに読みやすいということに注意しましょう。

もし必要であればグループの切り替えをチェックしましょう. LockGroup(group=N)はもしあなたがグループを4つもっているのならば有用でしょう。 そうでないのならばISO_Next_Group/ISO_Prev_Groupで十分です（グループが3つ以下の場合全てのグループは他のグループに隣接しています）。 LatchGroupは普通でないセットアップでは役に立つかもしれません.

xkb_symbols

それぞれのキーが何をするのか定義するメインセクションです。構文:

key <LABL> { [ G1L1, G1L2, G1L3, ... ], [ G2L1, G2L2, G2L3, ... ], ... }

<LABL>はxkb_keycodesセクションで定義されたキーラベルであり、GiLjはグループ i レベル j の時のキーシムです。 それぞれのグループにおけるキーシムの数はタイプ定義におけるレベルの数と一致しなくてはなりません(もしうまく設定されていない場合はxkbcompが警告を出すでしょう)。

使用可能なキーシムの一覧は/usr/include/X11/keysymdef.hを見ればわかります。 またkeysymdef.hにリストアップされているものとは別に、ユニコードシンボルに対してはUnnnn（nnnn は16進数）という表記を使用できます。 例えばU0301を鋭アクセントの付与に使用できます。 aとU0061は別物として扱われます(例えば, 殆どのアプリケーションは Ctrl+U0061ではなくCtrl+aが送信されてくることを期待します。なぜならそれらの持つ数値的な値が異なるからです。

キーのタイプはここで決定することもできます。その場合２つの記法があり、ひとつは

key.type = "T1";
key <...> { ... };
key <...> { ... };
key <...> { ... };
key.type = "T2";
key <...> { ... };
key <...> { ... };

のように複数のキーにまとめて適用するものであり、もうひとつはそれぞれのキーのみに適用するものです:

key <...> { type = "T", [ .... ], [ .... ] };

グループごとに異なるタイプを適用することができます。 この仕様はコンピュータにとっては直感に反しますが、実際問題としては有用な応用があります。 グループごとにタイプを設定するには以下の記法を用います:

key <...> { type[1] = "T1", type[2] = "T2", [ ... ], [ ... ] };

また、グループのタイプの違いなどを記憶しやすくするために、グループに対するラベルを以下のような記法で定義することができます。

name[1] = "EN";     // group 1
name[2] = "RU";     // group 2
name[3] = "UA";     // group 3

ここでラベルが定義されていれば xxkb でそれを見ることができます。 このセクションはまたmodifier_map行を含みます。 今はこれらの行はそっとしておいて、後述の仮想モディファイヤをチェックしてください。

xkb_geometry

（訳注：キーボード設定をソフトウェア的にいじると言う目的のためには）完全に関係のない物理的キーボードレイアウトを記述するセクションです。何の影響を受けることもなく削除してしまうことができます。

基本的なサンプル

既存のレイアウトに多くの一般的なキーに対する標準的な定義が含まれていると考えられるので、まずあなたの環境にすでに存在するレイアウトを確認しましょう。

この文書に登場する「xkb_keycods { text }」は「text」がxkb_keycodesセクションで追加されているべきことを意味します。 文脈から明らかな場合、セクション名は省略されます。

単一のキーの割り当て

特別な (マルチメディア) キーを有効にする:

xkb_keycodes {
    <VOL-> = 122;       // check with xev
    <VOL+> = 123;
}
   
xkb_symbols {
    key.type = "ONE_LEVEL";
    key <VOL-> { [ XF86AudioLowerVolume ] };
    key <VOL+> { [ XF86AudioRaiseVolume ] };
}

CapsLock で Escape、主に Vimer 向け:

key.type = "ONE_LEVEL";
key <CAPS> { [ Escape ] };

Ins と PrintScreen を交換する (両者が入れ替わっている場合 — Dell のノートパソコンのキーボードなど):

key.type = "ONE_LEVEL";
key <IN?>  { [    Print ] };
key <PRSC> { [   Insert ] };

HP のノートパソコンのキーボードでは、上記は上手くいかないことがあります。代わりに、キーコード自体を再定義してください:

partial xkb_keycodes "insert" {
    alias <I118> = <IN?>;
    <INS>  = 218;
    <I218> = 118;
};

Shift をスティッキーキーに変えるには以下を:

key <LFSH> {         [         Shift_L ] };

以下のように置き換えます:

key <LFSH> {         [         ISO_Level2_Latch ] };

複数のレイアウト

通常の英数キーに対しては、単に2/3/4番目の [] セクションをキー定義に加えるだけにしましょう。

key.type = "ALPHABETIC";
key <AD01> { [ q, Q ], [ a, A ] };      // QWERTY-AZERTY

key <AC02> { [        s,        S ],        // two cyrillic layouts
             [    U044B,    U042B ],
             [    U0456,    U0406 ] };

レイアウトの切り替えはLockGroupアクションによって引き起こすことができます。

interpret ISO_Next_Group { action = LockGroup(group=+1); };
interpret ISO_Prev_Group { action = LockGroup(group=-1); };

典型的には、これはキーシム ISO_Next_Group 及び ISO_Prev_Group をグループあるいはレベルの変更にもちいるということを意味します。

グループは循環するのでもし２つのグループが存在するときに ISO_Next_Group を２回を押すと元のグループに戻ってくることになるということを記しておきます。

２つ以上のレイアウトの循環的な切り替えに特化したキーの設定例：

key.type = "ONE_LEVEL";
key <RWIN> { [ ISO_Next_Group ] }

もし２つ以上のレイアウトを使用していて使わないキーがあるのなら、そのキーをレイアウトを切り替える専用のキーにしてしまうのがよいでしょう。 以下に３つのレイアウトが存在する場合を示します：

key.type = "ONE_LEVEL";
key <RCTL> { [ ISO_Next_Group ],    // g1: switch to g2
             [ ISO_Prev_Group ],    // g2: switch back to g1
             [ ISO_Prev_Group ] };  // g3: switch to g2

key <MENU> { [ ISO_Prev_Group ],    // g1: switch to g3
             [ ISO_Next_Group ],    // g2: switch to g3
             [ ISO_Next_Group ] };  // g3: switch back to g1

４つのレイアウトを使用する場合にはほとんどの場合 ISO_First_Group 及び ISO_Last_Group を使う必要があるでしょう。

同様のアイデアは以下のようにひとつのキーをTWO_LEVELタイプで使用することによっても実現できます：

key.type = "TWO_LEVEL";
key <MENU> { [ ISO_Next_Group, ISO_Prev_Group ],   
             [ ISO_Prev_Group, ISO_Next_Group ],   
             [ ISO_Prev_Group, ISO_Next_Group ] }; 

この方法は「Menu」をグループ２のために「Shift Menu」をグループ３のために割り当てるというものです（訳注：対称性にかけるので年のために記しておくとグループ２の時に「Menu」を押すとグループ１に戻り、レイアウト３の時に「Shift Menu」を押すとグループ１に戻るというようになっている。）。 CtrlやAltをShiftの代わりに使用するには TWO_LEVELタイプをPC_CONTROL_LEVEL2タイプやPC_ALT_LEVEL2タイプにそれぞれ置き換えれば良い.

複数の修飾キー（例えば Shift + Sfhift, Ctrl + Shift など）を用いてグループやレイアウトの切り替えを行うことは、 それらのキーに対する ONE_LEVEL の設定とは異なる別の方法によって実現される。 以下にShift + Shift の例を示す。:

key.type = "TWO_LEVEL";
key <LFSH> { [ Shift_L, ISO_Prev_Group ] };
key <RTSH> { [ Shift_R, ISO_Next_Group ] };

グループのラッチ（別名トグル：キーを押し続けている時に限りセットされる）するには、大抵の場合 ISO_Group_Latch キーシムにバインドされている ]LatchGroupアクションを使用する：

key <RCTL> { [ ISO_Group_Latch ] }

正しいグループに設定するには xkb_compatibility セクションで ISO_Group_Latch の定義を調整しておきましょう。

interpret ISO_Group_Latch { action = LatchGroup(group=3); };

標準的な例についてもっとたくさん知るには /usr/share/X11/xkb/symbols/group をチェックしましょう。

Additional symbols

一つのキーでよりたくさんのキーシムを打ち込めるようにします。

コンポーズキー

一般的なユニコード文字を入力する非常に簡単で極めて使い勝手の良い設定です（訳注：コンポーズキーについては修飾キー - Wikipedia#アクセント符号の入力[編集 ]、Compose key - Wikipedia を参考のこと）。

key <RALT> { [ Multi_key] };

Level3

考え方は Alt キーや AltGr キーの本来の意味と同じものです。 つまり、ある修飾キーが押されている状態で英数キーを押すとその英数キーだけでは直接入力できない付加的な文字が入力できるようになるというものです。

まず第一に、修飾キーを設定しましょう。

xkb_symbols { 
    key <LWIN> { [ISO_Level3_Shift ] };
    modifier_map Mod5 { ISO_Level3_Shift };
}

以下の定義は関係するセクションですでに定義されているはずですが、もしされていなければこれらも以下のように定義しましょう：

xkb_compatibility {
    interpret ISO_Level3_Shift { action= SetMods(modifiers=Mod5); };
}
   
xkb_types {
    type "THREE_LEVEL" {
        modifiers= Shift+Mod5;
        map[Shift]= Level2;
        map[Mod5]= Level3;
        map[Shift+Mod5]= Level3;
        level_name[Level1]= "Base";
        level_name[Level2]= "Shift";
        level_name[Level3]= "Level3";
    };
    type "FOUR_LEVEL" {
        modifiers= Shift+LevelThree;
        map[Shift]= Level2;
        map[LevelThree]= Level3;
        map[Shift+LevelThree]= Level4;
        level_name[Level1]= "Base";
        level_name[Level2]= "Shift";
        level_name[Level3]= "Alt Base";
        level_name[Level4]= "Shift Alt";
    };
}

注：xkb_compatibility 及び xkb_types の標準的な定義では Mode5 の代わりに LevelThree が用いられています。 上記の modifier_map が Mod5 を使う限り、使用上の違いはなく、結局 Mod5 のビットを（レベル３のビットとして）使うということです。

今度は、vi-スタイルのカーソル割り当てをキーそれ自身に行う設定例を示します：

key.type = "THREE_LEVEL";
key <AC06> { [ h, H,  Left ] };
key <AC07> { [ j, J,  Down ] };
key <AC08> { [ k, K,    Up ] };
key <AC09> { [ l, L, Right ] };

xev を用いて確認してみればわかるとおり、この設定のもとで Mod5+h を押すと純粋な左キーではなくて「Mod5+左キー」が生成されます。 しかし、ほとんどのアプリケーションは自分自身が使用しない state ビットは無視するので問題ありません。 state ビットに痕跡を残さずに キーコードを変更する方法に関しては後述する Overlay を見てください。

Meta, Super, Hyper

Real modifiers

いくつかのアプリケーション（特に emacs）では高次の state ビットを有意義に使うことが可能になっています。 Emacs の場合では Shift, Ctrl, Alt とは別に Meta, Super, Hyper と呼ばれる修飾キーが state ビットをコントロールするものとして存在することが仮定されています。

XKBの観点からはこれは Mod2, Mod3, Mod4, Mod5 のビットに関する設定がなされているのと同じことです。 なぜならこのようなアプリケーションを使用する場合は上述の Level3 の例の時のように type を編集する必要はなく、 ただビット自身が送信されるようにすれば良いからです。

xkb_compatibility {
    interpret Super_L { action = SetMods(modifiers=Mod3); };
}

xkb_symbols {
    key <LWIN> { [ Super_L ] };
    modifier_map Mod3 { Super_L };
}

xkb_compatibilityの標準的な定義においては Mod3 の代わりに Super モディファイヤが使用されます。 その定義をそのままにしておきつつこれらのキーを使用するにはただ、modifier_mapを然るべき場所に書けばよいのです。

名前のついた修飾キー ― つまり Super, Hyper あるいは Alt でさえ ― ModN 都の間に厳密な対応関係は存在しないということを心にとどめておいてください。 唯一広く使われるのは Mod1 で、あるアプリケーションはこれを Meta とよび、またあるキーはこれを Alt を呼びます。 それ以外のことに関しては個々のアプリケーションが state ビットをどのように扱うかを調べるか、 以下に述べる仮想キーに関する記述を参考にするか、あるいはその両方を試してください。

Keysym tracking

世の中には Meta_[LR] や Super_[LR], Hyper_[LR] キーを state ビットの変化ではなくキーシムの KeyPress/KeyRelease イベントをトラックするアプリケーションが存在することが知られています（openboxとか）。 このようなケースには

xkb_symbols {
    key <LWIN> { [ Super_L ] };
}

という記述で十分でユーザーはinterpret行及びmodifier_map行の記述を省略できます。

注：Openbox に関して言えば、両方の方法が可能になっています： "S-h"という設定では Super_[LR] イベントをトラックする一方で "Mod3-h" の場合は関連する state ビットをチェックします。

プリセット設定

XKB は大抵 /etc/X11/xorg.conf や /etc/X11/xorg.conf.d/*.conf などで以下のように XkbTypes/XkbCompat/XkbSymbols, XkbModel/XkbLayout (+XkbVariant/XkbOptions), XkbKeymap を指定することで設定されています:

Option  "XkbModel"    "thinkpad60"                                                                                                  
Option  "XkbLayout"   "us,sk,de"                                                                                                    
Option  "XkbVariant"  "altgr-intl,qwerty,"                                                                                          
Option  "XkbOptions"  "grp:menu_toggle,grp_led:caps"        

上記の設定で /usr/share/X11/xkb の複数のファイルが組み合わされて完全な XKB マップが定義されます (xkbcomp で dump できます)。実際に、setxkbmap -print を使うことで、xkbcomp で使用できる同一の .xkb ファイルを取得することが可能です:

setxkbmap -model thinkpad60 -layout us,sk,de -variant altgr-intl,qwerty \
    -option -option grp:menu_toggle -option grp_led:caps -print

出力の中に include があることに注意してください。各セクションのファイルは /usr/share/X11/xkb 下のサブディレクトリから取得されます。

xkb_types { include "complete" };

上記の設定なら xkbcomp は /usr/share/X11/xkb/types/complete を確認します。プラス記号は連結を意味します。

xkb_keycodes { include "evdev+aliases(qwerty)" };

上記の設定は以下と同じです:

xkb_keycodes {
    include "evdev";
    include "aliases(qwerty)";
};

上の記述のように括弧を使用することによってファイルの中で名前を付けられたセクションを選択することができます。女上記の例に関しては /usr/share/X11/xkb/keycodes/aliases の中身に

xkb_keycodes "qwerty" { ... };

という記述があるのを確認してください。 これがaliases(qwerty)が参照しているものです。 Finally, colons allow shifting parts of layout to another group.

関連する .xkb ファイルセクションを直接定義するXkbTypes/XkbCompat/XkbSymbols/XkbGeometryの値と異なり、 XkbModel, XkbLayout及びXkbRulesは/usr/share/X11/xkb/rules/以下にある non-xkb ファイルを加て参照します。 これらの non-xkb ファイルによって model や layout の値が特定の symbol や geometry に合わせられます。 XkbKeymap は完全な keymaps を参照します。詳細な記述に関してはIvan Pascalのページをチェックしてください。

ちょうど xkbcomp のアプローチと同じように、この種の設定は xetxkbmap を -print オプションなしで使うことによりオンザフライで行うことができます。

/usr/share/X11/xkb以下にあるファイルは設定ファイルの書き方の良い例になるでしょう 特に標準的なキーボード特性に非自明なXKBの実装を行う場合には (例えば keypad/NumLock の取り扱いなど)。 更に、もしあなたの行った変更を上流にプッシュしたい場合は編集すべきファイルがあります。 それに関しては事前に X Keyboard Config Rules をチェックしてください。

xmodmap

ときどきプリセット設定と合わせて使われていますが、xmodmap は XKB と直接の関係がありません。このツールは X の中でキーコードを (XKB 以前の) 別の方式で処理します。特に、xmodmap にはグループやタイプという概念が欠けているので、特定のキーに複数のキーシムを設定するのは上手くいきません。

単純な設定以外では、xmodmap を使用するのはあまり推奨されません。XKB に対応した xmodmap が xkbcomp です。ただし xkbcomp には -e オプションがないため、そんなに単純ではありません。とにかく、可能であれば、xkbcomp が推奨されるべきです。

インジケータ

"keyboard leds"と同様の意味である。 インジケーターの名前は xkb_keycodes セクションで物理的なLEDに合うように設定されている。 さもなくば、それらは重要ではない。 どのLEDにも適合しないインジケーターは"仮想的（virtual）"であると呼ばれる。 xkbvleds（パッケージxorg-xkbutils）はそれらの仮想的なインジケーターの状態をチェックできる。

例：

xkb_keycodes {
    indicator 1 = "LED1";       // first physical LED
}

インジケーターは常にXKBの内部状態の特定の部位を反映している。 以下に２つ例を示す。

モディファイヤの状態を示す例：

xkb_compatibility {
    indicator "LED1" { modifiers = Lock; }; // CapsLock indicator
}

現在のグループを示す例:

xkb_compatibility {
    indicator "LED1" { groups = 0x06; };    // "group 2 or group 3 is active"
}

値はビットマスクの値である。 グループに関してはビット1がグループ1を表しビット2がグループ2を表す、などと言った具合である。

Modifiers and types

ある時点で type セクションを除去したり、特殊な type を導入したり、あるいはその両方を行わなくてはならないことがあるかもしれません。

タイプ及びモディファイヤは強く結び付けられており、タイプの記述について話を始めるにあたってモディファイヤビットから始めることは大いに意味があることです。

まずどのビットを使うかを決めましょう。選択肢は８つしかありません。 更に、Shift, Control 及び Mod1 はいろんなアプリケーションによって広く用いられています。 Lock（別名 CapsLock）は事前に定義された意味を持ち上書きするのは難しいでしょう。 したがって実際には4つが自由に使えることになります。

警告 ：4つの標準的なタイプ、ONE_LEVEL, TWO_LEVEL, ALPHABETIC 及び KEYPAD は xkbcomp の中で 特別な扱いを受けます。これらはただ単にこのように名付けられているという理由により異なる動作をするでしょう。 これらを削除するのは避けてください。もしこれらのタイプに変更を加えて思うように行かなかった場合は、 代わりに新しいタイプを追加するようにしてください。

標準タイプにおける real modifiers の使用

あなたのベースとなる設定によっては、EIGHT_LEVEL や PC_RCONTROL_LEVEL2 のように使用されない標準タイプが出てくるでしょう。 意図しない動作を避けるためにそれらは削除してしまってください。

さて、いくつかの標準タイプは仮想モディファイヤを使用しています。 もしそれらを使用すると決めたのなら、この節を飛ばして後述の仮想モディファイヤの節に目を通してください。 そうでないならば、仮想モディファイヤについては一掃してしまうのがよいでしょう。 あなたが必要なタイプを確認し、それらをリアルなモディファイヤで置き換えるか定義自体を削除するかしてください。

例：

type "KEYPAD" {
    modifiers= Shift+NumLock;
    map[Shift]= Level2;
    map[NumLock]= Level2;
    level_name[Level1]= "Base";
    level_name[Level2]= "Number";
};

もしあなたが Mod2 を NumLock として用いたいのなら、タイプを以下のように変更してください。

type "KEYPAD" {
    modifiers= Shift+Mod2;
    map[Shift]= Level2;
    map[Mod2]= Level2;
    level_name[Level1]= "Base";
    level_name[Level2]= "Number";
};

もしあなたが NumLock モディファイヤを使用したくないのならば、以下のようにしてください。

type "KEYPAD" {
    modifiers= Shift;
    map[Shift]= Level2;
    level_name[Level1]= "Base";
    level_name[Level2]= "Number";
};

xkb_compatibility セクションでも同様にしてください。 一度この設定を行うとすべての「virtual_modifiers」行をファイルから削除することができるようになるはずです。

単独のモディファイヤビットの切り替え

基本的にはあなたが必要としているのは関連する一つの interpret エントリを伴う一つのキーシムです。 LWINキーのキーシムをISO_Level3_Shiftに変更し Mod5 の切り替えに使用する例：

xkb_compatibility {
    interpret ISO_Level3_Shift { action = SetMods(modifiers=Mod5); };
}

xkb_symbols {
    key <LWIN> { [ISO_Level3_Shift ] };
}

同様のやり方でSetMods以外にも,LockModsやLatchModsを特定のキーに設定できます。 SetModsは通常の"on while pressed（押している間だけ）" 修飾キーを作ります。 LockModsはCapsLockやNumLockのような"on/off"スイッチを作ります。 LatchModsは"on until next keypress（次のキーが押されるまで）"修飾キー別名スティッキー修飾キーを作ります。

modifier_map

モディファイヤマップは８つのモディファイヤビットを最大で２つのキーにマップするテーブルです。

Mod1ビットを左右のAltキーにマップする例:

modifier_map Mod1 { Alt_L, Alt_R };

In the core protocol, without XKB, it means more or less the same thing as

interpret Alt_L { action = SetMods(modifiers=Mod1); };
interpret Alt_R { action = SetMods(modifiers=Mod1); };

XKB does not use modifier map in its original meaning. XKBの内部では、それは単に仮想モディファイヤ（後述）をマップするための機能に過ぎません。

しかしながら、このテーブルはクライアントには簡単にアクセス可能であり、 このテーブルを用いた直感には反するがよく知られたひとつのトリックが存在します： モディファイヤマップを ModX ビットのどれが Altであるかを知るために使用するというものです。 この理由により、上述のように Alt_L 及び Alt_R にマップされた一つのモディファイヤを持つというのは良いアイデアです。 特に理由がない限りは、この場合 Alt に割り当てるモディファイヤビットは Mod1 にするべきです。

複数のキーボード

XKBでは接続された一つの物理キーボードに対するキーマップのみしか設定することができません。 この特性は問題となるキーボードが異なっている場合には非常に有用です。 例えばフルサイズのUSBキーボードが接続されたラップトップPCを考えてみましょう。

まずはじめに、xinput (package xorg-xinput)を用いてデバイスIDを取得しましょう：

AT Translated Set 2 keyboard                id=11   [slave  keyboard (3)]

次に,

xkbcomp -i 11 file.xkb $DISPLAY

あるいは

setxkbmap -device 11 ...

として特定のキーボードのみにキーマップを設定しましょう。 XKB コンフィギュレーションのダンプも同様に機能します:

xkbcomp -i 11 $DISPLAY file.xkb

TIPS:ありがちな間違いとしてはディバイスを指定しようとして xkbcomp -i11 とタイプしてしまうことです。-iオプションの後ろにスペースを挿入するようにしてください。

XKB のデバッグ

期待通りにキーが機能しないときは、まず XKB の内部状態を確認してください: 修飾キー, グループ, 制御ビット。3つはどれも LED を制御することができます。確認するには xkbvleds を使って下さい:

indicator "LED1" { modifiers = Lock; };
indicator "LED2" { groups = 2; };
indicator "LED3" { controls = audiblebell; };
   

それに加えて、 xkbwatchを使用するとすべての(リアル)モディファイヤをそれらのlock/latchステータスと同時に見ることができます。 モディファイヤビットはxevでも見ることができます. Xxkb では有効なgroupを見ることができますがその場合two_state modeはオフにするようにしてください。

Interpretationsセクションが思ったように動かない場合には、"interpret" blocksに重複がないかチェックしてください。 もし可能ならば、特定のキーシムに関係する記述をすべてコメントアウトしてみてください。 このあたりの話は9.2節でより詳しく説明されます。

キーマップをダウンロードしてサーバーが厳密に何を受け取っているのかをチェックすることもまた意味があります。 キーマップのダウンロードは以下のように行います。

xkbcomp $DISPLAY out.xkb

結果として出てくるファイルはインプットファイルと異なっていることが多いですが、 それを解決する次善策は知られていません。

仮想モディファイヤ

XKBの中で最も厄介な部分の一つが仮想モディファイヤです。 その機能は比較的マイナーでほとんどの場合無用であるにも関わらずすべての標準的なキーマップで目立つ位置に現れます。 「仮想モディファイヤ」という用語は甚だしく誤解を招きやすく、ほとんどの文献は助けにならなりません。

したがって、まず何よりもはじめに「仮想モディファイヤはリアルモディファイヤがそうであるような意味ではモディファイヤではない」ということを強調しておきたいです。。 それどころか仮想モディファイヤというのはリアルモディファイヤにエイリアスを振るために存在すると言っていいでしょう。 レベル定義に使えるビットが16個追加されるわけではないのです。 それらは単に8つあるモディファイヤビットの一つ（あるいは複数、場合によっては０個）を参照する 16個の可能な名前に過ぎないのです。

リアルモディファイヤビットは Shift, Lock, Control そして、Mod1-Mod5 と呼ばれます。 そこには Alt というビットは存在しません。 仮想モディファイヤはC言語のヘッダ風に書くならば以下のようなマクロ定義をできるようにしている似すぎません。

#define Alt Mod1

この記述によって Alt キーを修飾キーとして使いたがっているアプリケーションに適切に情報が渡ります。

仮想モディファイヤを一切定義することなく実用的なレイアウトを作ることも可能です。 標準的なモディファイヤの中で、Alt と Meta だけがこのような仮想モディファイヤを用いた取り扱いの必要があります。 なぜならば、なんにせよShift及びControlはリアルモディファイヤであり、NumLockは通常モディファイヤとしては使われないからです。.

また、基本的なXlibの機能を使用するすべてのアプリケーションに影響するキーマップに関連した事柄と違って 仮想モディファイヤはXKBlibの呼び出しから明示的に問い合わせられます。 つまりすべてのアプリケーションに影響があるわけではないのです。

仮想モディファイヤの定義

仮想及びリアルモディファイヤのマッピングはキーシムを媒介とする風変わりなやり方で定義されます。 そのようにな作法の裏にある理由を知りたければXKBprotoを参照してください。 まず以下のようにしてリアルモディファイヤMを適当なキーに割り当てます。

modifier_map M { <keysym> };

仮想モディファイヤVは以下のようにしてそのキーに割り当てることができます。

interpret <keysym> { virtualMod = V; };

もし仮想モディファイヤVがリアルキーMと一つでもきーシムを共有していれば、それはMにバインドされます。

注：仮想モディファイヤの名前は事前に定義されているわけではなくてそれらを使用する前に xkb_compatibility及びxkb_typesセクションで定義する必要があります：

xkb_compatibility "complete" {
    virtual_modifiers LevelThree,NumLock,Alt;
}

キーシムの解釈

仮想モディファイヤは "interpret <keysym>" ブロックであたかもそれら一つ一つが某かのリアルモディファイヤに対して定義されているかのごとく使用することができます。 このことは、いかなるリアルモディファイヤにもバインドされていない仮想モディファイヤVに対しては、

#define V

のような宣言を行ったことを意味し（すなわち none にマップされる）

interpret <key> { }
interpret <key>+V { }

ブロックは重複として扱われます。 その場合これらのうち一つだけ、より厳密に言うならファイルの中の最後のものだけ、が動作します。 このような場合xkbcompは通常警告を出します。

クライアントサイドのノート

XKB仮想モディファイヤをクライアントサイドで扱うには非自明なサーバーとのインタラクションが必要になります。 ほとんどのアプリケーションはそのような面倒をせず、単に XkeyEvent.state によって提供される ８つのリアルモディファイヤでやりくりしています。

しかしながら、アプリケーションがキープレスに関連した仮想モディファイヤを得ることはありえます。 例えば、Gtkは gdk-keymap-translate-keyboard-state() というような アプリケーションによって使われたり使われなかったりする関数を提供しています。

仮想モディファイヤのサポートらしきものを実装することは可能なのかもしれないが、実際にはありません。 5.3.3.2節の openbox の例を見てください。Altの扱いについて知りたければ, 8.3節を読んでください。

XKB 制御ビット

XKBの機能の様々な側面に影響を与えるビットの束。 これらをコントロールするには{Set,Latch,Lock}Controlsアクションを使用しましょう。

オーバーレイ

特定のキーのキーコード (とそのキーコードに関連付けられたキーシム) を一時的に変えることができる機能です。

例:

xkb_keycodes {
    <KP4> = 83;      // もし仮にデバイスが２つ目のキーコードを生成できないとしても、
    <K04> = 144;     // 両方のキーコードが定義されていなくてはなりません。
};

xkb_compatibility {
    interpret Overlay1_Enable { action = LockControls(controls=overlay1); };
};

xkb_symbols {
    key <KP4> { [ KP_Left ], overlay1=<KO4> };
    key <KO4> { [ KP_4 ] };

    key <NMLK> { [ Overlay1_Enable ] };
};

上の例でまず83をキーボードが生成できる「リアルな」キーコードと仮定しましょう。 オーバーレイビットをオフにするとこのキーは KP_Left キーシムを生成し、 オーバーレイビットをオンにすると今度は 、異なる xkb_symbols の列から値を拾いキーコード144（<K04>）及び それに関連付けられたキーシムである KP_4 を生成します。

ユーザー定義のタイプを使用することによっても同様の挙動を得ることができますが、 オーバーレイとユーザー定義のタイプの原理的な違いはオーバーレイはキーコード自体を変えてしまい state フィールドにはなんの痕跡も残さないということです。 しかしながらオーバーレイの拡張性は限定的です。なぜなら２つのコントロールビット、overlay1及びoverlay2しかオーバーレイには用意されておらず、 更に一つ一つのキーに対して一つしか代替キーコードを生成できないからです。つまり and each key can have only one alternative keycode, so writing

    key <KP4> { [ KP_Left ], overlay1=<KO4>, overlay2=<KX4> };

のように overlay1列とoverlay2列を同時に設定しても意味がないのです(しかしながらxkbcompはこれに関しては渓谷を出しません)。 overlay1= を選ぶか overlay2= を選ぶかはただ単に２つのビットのうちどちらに代替キーコードを生成させたいかによって決まります。

よく知られた唯一のオーバーレイの応用例は上述のようにキーパッド及びNumLockの実装です。 完璧な例に関しては /usr/share/X11/xkb/symbols/keypad を見よ。

マウスの操作

XKB によってキーボードからマウスポインタを操作することができます。適切に設定すれば、とっても便利です。ただし、どれくらい有用かは物理的なキーボードレイアウトやユーザーの個別設定によるところが大きいでしょう。

XKB の観点からすればこれは簡単に実装することができます。ユーザーは単に関連するアクションをトリガーすればよいのです。 極めて完璧な実装が /usr/share/X11/xkb/compat/mousekeys. に見られます。

注：MouseKeys コントロールビットが設定されるまではマウス関連のアクションは機能しません：

interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys); };

ほとんどのキーボードはマウスコントロールに特化したキーを持たないため、

MouseKeys と Overlay フラグのどちらかを組み合わせるというのは良い考えです:

interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys+Overlay1); };

こうすることによってポインターをコントロールするキーの定義を適切なオーバーレイブロックに移動することができます。

xkb_keycodes {
    <MUP> = 218;
    <MDWN> = 212;
    <MLFT> = 214;
    <MRHT> = 216;
}
    
xkb_symbols {
    key   <UP> { [    Up ], overlay1 = <MUP> };
    key <LEFT> { [  Left ], overlay1 = <MLFT> };
    key <RGHT> { [ Right ], overlay1 = <MRHT> };
    key <DOWN> { [  Down ], overlay1 = <MDWN> };
        
    key <MUP>  { [ Pointer_Up ] };
    key <MDWN> { [ Pointer_Down ] };
    key <MLFT> { [ Pointer_Left ] };
    key <MRHT> { [ Pointer_Right ] };
}

このようにしてマウスでないアクションをマウスをコントロールするのに使用することができます。 例えば修飾キーでマウスボタンのイベントを生成することもできます。

ローカル XKB フォルダ

以下のコマンドを使うことでローカルファイルから X キーマップを設定できます:

$ xkbcomp keymap.xkb $DISPLAY

keymap.xkb は以下のような構造のファイルです:

keymap.xkb

xkb_keymap {
    xkb_keycodes  { ... };
    xkb_types     { ... };
    xkb_compat    { ... };
    xkb_symbols   { ... };

    // Geometry is completely optional.
    // xkb_geometry  { include "pc(pc104)" };
};

ファイルの中に includes を記述することで、/usr/share/X11/xkb の代わりにローカルフォルダを参照することができます。その場合 xkbcomp の -I/path/ パラメータを使う必要があります。例:

$ xkbcomp -I$HOME/.xkb $HOME/.keymap.xkb $DISPLAY

$HOME/.keymap.xkb

xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)" };
    xkb_types     { include "complete" };
    xkb_compat    { include "complete" };
    xkb_symbols   { include "pc+custom+inet(evdev)" };
};

シンボルファイルは xkb_symbols で指定したのと同じファイル名にしてください:

$HOME/.xkb/symbols/custom

partial alphanumeric_keys xkb_symbols "custom" { ... };

トラブルシューティング

USB キーボードを切断すると設定が消える

固定キーマップ設定ではなくルールを使用することで、柔軟性があって永続的なキーマップを設定することができます。手動 (あるいはスクリプト) でリロードする必要はありません。

参照

http://www.x.org/wiki/XKB and links therein, especially

• An Unreliable Guide To XKB Configuration. Similar in scope to this page, with a bit different point of view. Recommended for a general picture.
• Ivan Pascal XKB docs. One of the oldest and most well-known guides. Focuses a lot on details, and explains some of exotic XKB features.
• XKB protocol specification. Comprehensive description of all XKB features. Extremely useful for understating how XKB works, includes a good description of virtual modifiers among other things. Some practice with xkbcomp is strongly recommended though, because the features are described on protocol level.
• X.org Wiki - XKB. Additional links to XKB resources.