CTRL key not working, when using alternative layout like workman

[gracicot]

Describe the bug
The CTRL key does not seem to be working. vim and tmux hotkeys are not triggered, and ctrl+c enters the text c instead of killing the process. The CTRL key works in other terminal apps

To Reproduce
Steps to reproduce the behavior:

1. Open kitty on M3 ARM64 macOS
2. Hit CTRL+C
3. ...
4. See the text c being entered.

Environment details

$ kitty --version    
kitty 0.36.2 created by Kovid Goyal

Input (Excluding mouse move):

-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(573.621,585.879) time=53369.3 flags=0x40101 win=0x14cf56240 winNum=4572 ctxt=0x0 keyCode=59
flagsChanged: modifier: ctrl native_key: 0x3b (<noname>) glfw_key: 0xe062 mods: ctrl 
[10.922] on_key_input: glfw key: 0xe062 native_code: 0x3b action: PRESS mods: ctrl text: '' state: 0 ignoring as keyboard mode does not support encoding this event
---------------- key down -------------------
NSEvent: type=KeyDown loc=(573.621,585.879) time=53369.6 flags=0x40101 win=0x14cf56240 winNum=4572 ctxt=0x0 chars="" unmodchars="c" repeat=0 keyCode=9
Press: native_key: 0x9 (c) glfw_key: 0x63 mods: ctrl char_count: 1 deadKeyState: 0 repeat: 0 
	insertText: c replacementRange: (9223372036854775807, 0)
text: 0x63 glfw_key: c marked_text: ()
[11.243] on_key_input: glfw key: 0x63 native_code: 0x9 action: PRESS mods: ctrl text: 'c' state: 0 sent key as text to child: c
----------------- key up --------------------
NSEvent: type=KeyUp loc=(573.621,585.879) time=53369.7 flags=0x40101 win=0x14cf56240 winNum=4572 ctxt=0x0 chars="" unmodchars="c" repeat=0 keyCode=9
Release: native_key: 0x9 (c) glfw_key: 0x63 mods: ctrl 
[11.321] on_key_input: glfw key: 0x63 native_code: 0x9 action: RELEASE mods: ctrl text: '' state: 0 ignoring as keyboard mode does not support encoding this event
-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(573.621,585.879) time=53369.8 flags=0x100 win=0x14cf56240 winNum=4572 ctxt=0x0 keyCode=59
flagsChanged: modifier: ctrl native_key: 0x3b (<noname>) glfw_key: 0xe062 mods: none 
[11.405] on_key_input: glfw key: 0xe062 native_code: 0x3b action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event

Additional context
Happens with --config NONE too

[kovidgoyal]

Your system is sending text to kitty when you press ctrl+c, as shown by
the log. In such cases kitty will correctly send the text to the
terminal applications. Whatever you have changed in your system to make
that happen, a third party keyboard layout or IME or similar it needs to
be fixed there.

[gracicot]

Hmm, I see. I do use an alternative keyboard, more specifically the workman layout. Is there a way I can make the ctrl key send the right key according to my layout or supporting alternative layout not supported yet?

I see #2000 and #606, but other than using a python script to generate my keyboard layout in kitty config, there's nothing else. Also those python scripts use xkb, which doesn't exist on macOS.

I can see that vim do recieve the wrong letter as soon as I use modifiers, and in a SSH session, the ctrl modifier seem to simply not work.

[kovidgoyal]

alternative layouts that work correctly are supported fine. For example,
try the dvorak layout.

[gracicot]

I see it works with dvorak, but completely breaks with workman. I use the latest workman layout from this repo: https://github.com/workman-layout/Workman

Is there a workaround I could apply, a fix on the layout itself or a config for kitty to support alternative layout other than dvorak?

[kovidgoyal]

there is no workaround in kitty for a keyboard layout that thinks ctrl+c should generate text. It needs to be fixed in the layout.

[gracicot]

I haven't had any problem with the terminal app from macos, iterm2, alacritty and a few others. I'm suspecting GLFW to not support workman layout properly or something like that. Kitty is the only one using GLFW, and I've had similar problems with GLFW based games.

Sure it may be a problem with the implementation of workman, but kitty is the only app that has been problematic for me.

[kovidgoyal]

So you are saying that because there's a bug in your keyboard layout and bugs in some other applications that happen to cancel that bug I should also introduce the bug into my software. I dont think so. If a keystroke produces text then kitty is going to assume that the keystroke is supposed to produce text and therefore produce text. That allows actual non-broken keyboard layouts to produce text when it is appropriate to do so and not have application software arbitrarily override them.