hyper key causes buffer to scroll down

[rien333]

On my system (4.19.10-arch1-1-ARCH, kitty 0.13.1, tried the git version) pressing the caps lock key causes kitty to reset from wherever I've scrolled, right back to the shell prompt (i.e. it undoes any scrolling I've done). xterm for example does not display this behavior. Caps lock, which I've remapped to Hyper_L, is my wm's main modifier, so the unwanted scrolling behavior is often annoying.

Kitty's keyboard debug output on pressing the caps lock key:

Press scancode: 0x42 clean_sym: Hyper_L composed_sym: Hyper_L 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
Release scancode: 0x42 clean_sym: Hyper_L mods: super glfw_fallback_key: 280 (CAPS LOCK) xkb_key: 65509 (Caps_Lock)
on_key_input: glfw key: 280 native_code: 0xffe5 action: RELEASE mods: 0x8 text: '' state: 0 ignoring as keyboard mode does not allow release events

To solve this, I've already tried mapping all keycodes from the output above to no_op, per the documentation, as well as added the option clear_all_shortcuts yes. Both resolve nothing, unfortunately. Any insight in which key or modifiers causes this to happen, and how to disable this behavior? All other modifiers I press (including super) don't display this problem.

[kovidgoyal]

Hyper is not a recognized modifier in glfw (the toolkit kitty uses) and
therefore, it wont behave like the other modifiers in kitty. Your best
bet is to map caps lock to super instead and map super to hyper.

[rien333]

After a very long time, I finally found a, somewhat hacky, fix for this.

The "obvious" solution to map caps-lock/hyper to do nothing still had the problem of scrolling down:

map 0xffe5 no_op

However, binding caps-lock/hyper to something meaningless stops the scrolling:

map 0xffe5 change_font_size current +0.0

[Luflosi]

@kovidgoyal could we add support for Hyper?

[rien333]

I still wonder whether my original buffer scroll down issue is related to Hyper or Caps Lock. It definitively receives (fallback?) scancode 0xffe5, which, in decimals, equals xkb_key: 65509 (Caps_Lock). As said, mapping this scancode to something meaningless kinda resolves this issue, although I've yet to come up with a properly meaningless mapping to bind Caps Lock to.

[kovidgoyal]

@Luflosi feel free to try

…

On Sun, Oct 27, 2019 at 05:27:48AM -0700, Luflosi wrote: @kovidgoyal could we add support for <kbd>Hyper</kbd>? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1255 (comment)

--

_____________________________________ Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

_____________________________________

[Luflosi]

I don't know how to simulate the Hyper key on macOS, so I can't implement this feature, sorry.

[rien333]

Fixed with b796cee!

[rien333]

@kovidgoyal this issue has returned once again in the slew of key input handling commits after 0.19.3. Perhaps something done in b796cee was made undone?

[rien333]

Could be because

kitty/kitty/keys.c

Lines 151 to 154 in f6d4b8e

	if (
	action != GLFW_RELEASE &&
	key != GLFW_FKEY_LEFT_SHIFT && key != GLFW_FKEY_RIGHT_SHIFT &&
	key != GLFW_FKEY_LEFT_ALT && key != GLFW_FKEY_RIGHT_ALT &&

doesn't check for the Caps Lock key (while the function is_modifier_key does)

[kovidgoyal]

Are you upto date on master? And if you are post the output of running

kitty --debug-keyboard

and pressing the hyper key.

[kovidgoyal]

In particular make sure you have 60e589f

[rien333]

Works fine again, thanks! I was on f6d4b8e, FWIW.