Ghostty Window Ignores Requested Geometry When Moving Between Monitors With Different Logical Resolutions

[UnsaltedScholar]

Issue Description

I have two monitors: my primary display (3840x2160 with 200% scale) and an external monitor (4096x2160 set to 2560x1440 with 175% scale).

If I create a ghostty window on the external monitor then move it to my primary display, the window does not obey the window size set by kwin (and additionally with the Krohnkite dynamic tiling script for KDE) and does not take the dimensions as it is "told" to.

However, if I instead create the ghostty window on my primary display, I can move it back and forth between displays without this issue occuring.

This issue is not apparent on other terminals I have tested (i.e. konsole and kitty). Additionally, if I set my external display's scale to 133% (such the windows match/have same logical resolution), this issue does not occur.

Expected Behavior

Ghostty should behave like the other terminals and obey geometry restrictions/requests regardless of the display it is opened on.

Actual Behavior

Behavior if displays are "unmatched":
https://github.com/user-attachments/assets/e565cfaa-fd6b-486c-9616-552c1924715a

As can be seen, the geometry is only broken when the window is created on the external display (the top window in the video).

Behavior if displays are "matched":
https://github.com/user-attachments/assets/7a7010dc-eddc-4eab-b275-4b2b988574cd

No issue.

Reproduction Steps

1. Have access to monitors with different resolutions/scales
2. Open ghostty on the lower set resolution display
3. Move ghostty to a display with higher resolution (but with scale set such that the displays aren't "matched"
4. Observe that the geometry looks squished (much more apparent when tiled)
5. Repeat process in reverse (open on the other monitor first)
6. Again move ghostty to the other display
7. Observe that there is no issue
8. Set each display's scale/resolutions such that the displays are "matched" (same logical resolution)
9. Repeat 1-6 and observe that there is no issue regardless of which display the window is opened on.

Ghostty Logs

The logs didn't seem to show any information that is relevant to this issue.

Ghostty Version

Ghostty 1.2.3-arch1.1

Version
  - version: 1.2.3-arch1.1
  - 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.17.5-2-cachyos
  - desktop env   : other
  - GTK version   :
    build         : 4.20.2
    runtime       : 4.20.2
  - libadwaita    : enabled
    build         : 1.8.1
    runtime       : 1.8.1
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

CachyOS Linux (kernel: 6.17.5-2-cachyos)

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

KDE Plasma 6.5.1

Minimal Ghostty Configuration

Issue appears to be independent of configuration options (I tested all of my set configuration options).

Additional Relevant Configuration

I am using the dynamic tiling KWin script Krohnkite (anametologin's fork, master branch). The issue remains even when the script is disabled, but it is more obvious when it is enabled.

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.

[UnsaltedScholar]

New info,

This appears to be an issue affecting a few other GTK apps. Not sure what exactly is going on. Another thing I've noticed that potentially clarifies my explanation above. Once moved to a monitor with a larger logical resolution, ghostty becomes locked to the number of columns/rows that would be possible when maximized on the monitor it was created on. Even when floating, trying to resize ghostty beyond this forced maximum will cause it to immediately shrink again (see video below).

2025-11-06.00-56-49.mp4

[UnsaltedScholar]

@pluiedev

One of the only other apps I have seen effected is GNOME eyedropper. Ninety-nine percent of gtk apps seem fine.

Edit:
Just tested, gnome terminal does not have this issue, but gnome console and Ptyxis do

[pluiedev]

That's interesting. Could this be a difference between GTK 3 and 4 then? (GNOME Terminal uses GTK 3, while Console/Ptyxis/Ghostty all use GTK 4)

[UnsaltedScholar]

Tested a few other gtk3 apps, they all seem to work fine. So it does seem to be a gtk 4 issue. I found this old gtk4 issue for Windows that seems to be talking about a similar problem (but I don't know if it is truly the same):
https://gitlab.gnome.org/GNOME/gtk/-/issues/5090

[pluiedev]

That's possible. Either way if this is reproducible on other apps then it's likely not a Ghostty bug. Please report it to the upstream GTK developers then!