i3 のほとんどのキーバインドには Mod4 を使用しますが、これには Mod1 を使用します。
bindsym Mod1+a workspace a
bindsym Mod1+b workspace b
bindsym Mod1+c workspace c
bindsym Mod1+d workspace d
...
ただし、これにより alt と altgr の両方がバインドされますが、一部の文字を入力するために altgr+<letter> を使用するので、これは望ましくありません。
xev は alt は Alt_L、altgr は Alt_R だと言っていますが、bindsym Alt_L+a動作しません
答え1
結局のところ、それは何によるかxmodマップmod1 の場合は と表示されます。たとえば、 と がAlt_L同じAlt_R修飾子にあると表示される場合、競合を避けるために後者を別の修飾子 (使用可能な 5 つの修飾子のうち) に移動する必要があります。
以下に例を示すページをいくつか示します。
- xmodmap で Alt_R を再マッピングすると VC 端末切り替えが無効になりますユーザー
Alt_Rがモッド1にモッド4(そして問題が発生しました)。変更する前に、xmodmap からの出力を確認する必要があります。 - xmodマップArchLinuxでは、修飾子を操作する詳細な例を示しています。動くキーを取得するには追加それを1つの修飾語にし、クリアそれを他から。
使用上の落とし穴xmodmapは、必ずしも知るキーシンボルの適切なキーコード（ などAlt_R）が見つからない場合、通常は、
xmodmap -pk
鍵についてシンボルスクリプトでそのキーコードを割り当てます。たとえば、あるマシンでxmodmap -pkは
108 0xffea (Alt_R) 0x0000 (NoSymbol) 0xffea (Alt_R)
このスクリプトを使用すると
keycode 108 = Alt_R
remove mod1 = Alt_R
add mod3 = Alt_R
出力は次のように変更されます。
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
これに:
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3 Alt_R (0x6c)
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
(この特定のマシンでは、回避策は必要ありません)。