Issue with custom XKB keymap #1990
Comments
|
I think this will be resolved with the solution to #1980 (WIP) |
|
See also #2000 |
Yes, but in general kitty currently does not remove consumed mods (the non-standard mod and alt) for a key event, which is part of what I want to fix too |
|
This is very similar to my problem: #1255. Due to the fact that glfw (kitty's backend) only recognizes a very small subset of modifiers, any modifiers outside of this small set behave oddly (see the discussion over at the glfw repo). In my case, my custom (caps-lock based) modifier causes kitty to scroll down fully (as if you pressed an actual key). This can become very annoying, as I use this custom modifier to switch windows. Can you confirm that kitty also scrolls down when you press your (custom) modifier, @infokiller? If so, I hypothesize that any 'glwf fallback key' causes kitty to scroll down, which might fixable on kitty's side. |
|
@rien333 in my case it doesn't scroll down |
|
I have a similar issue with my custom XKB layout - I have From the So, GLFW causes issues even with standard modifier - I wish I could use something like Keyboardio's key layout util to shuffle the keys at firmware level and make everything appear standard QWERTY to the OS - but my laptop's keyboard is not programmable, so I have to use custom xkb layouts. And I'm afraid until this issue is fixed, Kitty is a no-go for me 😞 |
|
I'll add the ^ key tomorrow, that will hopefully fix your problem. |
|
@evelineraine please test if #2222 fixes your problem. |
|
@Luflosi I have build kitty from #2222 and it still doesn't work. I see that glfw recognises the key now, but still Vim doesn't receive |
|
@kovidgoyal do you know why this doesn't work? |
|
You will need to add it to control_codes in keys.py. I am guessing OP |
diff --git a/kitty/keys.py b/kitty/keys.py
index 5d6e92c6..9184a1be 100644
--- a/kitty/keys.py
+++ b/kitty/keys.py
@@ -128,6 +128,7 @@ control_codes[defines.GLFW_KEY_3] = (27,)
control_codes[defines.GLFW_KEY_4] = (28,)
control_codes[defines.GLFW_KEY_5] = (29,)
control_codes[defines.GLFW_KEY_6] = (30,)
+control_codes[defines.GLFW_KEY_CIRCUMFLEX] = (30,)
control_codes[defines.GLFW_KEY_7] = (31,)
control_codes[defines.GLFW_KEY_SLASH] = (31,)
control_codes[defines.GLFW_KEY_8] = (127,)@kovidgoyal Like this?
@evelineraine Is that correct? If so, try building with the patch applied. |
|
yes, like that |
|
Oh and I think you also to to regenerate the key tables after making that change. |
|
Good catch. diff --git a/kitty/keys.h b/kitty/keys.h
index 2413dea6..758846b0 100644
--- a/kitty/keys.h
+++ b/kitty/keys.h
@@ -822,6 +822,8 @@ key_lookup(uint8_t key, KeyboardMode mode, uint8_t mods, uint8_t action) {
return "\x01\x1c";
case 58: // RIGHT_BRACKET
return "\x01\x1d";
+ case 59: // CIRCUMFLEX
+ return "\x01\x1e";
case 60: // UNDERSCORE
return "\x01\x00";
case 61: // GRAVE_ACCENT
@@ -2487,6 +2489,8 @@ key_lookup(uint8_t key, KeyboardMode mode, uint8_t mods, uint8_t action) {
return "\x01\x1c";
case 58: // RIGHT_BRACKET
return "\x01\x1d";
+ case 59: // CIRCUMFLEX
+ return "\x01\x1e";
case 60: // UNDERSCORE
return "\x01\x00";
case 61: // GRAVE_ACCENT
@@ -4161,6 +4165,8 @@ key_lookup(uint8_t key, KeyboardMode mode, uint8_t mods, uint8_t action) {
return "\x01\x1c";
case 58: // RIGHT_BRACKET
return "\x01\x1d";
+ case 59: // CIRCUMFLEX
+ return "\x01\x1e";
case 60: // UNDERSCORE
return "\x01\x00";
case 61: // GRAVE_ACCENT
@@ -5826,6 +5832,8 @@ key_lookup(uint8_t key, KeyboardMode mode, uint8_t mods, uint8_t action) {
return "\x01\x1c";
case 58: // RIGHT_BRACKET
return "\x01\x1d";
+ case 59: // CIRCUMFLEX
+ return "\x01\x1e";
case 60: // UNDERSCORE
return "\x01\x00";
case 61: // GRAVE_ACCENT
diff --git a/kitty/keys.py b/kitty/keys.py
index 5d6e92c6..9184a1be 100644
--- a/kitty/keys.py
+++ b/kitty/keys.py
@@ -128,6 +128,7 @@ control_codes[defines.GLFW_KEY_3] = (27,)
control_codes[defines.GLFW_KEY_4] = (28,)
control_codes[defines.GLFW_KEY_5] = (29,)
control_codes[defines.GLFW_KEY_6] = (30,)
+control_codes[defines.GLFW_KEY_CIRCUMFLEX] = (30,)
control_codes[defines.GLFW_KEY_7] = (31,)
control_codes[defines.GLFW_KEY_SLASH] = (31,)
control_codes[defines.GLFW_KEY_8] = (127,) |
|
I'll make a PR then so this can be in the master branch. |
|
I am also experiencing an unexpected behavior regarding modifiers: like @infokiller I have a custom XKB keymap as well, but my configuration adds a modifier to a keypress, and that modifier isn't detected by Kitty. Here is the relevant part of my keymap: When KeyPress event, serial 28, synthetic NO, window 0x6e00001,
root 0x5d2, subw 0x0, time 119252737, (161,-18), root:(1032,451),
state 0x1, keycode 118 (keysym 0xff63, Insert), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
But Kitty seems to miss that information: Press xkb_keycode: 0x76 clean_sym: Insert composed_sym: Insert mods: none glfw_key: 260 (INSERT) xkb_key: 65379 (Insert) on_key_input: glfw key: 260 native_code: 0xff63 action: PRESS mods: 0x0 text: '' state: 0 sent key to child Release xkb_keycode: 0x76 clean_sym: Insert mods: none glfw_key: 260 (INSERT) xkb_key: 65379 (Insert) on_key_input: glfw key: 260 native_code: 0xff63 action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events And as a result Insert alone is passed to the running application, instead of shift+insert. FWIW, I have a few more keymaps that add other modifiers to keypresses, such as ctrl and alt, and they also aren't detected by Kitty. |
|
@mbenford @infokiller Do you still have these issues? |
|
@orki I'm not one of the people who you asked, but I had a similar problem (Kitty would read Alt key when I was switching XKB layouts with a custom keymap), and now it is gone in the latest version of Kitty! Great job! I can now finally use Kitty comfortably. |
|
Closing, since this issue should be resolved. If someone is still experiencing it with kitty 0.20.3 or newer, let me know. |
|
@kovidgoyal please reopen, I still have the original issue with Kitty 0.20.3 |
|
Here is the keyboard log from kitty: |
|
@orki It still happens on my end as well (kitty 0.20.3). |
|
Having similar issue on 0.23.1. In my case Shift+Caps should produce a BackSpace. This works in other terminal emulators.
|
|
Having similar problems. My XKB configuration rebinds [Super]+[Left] to be [Home] and [Super]+[Right] to be [End], attempting to emulate macOS. Running while This would agree with When I do try and type the key combination in kitty, it turns [Super]+[Left] into D. This is true even if I have my xkb configuration disabled. I'm fairly ignorant to how X works, but it seems like kitty is registering the keys before my xkb config is consulted. Even if that were changed and kitty received [Super]+[Home] instead of [Super]+[Left], kitty would still produce an H on the terminal (as can be done by typing, well, [Super]+[Home]) and is probably caused by this. As for other terminals, Assuming the problem is bad configuration on my part, it would be useful to have a mappable action to move the cursor to the start or end of a line, imitating [Home], [End]; [Apple]+[Left], [Apple]+[Right]; or [Ctrl]+[A], [Ctrl]+[E]; if possible. I might be able to do this already, but with my look through the documentation I don't think I can. |
|
I feel like such a fool. I looked at the second link but just didn't read the part that explains how to do exactly what I want. Mapping [Super]+[Left] in kitty.conf works just like I expected (and I bound [Super]+[Home] for good measure). Thank you for the help, and thanks for your work on kitty! |
Thanks for this terminal - it's really the best I've seen so far!
As for my issue: I'm running a custom XKB keymap which uses
CapsLockas another modifier (ISO_LEVEL5_Shift), and I configuredCapsLock+Alt+jto redirect to theHomekey. Most applications work fine with that setting, including other terminal emulators I tested. However, Kitty seems to pass different keys to the running application, which I tested by usingCtrl-vin a shell.Here's the Kitty keyboard debug log I'm seeing:
Looking at the log, I suspect the issue is the
PRESS mods: 0x4part, where Kitty treats the alt mod as pressed. Here's a relevant excerpt from my XKB keymap file:Running
xev -event keyboardshows that the mod is correctly set by XKB:Specifically, see this part from that log:
KeyPress event, serial 28, synthetic NO, window 0x6400001, root 0x1e4, subw 0x0, time 552661607, (508,983), root:(1364,1015), state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: FalseAs you can see in the bolded part, the state of the modifiers is set to
0x0, which means no modifiers should be active.The text was updated successfully, but these errors were encountered: