Some dead keys does not work

[ElricleNecro]

Hi!

Some dead keys (¨ and ^ to be precise) cannot be used anymore (they doesn't do anything). The problem seems to be specific to kitty as those key are working as expected using other terminal/applications.

I am using kitty (last git master) under arch linux with an azerty layout and a french (utf-8) locale.

[kovidgoyal]

Sorry I dont know much about dead keys on X11. What modifier keys do you press to generate them?

[ElricleNecro]

I just press the key, then another characters and it show the characters with the accent (for example ^ + o = ô).

After some research and test, it seems to be linked to how glfw handle event.

[kovidgoyal]

Yes, glfw does not have support for dead keys/compose. It is on my TODO list to fork glfw and use a private copy anyway (there are various nice things I want that glfw does not eyt support and its development is very slow). If and when I do that adding support for dead keys via libxkbcommon should be easy.

[kovidgoyal]

For reference: glfw/glfw#1140

[zigius]

Also relevant for vim. For instance - switching to the previous buffer using CTRL + SHIFT + ^
is not possible.
Thanks for your hard work!

[kovidgoyal]

ctrl + shift + 6 should not generate anything. It would conflict with ctrl + 6. In most terminals they generate the same bytes. In kitty, ctrl+6 works, ctrl+shift+6 is ignored. Try running cat in any terminal and press ctrl+6 and then ctrl+shift+6 you will see they produce the same output.

[rosshadden]

I have a potentially related problem. I use xcape to set my left alt key to ctrl+space if you tap it, which is my tmux prefix. I have been using this for years with urxvt and later termite. In trying out kitty, I found that this does not work, though manually pressing ctrl+space does.

Even more strange, it seems to work once, the first time I start up kitty, and then never again until I open a new window, or something like that.

[troubas]

Possibly related: With the neo keyboard the navigation (and delete) keys on Layer 3 refuse to function - even though all other keys an all 6 Layers worrk perfectly.

[noctuid]

Navigation keys on layer 5 for xkb (ISO_Level5_Shift) also do not work for me.

[troubas]

Key Press Events:

holding down the Modifier key

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0xdf, subw 0x0, time 56315221, (343,315), root:(1146,337),
    state 0x0, keycode 108 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 94
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Pressing Left Arrow key

KeyPress event, serial 33, synthetic NO, window 0x3200001,
    root 0xdf, subw 0x0, time 56315914, (343,315), root:(1146,337),
    state 0x20, keycode 39 (keysym 0xff51, Left), same_screen YES,
    XKeysymToKeycode returns keycode: 113
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Releasing Left Arrow

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0xdf, subw 0x0, time 56315984, (343,315), root:(1146,337),
    state 0x20, keycode 39 (keysym 0xff51, Left), same_screen YES,
    XKeysymToKeycode returns keycode: 113
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Release Modifier

KeyRelease event, serial 33, synthetic NO, window 0x3200001,
    root 0xdf, subw 0x0, time 56316149, (343,315), root:(1146,337),
    state 0x20, keycode 108 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES,
    XKeysymToKeycode returns keycode: 23
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

If I'm not mistaken one should ignore the modifier key inside the application in this case.
The driver seems to handle the input and sends the correct keycodes?

Which in turrn seems to be the case for most keys except the following:

• keycode 38 (keysym 0xff50, Home)
• keycode 39 (keysym 0xff51, Left)
• keycode 40 (keysym 0xff54, Down)
• keycode 41 (keysym 0xff53, Right)
• keycode 42 (keysym 0xff57, End)
• keycode 26 (keysym 0xff52, Up)
• keycode 25 (keysym 0xff08, BackSpace)
• keycode 27 (keysym 0xffff, Delete)

one that is non-relevant: keycode 56 (keysym 0xff65, Undo), and probably some others that I'm not aware of.

[kovidgoyal]

Using xev isn't particularly useful. You'd need to use the tests/events.c program from glfw to see what keyboard events glfw sends, those are what kitty uses, not raw X11 events. Chances are you wont be able to fix this without modifying glfw, though.

[troubas]

I fear you might be right. There probably is no keyboard agnostic workaround.

The keypress event for the modifier gets logged, it however is not recognized at all

0000001b to 1 at 114.126: Key 0xffffffff Scancode 0x006c (UNKNOWN) (with no mods) was pr
essed

Then we have left, down, right in that order

0000001e to 1 at 116.623: Key 0x0053 Scancode 0x0027 (S) (i) (with no mods) was pressed
0000001f to 1 at 116.678: Key 0x0053 Scancode 0x0027 (S) (i) (with no mods) was released
00000020 to 1 at 116.948: Key 0x0044 Scancode 0x0028 (D) (a) (with no mods) was pressed
00000021 to 1 at 117.050: Key 0x0044 Scancode 0x0028 (D) (a) (with no mods) was released
00000022 to 1 at 117.248: Key 0x0046 Scancode 0x0029 (F) (e) (with no mods) was pressed
00000023 to 1 at 117.359: Key 0x0046 Scancode 0x0029 (F) (e) (with no mods) was released

And the Numpad seems to work because there is a seperation of input and keypresses:

00000024 to 1 at 119.332: Key 0x004a Scancode 0x002c (J) (n) (with no mods) was pressed
00000025 to 1 at 119.332: Character 0x00000034 (4) with modifiers (with no mods) input
00000026 to 1 at 119.332: Character 0x00000034 (4) input
00000027 to 1 at 119.426: Key 0x004a Scancode 0x002c (J) (n) (with no mods) was released
00000028 to 1 at 119.696: Key 0x004b Scancode 0x002d (K) (r) (with no mods) was pressed
00000029 to 1 at 119.696: Character 0x00000035 (5) with modifiers (with no mods) input
0000002a to 1 at 119.696: Character 0x00000035 (5) input
0000002b to 1 at 119.814: Key 0x004b Scancode 0x002d (K) (r) (with no mods) was released
0000002c to 1 at 120.005: Key 0x004c Scancode 0x002e (L) (t) (with no mods) was pressed
(( lock key mods enabled ))
0000002d to 1 at 120.005: Character 0x00000036 (6) with modifiers (with no mods) input
0000002e to 1 at 120.005: Character 0x00000036 (6) input

[kovidgoyal]

Yeah this will need switching of glfw to use libxkb then glfw should behave similar to all other modern toolkits. I just need to find the time to do the glfw modification. I dont know if running under wayland is an option for you, but IIRC the glfw wayland backend unlike the X11 backend does use libxkb, so that might work for you.

You can set the KITTY_ENABLE_WAYLAND=1 and WAYLAND_DISPLAY env vars to get kitty to use wayland.

[zen2]

I don't know if it's related: I'm using kitty-term on gentoo and most of bash keyboard shortcut (ctrl-w ctrl-a ctrl-e backspace, ...) doesn't work once I ssh on another gentoo where kitty-term is not installed.
I've solved this by adding the terminfo definition for kitty-term in /etc/terminfo.
That solves most of bash shortcuts when used over ssh.

There is several keyboard shortcuts that don't work locally and over SSH like it's "alt ."
That is really annoying since I use it a lot (that paste the last word of last command).
If I use cat to debug input I got ^[: isntead of ^[.
If I debug alt+, it seems that it take opcode of alt+'qwzerty key mapping' instead of alt+'azerty key mapping' (since I'm using azerty map).

So the problem seems to be when using alt modifier, the keyboard mapping is not the good one if you're not using the qwerty one.

[kenan-rhoton]

@kovidgoyal I understand you want to work on this on your glfw fork, anyway I could contribute to that? I'm up for it (as it's literally the only thing keeping me from switching fully to kitty, which is awesome), but I would need a little bit of direction on where to look and what to touch 🙃

[kovidgoyal]

Absolutely. Simply fork glfw for yourself and make the changes. You can send the PR to the glfw project and regardless of whether they accept it or not, I can always merge it into my fork (which is what kitty uses).

There are two stages of changes needed. To address the basic issue of not recognizing key mappings when using various X11 key mapping techniques, it should enough to simply switch to using libxkb to do the keybaord handling in the glfw X11 backend. You can look at the glfw wayland backend for inspiration, it uses libxkb already.

The second, more broad stage is to create a new keyboard API in glfw which is needed long term for robust keyboard handling, this is discussed in glfw/glfw#1140

I suggest you work only on the first stage to start with, as it should be enough to address the vast majority of issues in this bug report.

[kovidgoyal]

Well, I took a couple of days off to implement the new keyboard API in glfw. You can try it out in the xkb kitty branch. All the basic stuff seems to work, I haven't tested advanced features like compose, dead keys, changing keyboard layout on the fly though they should all work, the code for them is there.

The major regression is that XIM (X Input Method) does not work. It did not work very well with the old keyboard API either and not at all in wayland, so I dont think the loss is too great.

Try it out and let me know how it goes.

Note that currently it is linux only, I still have to implement the new api for macOS.

[kovidgoyal]

@rosshadden with the xkb branch of kitty your issue seems to be resolved. At elast, I tried running

xcape -d

the repeatedly pressing left ctrl in kitty running

showkey -a

and the output was

^[       27 0033 0x1b
^[       27 0033 0x1b
^[       27 0033 0x1b
^[       27 0033 0x1b
^[       27 0033 0x1b
^[       27 0033 0x1b
^[       27 0033 0x1b

indicating that pressing left ctrl generated escape as expected.

[kovidgoyal]

@ElricleNecro Your issue is also resolved. I tried the following:

xmodmap -e "keysym Super_L = Multi_key" 

Then in a newly opened kitty terminal (from the xkb branch) I pressed: Super_L, Shift + 6, o and got  ô in kitty, as expected.

[kovidgoyal]

@troubas I have no way of testing your issue since I dont have the neo keyboard.

[troubas]

@kovidgoyal Thanks a lot for your work! If I run wayland (using the sway display manager) my keyboard loses about all of its functionality. Even the shift key no longer works =)

However I think this needs to be adressed by the neo-developers and not you. Thanks again!

Edit: Actually with your modified version running the xkb branch in a X11 environment all non-navigational keys work exactly the same as before.

[kovidgoyal]

@troubas Run it with GLFW_DEBUG_KEYBOARD=1 and you should get output of what key events it is seeing, in that output the scancode will correspond to the keycode from xev.

[troubas]

@kovidgoyal This looks promising?

X11
The modifier:

scancode: 0x6c release: 0 clean_sym: ISO_Level5_Shift composed_sym: ISO_Level5_Shift mods: none glfw_key: UNKNOWN

Home, Left, Down, Right, End in that order:

scancode: 0x26 release: 0 clean_sym: u composed_sym: Home mods: none glfw_key: U
scancode: 0x26 release: 1 clean_sym: u mods: none glfw_key: U
scancode: 0x27 release: 0 clean_sym: i composed_sym: Left mods: none glfw_key: I
scancode: 0x27 release: 1 clean_sym: i mods: none glfw_key: I
scancode: 0x28 release: 0 clean_sym: a composed_sym: Down mods: none glfw_key: A
scancode: 0x28 release: 1 clean_sym: a mods: none glfw_key: A
scancode: 0x29 release: 0 clean_sym: e composed_sym: Right mods: none glfw_key: E
scancode: 0x29 release: 1 clean_sym: e mods: none glfw_key: E
scancode: 0x2a release: 0 clean_sym: o composed_sym: End mods: none glfw_key: O
scancode: 0x2a release: 1 clean_sym: o mods: none glfw_key: O

and release the modifier

scancode: 0x6c release: 1 clean_sym: ISO_Level5_Shift mods: none glfw_key: UNKNOWN

Wayland
Shift, followed by hi

scancode: 0x3e release: 0 clean_sym: Shift_R composed_sym: Caps_Lock mods: shift glfw_key: RIGHT SHIFT
scancode: 0x1e release: 0 clean_sym: h composed_sym: h text: h mods: shift+capslock glfw_key: H
scancode: 0x1e release: 1 clean_sym: h mods: shift+capslock glfw_key: H
scancode: 0x27 release: 0 clean_sym: i composed_sym: i text: i mods: shift+capslock glfw_key: I
scancode: 0x27 release: 1 clean_sym: i mods: shift+capslock glfw_key: I
scancode: 0x3e release: 1 clean_sym: Shift_R mods: none glfw_key: RIGHT SHIFT

And the same as above for X11 (less promising? ;)

scancode: 0x6c release: 0 clean_sym: ISO_Level5_Shift composed_sym: ISO_Level5_Lock mods: none glfw_key: UNKNOWN
scancode: 0x26 release: 0 clean_sym: u composed_sym: u text: u mods: numlock glfw_key: U
scancode: 0x27 release: 0 clean_sym: i composed_sym: i text: i mods: numlock glfw_key: I
scancode: 0x26 release: 1 clean_sym: u mods: numlock glfw_key: U
scancode: 0x28 release: 0 clean_sym: a composed_sym: a text: a mods: numlock glfw_key: A
scancode: 0x27 release: 1 clean_sym: i mods: numlock glfw_key: I
scancode: 0x29 release: 0 clean_sym: e composed_sym: e text: e mods: numlock glfw_key: E
scancode: 0x28 release: 1 clean_sym: a mods: numlock glfw_key: A
scancode: 0x29 release: 1 clean_sym: e mods: numlock glfw_key: E
scancode: 0x2a release: 0 clean_sym: o composed_sym: o text: o mods: numlock glfw_key: O
scancode: 0x2a release: 1 clean_sym: o mods: numlock glfw_key: O
scancode: 0x6c release: 1 clean_sym: ISO_Level5_Shift mods: none glfw_key: UNKNOWN

[kovidgoyal]

Yeah looks like it might be made to work on X11 at least. Basically have to use the composed symbol rather than the clean symbol. Wayland is hopeless, since both are wrong.

[rosshadden]

@kovidgoyal Awesome! I'll try out that branch when I get back from vacation.

[kovidgoyal]

@troubas I pushed a commit that should take care of it on X11. Basically, when a modifier that glfw does not know about is active, it uses the shifted (composed) key instead of the unshifted (clean) key.

[troubas]

@kovidgoyal jup navigation keys work now. Thank you good Sir! * pulls the hat *

I noticed the Home and End keys don't function and indeed also the native ones don't. Is this intentional / a config issue on my side?

[noctuid]

@troubas Home and End work for me in bash/fish but not in zsh (tested without sourcing my configuration as well).

[noctuid]

Regarding #403, should or will fcitx (and/or other xim alternatives) be supported?

[kovidgoyal]

Home and End work fine as far as I know. You might need to add some config to your shell to get it to read terminfo or add the bindings directly. For instance on zsh

    bindkey '\e[H'  beginning-of-line
    bindkey '\e[F'  end-of-line
    bindkey '\e[3~' delete-char

XIM is not likely to be supported, as far as I know it does not work with libxkbcommon (they both read xcompose files for instance) and it is pretty flaky, read all the bug reports about XIM causing hangs/crashes.

If you want to use it you will likely have to implement special support for it via dbus directly, like the other toolkits that support it do. That's a bit too much work for me, but patches are welcome. Personally, I would just use the Xcompose mechanism. It works on wayland as well.

[kovidgoyal]

Regarding fcitx, better than using dbus would be to create a new kitten, like the unicode input kitten (ctrl+shift+u) that reads the fcitx data files and presents a nice terminal interface for input. THis would have the advantage of working on all platforms and probably being easier to implement, no need for DBUS. It depends on how complex the fcitx data format is.

[troubas]

doh Added the zsh key-bindings and the home and end key work now. Thanks! 👍

[kenan-rhoton]

Amazing! Now if this would also work on macOS I would be a happy camper 🙃

[kovidgoyal]

What would work on macOS? As far as I know the xkb branch works on macOS as well.

[kovidgoyal]

Since no one has reported any outstanding issues (apart from XIM) I am merging into master and closing this bug report.

[noctuid]

I'm using ISO_Level5_Shift + w (capslock+w) as C-w using Redirect with xkb (see this line in my config) and have noticed that kitty just detects this as w instead of C-w.

[kovidgoyal]

Hmm I doubt remapping of modifiers for individual key presses is going to work with the way glfw functions. Modifier state is maintained independent of key presses. But you are welcome to take a stab at it, the relevant code is all in xkb_glfw.c, the two functions glfw_xkb_update_modifiers() and glfw_xkb_handle_key_event()

[kovidgoyal]

Indeed, looking at the code, I dont see how a compose rule that changes the value of a modifier on an unrelated keypress would work with libxkbcommon at all. Modifiers are stored in a state object that is not touched by the libxkb compose API.

[mlongval]

Hi there.
I just started using Kitty a few days ago. Very nice project! Congratulations!
I have a problem however.
I have used 'xcape' for years now to map a tap on the CapsLock key to ESC with this:

# make CapsLock behave like Ctrl:
setxkbmap -option ctrl:nocaps
# make short-pressed Ctrl behave like Escape:
xcape -e 'Control_L=Escape'

The setxkbmap part works (ie CapsLock becomes Ctrl), but the 'xcape' part does not (ie tapping the CapsLock - now Ctrl - does not issue an ESC.

I use this all the time in Zsh and Vim.

Is there any way of fixing this problem.

Thanks for any help, and thanks again for a great terminal emulator!

Cheers from Canada!