[Development] Wayland: getting a screen's fractional scale before the first window exists

[Ilya Fedin]

On Fri, 07 Aug 2026 22:34:46 +0000
Jamie Fitzgerald via Development <development at qt-project.org> wrote:

> Hi all,
> 
> I work on the Qt/Wayland side of LibreOffice's VCL plugin, and I'd
> like to ask whether Qt could expose a screen's fractional scale
> before any window exists, and if so, what shape you'd want it in.

Hi, I'm the author of 590173/590174.

> Why it's needed: LibreOffice sizes its menus, toolbars and dialogs
> while starting up, before it opens its first window. At that point
> QScreen::devicePixelRatio() returns the integer wl_output scale, so
> on a 220% desktop it reports 3 and the interface comes out about
> 1.36x too big. We currently force
> Qt::HighDpiScaleFactorRoundingPolicy::Round and let the compositor
> shrink the result, which wastes GPU work and softens everything. I
> have a change under review in LibreOffice (208347, tdf#172896) that
> reads the Wayland output directly instead, but our reviewer would
> rather we didn't carry Wayland specific code if Qt could provide the
> value, which is why I'm asking here first.
> 
> I've read 563344 ("Guess output devicePixelRatio from XdgOutput
> geometry"), last updated June 2024, and 590173 ("Client: Get screen's
> fractional device pixel ratio via xdg-output"), last updated October
> 2024. I'm not trying to reopen those arguments. I have one case that
> wasn't discussed and some measurements that may have moved the
> picture since.
> 
> The case: "use QWindow::devicePixelRatio() instead" has been the
> answer each time, and for most applications it's the right one. It
> doesn't apply here because there is no window yet. The layout happens
> before any surface is committed, so wp_fractional_scale_v1's
> preferred_scale event (Morten's question on 590173) hasn't arrived
> and can't.

That's kind of the same problem I made the patches for. Though, the
application I did it for is quite worse, it queries only
QGuiApplication::devicePixelRatio (the highest of all screens) on
launch and caches various graphics for all run time. Moreover, it
supports only integer device pixel ratios and gets the fractional part
via QScreen::primaryScreen()->logicalDotsPerInch() and supplies to its
own scaling engine (the application is written in Qt 5.3 times, way
before Qt got high dpi support) so having high dpi rounding policy work
properly was essential for the app to look properly with the fractional
scaling protocol.

> The measurements: David's point on 590173 was that a slightly wrong
> scale is worse than a rounded up one. I agree, so what I'd propose is
> a value that is always checked, or reported as unavailable. The check
> is that the calculated scale, rounded up, must equal the integer
> wl_output scale Qt already has. Rather than assume that holds, I
> tested four compositors across seven output configurations. KWin was
> on a real 4K panel, the rest headless. In every case the calculated
> scale rounded up matched the integer wl_output scale:

FWIW, that wasn't really a problem with my patch. It uses the
calculated scale only to report to the app while getting the buffer
size using the factor reported by the fractional scaling protocol.

> 
> -
> 
> KWin at 220%: calculated 2.20008, off by +0.00008
> 
> -
> 
> sway at 220%: calculated 2.20120, off by +0.00120
> 
> -
> 
> sway at 150%: calculated 1.50029, off by +0.00029
> 
> -
> 
> Hyprland at 240%: exact
> 
> -
> 
> mutter at 150%, 125% and 250%: exact in all three
> 
> So the worst error anywhere was 0.0012, about 0.05%. Mutter and
> Hyprland only offer scales whose logical size divides evenly, so both
> come out exact. KWin and sway accept arbitrary scales and round the
> logical size, which is the entire source of the small errors above.
> 
> One thing I'd particularly like checked. QWaylandScreen::geometry()
> works around mutter reporting a logical size equal to the native size
> (mutter issue 2631), which would make this calculation return 1.0. On
> mutter 50.3 I couldn't reproduce that: it reported 2560x1440 at 1.5,
> 3072x1728 at 1.25 and 1536x864 at 2.5, all correctly divided. Issue
> 2631 says the problem only occurs when scale-monitor-framebuffer is
> off, and mutter 50.3 answers "Unknown experimental feature" when I
> try to enable it, which I read as it no longer being optional. If
> that's right, xdgGeometryIsBogus now only covers older mutter, and
> the main objection here is weaker than it was in 2024. I may be
> missing something and would rather be told.
> 
> Limits of the above: only KWin was real hardware, the rest were
> headless virtual outputs. I didn't test niri, labwc, wayfire or
> weston. And although every compositor I tried reports the integer
> scale as the fractional scale rounded up, I can't find anything in
> the protocol requiring it, so I'm treating that as common practice
> rather than a guarantee.
> 
> So, which would you prefer? I'm happy to write whichever you think is
> right:

Those screen size problems wasn't the reason I abandoned the patch. The
only reason I abandoned that patch, as well as a bunch of other
pathces, was practical inability to get a review. I was waiting for
months and years. At some point I just surrended, abandoned them all
and limited myself to just reporting + carrying own patchset. You could
notice the last discussion on that patch was in September 2024 and I
abandoned it in October 2024, after a month of inactivity and
reviewers' discussion on what is the preferred API but nothing about
the patch itself and making other APIs working as best as possible
(which is still valuable in my opinion).

That exact patch's fate is that it was present in the Telegram Desktop
Qt patchset up until June 2025 and then I thought "why do I carry it?".

The initial rationale was bad perofrmance on Wayland and the patch
improved it to some degree but then it was discovered that the real
problem is a QImage::detach call in the RHI code (QTBUG-120565) and the
patchset has a patch for that problem too. So i tried to just remove it
and there were no complaints.

It seems almost no one notices the downscaling and performance problems
were solved by the other patch, so be it, fine. But I can continue the
work if there's any interest in the patch.