Bug 137924 - [KF5] UI not scaled correctly on HIDPI Wayland/KDE screens
Summary: [KF5] UI not scaled correctly on HIDPI Wayland/KDE screens
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.0.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:7.3.0
Keywords:
: 142882 147201 (view as bug list)
Depends on:
Blocks: HiDPI Wayland KDE
  Show dependency treegraph
 
Reported: 2020-11-02 05:02 UTC by David Gow
Modified: 2023-11-24 23:36 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Bad.png (see comment) (817.21 KB, image/png)
2021-11-17 16:21 UTC, Walter Tuvell
Details
Good.png (see comment). (1.05 MB, image/png)
2021-11-17 16:25 UTC, Walter Tuvell
Details
Rendering at 200%. Small UI. (11.02 KB, image/webp)
2022-10-10 11:33 UTC, Jos van den Oever
Details
Rendering at 100%. Normal UI. (4.47 KB, image/webp)
2022-10-10 11:34 UTC, Jos van den Oever
Details
LO under kf6 - neon unstable/Wayland - scaled to 80% (497.06 KB, image/jpeg)
2023-11-24 16:16 UTC, pieter kristensen
Details
LO under kf6 - neon unstable/Wayland - scaled to 100% (362.43 KB, image/jpeg)
2023-11-24 16:18 UTC, pieter kristensen
Details
LO under kf6 - neon unstable/Wayland - scaled to 115% (116.30 KB, image/jpeg)
2023-11-24 16:20 UTC, pieter kristensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Gow 2020-11-02 05:02:30 UTC
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
Comment 1 Michael Weghorn 2021-01-04 11:53:48 UTC
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.
Comment 2 Buovjaga 2021-02-18 13:21:57 UTC
Confirmed with a Wayland session on a Lenovo ThinkPad T570
Comment 3 Marian Klein 2021-05-28 00:59:11 UTC
I am affected too. on HiDPI 4k screen wayland on laptop HP Spectre X360
Comment 4 Nate Graham 2021-05-28 01:39:23 UTC
@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...
Comment 5 Marian Klein 2021-05-28 22:26:36 UTC
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.
Comment 6 David Gow 2021-05-30 09:19:00 UTC
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.
Comment 7 Michael Weghorn 2021-06-23 10:40:24 UTC
(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).
Comment 8 Doug 2021-07-25 05:17:36 UTC
*** Bug 142882 has been marked as a duplicate of this bug. ***
Comment 9 Alberto 2021-10-30 21:23:42 UTC
I'm affected too with Manjaro. Wayland session in plasma. Unusable
Comment 10 Walter Tuvell 2021-11-17 16:19:45 UTC
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).
Comment 11 Walter Tuvell 2021-11-17 16:21:31 UTC
Created attachment 176316 [details]
Bad.png (see comment)

Illustration of the problem.
Comment 12 Walter Tuvell 2021-11-17 16:25:24 UTC
Created attachment 176317 [details]
Good.png (see comment).

Illustration of the hack/fix.
Comment 13 Michael Weghorn 2021-11-18 21:07:13 UTC
(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.
Comment 14 Michael Weghorn 2021-11-18 21:22:21 UTC
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.
Comment 15 Commit Notification 2021-11-19 08:13:25 UTC
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.
Comment 16 Nate Graham 2021-11-19 14:36:33 UTC
Woohoo, thanks so much!
Comment 17 David Gow 2021-11-19 14:50:55 UTC
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.
Comment 18 Buovjaga 2021-11-19 14:54:28 UTC
(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
Comment 19 Michael Weghorn 2021-11-19 15:42:19 UTC
(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.
Comment 20 David Gow 2021-11-22 09:20:28 UTC
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!
Comment 21 Michael Weghorn 2021-11-22 09:38:09 UTC
(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!
Comment 22 Cor Blom 2021-12-03 15:43:58 UTC
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?
Comment 23 Buovjaga 2021-12-03 15:47:41 UTC
(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.
Comment 24 giors_00 2022-01-17 17:41:44 UTC
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.
Comment 25 Michael Weghorn 2022-01-17 22:42:54 UTC
(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):
Comment 26 lrdarknesss 2022-04-11 11:40:00 UTC
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?
Comment 27 Michael Weghorn 2022-04-11 12:01:56 UTC
(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.
Comment 28 Michael Weghorn 2022-06-16 10:11:58 UTC
*** Bug 147201 has been marked as a duplicate of this bug. ***
Comment 29 Jos van den Oever 2022-10-10 11:33:03 UTC
I'm still seeing this bug on this version:

Version: 7.3.3.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Rending at 200% fails to scale the UI. Rendering at 100% is fine.
Comment 30 Jos van den Oever 2022-10-10 11:33:47 UTC
Created attachment 182940 [details]
Rendering at 200%. Small UI.
Comment 31 Jos van den Oever 2022-10-10 11:34:20 UTC
Created attachment 182941 [details]
Rendering at 100%. Normal UI.
Comment 32 Jos van den Oever 2022-10-10 11:44:52 UTC
SAL_FORCEDPI=192 'fixes' the rendering of icons and dialogs at 200%, but then the icons are 2x too large on the 100% display.
Comment 33 David Gow 2022-10-10 14:08:13 UTC
For what it's worth, I _can't_ reproduce this anymore — the fix is still working on my system (2× scaled).

Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 34 Michael Weghorn 2022-10-10 14:22:27 UTC
(In reply to Jos van den Oever from comment #29)
> I'm still seeing this bug on this version:
> 
> Version: 7.3.3.2 / LibreOffice Community
> Build ID: 30(Build:2)
> CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded

How did you install that version? Is it the TDF version downloaded from the LibreOffice website or from your distro packages?

As mentioned in comment 13, this requires Qt >= 5.14 to be present at build and run time, i.e. it's not expected to work with TDF packages, but should work with distro packages if the distro provides a new enough Qt version.
Comment 35 Jos van den Oever 2022-10-11 07:32:49 UTC
The version of Qt is 5.15.5. I installed LibreOffice from NixOS 22.05 and NixOS unstable.

LibreOffice 7.4 has not made it to that packager yet.
Comment 36 Michael Weghorn 2022-10-11 12:56:43 UTC
(In reply to Jos van den Oever from comment #35)
> The version of Qt is 5.15.5. I installed LibreOffice from NixOS 22.05 and
> NixOS unstable.

That should be fine.

(In reply to Jos van den Oever from comment #32)
> SAL_FORCEDPI=192 'fixes' the rendering of icons and dialogs at 200%, but
> then the icons are 2x too large on the 100% display.

Is this a multi-monitor with the two screens set to use different scale factors?
Mixed scaling is known to not work really well yet, s. tdf#141578.
Comment 37 pieter kristensen 2023-11-24 16:16:24 UTC
Created attachment 191023 [details]
LO under kf6 - neon unstable/Wayland - scaled to 80%

Looks good to me. Is this bug miraculously healed by qt6? That would be great.
Comment 38 pieter kristensen 2023-11-24 16:18:26 UTC
Created attachment 191024 [details]
LO under kf6 - neon unstable/Wayland - scaled to 100%

This is 100%. For comparisson.
Comment 39 pieter kristensen 2023-11-24 16:20:15 UTC
Created attachment 191025 [details]
LO under kf6 - neon unstable/Wayland - scaled to 115%

Looks good to me. I am surprised by this.
Comment 40 Michael Weghorn 2023-11-24 23:36:43 UTC
(In reply to pieter kristensen from comment #37)
> Looks good to me. Is this bug miraculously healed by qt6? That would be
> great.

The issue that this bug report is about is fixed by the commit in comment 15, and needs a Qt version >= 5.14, so should already work fine with qt5 if you have a recent version of Qt 5.

Besides that, there is tdf#141578, which is about using multiple screens with different scale factors, which to my knowledge isn't fixed in qt6 either.

If you're seeing yet another behavior/scenario, it would be interesting to get more details on that...