super + key binding not working

[KestrelSoftworks]

Hardware: Lenovo Thinkpad laptop

When editing sxhkdrc like:

Super_L + f
    firefox

makes f key to bind to firefox command, and the actual Super_L + f prints the "f" letter in the terminal. I'm setting the key names according to what xev prints when I press the desired keys. The same error goes using super instead of Super_L If I try to add a different key combo like Super_L + Return it happens the same; Return binds to whatever command I associate in the next line, and Super_L + Return executes return normally.

What can be causing this?

sxhkd version is 0.6.1

[alichtman]

I have a similar issue on Ubuntu 20.10, same sxhkd version. I am using a Razer Chroma Ornata keyboard. Super keybindings ARE properly detected by Ubuntu, just not sxhkd.

@baskerville Any ideas what could be going on?

[amacgregor]

I have similar issues in Ubuntu 20.10 bindings are partially working but not all of them, workspaces for example correctly bind up to 5 but 6 to 9 won't work.

[KestrelSoftworks]

I messed around a bit with the code and xev.

• The problem not doing the super + n (where n is whatever desired key) combo correctly seems to be fixed if sxhkd is executed from bspwmrc instead of .xinitrc which was my case. Although the combo keeps breaking if I try to do a hot reload of sxhkd.

• I've also noticed that binding the Print key to anything in sxhkdrc makes other keys to misbehave, and the keyboard layout operates in a strange way, making the up arrow key act as the Print.

[amacgregor]

Interesting I have this issue and I am starting sxhkd from bspwmrc here is my configuration for reference:

https://gist.github.com/amacgregor/9d0b556103db9f5c5a2f1def6ba874ac

[KestrelSoftworks]

Interesting I have this issue and I am starting sxhkd from bspwmrc

Well, that makes my temporal fix a false positive. Thanks for commenting it (: I'm going back in my tests to look what can be then.

[adigitoleo]

@KestrelSoftworks

From man sxhkd:

The underscore character represents an empty sequence element.

Perhaps in your initial example, the underscore is not parsed how you expect.

[emanuele6]

Super_L + f
    firefox

Super_L + f is not a valid chord: it's formed by two keysyms!

The manual defines the config syntax like so:

General syntax:

    HOTKEY
        [;]COMMAND

    HOTKEY      := CHORD_1 ; CHORD_2 ; ... ; CHORD_n
    CHORD_i     := [MODIFIERS_i +] [~][@]KEYSYM_i
    MODIFIERS_i := MODIFIER_i1 + MODIFIER_i2 + ... + MODIFIER_ik

The valid modifier names are: super, hyper, meta, alt, control, ctrl,
shift, mode_switch, lock, mod1, mod2, mod3, mod4, mod5 and any.

The keysym names are given by the output of xev -event keyboard.

[...]

Notice that you can't have a chord with two keysyms: you can only have chords with exactly one keysym and with any number of modifiers.

Some examples:

• Super_L and f are both keysyms → ❎ Super_L + f is an invalid hotkey (0m+2k);
• super is a modifier and f is a keysym → ☑️ super + f is a valid hotkey (1m+1k);
• super is a modifier → ❎ super is an invalid hotkey (1m+0k);
• Super_L is a keysym → ☑️ Super_L is a valid hotkey (0m+1k).

You are misusing sxhkd trying to bind something to Super_L + f, so you should expect..

Super_L + f
	firefox

..to not work!

[adigitoleo]

@KestrelSoftworks

• The problem not doing the super + n (where n is whatever desired key) combo correctly seems to be fixed if sxhkd is executed from bspwmrc instead of .xinitrc which was my case. Although the combo keeps breaking if I try to do a hot reload of sxhkd.

Actually I did experience this issue yesterday as well, all of a sudden. Launching from bspwmrc fixed it for me (thanks). This is for version 0.6.2

• I've also noticed that binding the Print key to anything in sxhkdrc makes other keys to misbehave, and the keyboard layout operates in a strange way, making the up arrow key act as the Print.

Interesting, I have a binding for Print and I think I remember some other keys acting as Print when I was launching from xinitrc. I will check if the issue persists if launching from bspwmrc.

[adigitoleo]

@amacgregor

Interesting I have this issue and I am starting sxhkd from bspwmrc here is my configuration for reference:

https://gist.github.com/amacgregor/9d0b556103db9f5c5a2f1def6ba874ac

Looking at your config, I see that you are starting compton after sxhkd. I have absolutely no idea what is causing this issue, but in my config I start the compositor in xinitrc, and launching sxhkd later from bspwmrc works for me.

[ghost]

Interesting I have this issue and I am starting sxhkd from bspwmrc here is my configuration for reference:

https://gist.github.com/amacgregor/9d0b556103db9f5c5a2f1def6ba874ac

I'm having the same issue, keybinds work after restart but when I hot reload they stop working even after killing and running sxhkd again manually. I swapped my ALT and SUPER keys because I am running bspwm in a VM on a Windows host. I noticed you did the same and I believe that is the problem. As a test I disabled the config that remaps Super Alt and sxhkd works as expected.

[wardw]

On starting/reloading sxhkd: for those doing any keyboard layout changes I found it important that these are done before sxhkd is started.

On reloading sxhkd I found that sending sxhkd the -USR1 signal to reload wasn't sufficient if keyboard layout changes have been made since sxhkd was first launched (say, with setxkbmap or xmodmap) and where sxhkd is maintaining the same PID since before the layout change. However, killing the process entirely and relaunching seems to fix it for me. That is, it has been sufficient for me to do pkill -x sxhkd && sxhkd & rather than pkill -USR1 -x sxhkd after making any keyboard layout changes. I've actually modified my config

super + Escape
	pkill -USR1 -x sxhkd
super + shift + Escape
	pkill -x sxhkd && sxhkd

@0xPr0x an aside: xkb also has the option -option altwin:swap_lalt_lwin or -option altwin:swap_alt_win so you can remove the dependency on xmodmap from your config :). For a full list see if you have /usr/share/X11/xkb/rules/base.lst.

[axmad386]

On starting/reloading sxhkd: for those doing any keyboard layout changes I found it important that these are done before sxhkd is started.

On reloading sxhkd I found that sending sxhkd the -USR1 signal to reload wasn't sufficient if keyboard layout changes have been made since sxhkd was first launched (say, with setxkbmap or xmodmap) and where sxhkd is maintaining the same PID since before the layout change. However, killing the process entirely and relaunching seems to fix it for me. That is, it has been sufficient for me to do pkill -x sxhkd && sxhkd & rather than pkill -USR1 -x sxhkd after making any keyboard layout changes. I've actually modified my config

super + Escape
	pkill -USR1 -x sxhkd
super + shift + Escape
	pkill -x sxhkd && sxhkd

@0xPr0x an aside: xkb also has the option -option altwin:swap_lalt_lwin or -option altwin:swap_alt_win so you can remove the dependency on xmodmap from your config :). For a full list see if you have /usr/share/X11/xkb/rules/base.lst.

this solution works for me. I used dvorak programmer layout. When I use external keyboard, super key binding is valid, but when using internal keyboard it's doesnt work. pkill -x sxhkd && sxhkd do the trick. The config example should include this IMO.

[YasirAtiq]

New here I can't even open my terminal! Here is my binding for sxhkd for my terminal:

super + enter
             urxvt

[YasirAtiq]

New here I can't even open my terminal! Here is my binding for sxhkd for my terminal:

super + enter
             urxvt

Anything which I have configured with the super key doesn't work like dmenu (I'm still configuring) and reloading my configs. P.S. my hardware is Lenovo Thinkpad Laptop (Using Arch on VirtualBox)

[arktnld]

I have been experiencing this issue. I thought that sxhkd had a mode where the Super key was disabled, but I think that doesn't exist

[ferronyanide]

@YasirAtiq Replace enter with Return, it'll work.