Kitty keyboard: AltGr (ISO Level 3 Shift) and RCtrl (Compose) keys don't work

[LunarLambda]

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

Debian 12/sid with GNOME

WezTerm version

20240226-174525-22424c32

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I use the following setxkbmap settings:

rules:      evdev
model:      pc105
layout:     us,us
variant:    altgr-intl,
options:    compose:rctrl,caps:escape

When running neovim, which supports the kitty keyboard protocol, I cannot type characters such as ß (AltGr+S) or ü (AltGr+y). In Kitty this does work, and typing the characters into neovim works too. Disabling enable_kitty_keyboard also restores functionality.

output of kitten show_key -m kitty when pressing AltGr+s

ISO_LEVEL3_SHIFT PRESS 
CSI 57453 u

ß PRESS ß
CSI 223 :  : 115 ;  ; 223 u
Alternate key: s 

ß RELEASE 
CSI 223 :  : 115 ; 1 : 3 u
Alternate key: s 

ISO_LEVEL3_SHIFT RELEASE 
CSI 57453 ; 1 : 3 u

To Reproduce

1. Set enable_kitty_keyboard = true in config
2. setxkbmap us altgr-intl
3. Open neovim (ideally latest nightly appimage)
4. Enter insert mode and press keys while holding AltGr (none of them work). Same thing happens with the compose-key (right ctrl)

Configuration

local w = require 'wezterm'

return {
    audible_bell = 'Disabled',
    color_scheme = 'tokyonight_moon',
    enable_kitty_keyboard = true,
    font = w.font_with_fallback {
        {
            family = 'Berkeley Mono',
            harfbuzz_features = { 'calt=0' },
        },
        {
            family = 'FiraCode Retina',
            harfbuzz_features = { 'calt=0', 'ss03', 'ss05' }
        },
    },
    font_size = 15,
    force_reverse_video_cursor = true,
    freetype_load_target = 'Light',
    freetype_render_target = 'HorizontalLcd',
    hide_tab_bar_if_only_one_tab = true,
    initial_cols = 100,
    initial_rows = 32,
    use_fancy_tab_bar = false,
    window_background_opacity = 0.975,
    window_padding = {
        left = 0,
        right = 0,
        top = 0,
        bottom = 0,
    }
}

Expected Behavior

AltGr keys should work as they do in kitty

Logs

No logs found

Anything else?

This issue has been very inconsistent for me. Previously (either due to wezterm or system updates) it would work, or type the wrong key (AltGr+y would enter u, not ü, or type ü but not work with shift to produce Ü).

[oOosys]

Try intl. with AltGr dead keys ...

[LunarLambda]

That's exactly what the altgr-intl variant is. It's listed as "intl. with AltGr dead keys".

[deepestsound]

Hi, I can replicate this.

wezterm version: 20240325_093507_e5ac32f2 x86_64-unknown-linux-gnu Window Environment: X11 KWin (fedora 39)

I tried the OP's layout, ALTGR+letter combos work fine on all keys with, or without enable_kitty_keyboard. Same thing with RCTRL used as a compose key. But, adding SHIFT to a letter with those two modifiers makes no difference, it is ignored, only with enable_kitty_keyboard. Only some letters though.

For instance, ALTGR+y and RCTRL " y produce correctly ü, but ALTGR+SHIFT+y and RCTRL " SHIFT+y do not create the corresponding uppercase letter.

Notice that SHIFT is correctly recognized to produce " instead of ' in the second keycombo.

It works perfectly for other letter pairs, for instance: ß / §, ð / Ð. Still, the vast majority of shifted level_3 characters are not recognized.

OP's problem seems worse since not even normal ALTGR+letter combos seem to work, but they said that the way it breaks has been inconsistent over time, so I don't know what to make of it, maybe it's just the erratic nature of the same bug.

I tried the same steps with my own layout and it behaves like I just described.

I tried it on bash and on kakoune with wezterm, and on nvim with kitty and I got no issues.

If it can help with debugging, I can make a table with all the keys working / not working.

Regards

[LunarLambda]

I tried compose-key just now (rctrl). Exact same thing. Works completely fine without enable_kitty_keyboard, completely ceases to work at all when enabled.

Have also updated to the latest wezterm-nightly before trying the above.

It seems like the terminal doesn't send any bytes at all in my case. (tested with echo -en '\x1b[>1u'; showkey -a; echo -en '\x1b[<u')

[LunarLambda]

~~Update: it works fine on wayland. It also works fine on X11 if I use setxkbmap us alt-intl-unicode instead of setxkbmap us altgr-intl.

It still reproduces as described in the original issue however. Unsure whether to close or not.~~

I'm now actually wondering if I had somehow gotten altgr-intl mixed up with alt-intl. Whatever the case may be, altgr-intl works correctly on both X11 and Wayland, so either this was fixed on the side of XKB, or I made a mistake somewhere at some point I can no longer produce. Closing