Bug or Regression?
Regression
System Info and Version
Hyprland 0.56.1 (built from branch v0.56.1 at commit 5c9377c15f85c50648f35ca5a213754f95b93ca0)
aquamarine 0.14.0
Previously working on: Hyprland 0.56.0 + aquamarine 0.13.0 (no issue since at least 2026-08-04)
Kernel: 7.1.5-arch1-2
Distro: Arch Linux (Omarchy)
GPU: Intel Wildcat Lake iGPU, xe kernel driver, Mesa 26.1.6
Monitor: single output, 2560x1600 @ 120Hz, Hyprland scale 2.00
Compositor GPU acceleration is NOT the cause — reproduces identically with the client itself launched with --disable-gpu, ruling out Mesa/driver involvement. This is isolated to Wayland surface/buffer-scale negotiation between Hyprland/aquamarine and the client.
Description
Any Chromium-based client (tested: Chromium and Microsoft Edge, both stock Arch/AUR packages) launched with both:
--force-device-scale-factor=1--disable-features=WaylandFractionalScaleV1
...renders its content into only the top-left quarter of its allocated window area (half width, half height) on a HiDPI output with integer Hyprland scale of 2.0. The rest of the window's tile shows the desktop background through it. hyprctl clients reports the window's logical size correctly matching the full tile (e.g. [1256, 750]), so Hyprland believes the window is properly sized — but the client's submitted buffer is only rendering at what appears to be 1x scale, so the actual painted content covers just 1/4 of the intended physical area.
This exact flag combination has been in daily use since 2026-08-04 (used to force Chromium/Edge's own UI chrome to render at 1x instead of native 2x, since --force-device-scale-factor alone is overridden by the wp_fractional_scale_v1 protocol unless that feature is disabled). It broke specifically after upgrading hyprland 0.56.0 → 0.56.1 and aquamarine 0.13.0 → 0.14.0 on 2026-08-05 — no other relevant package (kernel, Mesa, the browser itself) changed in that window for the instance where this was first isolated.
Reproduction Steps
- On a Hyprland output with integer
scale set to 2 (or any non-1 integer scale), launch:
chromium --ozone-platform=wayland --force-device-scale-factor=1 --disable-features=WaylandFractionalScaleV1 about:blank
- Observe the window tiles/opens at the expected size, but rendered content only fills the top-left quarter of it.
Expected Behavior
Client content should fill the entire window area regardless of whether WaylandFractionalScaleV1 is disabled — the client should fall back to integer wl_surface.set_buffer_scale(2) correctly, as it did on Hyprland 0.56.0 / aquamarine 0.13.0.
Actual Behavior
Content buffer appears to be submitted at 1x scale while Hyprland allocates screen space for the window assuming 2x, leaving 3/4 of the window's area unpainted (background visible through it).
Additional Notes
- Tested with a fresh, isolated
--user-data-dir profile to rule out per-profile state — reproduces immediately on a blank profile.
- Live compositor-side nudges (toggling fullscreen, toggling floating/tiled,
hyprctl dispatch forcerendererreload) do not fix an already-running client's rendering — it appears the scale/buffer strategy is decided once at Wayland connection setup, not re-negotiated on xdg_toplevel reconfigure.
- Each flag individually (without the other) renders correctly at full size — only the combination triggers this.
Bug or Regression?
Regression
System Info and Version
Description
Any Chromium-based client (tested: Chromium and Microsoft Edge, both stock Arch/AUR packages) launched with both:
--force-device-scale-factor=1--disable-features=WaylandFractionalScaleV1...renders its content into only the top-left quarter of its allocated window area (half width, half height) on a HiDPI output with integer Hyprland
scaleof 2.0. The rest of the window's tile shows the desktop background through it.hyprctl clientsreports the window's logicalsizecorrectly matching the full tile (e.g.[1256, 750]), so Hyprland believes the window is properly sized — but the client's submitted buffer is only rendering at what appears to be 1x scale, so the actual painted content covers just 1/4 of the intended physical area.This exact flag combination has been in daily use since 2026-08-04 (used to force Chromium/Edge's own UI chrome to render at 1x instead of native 2x, since
--force-device-scale-factoralone is overridden by thewp_fractional_scale_v1protocol unless that feature is disabled). It broke specifically after upgradinghyprland0.56.0 → 0.56.1 andaquamarine0.13.0 → 0.14.0 on 2026-08-05 — no other relevant package (kernel, Mesa, the browser itself) changed in that window for the instance where this was first isolated.Reproduction Steps
scaleset to 2 (or any non-1 integer scale), launch:Expected Behavior
Client content should fill the entire window area regardless of whether
WaylandFractionalScaleV1is disabled — the client should fall back to integerwl_surface.set_buffer_scale(2)correctly, as it did on Hyprland 0.56.0 / aquamarine 0.13.0.Actual Behavior
Content buffer appears to be submitted at 1x scale while Hyprland allocates screen space for the window assuming 2x, leaving 3/4 of the window's area unpainted (background visible through it).
Additional Notes
--user-data-dirprofile to rule out per-profile state — reproduces immediately on a blank profile.hyprctl dispatch forcerendererreload) do not fix an already-running client's rendering — it appears the scale/buffer strategy is decided once at Wayland connection setup, not re-negotiated onxdg_toplevelreconfigure.