Is it possible to re-bind Capslock to Hyper?

abgruszecki commented 4 years ago

Hello,

I've remapped my Capslock to Hyper with xmodmap. For reference, this is the relevant xmodmaprc part:

clear Lock
keycode 66 = Hyper_L
add mod3 = Hyper_L

xkeysnail looks really cool and I'd like to use it. I tried to find a way to do the above with it, but it seems there isn't even a Hyper key. Is there any way to replicate that xmodmap config?

I tried to read the code and understand what would need to be fixed, but I didn't get very far. If it helps, it seems that uinput doesn't have a Hyper key variable either ( https://github.com/tuomasjjrasanen/python-uinput/blob/master/src/ev.py ).

kllmanu commented 4 years ago

Just load your .Xmodmap file again after starting xkeysnail.

pat-flew commented 4 years ago

YMMV but a partial workaround that for me at least (in Gnome) was updating the code to add a new modifier associated with an unused uinput key, and mapping that to capslock in xkeysnail config. Then it should also be possible to map the same key to Hyper in xmodmap if you have existing shortcuts using Hyper in applications.

e.g. https://github.com/pat-flew/xkeysnail/commit/663729c18b2c446932b29eedf7b368e323276e90

abgruszecki commented 4 years ago

@pat-flew thanks for the info, this looks like it could be helpful! I'm one of those people that rebind capslock-tap to escape and capslock-hold to hyper; I've so far used xmodmap+xcape to accomplish that. It looks like with your branch, I could use xkeysnail instead of xcape to support distinguishing between tap and hold. I'll try out your branch when I have the time, thanks again!

bjohas commented 3 years ago

Hi @pat-flew - would you be happy to make a PR? It would be great to have this feature in the application.

Alternatively, I would also be happy to test and make a PR if you prefer? I have some questions.

You defined hyper as 90/91, but that conflicts with earlier keys (as you explain). What was the reason for doing that, rather than just adding it to the list (with a separate number)?
I don't fully understand how the super key works. In the evdev file in xkb (on Linux) , , , all have their own keys. (See /usr/share/X11/xkb/keycodes/evdev if you're on Linux.) xkeysnail seems to handle Super by using Meta (see line 761 here: https://github.com/pat-flew/xkeysnail/commit/663729c18b2c446932b29eedf7b368e323276e90). I wonder whether it might make sense to add , for completeness? But I don't understand the application well enough... Often Meta is associated with the ALT key though, so I don't fully understand the use for Super here. Do you happen to know?
There are two other keys that appear in evdev, namely , (mode switch and iso-level3). I wonder how those are handled?

I would be super-happy to write out some code, but I'd probably need a bit of help when I get stuck... Would you be willing to help?

pat-flew commented 3 years ago

Hi @bjohas. IIRC, I didn't have any luck using undefined codes so switched to using an existing key and didn't investigate further, since that was enough for my use-case at the time.

Not sure about Hyper/Meta but I think that association has been around for the lifetime of this repo.

As it is, I wouldn't want to redefine katakana in a PR since I assume it might used by some. If there's a way to use an undefined code, or to determine some other more appropriate mapping, I think it could work.

Better, possibly, would be to allow additional modifiers, or simply a user-defined mapping for hyper in particular. I don't think it'd be too difficult; it'd mostly just need to touch on the parts that were modified in the fork.

The only keys xkeysnail gives special treatment to are the modifiers hardcoded into Keys.py. I think those two keys you mention are generally associated with Key.RIGHT_ALT and treated as a standard modifier.

bjohas commented 3 years ago

Hi @pat-flew - sorry for the slow reply. Yeah, I agree, a user-defined map for super/hyper would be good. Let me make a new issue, and see whether that would be welcome.

joshgoebel commented 2 years ago

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)

Here is my default xmodmap config... so Hyper is grouped in with Super... so even if you redirected a key (pick any key) with the keymapper to the Hyper (or figured out what X thinks that key is) you'll still have to move it to mod2/mod3 or something to get it out of the mud with Super...

So at that point (since you're running xmodmap anyways) what key you use starts to not matter all that much... here is my setup using F24... (and my new fork which allows defining custom modifiers in the first place)

https://github.com/joshgoebel/keyszer/wiki/Hyper

mooz / xkeysnail

Is it possible to re-bind Capslock to Hyper? #88