Open infokiller opened 5 years ago
I think this will be resolved with the solution to https://github.com/kovidgoyal/kitty/issues/1980 (WIP)
See also #2000
@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?
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
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 in my case it doesn't scroll down
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:
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 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?
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
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.
yes, like that
Oh and I think you also to to regenerate the key tables after making that change.
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!
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:
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 @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:
❯ kitty --debug-keyboard --config /dev/null
Loading new XKB keymaps
Modifier indices alt: 0x3 super: 0x6 hyper: 0xffffffff meta: 0xffffffff numlock: 0x4 shift: 0x0 capslock: 0x1
Press xkb_keycode: 0x42 clean_sym: ISO_Level5_Shift composed_sym: ISO_Level5_Shift mods: none glfw_key: 57454 (ISO_LEVEL5_SHIFT) xkb_key: 65041 (ISO_Level5_Shift) alternate_key: 57358 (CAPS_LOCK)
on_key_input: glfw key: 0xe06e native_code: 0xfe11 action: PRESS mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Press xkb_keycode: 0x40 clean_sym: Alt_L composed_sym: Alt_L active_unknown_mods: Mod3 mods: none glfw_key: 57443 (LEFT_ALT) xkb_key: 65513 (Alt_L)
on_key_input: glfw key: 0xe063 native_code: 0xffe9 action: PRESS mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Press xkb_keycode: 0x6e clean_sym: Home composed_sym: Home active_unknown_mods: Mod3 mods: alt glfw_key: 57356 (HOME) xkb_key: 65360 (Home)
on_key_input: glfw key: 0xe00c native_code: 0xff50 action: PRESS mods: alt text: '' state: 0 sent key to child
Release xkb_keycode: 0x6e clean_sym: Home mods: alt glfw_key: 57356 (HOME) xkb_key: 65360 (Home)
on_key_input: glfw key: 0xe00c native_code: 0xff50 action: RELEASE mods: alt text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Release xkb_keycode: 0x40 clean_sym: Alt_L mods: alt glfw_key: 57443 (LEFT_ALT) xkb_key: 65513 (Alt_L)
on_key_input: glfw key: 0xe063 native_code: 0xffe9 action: RELEASE mods: alt text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Release xkb_keycode: 0x42 clean_sym: ISO_Level5_Shift mods: none glfw_key: 57454 (ISO_LEVEL5_SHIFT) xkb_key: 65041 (ISO_Level5_Shift) alternate_key: 57358 (CAPS_LOCK)
on_key_input: glfw key: 0xe06e native_code: 0xfe11 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
@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.
Press xkb_keycode: 0x3e clean_sym: Shift_R composed_sym: Shift_R mods: numlock glfw_key: 57447 (RIGHT_SHIFT) xkb_key: 65506 (Shift_R) on_key_input: glfw key: 0xe067 native_code: 0xffe2 action: PRESS mods: numlock text: '' state: 0 ignoring as keyboard mode does not support encoding this event Press xkb_keycode: 0x42 clean_sym: Escape composed_sym: BackSpace mods: shift+numlock glfw_key: 57344 (ESCAPE) xkb_key: 65307 (Escape) shifted_key: 57347 (BACKSPACE) alternate_key: 57358 (CAPS_LOCK) on_key_input: glfw key: 0xe000 native_code: 0xff1b action: PRESS mods: shift+numlock text: '' state: 0 sent key to child Release xkb_keycode: 0x42 clean_sym: Escape mods: shift+numlock glfw_key: 57344 (ESCAPE) xkb_key: 65307 (Escape) shifted_key: 57347 (BACKSPACE) alternate_key: 57358 (CAPS_LOCK) on_key_input: glfw key: 0xe000 native_code: 0xff1b action: RELEASE mods: shift+numlock text: '' state: 0 ignoring as keyboard mode does not support encoding this event Release xkb_keycode: 0x3e clean_sym: Shift_R mods: shift+numlock glfw_key: 57447 (RIGHT_SHIFT) xkb_key: 65506 (Shift_R) shifted_key: 57358 (CAPS_LOCK) on_key_input: glfw key: 0xe067 native_code: 0xffe2 action: RELEASE mods: shift+numlock text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Having similar problems. My XKB configuration rebinds [Super]+[Left] to be [Home] and [Super]+[Right] to be [End], attempting to emulate macOS.
Running kitty +kitten show_key -m kitty
gives
LEFT_SUPER PRESS
CSI 57444 u
Super+LEFT PRESS
CSI 1 ; 9 D
Super+LEFT RELEASE
CSI 1 ; 9 : 3 D
Super+LEFT_SUPER RELEASE
CSI 57444 ; 9 : 3 u
while kitty --debug-keyboard
gives
Press xkb_keycode: 0x85 clean_sym: Super_L composed_sym: Super_L mods: none glfw_key: 57444 (LEFT_SUPER) xkb_key: 65515 (Super_L)
on_key_input: glfw key: 0xe064 native_code: 0xffeb action: PRESS mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Press xkb_keycode: 0x71 clean_sym: Left composed_sym: Home mods: super glfw_key: 57350 (LEFT) xkb_key: 65361 (Left) shifted_key: 57356 (HOME)
on_key_input: glfw key: 0xe006 native_code: 0xff51 action: PRESS mods: super text: '' state: 0 sent encoded key to child
Release xkb_keycode: 0x71 clean_sym: Left mods: super glfw_key: 57350 (LEFT) xkb_key: 65361 (Left) shifted_key: 57356 (HOME)
on_key_input: glfw key: 0xe006 native_code: 0xff51 action: RELEASE mods: super text: '' state: 0 ignoring as keyboard mode does not support encoding this event
Release xkb_keycode: 0x85 clean_sym: Super_L mods: super glfw_key: 57444 (LEFT_SUPER) xkb_key: 65515 (Super_L)
on_key_input: glfw key: 0xe064 native_code: 0xffeb action: RELEASE mods: super text: '' state: 0 ignoring as keyboard mode does not support encoding this event
This would agree with xev
which says (abreviated)
KeyPress event, serial 37, synthetic NO, window 0x7e00001,
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
KeyPress event, serial 37, synthetic NO, window 0x7e00001,
state 0x40, keycode 113 (keysym 0xff50, Home), same_screen YES,
XKeysymToKeycode returns keycode: 110
KeyRelease event, serial 37, synthetic NO, window 0x7e00001,
state 0x40, keycode 113 (keysym 0xff50, Home), same_screen YES,
XKeysymToKeycode returns keycode: 110
KeyRelease event, serial 37, synthetic NO, window 0x7e00001,
state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
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, xfce4-terminal
does move the cursor to the start and end of lines like I expect, however alacritty
simply does nothing. For non-terminal emulators, I get the desired effect in a handful of applications I tested it in, such as firefox and chromium. I remember this used to work in kitty, though I was using AutoKey instead of xkb. It suddenly stopped working but I just lived with it.
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
CapsLock
as another modifier (ISO_LEVEL5_Shift), and I configuredCapsLock+Alt+j
to redirect to theHome
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 usingCtrl-v
in a shell.Here's the Kitty keyboard debug log I'm seeing:
Looking at the log, I suspect the issue is the
PRESS mods: 0x4
part, where Kitty treats the alt mod as pressed. Here's a relevant excerpt from my XKB keymap file:Running
xev -event keyboard
shows that the mod is correctly set by XKB:Specifically, see this part from that log:
As you can see in the bolded part, the state of the modifiers is set to
0x0
, which means no modifiers should be active.