hyper modifier is conflated with super

[notpeelz]

I'm using the caps:hyper xkb option to map the hyper modifier to caps lock.

Pressing super-a or capslock-a will do the same thing with this config:

hyper + a
  xmessage test

In xev -event keyboard:

Pressing "caps lock":

KeyPress event, serial 28, synthetic NO, window 0x3800001,
    root 0x1d8, subw 0x0, time 71388248, (551,78), root:(3127,836),
    state 0x10, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x3800001,
    root 0x1d8, subw 0x0, time 71388320, (551,78), root:(3127,836),
    state 0x50, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Pressing "windows key":

KeyPress event, serial 28, synthetic NO, window 0x3800001,
    root 0x1d8, subw 0x0, time 71389352, (551,78), root:(3127,836),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x3800001,
    root 0x1d8, subw 0x0, time 71389428, (551,78), root:(3127,836),
    state 0x50, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Related: #52

[dvogeldev]

Just so happened to spot this from Prot. [https://gitlab.com/protesilaos/dotfiles/-/blob/master/bspwm/.config/sxhkd/sxhkdrc_bspc]

Please be very careful with the syntax of the key bindings for SXHKD. My tests would only yield the desired results when mod3' was referenced explicitly. Writinghyper' would mess things up with `super'.

Hope this helps

[notpeelz]

Hey thanks for replying. Unfortunately it doesn't seem to work for me. Perhaps it behaves differently because Prot uses xmodmap and not the caps:hyper xkb option?

[xulongwu4]

@LouisTakePILLz The option caps:hyper maps CapsLock to Hyper_L. However, it does not change the modifier category Hyper_L belongs to. This is the output of xmodmap after running setxkbmap -option caps:hyper:

$ setxkbmap -option caps:hyper
$ xmodmap
xmodmap:  up to 5 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Hyper_L (0x42),  Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

As you see, Hyper_L still belongs to mod4, which is the same as Super_L. This usually causes conflict in my experience. I used to have similar problems as yours and fixed it by removing Hyper_L from mod4 and then adding it to mod3.