Allow mapping directly to keycodes

[BombchuLink]

For multi-lingual layouts, being able to map to keycodes in (hex)decimal would be very nice for this.

eggsample:

super + #61 
     echo "hello world"

super + #0x6D
     echo "foo"

[brunetton]

+1000

[bricewge]

~~PR #181 implement this feature.~~

[hubisan]

Would be really nice to have this implemented. This is crucial when using multiple keyboard layouts.

Example: If I want to bind super + ; to a command, I have to bind super + ö as well for the German keyboard layout to always be able to use the same keys to invoke the command. Depending on the layouts used, this can get very complicated and confusing.

[im-n1]

@baskerville pretty please can we merge this?

[emanuele6]

@hubisan @im-n1 @bricewge what are you guys talking about? that is NOT what #181 implements.

Today, a guy in the #bspwm IRC channel on libera.chat found your comments and believed them.

---

snippet from the output of xev(1):

KeyPress event, serial 28, synthetic NO, window 0x3000001,
    root 0x114, subw 0x0, time 511886302, (346,424), root:(1032,447),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

That PR adds the ability to for example write super + 0x71 as a substitute for super + q: where 0x71 is the numeric representation of the q keysym in hexadecimal. It does not add the ability to specify keycodes (what, in this example, is 24 for the q key on my keyboard) directly in the HOTKEY definition.

[hubisan]

@emanuele6 The term bindcode is used in i3wm for binding a keycode. So I took it for given that the PR implements this. Thanks you for pointing out that this is not the case, fixed my comment.

[hubisan]

Adding this as information from the pull request #181 as it might be relevant, was at least for me:

Also, the users that are complaining about not being able to bind directly to keycodes in #216 don't seem to realise that, if they want their sxhkd configurations to be keyboard independant, they can just start their sxhkd without the -m <count> option and configure their hotkeys based on the US keyboard layout. sxhkd will not change keycodes for their hotkeys binded to keysyms even if they change keyboard layout at runtime; sxhkd only does that count times if the -m <count> option is passed, or every time if -m -1 is passed; otherwise it will start assuming the US keyboard layout and ignore mapping notify events, so it will never update keycodes.

So there is not even really a need to implement this "bind to keycode" feature that will surely be more complex and awkward to implement than this ~20 lines patch.

[a-pav]

@hubisan what you quoted from @emanuele6 is not ~~true~~ correct. I don't use -m and I still lose my "us" defined sxhkd bindings when I switch layout to, arabic, for example. Perhaps this isn't the case for close languages that share their alphabets, but for languages with different alphabets, it doesn't work.

[emanuele6]

I don't use -m and I still lose my "us" defined sxhkd bindings when I switch layout to, arabic, for example. Perhaps this isn't the case for close languages that share their alphabets, but for languages with different alphabets, it doesn't work.

That has nothing to do with keycodes.

what you quoted from @emanuele6 is not true.

No, what you are saying is not true.

https://user-images.githubusercontent.com/20175435/189543505-4cbae8c8-cd80-46ca-a0e0-9c1091d88ac7.mp4

[a-pav]

That has nothing to do with keycodes.

I didn't say that it does.

No, what you are saying is not true.

I watched your video. That's not what I meant by switching keyboard layout. I have the following command running at startup.

setxkbmap -model pc105 -layout us,ar -option grp:shifts_toggle,grp_led:caps

So switching between layouts is done by pressing both shift keys together.

In this setup, when I switch to arabic layout:

• sxhkd bindings like alt + ctrl + @i do not work.
• but bindings without @ like alt + ctrl + k, work ok!

When changing to arabic layout by reconfiguring setxkbmap, like you did in your video (i.e. setxkbmap ar):

• bindings work regardless of whether there's an @ before keysyms or not.

There might be something wrong with my observation here, but It seems to me that sxhkd currently works ok on different layouts EXCEPT when there's a @. (Although I haven't tested this case above, which contradicts this)

So I guess, maybe, this issue can be resolved by changing sxhkd parser behaviour when there is a @ before keysyms.

[emanuele6]

That has nothing to do with keycodes.

I didn't say that it does.

In this setup, when I switch to arabic layout:

• sxhkd bindings like alt + ctrl + @i do not work.
• but bindings without @ like alt + ctrl + k, work ok!

@a-pav Does that have anything to do with this issue? Did I lie? Would allowing you to bind keys to keycodes directly (what this issue is about) solve your problem? Do hotkeys stop working when you switch keysyms pressing both shifts? The answer to all of these questions is "no".

https://user-images.githubusercontent.com/20175435/189965014-4744f1b7-36fd-4d49-9eb8-7eb78978c174.mp4

Stop being so indecent, and comment on a issue related to your problem or open a new issue if you can't find one. Your problem has nothing to do with this issue.

[a-pav]

My man, I like to think of it as if we're developing together on this issue here. So like any piece of code in a software it's possible that we don't get it completely right in our first attempts. You are right, maybe we should transfer this problem to a separate issue. But me ending up here in a first place isn't so unjustified. As a new sxhkd user, I moved my most used set of keybindings to it, a set of @ prepended bindings executing xdotool commands. They didn't work on layout switch, I googled sxhkd keycode binding, then I was here. I had no intention to call you a lier. I apologize if I offended you that way. I edited my first comment, still not sure if the implied meanings are removed. FWIW English is not my first language.

Would allowing you to bind keys to keycodes directly (what this issue is about) solve your problem?

TL;DR: About this: I think it should, if its implementation is going to be consistent with @ before keysyms.