{{ message }}
Repository navigation
Conversation
The scale setting was a spin box stepping by 25%, so the only values reachable were 50, 75, 100, 125% and so on. On a 1920x1080 panel that skips 80%, which is the one useful step down: it gives a 2400x1350 desktop, 56% more room, while staying a clean divisor. Lower steps would not have been enough either. Hyprland quantises the scale to 1/120 and then requires the logical size to land on whole pixels; anything else is refused with "using suggested scale" in its log, so a free 1% spin box would silently hand back a different scale than the one asked for. 90% does not exist on 1920x1080 at all. Compute the usable scales from the monitor's own resolution instead and list them, each with the desktop size it produces, so every entry in the list is one that will actually apply. The values differ per monitor, which is why they are computed rather than hardcoded. MonitorConfigOption gains validScales() for the list and nearestValidScale() to match the float hyprctl reports back to an entry.
A scale that isn't a whole number only looks right in apps that implement wp_fractional_scale_v1. XWayland clients, GTK3 and some Electron builds are handed a whole scale instead and the compositor resizes their buffers, which softens them. That is a property of those clients, not something the shell can fix, so say it where the choice is made rather than leaving people to wonder why one window looks blurry. The notice only shows while a fractional scale is selected.
Owner
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The scale setting steps by 25%, so coming down from 100% the next stop is 75%. On a 1920x1080 laptop the one I actually wanted was 80%: it gives a 2400x1350 desktop, noticeably more room to work with, without going as small as 75%.
Lowering the step wouldn't have been enough on its own. Hyprland quantises the scale to 1/120 and then needs the logical size to land on whole pixels. Anything else it refuses, substitutes a "suggested scale" of its own and mentions it in its log. On 1920x1080 that means 80% and 83.33% are fine, while 90% doesn't exist at all, so a free 1% spin box would quietly hand back a different scale than the one you picked.
So rather than let people guess, the list is computed from the monitor's own resolution, and each entry shows the desktop size it produces. Everything offered is a value that will actually apply, and another monitor gets its own set, which is why the values are computed instead of hardcoded.
Screenshots
On this panel the list reads 75% · 2560×1440, 80% · 2400×1350, 83.33% · 2304×1296, 100% · 1920×1080, 120% · 1600×900, and so on up to 300%.
MonitorConfigOptiongains two small helpers:validScales()builds the list for a resolution, andnearestValidScale()matches the floathyprctlreports back to an entry of that list, sinceConfigComboBoxcompares values with===and would otherwise show nothing as selected.A caveat worth knowing
A scale that isn't a whole number only comes out sharp in apps that implement
wp_fractional_scale_v1. XWayland clients, GTK3 and some Electron builds get handed a whole scale instead, and the compositor resizes their buffers, so those windows look softer. Nothing the shell can do about it, it lives in the clients, but people shouldn't have to guess why one window went blurry: a notice now shows under the setting whenever a fractional scale is selected. Whole scales like 100% or 200% are unaffected.Testing
Single 1920x1080 screen, Hyprland 0.56.2. I worked out the allowed divisors separately and got the same 17 values between 50% and 200% that the helper produces, so the list isn't guessing. The settings page reloads with no QML warnings, and the entry matching the current scale comes up selected.
Worth saying out loud since it isn't free: below 100% the clients draw a larger surface that the compositor scales down, so 80% means roughly 1.5x the pixels of 100%. Text stays sharp, but it does cost GPU time on an iGPU.