[Upstream] Dead keys stopped working since GNOME 49 / GTK 4.20

[jhonrocha]

Issue Description

None of the dead keys are working anymore (`^~'")

2025-09-24.16-52-37.mp4

Expected Behavior

Deadkeys were working up until the recent update

Actual Behavior

Dead keys are ignored.

Reproduction Steps

1. Open Ghostty
2. Type a dead key and type another key to show it
3. Nothing happens

Ghostty Logs

No response

Ghostty Version

Ghostty 1.2.0-arch1

Version
  - version: 1.2.0-arch1
  - channel: tip
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.gtk
  - font engine   : font.main.Backend.fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.16.8-arch3-1
  - desktop env   : other
  - GTK version   :
    build         : 4.18.6
    runtime       : 4.20.1
  - libadwaita    : enabled
    build         : 1.7.7
    runtime       : 1.8.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Arch Linux x86_64 (6.16.8-arch3-1)

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

Hyprland

Minimal Ghostty Configuration

font-size = 12

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[pedrog14]

It seems to be related to gtk#7580 and gtk4#12

[Diegovsky]

Niri issue that links here YaLTeR/niri#2476

[absforshort]

This is happening after I updated Ghostty a few days back, so it seems to be something done to Ghostty that made it not interact with the Alt Gr and ^¨~ key? It feels like it wouldn't be specific to Gnome, since I don't use Gnome, I use Hyprland with Quickshell on top to make my own desktop. Though I get that it could be changes to GTK perhaps, but then I don't get why can I use the ~ everywhere else outside of Ghostty that I have tested, which to be fair is only in my own Launcher app's search box, Vivaldi, Steam and Discord since I have very few apps installed, but nonetheless, it's purely Ghostty that is not letting me type out these symbols making me believe something must have changed from the previous version to this latest one with how it interacts with keys?

On a Norwegian keyboard you would need to press Alt Gr + the ^¨~ key + Spacebar to confirm it. Monitoring keystrokes in Ghostty makes it only print out the keycode for the spacebar, so the Alt Gr and the ^¨~ are simply not detected at all.

Arch to my knowledge keeps Ghostty pretty up to date, so it's not like I should have been lagging behind on updating it and this was resulting from a change that was done months ago in June. It's not that long ago it had an update that changed how my PS1 prompt was formatted, which was easy enough to fix by adding a space behind certain powerline symbols to make them proper sized. That update did not break the key combination. I wouldn't care much if I didn't use ~ to cd back to the /home/username directory quickly, but since it's one of the more useful keys for swiftly moving around on your Linux system, it does kinda get frustrating that ~ doesn't work all of a sudden and I don't quite understand why.

[mfxa]

I switched to kitty at least for now as I also use ~ frequently.

Small tip that you may or may not know:
You can cd to $HOME just by typing cd with no arguments. Of course that doesn't help when you don't want to cd there, but just want to edit a file there or something. Then $HOME or the full path is needed.

[rhodes-b]

the ~ everywhere else outside of Ghostty that I have tested, which to be fair is only in my own Launcher app's search box, Vivaldi, Steam and Discord since I have very few apps installed, but nonetheless, it's purely Ghostty that is not letting me type out these symbols making me believe something must have changed from the previous version to this latest one with how it interacts with keys?

Again nothing to do with ghostty version you are on arch which has GTK 4.20 if you looked at the marked answer the breaking change comes in GTK 4.19

None of those apps you mentioned are GTK based apps so yeah they wont be "broken", this discussion already tells you how to fix it use that solution.

it does kinda get frustrating that ~ doesn't work all of a sudden and I don't quite understand why.

Its a upstream change like already stated in this discussion

It feels like it wouldn't be specific to Gnome

Its not. Like the commit message above says GTK now expects that the compositor is translating the keys instead of GTK doing it. Hyprland is clearly not doing it so you need to tell GTK please keep doing it how you used to

This release makes GTK rely on the Wayland text protocol
for input method support. For compositors without that protocol,
you can manually

Its in the commit notes

I switched to kitty at least for now as I also use ~ frequently.

Kitty is not GTK based so again they are uneffected

[LRitzdorf]

Hyprland discussion thread exists now: hyprwm/Hyprland#12042

[rhodes-b]

For future references of this discussion ghostty did not break anything ghostty uses GTK, this is entirely a upstream issue please look at the answer to this discussion
#8899 (reply in thread)

This will effect multiple compositors like stated in the commit message

This release makes GTK rely on the Wayland text protocol
for input method support

each compositor needs to handle it

The answer is quite simple, you need to use a environment variable to get it to work again
GTK_IM_MODULE=simple ghostty this is in the marked answer

For compositors without that protocol,
you can manually set GTK_IM_MODULE=simple to get back support for
X11-style compose sequences and dead keys.

An alternative if you don't have a IME installed you may need to install one for it to work properly again your compositor needs to support the protocol described above

[LRitzdorf]

Okay, follow-up: Hyprland does implement the Wayland text protocol, but Ghostty still doesn't acknowledge dead keys or Compose keys unless GTK_IM_MODULE=simple is set. It sounds like that's a GTK or Ghostty bug?

Per hyprwm/Hyprland#12042 (reply in thread), I've set WAYLAND_DEBUG=1 and tested a Compose sequence in Ghostty, but the relevant logs are about 1200 lines — is there anything specific I could filter for, or a better way to capture logs directly from Ghostty itself?

[rhodes-b]

are you using a IME like ibus as expected?

Is it actually only a ghostty problem ie do other GTK4 apps like ptyxis etc work properly there is missing information here.

ghostty doesnt do anything special for non x11 compose style sequences those are simply handed over by GTK so no it isn't a ghostty bug

[LRitzdorf]

Tested with pavucontrol, which is also GTK4, and the same thing happens there — so this is definitely on the GTK side, consistent with #8899 (comment). Good to know that GTK expects an IME now; I'm not using one, and was expecting it to fall back to the GTK_IM_MODULE=simple behavior automatically if no IME was present. Thanks for the clarification!

[pluiedev]

I did some more research into this and I think I got a better picture.

TL;DR: Install an input method framework like IBus or Fcitx 5 for comprehensive dead key support, or if you're content with GTK's naïve implementation, set GTK_IM_MODULE to simple.

---

As of GTK 4.20, GTK no longer falls back to handling compose keys and dead key behaviors by itself only when using Wayland, and when an input method isn't present. I can only guess that the reasoning behind this is because a graphical toolkit rightfully shouldn't concern itself with a compose key implementation, and it should be the responsibility of the input method.

I might have accidentally spread a misconception that the compositor needs to implement any amount of special support for this. zwp_text_input_v3, the underlying protocol that powers IME support for modern compositors, is already very widely supported¹, and as long as you're using a compliant compositor with a supported input method framework (e.g. IBus or Fcitx 5), dead keys should just work for you. If you're using a compositor that doesn't support it yet, then you may need to manually set GTK_IM_MODULE to simple to force GTK to use its naïve compose/dead key implementation.

None of this applies to X11 either, which still defaults to the naïve implementation since there's no standardized way for input methods to communicate to the compositor.

The reason why this seemingly only impacts non-GNOME users, is that GNOME Shell bundles IBus by default, which has been handling compose keys and dead keys on GNOME unless explicitly opted out otherwise. There's, again, nothing that individual compositors need to do.

Footnotes

1. As in, unless you're using a weird, niche compositor like Weston, Cage, Gamescope or Louvre, it should Just Work. ↩