Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
abgruszecki opened this issue Jun 7, 2020 · 7 comments
Open

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

abgruszecki opened this issue Jun 7, 2020 · 7 comments

Comments

@abgruszecki
Copy link

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
Copy link
Contributor

kllmanu commented Jun 24, 2020

Just load your .Xmodmap file again after starting xkeysnail.

@pat-flew
Copy link

pat-flew commented Aug 1, 2020

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. pat-flew@663729c

@abgruszecki
Copy link
Author

@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
Copy link

bjohas commented Dec 27, 2020

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: pat-flew@663729c). 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
Copy link

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
Copy link

bjohas commented Jan 7, 2021

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
Copy link

joshgoebel commented Jun 20, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants