Xのキーマッピングは、主にSOやSUなどの場所から例をコピーして貼り付け、それが機能するかどうかを確認することを含む、私にとっては少しブラックアートであることを最初に認めます。ただし、この場合、xcapeとi3lockをうまく連携させるために何が起こったのかをよりよく理解する必要があります。
Xcapeユーティリティを使用して、長押しするとリターンキーを別のコントロールにマッピングし、押したり離したりしても通常のキー押下として動作します。この設定は次のようになります。
if [ -e ${XCAPE} ]; then
killall xcape 2> /dev/null
${XMODMAP} -e 'keycode 36 = 0x1234'
${XMODMAP} -e 'add control = 0x1234'
${XMODMAP} -e 'keycode any = Return'
${XCAPE} -e '0x1234=Return'
KEYMAPS="${KEYMAPS} StRet->Ctrl"
fi
私がこれを理解しているように、それはリターンキー(36)を偽のキー(0x1234)に再マップします。次に、マップを変更して、コントロールも(0x1234)にマップされるようにします。次に、xcapeは「魔法」を実行して、長押しに応じて正しいキーコードが送信されるようにします。
これはすべて正常に機能しますが、起動する前にXキーボードマップの操作を行う画面ロックプログラム(i3lock)が壊れます。次のメッセージで失敗します。
Error: (unknown file):1092:13: syntax error
Error: Failed to parse input xkb file
[i3lock] xkb_keymap_new_from_file failed
i3lock: Could not load keymap
キーマップをダンプするためにデバッグを追加すると、混乱を引き起こしたのは次の行であると推測しました。
xkb_symbols "pc_gb_inet(evdev)_ctrl(nocaps)" {
name[group1]="English (UK)";
key <> { [ Return ] };
key <ESC> { [ Escape ] };
key <AE01> {
...
では、何が起こったのでしょうか。 2つは根本的に互換性がありませんか? i3lockを実行する前に、キーマップを部分的に復元する必要がありますか?
したがって、よく掘り下げた後、最初の 'keycode any = Return'は、i3lockキーマップ処理を混乱させるキーコード8を設定することがわかりました。さらに、パスワードを入力できるように、キーコード36がリターンを生成することを確認する必要があります。
I3lockの呼び出しをスクリプトでラップしたので、i3の構成では次のようになります。
# background, screensaver and locking
exec xautolock -time 10 -locker '/home/alex/.config/i3/lock_screen.sh'
bindsym $mod+l exec /home/alex/.config/i3/lock_screen.sh
ロック画面のスクリプトは単純です。
# The initial key-sequence chosen by xcape does confuse i3lock so we reset it
xmodmap -e "keycode 8 = "
# Ensure the return key does work as intended
xmodmap -e 'keycode 36 = Return'
i3lock -c 334433