[KF5] UI not scaled correctly on HIDPI Wayland/KDE screens

Bug 137924 - [KF5] UI not scaled correctly on HIDPI Wayland/KDE screens

Description:
When running any LibreOffice application under a KDE Wayland session (specifically, the "Plasma (Full Wayland)" session under OpenSUSE Tumbleweed), on a HiDPI display, the UI elements (buttons, etc) are not scaled, appearing tiny.

The layout of most windows (dialog boxes, etc), including the main windows of the various applications (Writer, Impress, etc) only use the top-left quarter of the window (when 2× scaling is enabled for the display in KDE), though resizeable windows will usually correctly use the whole window area if it's resized. Note that the mouse cursor still interacts correctly with these controls, so it seems to be a layout problem rather than a rendering problem.

Note that the menu bar is scaled correctly — presumably it's handled differently.

The "gtk3" VCL plugin seems to work fine. This issue seems to have only appeared when Bug 127687 was fixed (beforehand, everything was blurry and pixelated: I think KWin was scaling the window). I haven't actually tried to bisect, though, so take that with a grain of salt.

Steps to Reproduce:
Start any LibreOffice application under a KDE Wayland session, (with QT_QPA_PLATFORM=wayland and SAL_USE_VCLPLUGIN=kf5, both of which should be defaults).

Actual Results:
The controls in windows are tiny, and may be squeezed into the top-left-hand corner of the window.

See screenshots:
https://davidgow.net/stuff/lowriter-recovery-hidpi-scale.png
https://davidgow.net/stuff/lowriter-totd-hidpi-scale.png
https://davidgow.net/stuff/lowriter-mainwin-hidpi-scale.png


Expected Results:
The controls in the UI are twice the width and twice the height.

Basically, it should look like this, but not blurry (this is running under XWayland, where a lower-resolution display is reported to the application, and the window manager scales the input/output):
https://davidgow.net/stuff/lowriter-mainwin-x11-scale.png


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
This seems to have been happening since LibreOffice 7.0.

I've tried it with and without a new UserProfile and OpenGL enabled/disabled. The system in question is running OpenSUSE Tumbleweed (a rolling-release distro), with an Intel Integrated Graphics chipset. (This is a Dell XPS 13 9360 laptop.)

The output of "$ env | grep QT" is below, but changing these (except QT_QPA_PLATFORM) doesn't fix the issue:
QT_QPA_PLATFORM=wayland
PLASMA_USE_QT_SCALING=1
QT_WAYLAND_FORCE_DPI=96
QT_IM_MODULE=fcitx
QT_AUTO_SCREEN_SCALE_FACTOR=0

I can essentially reproduce small icons in Writer main win on a FullHD screen (1920x1080) by explicitly enabling scaling:

   QT_QPA_PLATFORM=wayland QT_SCALE_FACTOR=2 ./instdir/program/soffice.bin --writer

and icons are larger when using QT_QPA_PLATFORM=xcb instead.

I'm using an LO master build as of commit 211688521a983963adc9ca827eebd0e2435f2705 on Debian testing, which currently has Qt 5.15.2, Plasma 5.20, KWin 5.20.4.


I see all kinds of other issues in LibreOffice and other KDE apps with 'QT_QPA_PLATFORM=wayland QT_SCALE_FACTOR=2', like elements being wrongly arranged in Kate's save as dialog or LibreOffice dialogs, so I'm not sure whether all of the reported issues are actually a LO problem, or some lower levels (like Qt) might have issues as well - at least in my setup.

Confirmed with a Wayland session on a Lenovo ThinkPad T570

I am affected too. on HiDPI 4k screen wayland on laptop HP Spectre X360

@Michael

I have a true HiDPI screen and DE setup in KDE Plasma where everything generally works fine on Wayland (barring bugs like this, of course :) ), so I can track down for you which issues are only in seen in LO and which issues are quirks of a handmade testing setup. Gimmie a day or two...

Hi Michael.
I also can confirm xcb works better for me on wayland / kubuntu 21.04

QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1  libreoffice --calc

Is quite usable setup on HiDPi/4k wayland ,although the fonts are not as sharp as they could be.  I use SCALE 200% in system settings /display configuration. 
Thank you for bringing env var QT_QPA_PLATFORM to the attention.

I can confirm that this is still happening for me, too.

I've been using the gtk3 backend, which does work properly with HiDPI screens with KDE/wayland:

$ SAL_USE_VCLPLUGIN=gtk3 lowriter

However, using the xcb backend as Marian suggested also works, albeit appearing a bit blurrier:

$ QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1 lowriter

Both of these are quite usable, but ideally the kf5 backend would work properly.

Like Nate, I'm not seeing any similar issues in other Qt apps, so this appears to be LibreOffice specific.

(In reply to Nate Graham from comment #4)
> @Michael
> 
> I have a true HiDPI screen and DE setup in KDE Plasma where everything
> generally works fine on Wayland (barring bugs like this, of course :) ), so
> I can track down for you which issues are only in seen in LO and which
> issues are quirks of a handmade testing setup. Gimmie a day or two...

@Nate: Thanks for the offer! Unless anybody else takes a look earlier (which would be highly appreciated), I hope I'll find some time to take a look at those issues at some point in time, but can't really say when I'll be able to do so.

(In reply to David Gow from comment #6)
> Like Nate, I'm not seeing any similar issues in other Qt apps, so this
> appears to be LibreOffice specific.

That's well possible. I'm on Debian testing which doesn't have the latest Plasma/KF5 versions and it's just not fun using Plasma Wayland there so far,  since very basic things don't work (reliably). (I have plasma-desktop 4:5.20.5-4, libqt5core5a:amd64 5.15.2+dfsg-7, libgtk-3-0:amd64 3.24.24-4).

*** Bug 142882 has been marked as a duplicate of this bug. ***

I'm affected too with Manjaro. Wayland session in plasma. Unusable

I can also testify to what other have written in this thread: the problem exists on my brand new Dell XPS 13 9310 3456×2160 hiDPI, with fresh install of Fedora/KDE; and that the "QT_QPA_PLATFORM=xcb QT_SCALE_FACTOR=1.0" hack works; and also that the hack doesn't work as perfectly as desired (with scale factor 210%). See attached pics (Bad.png, Good.png).

Created attachment 176316 [details]
Bad.png (see comment)

Illustration of the problem.

Created attachment 176317 [details]
Good.png (see comment).

Illustration of the hack/fix.

(In reply to Michael Weghorn from comment #7)
> (In reply to David Gow from comment #6)
> > Like Nate, I'm not seeing any similar issues in other Qt apps, so this
> > appears to be LibreOffice specific.
> 
> That's well possible. I'm on Debian testing which doesn't have the latest
> Plasma/KF5 versions and it's just not fun using Plasma Wayland there so far,
> since very basic things don't work (reliably). (I have plasma-desktop
> 4:5.20.5-4, libqt5core5a:amd64 5.15.2+dfsg-7, libgtk-3-0:amd64 3.24.24-4).

The overall Wayland experience is much better with Plasma 5.23 which is now in Debian testing, thanks a lot for everybody involved on KDE/Qt side! :-)


Pending fix: https://gerrit.libreoffice.org/c/core/+/125507

This requires Qt >= 5.14. To my knowledge, TDF builds are using older Qt, so you'll probably still run into the problem when using those instead of distro-provided packages.

While some UI elements (like e.g. the "Help" -> "About LibreOffice"
still look quite broken with the qt5 and kf5 VCL plugins
in a Plasma Wayland session when using a scale factor of 2 and the menu misbehaves (at least on my Debian testing with Qt 5.15.2 and Plasma 5.23), they are fine when using the qt6 VCL plugin with a custom build of qtbase
and qtwayland from Qt's "dev" git branches. So I'd for now assume that those are not LibreOffice problems, but rather Qt ones fixed upstream in the meanwhile.

Note that as a workaround, setting environment variable SAL_FORCEDPI also works, which needs to be set to <QT_SCALE_FACTOR> * 96 dpi for a 96 dpi screen, e.g. SAL_FORCEDPI=192 when using a scale factor of 2.

Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dc0016bc8d7e6c4456f4442c7ccf287bfc0c2e9b

tdf#137924 qt (>=5.14): Use proper DPI without requiring window handle

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Woohoo, thanks so much!

Thanks a lot — I can confirm the SAL_FORCEDPI workaround works fine here. I'll see if I can test a build with the proper fix, too.

(In reply to David Gow from comment #17)
> Thanks a lot — I can confirm the SAL_FORCEDPI workaround works fine here.
> I'll see if I can test a build with the proper fix, too.

New Linux builds should appear here tomorrow: https://dev-builds.libreoffice.org/daily/master/current.html

(In reply to Buovjaga from comment #18)
> (In reply to David Gow from comment #17)
> > Thanks a lot — I can confirm the SAL_FORCEDPI workaround works fine here.
> > I'll see if I can test a build with the proper fix, too.
> 
> New Linux builds should appear here tomorrow:
> https://dev-builds.libreoffice.org/daily/master/current.html

That's certainly worth trying, but please note my comment #13 in case you still see the issue when testing with that build (the build version matters, not just the runtime version of Qt):

> This requires Qt >= 5.14. To my knowledge, TDF builds are using older Qt, so
> you'll probably still run into the problem when using those instead of
> distro-provided packages.

It took a few goes, but I managed to build the latest LibreOffice against Qt 5.15.2 and can confirm the issue is fixed on my machine. Thanks a lot!

(In reply to David Gow from comment #20)
> It took a few goes, but I managed to build the latest LibreOffice against Qt
> 5.15.2 and can confirm the issue is fixed on my machine. Thanks a lot!

Thanks for checking!

I have used LibreOffice with this patch for a while and it works well in general. One thing I noticed is that the comments bar in Writer does not scale and is very small. The text is scaled, but does not fit completely. The comments bar is the comments immediately right of the text.

Do others see that?

Reopen? New bug?

(In reply to Cor Blom from comment #22)
> I have used LibreOffice with this patch for a while and it works well in
> general. One thing I noticed is that the comments bar in Writer does not
> scale and is very small. The text is scaled, but does not fit completely.
> The comments bar is the comments immediately right of the text.
> 
> Do others see that?
> 
> Reopen? New bug?

I think a new report would be nice.

I tried on this version:

Version: 7.3.1.0.0+ / LibreOffice Community
Build ID: 773cc6b9ad92f28405ca204f1fa475e33f15132b
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+wayland)
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

On arch linux and the bug is right there: no proper scaling, interface too small and libreoffice unusable. 

I am on arch linux with a quite vanilla plasma version (KDE plasma version 5.23.5, kde framework 5.90.0, qt version 5.15.2, kernel 5.16.1). Obviously I am talking about wayland context.

(In reply to giors_00 from comment #24)
> I tried on this version:
> 
> Version: 7.3.1.0.0+ / LibreOffice Community
> Build ID: 773cc6b9ad92f28405ca204f1fa475e33f15132b
> CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+wayland)
> Locale: es-ES (es_ES.UTF-8); UI: en-US
> Calc: threaded
> 
> On arch linux and the bug is right there: no proper scaling, interface too
> small and libreoffice unusable. 
> 
> I am on arch linux with a quite vanilla plasma version (KDE plasma version
> 5.23.5, kde framework 5.90.0, qt version 5.15.2, kernel 5.16.1). Obviously I
> am talking about wayland context.

Where do you have that LibreOffice version from? Is it the one packaged by arch, or downloaded from TDF?

If it's downloaded from TDF, please note my comment 13:

> This requires Qt >= 5.14. To my knowledge, TDF builds are using older Qt, so you'll probably still run into the problem when using those instead of distro-provided packages.

and comment 19:

> [...] (the build version matters, not just the runtime version of Qt):

I just tried the "libreoffice-dev-bin" PKGBUILD from the AUR but this doesn't seem to include the new fix.
The PKGBUILD downloads the following installer: https://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOffice_7.3.0.3_Linux_x86-64_rpm.tar.gz
It reports the following information:

Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded


However i also tried the daily dev builds from TDF server and this seemed to work.
It reports as:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 6f39602ecb9b90795bfd4101273f90b16f17b6d6
CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

Do i maybe need to switch the the new QT6 based Plugin to make this also work in LO 7.3.0.3?

(In reply to lrdarknesss from comment #26)
> I just tried the "libreoffice-dev-bin" PKGBUILD from the AUR but this
> doesn't seem to include the new fix.
> The PKGBUILD downloads the following installer:
> https://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOffice_7.3.0.
> 3_Linux_x86-64_rpm.tar.gz
> It reports the following information:
> 
> Version: 7.3.0.3 / LibreOffice Community
> Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
> CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
> Locale: de-DE (de_DE.UTF-8); UI: en-US
> Calc: threaded
> 
> 
> However i also tried the daily dev builds from TDF server and this seemed to
> work.
> It reports as:
> Version: 7.4.0.0.alpha0+ / LibreOffice Community
> Build ID: 6f39602ecb9b90795bfd4101273f90b16f17b6d6
> CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
> Locale: de-DE (de_DE.UTF-8); UI: en-US
> Calc: threaded

That's interesting, because the fix for the bug handled here is contained in 7.3, and I'd expect it not to work with the TDF-provided packages since those are built with older Qt versions, s. previous comments...

Maybe, the issue you're running into is another one and was fixed by one of the recent Wayland-related fixes for the qt5/qt6/kf5 VCL plugins, like
tdf#147523, tdf#144585, or tdf#141578?

> Do i maybe need to switch the the new QT6 based Plugin to make this also
> work in LO 7.3.0.3?

No, shouldn't be needed for the issue handled here.