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 CapsLock as another modifier (ISO_LEVEL5_Shift), and I configured CapsLock+Alt+j to redirect to the Home key. 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 using Ctrl-v in a shell.
Here's the Kitty keyboard debug log I'm seeing:
❯ kitty --debug-keyboard --config /dev/null
Press scancode: 0x42 clean_sym: ISO_Level5_Shift composed_sym: ISO_Level5_Shift mods: none glfw_fallback_key: 280 (CAPS LOCK) xkb_key: 65509 (Caps_Lock)
on_key_input: glfw key: 280 native_code: 0xffe5 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Press scancode: 0x40 clean_sym: Alt_L composed_sym: Alt_L active_unknown_mods: Mod3 mods: none glfw_key: 342 (LEFT ALT) xkb_key: 65513 (Alt_L)
on_key_input: glfw key: 342 native_code: 0xffe9 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Press scancode: 0x6e clean_sym: Home composed_sym: Home active_unknown_mods: Mod3 mods: alt glfw_key: 268 (HOME) xkb_key: 65360 (Home)
on_key_input: glfw key: 268 native_code: 0xff50 action: PRESS mods: 0x4 text: '' state: 0 sent key to child
Release scancode: 0x6e clean_sym: Home mods: alt glfw_key: 268 (HOME) xkb_key: 65360 (Home)
on_key_input: glfw key: 268 native_code: 0xff50 action: RELEASE mods: 0x4 text: '' state: 0 ignoring as keyboard mode does not allow release events
Release scancode: 0x40 clean_sym: Alt_L mods: alt glfw_key: 342 (LEFT ALT) xkb_key: 65513 (Alt_L)
on_key_input: glfw key: 342 native_code: 0xffe9 action: RELEASE mods: 0x4 text: '' state: 0 ignoring as keyboard mode does not allow release events
Release scancode: 0x42 clean_sym: ISO_Level5_Shift mods: none glfw_fallback_key: 280 (CAPS LOCK) xkb_key: 65509 (Caps_Lock)
on_key_input: glfw key: 280 native_code: 0xffe5 action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events
key <AC07> {
type = "EIGHT_LEVEL_ALPHABETIC",
symbols[Group1] = [ j, J, j, J],
actions[Group1] = [ NoAction(), NoAction(), NoAction(), NoAction(), RedirectKey(key =<LEFT>,clearMods =LevelFive), RedirectKey(key =<LEFT>,clearMods =LevelFive), RedirectKey(key =<HOME>,clearMods =Alt+LevelFive), RedirectKey(key =<HOME>,clearMods =Alt+LevelFive) ],
};
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: False
As you can see in the bolded part, the state of the modifiers is set to 0x0, which means no modifiers should be active.
infokiller
All 19 comments
I think this will be resolved with the solution to https://github.com/kovidgoyal/kitty/issues/1980 (WIP)
bew
on 24 Sep 2019
See also #2000
bew
on 25 Sep 2019
@bew reading #2000 I understand that your proposed fix is to handle non-standard modifiers (I use ISO_Level5_Shift specifically here). But isn't the issue here that the Alt modifier is detected even though XKB cleared it?
infokiller
on 25 Sep 2019
But isn't the issue here that the Alt modifier is detected even though XKB cleared it?
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
bew
on 25 Sep 2019
This is very similar to my problem: https://github.com/kovidgoyal/kitty/issues/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
on 4 Nov 2019
@rien333 in my case it doesn't scroll down
infokiller
on 5 Nov 2019
I have a similar issue with my custom XKB layout - I have ^ moved to QWERTY 8 (shiftless). When I press Ctrl-^ (keybinding used in Vim), I have one character deleted in the shell (like Backspace does), and nothing happening in Vim.
From the --debug-keyboard output I assume that GLFW doesn't recognize what key is being pressed, and falls back to treating it as 8, and then sends Ctrl-8 to the shell (which seems to erase one character left, for some reason).
Press xkb_keycode: 0x64 clean_sym: Control_R composed_sym: Control_R mods: none glfw_key: 345 (RIGHT CONTROL) xkb_key: 65508 (Control_R)
on_key_input: glfw key: 345 native_code: 0xffe4 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Press xkb_keycode: 0x9 clean_sym: asciicircum composed_sym: asciicircum mods: ctrl glfw_fallback_key: 56 (8) xkb_key: 56 (8)
on_key_input: glfw key: 56 native_code: 0x38 action: PRESS mods: 0x2 text: '' state: 0 sent key to child
Release xkb_keycode: 0x9 clean_sym: asciicircum mods: ctrl glfw_fallback_key: 56 (8) xkb_key: 56 (8)
on_key_input: glfw key: 56 native_code: 0x38 action: RELEASE mods: 0x2 text: '' state: 0 ignoring as keyboard mode does not allow release events
Release xkb_keycode: 0x64 clean_sym: Control_R mods: ctrl glfw_key: 345 (RIGHT CONTROL) xkb_key: 65508 (Control_R)
on_key_input: glfw key: 345 native_code: 0xffe4 action: RELEASE mods: 0x2 text: '' state: 0 ignoring as keyboard mode does not allow release events
So, GLFW causes issues even with standard modifier - Ctrl.
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 :disappointed:
evelineraine
on 21 Dec 2019
I'll add the ^ key tomorrow, that will hopefully fix your problem.
Luflosi
on 21 Dec 2019
@evelineraine please test if #2222 fixes your problem.
Luflosi
on 22 Dec 2019
@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 Ctrl-^ correctly and nothing happens.
Press xkb_keycode: 0x64 clean_sym: Control_R composed_sym: Control_R mods: none glfw_key: 345 (RIGHT CONTROL) xkb_key: 65508 (Control_R)
on_key_input: glfw key: 345 native_code: 0xffe4 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Press xkb_keycode: 0x9 clean_sym: asciicircum composed_sym: asciicircum mods: ctrl glfw_key: 94 (CIRCUMFLEX) xkb_key: 94 (asciicircum)
on_key_input: glfw key: 94 native_code: 0x5e action: PRESS mods: 0x2 text: '' state: 0 sent key to child
Release xkb_keycode: 0x9 clean_sym: asciicircum mods: ctrl glfw_key: 94 (CIRCUMFLEX) xkb_key: 94 (asciicircum)
on_key_input: glfw key: 94 native_code: 0x5e action: RELEASE mods: 0x2 text: '' state: 0 ignoring as keyboard mode does not allow release events
Release xkb_keycode: 0x64 clean_sym: Control_R mods: ctrl glfw_key: 345 (RIGHT CONTROL) xkb_key: 65508 (Control_R)
on_key_input: glfw key: 345 native_code: 0xffe4 action: RELEASE mods: 0x2 text: '' state: 0 ignoring as keyboard mode does not allow release events
@kovidgoyal do you know why this doesn't work?
Luflosi
on 4 Jan 2020
You will need to add it to control_codes in keys.py. I am guessing OP
wants it to generate the same code as ctrl+6, so add it next to line 130
kovidgoyal
on 5 Jan 2020
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?
I am guessing OP wants it to generate the same code as ctrl+6
@evelineraine Is that correct? If so, try building with the patch applied.
Luflosi
on 5 Jan 2020
yes, like that
kovidgoyal
on 5 Jan 2020
Oh and I think you also to to regenerate the key tables after making that change.
kovidgoyal
on 5 Jan 2020
Good catch.
@evelineraine here is the new patch:
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,)
@Luflosi, tested this patch on top of #2222 - Ctrl-^ works correctly now in Vim.
Thank you very much!
evelineraine
on 11 Jan 2020
I'll make a PR then so this can be in the master branch.
Luflosi
on 11 Jan 2020
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:
key <LatV> { Overlay1 = <PAST> };
key <PAST> {
symbols = [ VoidSymbol ],
actions = [ Redirect(key=<INS>, mods=Shift) ]
};
When Overlay1 is enabled the character _V_ emulates _shift+insert_, which works as paste in most applications. xev reports that shift is indeed active:
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
on 26 Nov 2020
Related issues
reed-jones
·
4Comments
Nudin
·
3Comments
JJGO
·
3Comments
skosch
·
3Comments
bewzaalex
·
3Comments