Description: Setting per monitor scaling factors simply makes Libreoffice unusable (plamsa + wayland) Steps to Reproduce: 1.Set fractional scaling factor per monitor 2.open libreoffice 3. Actual Results: Libreoffice is simply unusable Expected Results: Libreoffice should scale accrdingly Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.2.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: es-ES (es_ES.UTF-8); UI: es-ES 7.1.2-2 Calc: threaded
Created attachment 171049 [details] Libreoffice window main screen (scaling factor 100%)
Created attachment 171050 [details] Libreoffice writer on screen 2 (scaling factor=175%)
Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only the second one having scaling set to 175%. I see the behavior shown in attachment 171050 [details] if the Writer window first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling 175 %), then maximize it. However, when unmaximizing the window and maximizing it again, it looks OK and the whole area of the window is used. This is on Debian testing with plasma-workspace-wayland 4:5.20.5-5, libqt5core5a:amd64 5.15.2+dfsg-5. Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: bcf0ed2f672646107b42cbe67e5c3c9d170bb33a CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #3) > Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only > the second one having scaling set to 175%. Identical situation. > > I see the behavior shown in attachment 171050 [details] if the Writer window > first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling > 175 %), then maximize it. However, when unmaximizing the window and > maximizing it again, it looks OK and the whole area of the window is used. Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize makes it better but I wouldn't say "ok". 1. every time you change screen, you have to minimize and maximize. 2. take a look at the menu bar. It is really inconsistent: on the screen with 100% scaling, it keeps showing the menu-bar 175% scaled.
(In reply to giors_00 from comment #4) > > I see the behavior shown in attachment 171050 [details] if the Writer window > > first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling > > 175 %), then maximize it. However, when unmaximizing the window and > > maximizing it again, it looks OK and the whole area of the window is used. > > Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize > makes it better but I wouldn't say "ok". > > 1. every time you change screen, you have to minimize and maximize. > > 2. take a look at the menu bar. It is really inconsistent: on the screen > with 100% scaling, it keeps showing the menu-bar 175% scaled. You're right, "OK" was maybe too strong, what I meant was that the most obvious problem in the screenshot (that a large part of the area is completely unused) disappears, so this might give a hint on where to look once somebody wants to analyze further.
I have been trying switching between gtk3 and qt5 plugin and have to say that with gtk3 things are going better. No globalmenu nor menu, though...
*** Bug 147639 has been marked as a duplicate of this bug. ***
Created attachment 179388 [details] Weston with two outputs, one scaled and LO kf5 running. I've found that I can run Bullsyeye Weston in a two screen setup with one scaled window via weston.ini: [core] xwayland=true [output] name=X1 mode=800x600 scale=2 [output] name=X2 mode=1024x768 and weston -c $PWD/weston.ini --output-count=2 This works for LO gtk3, but kf5 is broken, interestingly just on the non-scaled screen, the other looks almost correct. But for whatever reason the start center image is tiny on 200%. It looks like LO has cached the larger fonts and scaling when moving the window form 2x to non-scaling. gtk3 is also "interesting", because it changes the layout of the windows near the border and even resizes it. That's still when completely on one screen. Maximizing the main LO window on the scaled screen crashes LO with just Qt stuff in the backtrace (and also crashes gtk3), but works for the non-scaled screen. A kate window is maximizable on both screens and moving it between both screens works fine, so the kf5 LO should be able to work correct; but kf5 has additional Wayland libs; not sure they must be used explicitly or not. I've tried to find a way to flush the graphics cache somehow from the screen change handler to no avail in the end.
Just some finishing comment for the moment. LO VCL has basically no internal representation to handle a changed DPI / scaling factor properly. OutputDevice has mnDPIX, mnDPIY and mnDPIScalePercentage, but these are just updated when a window is destroyed. A crude workaround would probably be to destroy and restore a window when it is moved to a different screen with different scaling. Fixing VCL and widgets at large to support proper scaling is a lot of work. Since Gtk just has non-fractional scaling, it's way of simply upscaling the 100% output works quite well; maybe we should switch to this kind of scaling too, for the time being, seeing also bug 146297...
Created attachment 179412 [details] Screencast of with v3 of Gerrit patch https://gerrit.libreoffice.org/c/core/+/132650
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/881cfbf77567194f5016a961d1c3db869734d68b tdf#141578 Qt handle QtFrame screen changes It will be available in 7.4.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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/76de12a19bd90c0ed0d7a6a85502d3dccdbeba4e tdf#141578 Qt handle QtFrame screen changes It will be available in 7.3.3. 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.
This patch just prevents the min/max hassle, so LO updates the client area of the window correctly. Scaling factor change is still not handled, so I removed the target entries from the whiteboard.
*** Bug 151218 has been marked as a duplicate of this bug. ***
Still repro in 7.4.2.3.
Created attachment 185387 [details] KF5 Backend Screenshot I just tried out different VCL backends using the following Libreoffice version (from Arch/ Manjaro package): Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: 50(Build:3) CPU threads: 6; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+wayland) Locale: de-DE (de_DE.UTF-8); UI: en-US 7.5.0-1 Calc: CL threaded I have a primary 4K screen (125% wayland scaling) and two secondary FHD screens with 100% scaling. The screenshots are all from my primary 4K screen. First with kf5 backend:
Created attachment 185388 [details] QT5 Screenshot Same problem with the QT5 backend
Created attachment 185390 [details] QT6 Backend With Qt6 it looks more or less as desired. Interestingly, xeyes tells me, that this is in fact running in XWayland mode...? Can i force it to somehow use the native Wayland?
Created attachment 185391 [details] QT6 backend in Wayland mode Sorry for the spam, but I don' think that i can edit messages here or attach multiple screenshots to one post. I found the reason for the apparently "good" scaling with QT6. I hadn't installed the qt6-wayland package, so Qt was using XWayland. It also reported the following in the console: > SAL_USE_VCLPLUGIN=qt6 lowriter > qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" After I installed the package, Libreoffice was started with Wayland support and the scaling was bad as with QT5 again.
*** Bug 147216 has been marked as a duplicate of this bug. ***