web-dev-qa-db-ja.com

i3ではaltgrではなくaltをバインドします

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は機能しません

x11keyboard-shortcutsi3
4
Alice Ryhl

最終的には、 xmodmap がmod1に対して何を表示するかによって異なります。たとえば、Alt_LとAlt_Rが同じ修飾子上にあることが示されている場合、競合を避けるために、後者を（5つの使用可能な修飾子のうちの）別の修飾子に移動する必要があります。

例を示すいくつかのページを次に示します。

  • xmodmapdisableを使用してAlt_Rを再マッピングするVC端末の切り替え は、ユーザーがAlt_Rをから移動した例を示しています）mod1からmod4（そして問題が発生しました）。変更する前に、xmodmapからの出力を確認する必要があります。
  • ArchLinuxの xmodmap は、修飾子を操作する詳細な例を示しています。キーを移動するには、1つの修飾子に追加し、clear他からそれを。

xmodmapを使用する際の落とし穴の1つは、キーシンボルの適切なキーコード（Alt_Rなど）を常に知っているとは限らないことです。 ）。私がそれに遭遇したとき、私は通常、からの出力を調べることによってそれを回避することができます

xmodmap -pk

キーsymbolの場合、スクリプトでそのキーコードを割り当てます。たとえば、あるマシンでは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)

（この特定のマシンでは、回避策は必要ありません）。

3
Thomas Dickey