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

Strange reaction on "menu" button #2519

Closed
korjavin opened this issue Apr 8, 2020 · 15 comments · Fixed by #2527
Closed

Strange reaction on "menu" button #2519

korjavin opened this issue Apr 8, 2020 · 15 comments · Fixed by #2527

Comments

@korjavin
Copy link

korjavin commented Apr 8, 2020

I have layout switcher on "menu" button grp:menu_toggle

When I start vim in kitty and press "menu" it makes something wierd.

It changes the capitalization of the next few words.

@kovidgoyal
Copy link
Owner

You r menu button is being reported as some key press to kitty. Use --debug-keyboard to see what.

@korjavin
Copy link
Author

korjavin commented Apr 9, 2020


Press xkb_keycode: 0x87 clean_sym: ISO_Next_Group composed_sym: ISO_Next_Group mods: numlock glfw_fallback_key: 348 (MENU) xkb_key: 65383 (Menu)
on_key_input: glfw key: 348 native_code: 0xff67 action: PRESS mods: 0x0 text: '' state: 0 sent key to child
Release xkb_keycode: 0x87 clean_sym: ISO_Next_Group mods: numlock glfw_fallback_key: 348 (MENU) xkb_key: 65383 (Menu)
on_key_input: glfw key: 348 native_code: 0xff67 action: RELEASE mods: 0x0 text: '' state: 0 ignoring as keyboard mode does not allow release events

@kovidgoyal
Copy link
Owner

According to that the menu key is being correctly dispatched, encoded as
^[[29~ as expected. if vim is not handling the key correctly, its a bug
in vim. You can workaround it by mapping the key press to send something
else using send_text in kitty.conf

@korjavin
Copy link
Author

korjavin commented Apr 9, 2020

I don't have any problem with vim and this key with lxterminal and gnome-terminal.

@kovidgoyal
Copy link
Owner

Presumably because lxterminal and gnome-terminal dont support this key.

@trygveaa
Copy link
Sponsor Contributor

trygveaa commented Apr 9, 2020

Kitty should probably not interpret the menu key when grp:menu_toggle is on? I see that xterm sends the control code when grp:menu_toggle is not on, but ignores it when it's on.

@kovidgoyal
Copy link
Owner

I have no clue what grp:menu_toggle is but if someone knows of an API in libxkbcommon to query it feel free to submit a patch against xkb_glfw.c

@trygveaa
Copy link
Sponsor Contributor

trygveaa commented Apr 9, 2020

It's an XKB option to use the menu key to switch keyboard layout. You can activate it by running:

setxkbmap -option grp:menu_toggle

@kovidgoyal
Copy link
Owner

I have no clue how to get libxkbcommon to tell kitty that, if you do
patches are welcome.

@trygveaa
Copy link
Sponsor Contributor

@kovidgoyal: The issue is caused by this code:

kitty/glfw/xkb_glfw.c

Lines 625 to 632 in 8590334

if (glfw_sym == GLFW_KEY_UNKNOWN && !key_text[0]) {
int num_default_syms = xkb_state_key_get_syms(sg->default_state, code_for_sym, &default_syms);
if (num_default_syms > 0) {
xkb_sym = default_syms[0];
glfw_sym = glfw_key_for_sym(xkb_sym);
is_fallback = true;
}
}

When the grp:menu_toggle option is on, xkb_sym is XKB_KEY_ISO_Next_Group and glfw_sym is GLFW_KEY_UNKNOWN at the start of this code. Then you load the keysym from default_keymap which doesn't have any options set, so that returns XKB_KEY_Menu. I'm not sure why you fallback to default_keymap, so I'm not sure what the correct fix for this is?

I guess you could check if xkb_sym is XKB_KEY_ISO_Next_Group in that if condition, but there are more keysyms which should be ignored, like XKB_KEY_ISO_Prev_Group and probably others.

@kovidgoyal
Copy link
Owner

I dont recall exactly but I'd guess it's to fallback if the key is
unknown. It should be safe to check for next group/prev group in the if.

trygveaa added a commit to trygveaa/kitty that referenced this issue Apr 10, 2020
XKB has various options for using keys to switch the keyboard layout.
When these are set, XKB will return keysyms which are unknown to GLFW,
so kitty will fallback to using a keymap without the options set, which
causes the keys to be interpreted as the original keysyms.

However, when these options are set, kitty shouldn't interpret the keys.
Therefore, check for some specific keysyms and return before translating
to GLFW keysyms.

There may be more keysyms which should be ignored, but as far as I can
see from https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/xkeyboard-config-2.29/symbols/group
these are the ones which can be triggered by XKB options.

Fixes kovidgoyal#2519
@trygveaa
Copy link
Sponsor Contributor

trygveaa commented Apr 10, 2020

I submitted #2527 which does that. Fallbacking to the default layout when a key is unknown seems to me like something which could potentially lead to more issues though, but I probably don't know enough about this.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Apr 10, 2020 via email

@trygveaa
Copy link
Sponsor Contributor

@korjavin: This issue is now fixed.

Quite possible but it also means that various keys that would be unusable in some layouts are at least mappable.

Hm, yeah, okay. Maybe they could be just used for mappings, and not sent to the process running in the terminal? Though, I guess that might make for some confusing behavior.

@korjavin
Copy link
Author

Great!

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

Successfully merging a pull request may close this issue.

3 participants