「X keyboard extension」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(文字列「http://www.x.org/」を「https://www.x.org/」に置換)
(3人の利用者による、間の39版が非表示)
8行目: 8行目:
 
キーボードを設定するシンプルな方法を探してここに辿り着いた場合は、まず最初に [[Xorg でのキーボード設定]]を見てください。
 
キーボードを設定するシンプルな方法を探してここに辿り着いた場合は、まず最初に [[Xorg でのキーボード設定]]を見てください。
   
''訳注:このページは基本的には [https://wiki.archlinux.org/index.php/X_KeyBoard_extension X KeyBoard extension - Arch Wiki] の翻訳ですが、扱っている機能が言語に依存するものであり適宜日本語ユーザーに必要と思われる補足を入れていくことにします。''
+
{{Tip|このページは基本的には [https://wiki.archlinux.org/index.php/X_KeyBoard_extension 英語版の記事] の翻訳ですが、扱っている機能が言語に依存するものであり適宜日本語ユーザーに必要と思われる補足を入れていくことにします。}}
   
 
== 用心と準備 ==
 
== 用心と準備 ==
24行目: 24行目:
 
=== ルールを使う ===
 
=== ルールを使う ===
   
{{ic|/usr/share/X11/xkb/rules/}} の中の {{ic|*.lst}} ファイルや [http://www.x.org/wiki/XKB/ XKB のホームページ] にルールの設定方法が載っています。あなたの設定は {{ic|/etc/X11/xorg.conf.d/}} に保存することができます。
+
{{ic|/usr/share/X11/xkb/rules/}} の中の {{ic|*.lst}} ファイルや [https://www.x.org/wiki/XKB/ XKB のホームページ] にルールの設定方法が載っています。あなたの設定は {{ic|/etc/X11/xorg.conf.d/}} に保存することができます。
   
 
例えば {{ic|Caps Lock}} キーを {{ic|Escape}} にリマップしたい場合:
 
例えば {{ic|Caps Lock}} キーを {{ic|Escape}} にリマップしたい場合:
37行目: 37行目:
 
}}
 
}}
   
=== キーマップを使う (非推奨) ===
+
=== キーマップを使う (非推奨*) ===
  +
{{Tip|非推奨ではありますがこのページはほとんどキーマップを用いたキーカスタマイズに関する話です。}}
   
 
({{Pkg|xorg-xkbcomp}} パッケージに入っている) xkbcomp を使って XKB のデータを操作します。現在の設定を確認するには、次を実行:
 
({{Pkg|xorg-xkbcomp}} パッケージに入っている) xkbcomp を使って XKB のデータを操作します。現在の設定を確認するには、次を実行:
47行目: 48行目:
 
$ xkbcomp input.xkb $DISPLAY
 
$ xkbcomp input.xkb $DISPLAY
   
{{ic|$DISPLAY}} 引数を付けないと xkbcomp は .xkb ファイルから (無能の) .xkm ファイルへのコンパイルを始めるので注意してください。サーバーには何もアップロードされません。ただし、構文のチェックが行われてエラーを報告してきます。
+
{{ic|$DISPLAY}} 引数を付けないと xkbcomp は .xkb ファイルから (ほとんど役に立たない) .xkm ファイルへのコンパイルを始めるので注意してください。サーバーには何もアップロードされません。ただし、構文のチェックが行われてエラーを報告してきます。
   
 
レイアウトの用意ができたら、{{ic|~/.Xkeymap}} として保存して {{ic|~/.xinitrc}} から起動時にロードするようにしてください:
 
レイアウトの用意ができたら、{{ic|~/.Xkeymap}} として保存して {{ic|~/.xinitrc}} から起動時にロードするようにしてください:
70行目: 71行目:
 
XFilterEvent returns: False
 
XFilterEvent returns: False
   
keycode 21, state 0x1, keysym 0x2b, plus に着目してください。keycode 21 は入力デバイスが X に送信した値で、物理的なキーのインデックスです。state は修飾キーを表しており、0x01 は Shift です。キーコードと状態の値は XKeyEvent(3) で X からアプリケーションに送信されます。キーシムと対応する文字は、クライアントが XLookupString(3) などを使って取得します。
+
keycode 21, state 0x1, keysym 0x2b, plus に着目してください。keycode 21 は入力デバイスが X に送信した値で、物理的なキーのインデックスです。state は修飾キーを表しており、0x01 は Shift です。キーコードと状態の値は XKeyEvent(3) で X からアプリケーションに送信されます。キーシム(''訳注:語感からわかるかもしれませんがどの文字に対応するかを表す数値です'')と対応する文字は、クライアントが XLookupString(3) などを使って取得します。
   
 
state フィールドのビットはあらかじめ名前が定義されています: 下から {{ic|Shift}}, {{ic|Lock}}, {{ic|Control}}, {{ic|Mod1}}, {{ic|Mod2}},
 
state フィールドのビットはあらかじめ名前が定義されています: 下から {{ic|Shift}}, {{ic|Lock}}, {{ic|Control}}, {{ic|Mod1}}, {{ic|Mod2}},
 
{{ic|Mod3}}, {{ic|Mod4}}, {{ic|Mod5}} です。従って、{{ic|Ctrl+Shift}} は 0x05 となります。クライアントアプリケーションは基本的に必要なビットしか確認しません。そのため通常のキーボード入力でアプリケーションを使うときに {{ic|Ctrl+key}} ショートカットは {{ic|Control}} と {{ic|Control+Mod3}} を区別しないのが普通です。
 
{{ic|Mod3}}, {{ic|Mod4}}, {{ic|Mod5}} です。従って、{{ic|Ctrl+Shift}} は 0x05 となります。クライアントアプリケーションは基本的に必要なビットしか確認しません。そのため通常のキーボード入力でアプリケーションを使うときに {{ic|Ctrl+key}} ショートカットは {{ic|Control}} と {{ic|Control+Mod3}} を区別しないのが普通です。
   
キーシムも数です。{{ic|/usr/include/X11/keysymdef.h}} で {{ic|KP_}} によって定義されているように、ほとんどに名前が付けられています。ただし、数はクライアントが実際に受け取るものです。方向キーや Enter、Backspace や F キー、あるいは様々なショートカットなど、アプリケーションが特定の値を使うときだけキーシムは意味を持ちます。他の場合は、文字が使われます。
+
キーシムも数です。{{ic|/usr/include/X11/keysymdef.h}} で {{ic|KP_}} によって定義されているように、ほとんどに名前が付けられています。ただし、数はクライアントが実際に受け取るものです。方向キーや Enter、Backspace や F キー、あるいは様々なショートカットなど、アプリケーションが特定の値を使うときだけキーシムは意味を持ちます。他の場合は、文字が使われます。
   
 
=== キーコードの翻訳 ===
 
=== キーコードの翻訳 ===
   
XKB は多くの場合 XLookupString ステージで動きます。
+
XKB は多くの場合 XLookupString ステージで動きます。XLookupString ステージでは入力されたキーコードがその内部状態にもとづきキーシムに変換されます。ここで内部状態とはグループ (group) および状態 (state) の値の対のことです:
XLookupString ステージでは入力されたキーコードがその内部状態にもとづきキーシムに変換されます。
 
ここで内部状態とはグループ(group)および状態(state)の値の対のことです。
 
   
 
(keycode, group, state) → keysym
 
(keycode, group, state) → keysym
   
ここでのグループは典型的には US-EnglishだとかFrench-AZWERTY, ロシア語、ギリシャ語などといった「レイアウト」 情報を表しています。
+
グループは典型的には US-English だとか French-AZWERTY, ロシア語、ギリシャ語などといった「レイアウト」情報を表しています。グループは最大で4種類の値を持つことができます。
グループは最大で4種類の値を持つことができます.
 
   
 
内部的には、上述の変換は以下の様な追加のステップから構成されています:
 
内部的には、上述の変換は以下の様な追加のステップから構成されています:
94行目: 92行目:
 
(keycode, group, level) → S[keycode][group][level]
 
(keycode, group, level) → S[keycode][group][level]
   
ここで {{ic|S}} は変換表です実際には以下に述べる{{ic|xkb_symbols}}を呼び出しています)。
+
{{ic|S}} は変換表です (実際には以下に述べる {{ic|xkb_symbols}} を呼び出しています)。
   
型(Types)はどの修飾子がどのキーに影響を及ぼしているの情報含んいま(ここで修飾子およびキーは一般複数で); 
+
(Type) はどの修飾子がどのキーに影響を及ぼかを示すものです。基本的にはれが {{ic|S}} の三次元目の変数 level の範囲を狭める方法す。例えば、典型的な英数キーは {{ic|Shift}} キーのみから影響を受けます。その場合、型 {{ic|TWO_LEVEL}} セットされ以下のようになりま:
基本的にはこれが{{ic|S}}の三次元目の変数 level の範囲を狭める方法です。 
 
例えば, 典型的な英数キーは{{ic|Shift}}キーのみから影響を受けます。; その場合型は{{ic|TWO_LEVEL}}にセットされ,
 
   
 
(state, TWO_LEVEL) → level = ((state >> 0) & 0x01) = state & 0x01
 
(state, TWO_LEVEL) → level = ((state >> 0) & 0x01) = state & 0x01
   
  +
レベルは0または1となります。したがって、このケースの変換表は {{ic|S[keycode][0..4][0..1]}} となりシフトキーを押さない場合の {{ic|S[keycode][0..4][0..256]}} よりも狭まります。
となり、レベルは0または1となります。
 
  +
したがって、このケースの変換表は{{ic|S[keycode][0..4][0..1]}}となりシフトキーを押さない場合の{{ic|S[keycode][0..4][0..256]}}よりも狭まります。
 
  +
{{Tip|この節の説明はこなれているとは言えず、型の定義を行っているファイルを実際に読んでみたほうが理解し易いと思います。}}
   
 
=== キーシムと状態 ===
 
=== キーシムと状態 ===
   
X termsでは, {{ic|a}}および{{ic|Ctrl+a}}状態は異ながキーシムは同じです。
+
X ターミナルでは {{ic|a}}{{ic|Ctrl+a}}状態 (state) は異なりますがキーシムは同じです。一方 {{ic|a}} と {{ic|A}} はキーシム自体が異なっています。
一方{{ic|a}}および{{ic|A}}はキーシム自体が異なっています.
 
   
XKBのタスクとしてはキーシムの変換のみを行い、
+
XKB のタスクとしてはキーシムの変換のみを行い、状態自体は個々のアプリケーションにおける後段処理で扱うということが一般的です。
状態自体は個々のアプリケーションにおける後段処理で扱うということが一般的です。
 
   
また、XKB における状態は幾分遅れて作用す。
+
また、XKB における状態は遅延評価のような扱いを受けます。つまり、そはユーザーがキーを押す前に状態をセットておかなくてはならないということです。
つまり、それはユーザーがキーを押す前に状態をセットしておかなくてはならないということです。
 
   
  +
例: rxvt で {{ic|Ctrl+h}} はバックスペースとして機能するようにアプリケーション内で設定できます。この場合、rxvt は {ic|Control}} のビットが値としてセットされた状態と同時に {{ic|h}} キーシムを受け取ります。これは {{ic|Backspace}} キーシムと明らかに異なるものです。それとは違って、XKB を使えば {{ic|Ctrl+h}} の組み合わせから {{ic|Control}} ビットを値として持つ状態とともに {{ic|Backspace}} キーシムを生成することができます。この場合、rxvtは {{ic|Ctrl}} キーが押されている限り物理的な {{ic|Backspace}} キーと {{ic|h}} キーを異なるキーとして区別することができません。XKB を用いて {{ic|Ctrl+h}} の組み合わせから {{ic|Control}} ビットが設定されていない {{ic|Backspace}} キーシムを生成することもできますが、それは {{ic|Control+Backspace}} を実装するよりも難しくなります。
例: {{ic|Ctrl+h}}rxvt内のアプリケーション設定によってはバックスペースとして機能するようにできます。
 
この場合、rxvtは{{ic|Control}}のビットが値としてセットされた状態と同時に{{ic|h}}キーシムを受け取ります。
 
これは{{ic|Backspace}}キーシムと明らかに異なるものです。
 
それとは違って、XKBを使えば{{ic|Ctrl+h}}の組み合わせから{{ic|Control}}ビットを値として持つ状態とともに{{ic|Backspace}}キーシムを生成することができます。
 
この場合、 rxvtは{{ic|Ctrl}}キーが押されている限り物理的な{{ic|Backspace}}キーと{{ic|h}}キーを異なるキーとして区別することができません。
 
XKBを用いて{{ic|Ctrl+h}}の組み合わせから{{ic|Control}}ビットが設定されていない{{ic|Backspace}}キーシムを生成することもできますが、
 
それは{{ic|Control+Backspace}}を実装するよりも難しいです。
 
   
 
=== アクション ===
 
=== アクション ===
   
上述の変換表から得られたキーシムはなにがしかのアクションを引き起こすことができます
+
上述の変換表から得られたキーシムはなにがしかのアクションを引き起こすことができます:
   
 
(keysym, state) → action
 
(keysym, state) → action
   
XKBにおいては、修飾ビットの設定およびロックは、コンソールのスイッチングやサーバーの終了、ポインターの移動などのあらゆるXサーバー上のインタラクションと同様の意味で、アクションなのです。
+
XKB においては、修飾ビットの設定およびロックは、コンソールのスイッチングやサーバーの終了、ポインターの移動などのあらゆる X サーバー上のインタラクションと同様の意味で、アクションなのです。アクションは一般にはキーシムに影響を及ぼしませんし、キーシムを生成することはアクションではありません
アクションは一般にはキーシムに影響を及ぼしませんし、キーシムを生成することはアクションではありません。
 
   
(keysym, state)ペア一つつき一つだけ可能なアクションが一つだけ存在します。
+
ひとつの (keysym, state)ペアに設定出来るアクションはひとつだけす。
   
 
== レイアウトの編集 ==
 
== レイアウトの編集 ==
139行目: 126行目:
 
まずはサーバーのデフォルト設定から始めます。できるかぎり、少しずつ変更を加えてテストするようにしてください。
 
まずはサーバーのデフォルト設定から始めます。できるかぎり、少しずつ変更を加えてテストするようにしてください。
   
xkbcomp によって生成される .xkb ファイルはシンプルなテキストファイルです。C++ 風のコメント (// で行末までコメントにする) が使えます。xkb_keycodes の "name-here" にあるように、セクション名はこの段階ではあまり意味がないので省いてもかまいません。
+
xkbcomp によって生成される {{ic|.xkb}} ファイルはシンプルなテキストファイルです。C++ 風のコメント (// で行末までコメントにする) が使えます。{{ic|xkb_keycodes}} の "name-here" にあるように、セクション名はこの段階ではあまり意味がないので省いてもかまいません。
   
 
=== xkb_keycodes ===
 
=== xkb_keycodes ===
145行目: 132行目:
 
キーコードの定義。ファイルの残りの部分では数字のキーコードは使わず、このセクションで定義した記号のキーラベルだけを用います。
 
キーコードの定義。ファイルの残りの部分では数字のキーコードは使わず、このセクションで定義した記号のキーラベルだけを用います。
   
  +
実際に問題となるキーのみを残しておくと言うのは良いアイデアです。
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_symbols セクションではこれらのラベルのみが使用されます。
151行目: 139行目:
 
=== xkb_types ===
 
=== xkb_types ===
   
このセクションは xkb_symbols の前にあります(すなわちより低レイヤーということです)。したがって英数キーで閉じた使い方をするときは見るだけにとどめて、変更はしないほうが賢明でしょう(''訳注:しかしながら日本語ユーザー例えば無変換キーを修飾キーとて用たりする場合のファイルを用意したり既存のファイルを編集する必要があります。'')
+
このセクションは xkb_symbols の前にあります(すなわちより低レイヤーということです)。したがって英数キーで閉じた使い方をするときは見るだけにとどめて、変更はしないほうが賢明でしょう(''訳注:しかしながらシフトとCapsLockで大文字小文字切り替わる英数キーのような典型的なタイプ以外のもの使用い場合は自分で書く必要があります。'')
 
標準的なタイプは後述の仮想修飾キーにその多くを依存しています。
 
標準的なタイプは後述の仮想修飾キーにその多くを依存しています。
 
今のところ、あなたが必要なタイプを探すに留めるようにしてください。
 
今のところ、あなたが必要なタイプを探すに留めるようにしてください。
163行目: 151行目:
   
 
タイプの記述自身は極めてシンプルです。次の行
 
タイプの記述自身は極めてシンプルです。次の行
Type description themselves are quite simple.
 
   
 
modifiers= Shift+NumLock+LevelThree;
 
modifiers= Shift+NumLock+LevelThree;
202行目: 189行目:
 
殆どのアプリケーションは {{ic|Ctrl+U0061}}ではなく{{ic|Ctrl+a}}が送信されてくることを期待します。なぜならそれらの持つ数値的な値が異なるからです。
 
殆どのアプリケーションは {{ic|Ctrl+U0061}}ではなく{{ic|Ctrl+a}}が送信されてくることを期待します。なぜならそれらの持つ数値的な値が異なるからです。
   
  +
キーのタイプはここで決定することもできます。その場合2つの記法があり、ひとつは
Key types are also specified here, either as
 
   
 
key.type = "T1";
 
key.type = "T1";
212行目: 199行目:
 
key <...> { ... };
 
key <...> { ... };
   
  +
のように複数のキーにまとめて適用するものであり、もうひとつはそれぞれのキーのみに適用するものです:
or individually for each key:
 
   
 
key <...> { type = "T", [ .... ], [ .... ] };
 
key <...> { type = "T", [ .... ], [ .... ] };
   
  +
グループごとに異なるタイプを適用することができます。
Key type may be different in different groups. This is somewhat counter-intuitive, but
 
  +
この仕様はコンピュータにとっては直感に反しますが、実際問題としては有用な応用があります。
actually has some useful applications. To set types for each group, use this:
 
  +
グループごとにタイプを設定するには以下の記法を用います:
   
 
key <...> { type[1] = "T1", type[2] = "T2", [ ... ], [ ... ] };
 
key <...> { type[1] = "T1", type[2] = "T2", [ ... ], [ ... ] };
   
  +
また、グループのタイプの違いなどを記憶しやすくするために、グループに対するラベルを以下のような記法で定義することができます。
You can set labels for the groups using
 
 
 
 
name[1] = "EN"; // group 1
 
name[1] = "EN"; // group 1
227行目: 215行目:
 
name[3] = "UA"; // group 3
 
name[3] = "UA"; // group 3
   
  +
ここでラベルが定義されていれば xxkb でそれを見ることができます。
This is what xxkb will show if labels are enabled there.
 
  +
このセクションはまた{{ic|modifier_map}}行を含みます。
 
  +
今はこれらの行はそっとしておいて、後述の仮想モディファイヤをチェックしてください。
The section also contains {{ic|modifier_map}} lines. Leave them alone for now,
 
or check Virtual Modifiers below.
 
   
 
=== xkb_geometry ===
 
=== xkb_geometry ===
   
  +
(キーボード設定をソフトウェア的にいじると言う目的のためには)完全に関係のない物理的キーボードレイアウトを記述するセクションです。何の影響を受けることもなく削除してしまうことができます。
A completely irrelevant section describing physical keyboard layout.
 
Can be deleted without any consequences.
 
   
 
== 基本的なサンプル ==
 
== 基本的なサンプル ==
   
  +
既存のレイアウトに多くの一般的なキーに対する標準的な定義が含まれていると考えられるので、まずあなたの環境にすでに存在するレイアウトを確認しましょう。
Check your existing layout first, as it likely contains standard definition for many common keys.
 
   
  +
この文書に登場する「xkb_keycods { text }」は「text」がxkb_keycodesセクションで追加されているべきことを意味します。
Thoughout the text, "xkb_keycodes { text }" means "text" should be added
 
  +
文脈から明らかな場合、セクション名は省略されます。
to xkb_keycodes section.
 
Whenever it's clear from context, section names are omited.
 
   
 
=== 単一のキーの割り当て ===
 
=== 単一のキーの割り当て ===
289行目: 274行目:
 
=== 複数のレイアウト ===
 
=== 複数のレイアウト ===
   
  +
通常の英数キーに対しては、単に2/3/4番目の [] セクションをキー定義に加えるだけにしましょう。
For regular alphanumeric keys, just add a second/third/fourth [ ] section to the key definition:
 
   
 
key.type = "ALPHABETIC";
 
key.type = "ALPHABETIC";
298行目: 283行目:
 
[ U0456, U0406 ] };
 
[ U0456, U0406 ] };
   
  +
レイアウトの切り替えはLockGroupアクションによって引き起こすことができます。
Layout switching is done by triggering action LockGroup:
 
   
 
interpret ISO_Next_Group { action = LockGroup(group=+1); };
 
interpret ISO_Next_Group { action = LockGroup(group=+1); };
 
interpret ISO_Prev_Group { action = LockGroup(group=-1); };
 
interpret ISO_Prev_Group { action = LockGroup(group=-1); };
   
  +
典型的には、これはキーシム ISO_Next_Group 及び ISO_Prev_Group をグループあるいはレベルの変更にもちいるということを意味します。
Typically this means placing ISO_Next_Group and ISO_Prev_Group
 
keysyms in correct group/level positions. Note that groups wrap, so if you have two groups and hit
 
ISO_Next_Group twice, you will return to the group you started with.
 
   
  +
グループは循環するのでもし2つのグループが存在するときに ISO_Next_Group を2回を押すと元のグループに戻ってくることになるということを記しておきます。
Cyclic switching between two or more layouts with a dedicated key:
 
  +
  +
2つ以上のレイアウトの循環的な切り替えに特化したキーの設定例:
 
 
 
key.type = "ONE_LEVEL";
 
key.type = "ONE_LEVEL";
 
key <RWIN> { [ ISO_Next_Group ] }
 
key <RWIN> { [ ISO_Next_Group ] }
   
  +
もし2つ以上のレイアウトを使用していて使わないキーがあるのなら、そのキーをレイアウトを切り替える専用のキーにしてしまうのがよいでしょう。
If you have more than two layouts and some keys to spare, it may be a better idea to have a dedicated
 
  +
以下に3つのレイアウトが存在する場合を示します:
key for each layout. Example for three layouts:
 
   
 
key.type = "ONE_LEVEL";
 
key.type = "ONE_LEVEL";
324行目: 309行目:
 
[ ISO_Next_Group ] }; // g3: switch back to g1
 
[ ISO_Next_Group ] }; // g3: switch back to g1
   
With four layouts, you will likely have to use ISO_First_Group and ISO_Last_Group.
+
4つのレイアウトを使用する場合にはほとんどの場合 ISO_First_Group 及び ISO_Last_Group を使う必要があるでしょう。
   
  +
同様のアイデアは以下のようにひとつのキーをTWO_LEVELタイプで使用することによっても実現できます:
The same idea can be implemented with only one key by utilizing TWO_LEVEL type:
 
   
 
key.type = "TWO_LEVEL";
 
key.type = "TWO_LEVEL";
333行目: 318行目:
 
[ ISO_Prev_Group, ISO_Next_Group ] };
 
[ ISO_Prev_Group, ISO_Next_Group ] };
   
  +
この方法は「Menu」をグループ2のために「Shift Menu」をグループ3のために割り当てるというものです(''訳注:対称性にかけるので念のために記しておくとグループ2の時に「Menu」を押すとグループ1に戻り、レイアウト3の時に「Shift Menu」を押すとグループ1に戻るというようになっている。'')。
This way it's Menu for group 2 and Shift-Menu for group 3. To use Ctrl or Alt instead of Shift,
 
  +
CtrlやAltをShiftの代わりに使用するには
replace TWO_LEVEL with PC_CONTROL_LEVEL2 or PC_ALT_LEVEL2 types respectively.
 
  +
TWO_LEVELタイプをPC_CONTROL_LEVEL2タイプやPC_ALT_LEVEL2タイプにそれぞれ置き換えれば良い.
   
  +
複数の修飾キー(例えば Shift + Sfhift, Ctrl + Shift など)を用いてグループやレイアウトの切り替えを行うことは、
Switching using two modifier keys (Shift+Shift, Ctrl+Shift etc) can be done by using something other
 
  +
それらのキーに対する ONE_LEVEL の設定とは異なる別の方法によって実現される。
than ONE_LEVEL for these keys. Shift+Shift example:
 
  +
以下にShift + Shift の例を示す。:
   
 
key.type = "TWO_LEVEL";
 
key.type = "TWO_LEVEL";
343行目: 330行目:
 
key <RTSH> { [ Shift_R, ISO_Next_Group ] };
 
key <RTSH> { [ Shift_R, ISO_Next_Group ] };
   
  +
グループのラッチ(別名トグル:キーを押し続けている時に限りセットされる)するには、大抵の場合 ISO_Group_Latch キーシムにバインドされている
To latch a group (aka toggle; set for the time you hold the key only), use LatchGroup action typically
 
  +
]LatchGroupアクションを使用する:
bound to ISO_Group_Latch keysym:
 
   
 
key <RCTL> { [ ISO_Group_Latch ] }
 
key <RCTL> { [ ISO_Group_Latch ] }
   
  +
正しいグループに設定するには xkb_compatibility セクションで ISO_Group_Latch の定義を調整しておきましょう。
Adjust ISO_Group_Latch definition in xkb_compatibility section to use the right group:
 
   
 
interpret ISO_Group_Latch { action = LatchGroup(group=3); };
 
interpret ISO_Group_Latch { action = LatchGroup(group=3); };
   
Check /usr/share/X11/xkb/symbols/group for more standard examples.
+
標準的な例についてもっとたくさん知るには /usr/share/X11/xkb/symbols/group をチェックしましょう。
   
 
=== Additional symbols ===
 
=== Additional symbols ===
   
  +
一つのキーでよりたくさんのキーシムを打ち込めるようにします。
Typing more with the same keys.
 
   
 
==== コンポーズキー ====
 
==== コンポーズキー ====
   
  +
一般的なユニコード文字を入力する非常に簡単で極めて使い勝手の良い設定です''(訳注:コンポーズキーについては[https://ja.wikipedia.org/wiki/%E4%BF%AE%E9%A3%BE%E3%82%AD%E3%83%BC#.E3.82.A2.E3.82.AF.E3.82.BB.E3.83.B3.E3.83.88.E7.AC.A6.E5.8F.B7.E3.81.AE.E5.85.A5.E5.8A.9B 修飾キー - Wikipedia#アクセント符号の入力[編集]
Easy to set up and extremely useful for entering common unicode characters.
 
  +
]、[https://en.wikipedia.org/wiki/Compose_key Compose key - Wikipedia] を参考のこと)''。
   
key <RALT> { [ Multi_key ] };
+
key <RALT> { [ Multi_key] };
   
 
==== Level3 ====
 
==== Level3 ====
   
  +
考え方は Alt キーや AltGr キーの本来の意味と同じものです。
The idea is similar to Alt or AltGr in their original meaning: alphanumeric keys
 
  +
つまり、ある修飾キーが押されている状態で英数キーを押すとその英数キーだけでは直接入力できない付加的な文字が入力できるようになるというものです。
get additional characters, activated by holding down some modifier key.
 
   
  +
まず第一に、修飾キーを設定しましょう。
First of all, setting up the modifier.
 
   
 
xkb_symbols {
 
xkb_symbols {
376行目: 364行目:
 
}
 
}
   
  +
Also, the following should already be defined in the relevant sections, but in case it is not:
 
  +
以下の定義は関係するセクションですでに定義されているはずですが、もしされていなければこれらも以下のように定義しましょう:
   
 
xkb_compatibility {
 
xkb_compatibility {
404行目: 393行目:
 
}
 
}
   
  +
注:xkb_compatibility 及び xkb_types の標準的な定義では Mode5 の代わりに LevelThree が用いられています。
Note standard definitions have LevelThree instead of Mod5 in xkb_compatibility and xkb_types.
 
  +
上記の modifier_map が Mod5 を使う限り、使用上の違いはなく、結局 Mod5 のビットを(レベル3のビットとして)使うということです。
As long as modifier_map above uses Mod5, there is no practical difference, you will end up using Mod5
 
bit anyway.
 
   
  +
今度は、vi-スタイルのカーソル割り当てをキーそれ自身に行う設定例を示します:
Now, the keys themselves, vi-style cursors in this case:
 
   
 
key.type = "THREE_LEVEL";
 
key.type = "THREE_LEVEL";
416行目: 404行目:
 
key <AC09> { [ l, L, Right ] };
 
key <AC09> { [ l, L, Right ] };
   
  +
xev を用いて確認してみればわかるとおり、この設定のもとで Mod5+h を押すと純粋な左キーではなくて「Mod5+左キー」が生成されます。
As you may find out using xev, this produces Mod5+Left instead of just Left. But that is ok as most
 
  +
しかし、ほとんどのアプリケーションは自分自身が使用しない state ビットは無視するので問題ありません。
appications ignore state bits they do not use. For an alternative solution, check Overlays below.
 
  +
state ビットに痕跡を残さずに キーコードを変更する方法に関しては後述する Overlay を見てください。
   
 
=== Meta, Super, Hyper ===
 
=== Meta, Super, Hyper ===
423行目: 412行目:
 
==== Real modifiers ====
 
==== Real modifiers ====
   
  +
いくつかのアプリケーション(特に emacs)では高次の state ビットを有意義に使うことが可能になっています。
Some applications (notably emacs) allow meaningful use of higher state bits. It is usually assumed
 
  +
Emacs の場合では Shift, Ctrl, Alt とは別に Meta, Super, Hyper と呼ばれる修飾キーが state ビットをコントロールするものとして存在することが仮定されています。
there are modifier keys called Meta, Super and Hyper on the keyboard beside standard Shift, Ctrl and Alt,
 
which control these bits.
 
   
  +
XKBの観点からはこれは Mod2, Mod3, Mod4, Mod5 のビットに関する設定がなされているのと同じことです。
From XKB point of view this means setting Mod2, Mod3, Mod4 and Mod5 modifier bits. Because all
 
  +
なぜならこのようなアプリケーションを使用する場合は上述の Level3 の例の時のように type を編集する必要はなく、
you need is the bits themselves, there is no need to edit types like in the Level3 example above.
 
  +
ただビット自身が送信されるようにすれば良いからです。
   
 
xkb_compatibility {
 
xkb_compatibility {
439行目: 428行目:
 
}
 
}
   
  +
{{ic|xkb_compatibility}}の標準的な定義においては Mod3 の代わりに Super モディファイヤが使用されます。
Standard definitions use Super modifier instead of Mod3 in {{ic|xkb_compatibility}}.
 
  +
その定義をそのままにしておきつつこれらのキーを使用するにはただ、{{ic|modifier_map}}を然るべき場所に書けばよいのです。
You can keep that, just make sure {{ic|modifier_map}} line is in place.
 
   
  +
名前のついた修飾キー ― つまり Super, Hyper あるいは Alt でさえ ― ModN 都の間に厳密な対応関係は存在しないということを心にとどめておいてください。
Keep in mind there is no strict correspondence between ModN and named modifiers like Super, Hyper or even Alt.
 
  +
唯一広く使われるのは Mod1 で、あるアプリケーションはこれを Meta とよび、またあるキーはこれを Alt を呼びます。
Mod1 is the only one that is widely used; some applications call it Meta, some Alt. For the others,
 
  +
それ以外のことに関しては個々のアプリケーションが state ビットをどのように扱うかを調べるか、
check how particular application treats state bits, and/or check Virtual modifiers below.
 
  +
以下に述べる仮想キーに関する記述を参考にするか、あるいはその両方を試してください。
   
 
==== Keysym tracking ====
 
==== Keysym tracking ====
   
  +
世の中には Meta_[LR] や Super_[LR], Hyper_[LR] キーを state ビットの変化ではなくキーシムの KeyPress/KeyRelease イベントをトラックするアプリケーションが存在することが知られています(openboxとか)。
At least one application (openbox) is known to track KeyPress/KeyRelease events for Meta_[LR], Super_[LR]
 
  +
このようなケースには
and Hyper_[LR] keysyms instead of relying on the state bits. In such case
 
   
 
xkb_symbols {
 
xkb_symbols {
455行目: 445行目:
 
}
 
}
   
is enough and you can omit {{ic|interpret}} and {{ic|modifier_map}} lines.
+
という記述で十分でユーザーは{{ic|interpret}}行及び{{ic|modifier_map}}行の記述を省略できます。
   
  +
注:Openbox に関して言えば、両方の方法が可能になっています:
Speaking of openbox, note it actually allows both methods: "S-h" tracks Super_[LR] events
 
  +
"S-h"という設定では Super_[LR] イベントをトラックする一方で
while "Mod3-h" checks relevant state bit.
 
  +
"Mod3-h" の場合は関連する state ビットをチェックします。
   
 
== プリセット設定 ==
 
== プリセット設定 ==
489行目: 480行目:
 
};
 
};
   
  +
上の記述のように括弧を使用することによってファイルの中で名前を付けられたセクションを選択することができます。女上記の例に関しては {{ic|/usr/share/X11/xkb/keycodes/aliases}} の中身に
Parenthesis select named section from the file. Check
 
{{ic|/usr/share/X11/xkb/keycodes/aliases}} and note
 
   
 
xkb_keycodes "qwerty" { ... };
 
xkb_keycodes "qwerty" { ... };
   
  +
という記述があるのを確認してください。
this is the part {{ic|aliases(qwerty)}} refers to. Finally, colons allow shifting
 
  +
これが{{ic|aliases(qwerty)}}が参照しているものです。
parts of layout to another group.
 
  +
Finally, colons allow shifting parts of layout to another group.
   
Unlike XkbTypes/XkbCompat/XkbSymbols/XkbGeometry values, which define relevant
 
.xkb file sections directly, XkbModel, XkbLayout and XkbRules refer to
 
additional non-xkb files found under {{ic|/usr/share/X11/xkb/rules/}} that match model
 
and layout values to specific symbols and geometry. XkbKeymap refers to complete
 
keymaps. Check Ivan Pascal page for detailed description.
 
   
  +
関連する .xkb ファイルセクションを直接定義するXkbTypes/XkbCompat/XkbSymbols/XkbGeometryの値と異なり、 XkbModel, XkbLayout及びXkbRulesは{{ic|/usr/share/X11/xkb/rules/}}以下にある non-xkb ファイルを加て参照します。
Just like with xkbcomp approach, this kind of configuration can be done
 
  +
これらの non-xkb ファイルによって model や layout の値が特定の symbol や geometry に合わせられます。
on the fly: use setxkbmap without -print option.
 
  +
XkbKeymap は完全な keymaps を参照します。詳細な記述に関しては[http://pascal.tsu.ru/en/xkb/setup.html Ivan Pascalのページ]をチェックしてください。
   
  +
ちょうど xkbcomp のアプローチと同じように、この種の設定は xetxkbmap を -print オプションなしで使うことによりオンザフライで行うことができます。
The files from {{ic|/usr/share/X11/xkb}} are a good source of examples, especially when it
 
  +
comes to standard keyboard features with nontrivial XKB implementation
 
  +
(e.g. keypad/NumLock handling). Also, these are the files you have to edit to push
 
  +
{{ic|/usr/share/X11/xkb}}以下にあるファイルは設定ファイルの書き方の良い例になるでしょう
your changes upstream. Check [http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules X Keyboard Config Rules] before doing it though.
 
  +
特に標準的なキーボード特性に非自明なXKBの実装を行う場合には
  +
(例えば keypad/NumLock の取り扱いなど)。
  +
更に、もしあなたの行った変更を上流にプッシュしたい場合は編集すべきファイルがあります。
  +
それに関しては事前に [https://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules X Keyboard Config Rules] をチェックしてください。
   
 
=== xmodmap ===
 
=== xmodmap ===
519行目: 510行目:
 
== インジケータ ==
 
== インジケータ ==
   
  +
As in "keyboard leds".
 
  +
"keyboard leds"と同様の意味である。
Indicator names are used to match the to the physical LEDs in xkb_keycodes section.
 
  +
インジケーターの名前は xkb_keycodes セクションで物理的なLEDに合うように設定されている。
Otherwise, they are irrelevant. Indicators not matched to any LED are called "virtual";
 
  +
さもなくば、それらは重要ではない。
xkbvleds (package {{Pkg|xorg-xkbutils}}) can be used to check their state. Example:
 
  +
どのLEDにも適合しないインジケーターは"仮想的(virtual)"であると呼ばれる。
  +
xkbvleds(パッケージ{{Pkg|xorg-xkbutils}})はそれらの仮想的なインジケーターの状態をチェックできる。
  +
  +
例:
   
 
xkb_keycodes {
 
xkb_keycodes {
528行目: 523行目:
 
}
 
}
   
  +
インジケーターは常にXKBの内部状態の特定の部位を反映している。
Indicators always reflect specified part of XKB internal state. Two common modes is showing
 
  +
以下に2つ例を示す。
modifier state:
 
  +
  +
モディファイヤの状態を示す例:
   
 
xkb_compatibility {
 
xkb_compatibility {
535行目: 532行目:
 
}
 
}
   
  +
現在のグループを示す例:
or current group:
 
   
 
xkb_compatibility {
 
xkb_compatibility {
541行目: 538行目:
 
}
 
}
   
  +
値はビットマスクの値である。
The values are bitmasks. For groups, bit 1 is group 1, bit 2 is group 2 and so on.
 
  +
グループに関してはビット1がグループ1を表しビット2がグループ2を表す、などと言った具合である。
   
 
== Modifiers and types ==
 
== Modifiers and types ==
   
  +
ある時点で type セクションを除去したり、特殊な type を導入したり、あるいはその両方を行わなくてはならないことがあるかもしれません。
At some point it may become necessary to clean up types section, and/or to introduce
 
  +
unusual types.
 
  +
タイプ及びモディファイヤは強く結び付けられており、タイプの記述について話を始めるにあたってモディファイヤビットから始めることは大いに意味があることです。
   
  +
まずどのビットを使うかを決めましょう。選択肢は8つしかありません。
Types and modifiers are tightly connected, so it makes a lot of sense to start with
 
  +
更に、Shift, Control 及び Mod1 はいろんなアプリケーションによって広く用いられています。
the modifier bits first, before doing anything with the type descriptions.
 
  +
Lock(別名 CapsLock)は事前に定義された意味を持ち上書きするのは難しいでしょう。
  +
したがって実際には4つが自由に使えることになります。
   
  +
'''警告''' :4つの標準的なタイプ、ONE_LEVEL, TWO_LEVEL, ALPHABETIC 及び KEYPAD は xkbcomp の中で
Decide which bits you will use. There are only eight of them, and of those,
 
  +
特別な扱いを受けます。これらはただ単にこのように名付けられているという理由により異なる動作をするでしょう。
Shift, Control and Mod1 are widely used in applications, and Lock (aka CapsLock)
 
  +
これらを削除するのは避けてください。もしこれらのタイプに変更を加えて思うように行かなかった場合は、
has pre-defined meaning which also may be hard to override.
 
  +
代わりに新しいタイプを追加するようにしてください。
The remaining four, however, are fair play.
 
   
  +
=== 標準タイプにおける real modifiers の使用 ===
Warning: four standard types, ONE_LEVEL, TWO_LEVEL, ALPHABETIC and KEYPAD, receive
 
special treatment in xkbcomp. They may work differently just because they are named
 
this way. Avoid deleting them. If some changes do not work as expected, try adding a new
 
type instead.
 
   
  +
あなたのベースとなる設定によっては、EIGHT_LEVEL や PC_RCONTROL_LEVEL2 のように使用されない標準タイプが出てくるでしょう。
=== Using real modifiers in standard types ===
 
  +
意図しない動作を避けるためにそれらは削除してしまってください。
   
  +
さて、いくつかの標準タイプは仮想モディファイヤを使用しています。
Depending of your base configuration, there may be a lot of unused standard types
 
  +
もしそれらを使用すると決めたのなら、この節を飛ばして後述の仮想モディファイヤの節に目を通してください。
like EIGHT_LEVEL or PC_RCONTROL_LEVEL2.
 
  +
そうでないならば、仮想モディファイヤについては一掃してしまうのがよいでしょう。
Remove them to avoid doing unnecessary work.
 
  +
あなたが必要なタイプを確認し、それらをリアルなモディファイヤで置き換えるか定義自体を削除するかしてください。
   
  +
例:
Now, some standard types use virtual modifiers. If you decide to use them, check
 
Virtual modifiers below and skip this section. Otherwise, it's a good idea
 
to get rid of them completely. Check the types you need, and either replace them
 
with corresponding real ones, or remove relevant definitions. Example:
 
   
 
type "KEYPAD" {
 
type "KEYPAD" {
580行目: 577行目:
 
};
 
};
   
  +
もしあなたが Mod2 を NumLock として用いたいのなら、タイプを以下のように変更してください。
if you use Mod2 for NumLock, change the type to
 
   
 
type "KEYPAD" {
 
type "KEYPAD" {
590行目: 587行目:
 
};
 
};
   
  +
もしあなたが NumLock モディファイヤを使用したくないのならば、以下のようにしてください。
if you are not going to have NumLock modifier, change it to
 
   
 
type "KEYPAD" {
 
type "KEYPAD" {
599行目: 596行目:
 
};
 
};
   
Do the same in xkb_compatibility section too.
+
xkb_compatibility セクションでも同様にしてください。
  +
一度この設定を行うとすべての「virtual_modifiers」行をファイルから削除することができるようになるはずです。
Once it's done, you should be able to remove all "virtual_modifiers" lines in the file.
 
   
  +
=== 単独のモディファイヤビットの切り替え ===
=== Switching a single modifier bit ===
 
   
  +
基本的にはあなたが必要としているのは関連する一つの interpret エントリを伴う一つのキーシムです。
Basically all you need is a keysym with a relevant interpretation entry.
 
Example for Mod5 switching with {{ic|LWIN}} key, with {{ic|ISO_Level3_Shift}} for keysym:
+
{{ic|LWIN}}キーのキーシムを{{ic|ISO_Level3_Shift}}に変更し Mod5 の切り替えに使用する例:
   
 
xkb_compatibility {
 
xkb_compatibility {
615行目: 612行目:
 
}
 
}
   
Aside from {{ic|SetMods}}, you can also use {{ic|LockMods}} or {{ic|LatchMods}}.
+
同様のやり方で{{ic|SetMods}}以外にも,{{ic|LockMods}}{{ic|LatchMods}}を特定のキーに設定できます。
{{ic|SetMods}} makes a regular "on while pressed" modifier key.
+
{{ic|SetMods}}は通常の"on while pressed(押している間だけ)" 修飾キーを作ります。
{{ic|LockMods}} makes an "on/off" switch like CapsLock or NumLock.
+
{{ic|LockMods}}はCapsLockやNumLockのような"on/off"スイッチを作ります。
{{ic|LatchMods}} means "on until next keypress" aka sticky modifier
+
{{ic|LatchMods}}"on until next keypress(次のキーが押されるまで)"修飾キー別名スティッキー修飾キーを作ります。
   
 
=== modifier_map ===
 
=== modifier_map ===
   
  +
モディファイヤマップは8つのモディファイヤビットを最大で2つのキーにマップするテーブルです。
Modifier map is a table that maps each of eight modifier bits to at most
 
  +
two keys:
 
  +
Mod1ビットを左右のAltキーにマップする例:
   
 
modifier_map Mod1 { Alt_L, Alt_R };
 
modifier_map Mod1 { Alt_L, Alt_R };
633行目: 631行目:
 
interpret Alt_R { action = SetMods(modifiers=Mod1); };
 
interpret Alt_R { action = SetMods(modifiers=Mod1); };
   
XKB does not use modifier map in its original meaning. Within XKB, its
+
XKB does not use modifier map in its original meaning.
  +
XKBの内部では、それは単に仮想モディファイヤ(後述)をマップするための機能に過ぎません。
only function is to map virtual modifiers (see below).
 
   
  +
しかしながら、このテーブルはクライアントには簡単にアクセス可能であり、
However, the table is easily accessible by clients, and there is one
 
  +
このテーブルを用いた直感には反するがよく知られたひとつのトリックが存在します:
counter-intuitive (but well-known) trick involving it:
 
  +
モディファイヤマップを ModX ビットのどれが Altであるかを知るために使用するというものです。
modifier map is used to tell which of ModX bits is Alt.
 
  +
この理由により、上述のように Alt_L 及び Alt_R にマップされた一つのモディファイヤを持つというのは良いアイデアです。
Because of this, it is a good idea to have one modifier mapped
 
  +
特に理由がない限りは、この場合 Alt に割り当てるモディファイヤビットは Mod1 にするべきです。
to Alt_L or Alt_R as shown above. Unless you have very good reasons
 
to do otherwise, it should be Mod1.
 
   
  +
== 複数のキーボード ==
== Multiple keyboards ==
 
   
  +
XKBでは接続された一つの物理キーボードに対するキーマップのみしか設定することができません。
XKB allows setting keymap for a single connected physical keyboard only.
 
  +
この特性は問題となるキーボードが異なっている場合には非常に有用です。
This feature can be extremely useful for multi-keyboard setups when keyboards
 
  +
例えばフルサイズのUSBキーボードが接続されたラップトップPCを考えてみましょう。
in question are different; consider a laptop with a full-size USB keyboard attached.
 
   
First of all, use xinput (package {{Pkg|xorg-xinput}}) to get device IDs:
+
まずはじめに、xinput (package {{Pkg|xorg-xinput}})を用いてデバイスIDを取得しましょう:
   
 
AT Translated Set 2 keyboard id=11 [slave keyboard (3)]
 
AT Translated Set 2 keyboard id=11 [slave keyboard (3)]
   
  +
次に,
Now,
 
   
 
xkbcomp -i 11 file.xkb $DISPLAY
 
xkbcomp -i 11 file.xkb $DISPLAY
   
  +
あるいは
or
 
  +
 
setxkbmap -device 11 ...
 
setxkbmap -device 11 ...
   
  +
として特定のキーボードのみにキーマップを設定しましょう。
will set keymap for specified keyboard only. Dumping XKB configuration works too:
 
  +
XKB コンフィギュレーションのダンプも同様に機能します:
   
 
xkbcomp -i 11 $DISPLAY file.xkb
 
xkbcomp -i 11 $DISPLAY file.xkb
   
  +
TIPS:ありがちな間違いとしてはディバイスを指定しようとして {{ic|xkbcomp -i11}} とタイプしてしまうことです。{{ic|-i}}オプションの後ろにスペースを挿入するようにしてください。
Note {{ic|xkbcomp -i11}} will not work and will not give a clear error message either. Make sure
 
you have space after {{ic|-i}}.
 
   
 
== XKB のデバッグ ==
 
== XKB のデバッグ ==
675行目: 673行目:
 
indicator "LED3" { controls = audiblebell; };
 
indicator "LED3" { controls = audiblebell; };
 
 
  +
それに加えて、 xkbwatchを使用するとすべての(リアル)モディファイヤをそれらのlock/latchステータスと同時に見ることができます。
Additionally, xkbwatch shows all (real) modifiers together with their lock/latch status.
 
  +
モディファイヤビットはxevでも見ることができます. Xxkb では有効なgroupを見ることができますがその場合two_state modeはオフにするようにしてください。
Modifiers are also reported by xev. Xxkb can be used to monitor effective group, but
 
make sure two_state mode is off.
 
   
  +
Interpretationsセクションが思ったように動かない場合には、"interpret" blocksに重複がないかチェックしてください。 もし可能ならば、特定のキーシムに関係する記述をすべてコメントアウトしてみてください。
In case interpretations section does not work well, make sure to check for duplicated
 
  +
このあたりの話は9.2節でより詳しく説明されます。
"interpret" blocks. Better yet, try commenting out anything related to specific keysym.
 
See section 9.2 for explanation.
 
   
  +
キーマップをダウンロードしてサーバーが厳密に何を受け取っているのかをチェックすることもまた意味があります。
It also makes sense to check what exactly the server got by downloading the keymap back with
 
  +
キーマップのダウンロードは以下のように行います。
 
 
 
xkbcomp $DISPLAY out.xkb
 
xkbcomp $DISPLAY out.xkb
   
  +
結果として出てくるファイルはインプットファイルと異なっていることが多いですが、
The results tend to be different from the input file. There is no known work-around for this.
 
  +
それを解決する次善策は知られていません。
   
  +
== 仮想モディファイヤ ==
== Virtual Modifiers ==
 
   
  +
XKBの中で最も厄介な部分の一つが仮想モディファイヤです。
One of the most troublesome parts of XKB, virtual modifiers appear prominently
 
  +
その機能は比較的マイナーでほとんどの場合無用であるにも関わらずすべての標準的なキーマップで目立つ位置に現れます。
in all standard keymaps, despite being a relatively minor and mostly useless feature.
 
  +
「仮想モディファイヤ」という用語は甚だしく誤解を招きやすく、ほとんどの文献は助けにならなりません。
The term itself is grossly misleading, and most of the docs do not help much either.
 
   
  +
したがって、まず何よりもはじめに'''「仮想モディファイヤはリアルモディファイヤがそうであるような意味ではモディファイヤではない」'''ということを強調しておきたいです。。
So, first of all: virtual modifiers are not modifiers in the same way real modifiers are.
 
  +
それどころか仮想モディファイヤというのはリアルモディファイヤにエイリアスを振るために存在すると言っていいでしょう。
If anything, it is a way to name some of the real modifiers. They are not 16 more bits
 
  +
レベル定義に使えるビットが16個追加されるわけではないのです。
that can be used in level definitions. They are 16 possible names, each referring
 
  +
それらは単に8つあるモディファイヤビットの一つ(あるいは複数、場合によっては0個)を参照する
to one (or some, or none) of the 8 modifier bits.
 
  +
16個の可能な名前に過ぎないのです。
   
Real modifier bits are called Shift, Lock, Control and Mod1-Mod5. There are no
+
リアルモディファイヤビットは Shift, Lock, Control そして、Mod1-Mod5 と呼ばれます。
  +
そこには Alt というビットは存在しません。
Alt among them. Virtual modifiers were introduced to allow saying something like
 
  +
仮想モディファイヤはC言語のヘッダ風に書くならば以下のようなマクロ定義をできるようにしている似すぎません。
 
 
 
#define Alt Mod1
 
#define Alt Mod1
   
  +
この記述によって Alt キーを修飾キーとして使いたがっているアプリケーションに適切に情報が渡ります。
to applications willing to use this information.
 
   
  +
仮想モディファイヤを一切定義することなく実用的なレイアウトを作ることも可能です。
It is possible to make a usable layout without defining virtual modifiers at all.
 
  +
標準的なモディファイヤの中で、Alt と Meta だけがこのような仮想モディファイヤを用いた取り扱いの必要があります。
Among standard modifiers, only Alt/Meta actually need such treatment, because
 
  +
なぜならば、なんにせよShift及びControlはリアルモディファイヤであり、NumLockは通常モディファイヤとしては使われないからです。.
Shift and Control are real modifiers anyway and NumLock is not normally used as a modifier.
 
   
  +
また、基本的なXlibの機能を使用するすべてのアプリケーションに影響するキーマップに関連した事柄と違って
Also, unlike most of the keymap-related things that affect any application using
 
  +
仮想モディファイヤはXKBlibの呼び出しから明示的に問い合わせられます。
basic Xlib functions, virtual modifiers must be queried explicitly using XKBlib
 
  +
つまりすべてのアプリケーションに影響があるわけではないのです。
calls. Not all applications actually do that.
 
   
  +
=== 仮想モディファイヤの定義 ===
=== Defining virtual modifiers ===
 
   
  +
仮想及びリアルモディファイヤのマッピングはキーシムを媒介とする風変わりなやり方で定義されます。
The mapping between virtual and real modifiers is defined in a rather weird way
 
  +
そのようにな作法の裏にある理由を知りたければXKBprotoを参照してください。
using keysyms as a medium. Refer to XKBproto for some reasons behind this.
 
  +
まず以下のようにしてリアルモディファイヤMを適当なキーに割り当てます。
Real modifiers M are assigned to a key using
 
   
 
modifier_map M { <keysym> };
 
modifier_map M { <keysym> };
   
  +
仮想モディファイヤVは以下のようにしてそのキーに割り当てることができます。
Virtual modifiers V can be assigned to a key using
 
   
 
interpret <keysym> { virtualMod = V; };
 
interpret <keysym> { virtualMod = V; };
   
  +
もし仮想モディファイヤVがリアルキーMと一つでもきーシムを共有していれば、それはMにバインドされます。
If a virtual modifier V shares at least one keysym with a real modifier M,
 
it is bound to M.
 
   
  +
注:仮想モディファイヤの名前は事前に定義されているわけではなくてそれらを使用する前に
Note that virtual modifier names are not pre-defined and must be declared in
 
xkb_compatibility and xkb_types sections before using them:
+
xkb_compatibility及びxkb_typesセクションで定義する必要があります:
   
 
xkb_compatibility "complete" {
 
xkb_compatibility "complete" {
737行目: 736行目:
 
}
 
}
   
=== Keysym interpretation ===
+
=== キーシムの解釈 ===
   
  +
仮想モディファイヤは "interpret <keysym>" ブロックであたかもそれら一つ一つが某かのリアルモディファイヤに対して定義されているかのごとく使用することができます。
Virtual modifiers can be used in interpret <keysym> blocks as if they were
 
  +
このことは、いかなるリアルモディファイヤにもバインドされていない仮想モディファイヤVに対しては、
defined to the respective real modifiers. For a virtual modifier V not bound
 
to any real modifier, this means
 
 
 
 
#define V
 
#define V
   
  +
のような宣言を行ったことを意味し(すなわち none にマップされる)
type declaration, and
 
 
 
 
interpret <key> { }
 
interpret <key> { }
 
interpret <key>+V { }
 
interpret <key>+V { }
   
  +
ブロックは重複として扱われます。
blocks will be treated as duplicates. Only one of them, the last one in the file, will work.
 
  +
その場合これらのうち一つだけ、より厳密に言うならファイルの中の最後のものだけ、が動作します。
xkbcomp usually gives a warning in cases like this.
 
  +
このような場合xkbcompは通常警告を出します。
   
  +
=== クライアントサイドのノート ===
=== Client side notes ===
 
   
  +
XKB仮想モディファイヤをクライアントサイドで扱うには非自明なサーバーとのインタラクションが必要になります。
Handling XKB virtual modifiers on the client side requires some non-trivial server interaction.
 
  +
ほとんどのアプリケーションはそのような面倒をせず、単に XkeyEvent.state によって提供される
Most applications just do not bother, sticking with 8 real modifiers supplied in XKeyEvent.state.
 
  +
8つのリアルモディファイヤでやりくりしています。
   
  +
しかしながら、アプリケーションがキープレスに関連した仮想モディファイヤを得ることはありえます。
However, it is possible for an application to obtain virtual modifiers associated with a key press.
 
Gtk, for instance, has [http://www.gtk.org/api/2.6/gdk/gdk-Keyboard-Handling.html#gdk-keymap-translate-keyboard-state gdk-keymap-translate-keyboard-state()]
+
例えば、Gtk [http://www.gtk.org/api/2.6/gdk/gdk-Keyboard-Handling.html#gdk-keymap-translate-keyboard-state gdk-keymap-translate-keyboard-state()] というような
  +
アプリケーションによって使われたり使われなかったりする関数を提供しています。
which may or may not be used in particular application.
 
   
  +
仮想モディファイヤのサポートらしきものを実装することは可能なのかもしれないが、実際にはありません。
Some others may implement something that looks like virtual modifier support, but actually is not.
 
  +
5.3.3.2節の openbox の例を見てください。Altの扱いについて知りたければ, 8.3節を読んでください。
Check openbox example in section 5.3.3.2. Regarding Alt handling, check section 8.3.
 
   
 
== XKB 制御ビット ==
 
== XKB 制御ビット ==
   
  +
XKBの機能の様々な側面に影響を与えるビットの束。
A bunch of bit flags affecting various aspects of XKB functionality.
 
To control them, use {Set,Latch,Lock}Controls actions.
+
これらをコントロールするには{Set,Latch,Lock}Controlsアクションを使用しましょう。
 
=== オーバーレイ ===
 
 
特定のキーのキーコード (とキーシム) を一時的に変えることができる機能です。例:
 
 
xkb_keycodes {
 
<KP4> = 83; // both keycodes must be defined,
 
<K04> = 144; // even if the device cannot produce the second one
 
};
 
 
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 ] };
 
};
 
 
Let us assume 83 is a "real" code the keyboard can produce. With overlay1 bit off,
 
the key will produce KP_Left keysym. With overlay1 bit on, it will produce keycode 144
 
and associated keysym KP_4, taking it from a different xkb_symbols row.
 
 
The principal difference between overlays and user-defined types, which can be used to
 
accomplish similar behavior too, is that overlays change keycode and leave no traces in the state field.
 
However, overlays are very limited. There are only two control bits, overlay1 and overlay2),
 
and each key can have only one alternative keycode, so writing
 
 
key <KP4> { [ KP_Left ], overlay1=<KO4>, overlay2=<KX4> };
 
 
is useless (but xkbcomp will not warn you). Each key has only one "alternative keycode" field,
 
the choice between overlay1= and overlay2= only determines which of the two bits
 
enables that alternative keycode.
 
 
The only well-know application for overlays is implementing keypad/NumLock, as shown above.
 
Check /usr/share/X11/xkb/symbols/keypad for a complete example.
 
   
 
=== マウスの操作 ===
 
=== マウスの操作 ===
812行目: 774行目:
 
XKB によってキーボードからマウスポインタを操作することができます。適切に設定すれば、とっても便利です。ただし、どれくらい有用かは物理的なキーボードレイアウトやユーザーの個別設定によるところが大きいでしょう。
 
XKB によってキーボードからマウスポインタを操作することができます。適切に設定すれば、とっても便利です。ただし、どれくらい有用かは物理的なキーボードレイアウトやユーザーの個別設定によるところが大きいでしょう。
   
  +
XKB の観点からすればこれは簡単に実装することができます。ユーザーは単に関連するアクションをトリガーすればよいのです。
From XKB point of view it is relatively simple to implement, one should just trigger
 
  +
極めて完璧な実装が
relevant actions. Fairly complete implementation can be found in
 
 
{{ic|/usr/share/X11/xkb/compat/mousekeys}}.
 
{{ic|/usr/share/X11/xkb/compat/mousekeys}}.
  +
に見られます。
   
  +
注:{{ic|MouseKeys}} コントロールビットが設定されるまではマウス関連のアクションは機能しません:
Note that the actions will not work unless {{ic|MouseKeys}} control bit is set:
 
   
 
interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys); };
 
interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys); };
   
  +
ほとんどのキーボードはマウスコントロールに特化したキーを持たないため、
Because most keyboards do not have dedicated mouse control keys,
 
  +
combining {{ic|MouseKeys}} and one of the {{ic|Overlay}} flags may be a good idea:
 
  +
{{ic|MouseKeys}} と {{ic|Overlay}} フラグのどちらかを組み合わせるというのは良い考えです:
   
 
interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys+Overlay1); };
 
interpret Pointer_EnableKeys { action= LockControls(controls=MouseKeys+Overlay1); };
   
  +
こうすることによってポインターをコントロールするキーの定義を適切なオーバーレイブロックに移動することができます。
This allows moving pointer control keys to appropriate overlay block:
 
   
 
xkb_keycodes {
 
xkb_keycodes {
846行目: 810行目:
 
}
 
}
   
  +
このようにしてマウスでないアクションをマウスをコントロールするのに使用することができます。
This way it is possible to assign non-mouse actions to the keys used to control mouse,
 
  +
例えば修飾キーでマウスボタンのイベントを生成することもできます。
and thus, for example, use modifier keys to generate mouse buttons events.
 
   
 
== ローカル XKB フォルダ ==
 
== ローカル XKB フォルダ ==
895行目: 859行目:
 
== 参照 ==
 
== 参照 ==
   
http://www.x.org/wiki/XKB and links therein, especially
+
https://www.x.org/wiki/XKB and links therein, especially
   
 
* [http://www.charvolant.org/~doug/xkb/html/index.html An Unreliable Guide To XKB Configuration]. Similar in scope to this page, with a bit different point of view. Recommended for a general picture.
 
* [http://www.charvolant.org/~doug/xkb/html/index.html An Unreliable Guide To XKB Configuration]. Similar in scope to this page, with a bit different point of view. Recommended for a general picture.
 
* [http://pascal.tsu.ru/en/xkb/ 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.
 
* [http://pascal.tsu.ru/en/xkb/ 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.
* [http://www.x.org/releases/current/doc/kbproto/xkbproto.pdf 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.
+
* [https://www.x.org/releases/current/doc/kbproto/xkbproto.pdf 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.
* [http://www.x.org/wiki/XKB X.org Wiki - XKB]. Additional links to XKB resources.
+
* [https://www.x.org/wiki/XKB X.org Wiki - XKB]. Additional links to XKB resources.

2018年2月6日 (火) 23:54時点における版

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

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

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

ヒント: このページは基本的には 英語版の記事 の翻訳ですが、扱っている機能が言語に依存するものであり適宜日本語ユーザーに必要と思われる補足を入れていくことにします。

用心と準備

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 ショートカットは ControlControl+Mod3 を区別しないのが普通です。

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

キーコードの翻訳

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

(keycode, group, state) → keysym

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

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

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

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

型 (Type) はどの修飾子がどのキーに影響を及ぼすかを示すものです。基本的にはこれが 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 ターミナルでは aCtrl+a の状態 (state) は異なりますがキーシムは同じです。一方 aA はキーシム自体が異なっています。

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

また、XKB における状態は遅延評価のような扱いを受けます。つまり、それはユーザーがキーを押す前に状態をセットしておかなくてはならないということです。

例: rxvt で Ctrl+h はバックスペースとして機能するようにアプリケーション内で設定できます。この場合、rxvt は {ic|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

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

実際に問題となるキーのみを残しておくと言うのは良いアイデアです。

ラベル自体は任意です。後ろに続くの 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を鋭アクセントの付与に使用できます。 aU0061は別物として扱われます(例えば, 殆どのアプリケーションは Ctrl+U0061ではなくCtrl+aが送信されてくることを期待します。なぜならそれらの持つ数値的な値が異なるからです。

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

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 をグループあるいはレベルの変更にもちいるということを意味します。

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

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

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

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

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

4つのレイアウトを使用する場合にはほとんどの場合 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」をグループ2のために「Shift Menu」をグループ3のために割り当てるというものです(訳注:対称性にかけるので念のために記しておくとグループ2の時に「Menu」を押すとグループ1に戻り、レイアウト3の時に「Shift Menu」を押すとグループ1に戻るというようになっている。)。 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 のビットを(レベル3のビットとして)使うということです。

今度は、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の内部状態の特定の部位を反映している。 以下に2つ例を示す。

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

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 を導入したり、あるいはその両方を行わなくてはならないことがあるかもしれません。

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

まずどのビットを使うかを決めましょう。選択肢は8つしかありません。 更に、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以外にも,LockModsLatchModsを特定のキーに設定できます。 SetModsは通常の"on while pressed(押している間だけ)" 修飾キーを作ります。 LockModsはCapsLockやNumLockのような"on/off"スイッチを作ります。 LatchModsは"on until next keypress(次のキーが押されるまで)"修飾キー別名スティッキー修飾キーを作ります。

modifier_map

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

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つあるモディファイヤビットの一つ(あるいは複数、場合によっては0個)を参照する 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 によって提供される 8つのリアルモディファイヤでやりくりしています。

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

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

XKB 制御ビット

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

マウスの操作

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

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

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

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

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

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

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 キーボードを切断すると設定が消える

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

参照

https://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.