Bug
Under KDE Plasma 6 Wayland on a fractional-scale output (1.25, 1.5, …), the embedded Ghostty terminal area renders into the bottom-left corner of an oversized framebuffer instead of filling the GLArea. The visible terminal occupies roughly 1 / (fractional_scale)² of the pane; keystrokes are accepted but the text is drawn outside the visible region.
At integer scales (1.0, 2.0) the bug does not occur.
Screenshots (before / after) to follow in a comment — gh issue create doesn't accept image uploads.
Reproduction
- KDE Plasma 6 Wayland (tested on Bazzite Fedora 44, single output at 2048×1152)
- System Settings → Display → set scale to 1.25 (or 1.5)
- Launch the Limux AppImage without
GDK_BACKEND=x11 (the =x11 env var works around the bug by routing through XWayland, where KWin bitmap-composites the whole window)
- Open any workspace
Expected: the terminal fills the GLArea, text renders at the correct size for the fractional scale.
Actual: terminal occupies the bottom-left ~62% (at 1.25) / ~44% (at 1.5) of the pane and the rest is black. Typing is consumed but appears outside the visible area.
Root cause
refresh_surface_display in rust/limux-host-linux/src/terminal.rs passes:
ghostty_surface_set_size(w, h) where w, h are the GLArea's logical (CSS) allocation, and
ghostty_surface_set_content_scale(scale, scale) where scale = gl_area.scale_factor() (integer).
GTK4 allocates the GLArea's backing FBO at logical_size × scale_factor() physical pixels. On Wayland fractional outputs, the compositor downscales that integer-scaled buffer to the fractional surface size via wp-fractional-scale-v1. Ghostty's renderer treats set_size as the physical-pixel canvas and set_content_scale only for HiDPI font/cell metrics, so passing logical pixels leaves it drawing into the bottom-left sub-rectangle of the oversized FBO.
Workaround
GDK_BACKEND=x11 in the launcher — XWayland reports an integer scale and KWin handles the fractional downscale via bitmap composite. Functional but loses native Wayland behavior and exposes a separate symbolic-icon issue (#80).
Environment
PR with fix to follow.

Bug
Under KDE Plasma 6 Wayland on a fractional-scale output (1.25, 1.5, …), the embedded Ghostty terminal area renders into the bottom-left corner of an oversized framebuffer instead of filling the GLArea. The visible terminal occupies roughly
1 / (fractional_scale)²of the pane; keystrokes are accepted but the text is drawn outside the visible region.At integer scales (1.0, 2.0) the bug does not occur.
Screenshots (before / after) to follow in a comment —
gh issue createdoesn't accept image uploads.Reproduction
GDK_BACKEND=x11(the=x11env var works around the bug by routing through XWayland, where KWin bitmap-composites the whole window)Expected: the terminal fills the GLArea, text renders at the correct size for the fractional scale.
Actual: terminal occupies the bottom-left ~62% (at 1.25) / ~44% (at 1.5) of the pane and the rest is black. Typing is consumed but appears outside the visible area.
Root cause
refresh_surface_displayinrust/limux-host-linux/src/terminal.rspasses:ghostty_surface_set_size(w, h)wherew, hare the GLArea's logical (CSS) allocation, andghostty_surface_set_content_scale(scale, scale)wherescale = gl_area.scale_factor()(integer).GTK4 allocates the GLArea's backing FBO at
logical_size × scale_factor()physical pixels. On Wayland fractional outputs, the compositor downscales that integer-scaled buffer to the fractional surface size viawp-fractional-scale-v1. Ghostty's renderer treatsset_sizeas the physical-pixel canvas andset_content_scaleonly for HiDPI font/cell metrics, so passing logical pixels leaves it drawing into the bottom-left sub-rectangle of the oversized FBO.Workaround
GDK_BACKEND=x11in the launcher — XWayland reports an integer scale and KWin handles the fractional downscale via bitmap composite. Functional but loses native Wayland behavior and exposes a separate symbolic-icon issue (#80).Environment
mainAppImage with the SVG-loader patch from Pane action toolbar: 4 of 6 icons render as broken-image fallback (Fedora/Bazzite, v0.1.19 AppImage) #80)PR with fix to follow.