X の「下位レイヤー」でのキーボードの再マッピング

X の「下位レイヤー」でのキーボードの再マッピング

キーマップは OSI モデルと似たフローを持っていますが、それほど明確に定義されていません。現在、希望よりも高いレベルで再マッピングしています。明らかに、レイヤー 1 は物理キーボードに対応し、レイヤー 7 はアプリケーションに対応していますが、他にレイヤーがいくつあるか、またそれらがどこに位置しているかはわかりません。

これが専用のプログラム可能な物理キーボードを備えたデスクトップであれば、問題ありませんが、残念ながらこれはラップトップであり、内蔵キーボードを使用しながら再マップを維持する必要があります。

ちなみに、私は次のキーのペアを交換しています: [Tilde/Esc]、[Caps/LCtrl]、[Back{space,slash}]。Dvorak も使用していますが、これは OS で標準的な方法で構成されています。

現在、X で変更を加えるために /usr/share/X11/xkb/keycodes/evdev を変更しています (コンソール用のカスタム レイアウト ファイルも作成していますが、これはここでは関係ありません)。これが「レイヤー スタック」のどこに該当するかはわかりません。

問題:私のキーマップは、Web VNC クライアントを使用する Proxmox コンソール セッションには変換されません。(レイアウトも適用されませんが、これは想定内のことです。) 問題は、明らかに、evdev 再マップがまだ適用されていない下位レイヤーで VNC クライアントがキーボードをフックしていることです。

Windows では、KeyTweak というユーティリティを使用してレジストリのスキャンコード マップを生成します。これは基本的に「レイヤー 3」のようです。キーボードを「レイヤー 2」に接続するゲームをプレイしたことがありますが、ほとんどのゲームでは入力がほとんどないため、ほとんど問題にはなりません。

結論は、私の想像上の OSI キーボード モデルで evdev がどこに該当するかはわかりませんが、下位レイヤーで再マップするにはどうすればよいでしょうか。何らかの理由で再マップからスワップアウトする必要がないため、この変更は基本的に永続的です。BIOS で実行できる場合はそうします。

答え1

答えはudevでした。私は基本的にこの郵便受け要点は次のとおりです。

  • インストールevtest
  • 実行してevtest再マッピングしたいキーを押して確認します両方スキャンコードとキーコード。
  • 以下の /etc/udev/hwdb.d/ような内容の新規ファイルを作成します。70-keyremap.hwdb
    • 番号はファイルの順序であると想定していますが、ベースとなる既存のファイルがなかったので、それよりも大きな番号が必要になる前提条件が何なのかはわかりません。実際、hwdb.dTumbleweed にはディレクトリが存在しなかったため、作成する必要がありましたが、それでも機能しました。
  • 走るsystemd-hwdb update
  • リブート

_

# This is from the brokkr.net post I linked above
# Format can be found on [https://wiki.archlinux.org/title/Map_scancodes_to_keycodes].

$ cat 70-keymap.hwdb
evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
 KEYBOARD_KEY_01=41     # Remap Tilde to Esc
 KEYBOARD_KEY_29=01     # Remap Esc to Tilde (evtest showed "1" but when I put that without the leading zero, it was interpreted as the literal [1] key.)
 KEYBOARD_KEY_3A=29     # Remap Caps to LCtrl
 KEYBOARD_KEY_1D=58     # Remap LCtrl to Caps
 KEYBOARD_KEY_0E=43     # Remap Backspace to Backslash
 KEYBOARD_KEY_2B=14     # Remap Backslash to Backspace

アップデート: 上記の方法は私のラップトップではうまくいきましたが、ドッキングすると、外部キーボードはデフォルトのキーマップを使い続けました。これは、内部キーボードが PS/2 を使用して通信しているためであることがわかりました。PS/2 では、AT スキャンコード (atkbdデバイス文字列内) がまだ使用されていますが、USB はまったく異なります。結局、evtest を再度実行して、USB ボードからスキャンコードを取得し、別のマップを書き込む必要がありました。結果のファイルは次のとおりです。

evdev:atkbd:dmi:*
 KEYBOARD_KEY_01=41
 KEYBOARD_KEY_29=01
 KEYBOARD_KEY_3A=29
 KEYBOARD_KEY_1D=58
 KEYBOARD_KEY_0E=43
 KEYBOARD_KEY_2B=14

evdev:input:b0003v*
 KEYBOARD_KEY_70029=41
 KEYBOARD_KEY_70035=01
 KEYBOARD_KEY_70039=29
 KEYBOARD_KEY_700e0=58
 KEYBOARD_KEY_7002a=43
 KEYBOARD_KEY_70031=14

関連情報