Skip to content

fix: Correct buffer scaling when using fractional scale protocol - #28

Merged
sin-ack merged 2 commits into
sin-ack:masterfrom
bigFin:fractional-scaling
Nov 30, 2025
Merged

sin-ack merged 2 commits into
sin-ack:masterfrom
bigFin:fractional-scaling

Conversation

@bigFin

@bigFin bigFin commented Nov 29, 2025

Copy link
Copy Markdown
Contributor

Description

This PR fixes an issue where the application would render with incorrect dimensions on Wayland compositors using fractional scaling (in my case Niri).

The Problem

When the wp_fractional_scale_manager_v1 protocol is active, the application is responsible for rendering at the exact physical pixel size, and the Wayland surface buffer scale should be set to 1.

Previously, the application was correctly using wp_viewport for sizing but was also setting the wl_surface buffer scale to the integer scale factor provided by wl_output (e.g., setting it to 2 on a 1.25x scale output).

This "double scaling" caused the compositor to interpret the buffer as having half the intended logical size (e.g., 3840 physical pixels / scale 2 = 1920 logical pixels), resulting in mismatched window geometry and errors such as:
wp_viewport: source rectangle extends outside of the content area

The Fix

The fix ensures that wl_surface.setBufferScale is explicitly set to 1 whenever the wp_fractional_scale_manager_v1 is available and in use. The existing logic for integer-only scaling remains unchanged to prevent regressions on compositors that do not support fractional scaling.

Verification

  • Tested on Niri with a 1.25x scale factor.
  • Confirmed that the application now fills the screen correctly without viewport errors.

sin-ack and others added 2 commits November 30, 2025 00:54
This was allowing incorrectly-formatted Zig code to pass CI.
When wp_fractional_scale_manager_v1 is active, the compositor expects
the buffer scale to be 1, with scaling handled via wp_viewport.
Previously, we were mistakenly applying the integer output scale (e.g.
2x) to the buffer, resulting in a logical size mismatch and rendering
errors on compositors like Niri.

@sin-ack sin-ack left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the commit and code formatting, and added a shortened version of the explanation to the code to keep things clear. Otherwise LGTM, the fix seems to work on both Niri and Hyprland for various scales. Thanks for the contribution!

@sin-ack
sin-ack merged commit 8ad06cf into sin-ack:master Nov 30, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants