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.
*** Bug 147201 has been marked as a duplicate of this bug. ***
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.
Created attachment 182940 [details] Rendering at 200%. Small UI.
Created attachment 182941 [details] Rendering at 100%. Normal UI.
SAL_FORCEDPI=192 'fixes' the rendering of icons and dialogs at 200%, but then the icons are 2x too large on the 100% display.
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
(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.
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.
(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.
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.
Created attachment 191024 [details] LO under kf6 - neon unstable/Wayland - scaled to 100% This is 100%. For comparisson.
Created attachment 191025 [details] LO under kf6 - neon unstable/Wayland - scaled to 115% Looks good to me. I am surprised by this.
(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...
I am using both Neon user and Neon testing. Is there a way to test the qt6/kf6 integration on these systems? I believe those packages aren't in the repositories at this moment. Thank you.
(In reply to pieter kristensen from comment #41) > I am using both Neon user and Neon testing. Is there a way to test the > qt6/kf6 integration on these systems? > I believe those packages aren't in the repositories at this moment. > Thank you. TDF builds don't include these VCL plugins at this point either, because AlmaLinux 8 (on which the builds are done) doesn't have Qt 6 yet. You can build LibreOffice yourself ( see https://wiki.documentfoundation.org/Development/BuildingOnLinux - add the --enable-qt6/--enable-kf6 autogen switches to enable these). Alternatively, you could try using packages from another distro, but that may or may not work, depending on whether these depend on newer system libraries than what KDE Neon provides.