Created attachment 124632 [details] Dolphin vs a Gtk+ app rendering SUMMARY Certain apps are rendering font sizes too large in comparison to others. This applies to: * Dolphin * Kate * KWrite * Konsole The font sizes are about 25% larger than expected. System Settings and just about every other app I have including Chromium run at the correct size. I am attaching screenshots for reference. The first is a Gtk+ app vs Dolphin, where the Gtk+ app is showing the correct scale. The second is System Settings which is rendering correctly with the current settings. STEPS TO REPRODUCE 1. Set scale factor to 1.5 2. Log out and log back in 3. Run Kate OBSERVED RESULT Kate is running with correct size icons (I think) but a 25% larger font than expected. EXPECTED RESULT Kate should have normal size fonts as other apps (like System Settings) do. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Gentoo, 5.17.4 (available in About System) KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.14.0 ADDITIONAL INFORMATION Recently updated to latest versions available of Qt, Plasma, etc on Gentoo Portage. This was not happening in a prior version. I do not have forced font DPI enabled nor a DPI setting in ~/.Xresources.
Created attachment 124633 [details] System Settings rendering correctly
Created attachment 124634 [details] Konsole displaying incorrectly Konsole claims this is point size 9 but it definitely is not when compared to my browser or LibreOffice.
Created attachment 124635 [details] New user screenshot This is from a new user account with minimal customisation, 1.5x scale enabled, 144 DPI force enabled (because that is what System Settings does automatically). The left is Kate and the right KPatience. KPatience correctly shows its menus while Kate remains too large.
Created attachment 124839 [details] VirtualBox screenshot Found a non-KDE app affected: VirtualBox
Did you reboot after applying the 1.5x scale factor? Does the issue reproduce when switching to the Breeze widget style and Breeze icons and rebooting?
I rebooted and still get the same issue. About to try switching to Breeze widget style.
Rebooted with Breeze theme (and all other appearance settings set to Breeze) and still got the same issue. Just for reference, this is a KF5 5.65.0 installation. Plasma-desktop and related is at 5.17.4. Qt is at 5.14.0.
Thanks.
Do the Qt applications look as expected if you force DPI to 96? If so, it's probably Qt scaling fonts twice (1.5 * 144dpi = 216dpi) which amounts to a 2.25x scaling of fonts.
Yes, I confirm that setting DPI to 96 for fonts fixes the issue for me (although compared to the reporter, I have issues only in apps that use QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true)).
So maybe Qt 5.14 is double-scaling the fonts for apps using Qt::AA_EnableHighDpiScaling. :/ Sounds like maybe it's time for a Qt bug report. Any chance you could file one?
I currently have the broken apps forced to use 96 DPI but of course this means the toolbar icons, etc are very small on a 4K display.
It's probably accidentally fixed in Qt5.14.1 with c7fec68e1936576070d0fbac6cf40b818366d298 on QtBase, but that commit will break other things and I'm hoping it gets reverted. There's some follow up on https://codereview.qt-project.org/c/qt/qtbase/+/285351
Either way, a Qt bug. Let's follow up upstream. Thanks everyone!
The matching upstream bug report seems to be https://bugreports.qt.io/browse/QTBUG-80919 The "accidental fix" was part of the efforts for https://bugreports.qt.io/browse/QTBUG-80323
I think maybe this bug we're seeing is user's running plasma compiled against Qt5.13 on 5.14 - we introduced a change in startplasma, but we made that switch at compile time, which is arguably not right.
As you're on gentoo, can you be sure to re-emerge plasma-workspace after you upgraded Qt to rule that out?
(In reply to David Edmundson from comment #17) > As you're on gentoo, can you be sure to re-emerge plasma-workspace after you > upgraded Qt to rule that out? Currently doing a system upgrade which update my system to 5.17.5. I will reboot after to make sure I'm running all newly built libs.
I updated and rebooted. This issue remains. I tested Ark, VirtualBox and Qt Designer. All 3 show large fonts.
Also one workaround for now that must be applied to the broken apps specifically is to use the QT_FONT_DPI environment variable. Setting this to 96 in the .desktop file for Kate/Dolphin/etc makes things seem normal again, and icons are the correct size. $ fgrep Exec ~/.local/share/applications/org.kde.kate.desktop Exec=env QT_FONT_DPI=96 kate -b %U
(In reply to David Edmundson from comment #13) > It's probably accidentally fixed in Qt5.14.1 with > c7fec68e1936576070d0fbac6cf40b818366d298 on QtBase, but that commit will > break other things and I'm hoping it gets reverted. In a downstream bug report (https://bugzilla.opensuse.org/show_bug.cgi?id=1160624) I asked the reporter to test 5.14.0 with that commit applied and it's only a partial success: > Thanks,the workarroun partial fix the issue but kwon decorations now are to > small, I Will wait until the bug is solved.
*** Bug 416014 has been marked as a duplicate of this bug. ***
*** Bug 416124 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #14) > Either way, a Qt bug. Let's follow up upstream. > > Thanks everyone! Can you please point me to the Qt bug report? I first could workaround this by moving from the Manjaro testing branch to the stable branch, but with the latest update I'm not effected again and it's really annoying. :-(
I put it in the URL field of this bug report. :)
(In reply to Nate Graham from comment #25) > I put it in the URL field of this bug report. :) But it's not merged yet? Uh, this is really bothering me a lot. Any ETA? (In reply to Andrew Udvare from comment #20) > Also one workaround for now that must be applied to the broken apps > specifically is to use the QT_FONT_DPI environment variable. Setting this to > 96 in the .desktop file for Kate/Dolphin/etc makes things seem normal again, > and icons are the correct size. > > $ fgrep Exec ~/.local/share/applications/org.kde.kate.desktop > Exec=env QT_FONT_DPI=96 kate -b %U Unfortunately this did only work for me for Kate and Okular. Konsole resists to `env QT_FONT_DPI=96 konsole` in the desktop file.* I placed it at every Exec= line. What I do now is, open Konsole and enter "env QT_FONT_DPI=96 konsole", which works... * I made sure via updatedb && locate konsole.desktop that there's only one.
Even with the pending Qt patch for Xft.dpi merged, this doesn't seem to be completely fixed, see comment 21. However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal success. I tried to reproduce the issue in a VM and can't tell a difference between QT_AUTO_SCREEN_SCALE_FACTOR set to 0 and unset. So I assume this is related to the hardware's reported DPI. This makes sense considering that QT_AUTO_SCREEN_SCALE_FACTOR is about that - using hardware dpi / 96 for scaling. So AFAICT QT_AUTO_SCREEN_SCALE_FACTOR=0 is still necessary even with Qt 5.14.x. Reopening as this appears to require more discussion. Note that the not directly related text rendering issue (https://bugreports.qt.io/browse/QTBUG-80967) should be fixed with Qt 5.14.1, but is also worked around by setting QT_AUTO_SCREEN_SCALE_FACTOR=0.
(In reply to Fabian Vogt from comment #27) > However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal > success. > Thanks, I can confirm that! I had to revert the `Exec=env QT_FONT_DPI=96` changes in the desktop file and added `QT_AUTO_SCREEN_SCALE_FACTOR=0` to /etc/environment. After rebooting everything went back to normal. (Putting `export QT_AUTO_SCREEN_SCALE_FACTOR=0` into the .bashrc and logging out and back in again was not successfull for unknown reasons.)
The goal should be to have no extra environment variables set to solve this issue.
(In reply to Postix from comment #28) > (In reply to Fabian Vogt from comment #27) > > However, setting QT_AUTO_SCREEN_SCALE_FACTOR=0 seems to have universal > > success. > > > > > Thanks, I can confirm that! I had to revert the `Exec=env QT_FONT_DPI=96` > changes in the desktop file and added `QT_AUTO_SCREEN_SCALE_FACTOR=0` to > /etc/environment. > After rebooting everything went back to normal. > > (Putting `export QT_AUTO_SCREEN_SCALE_FACTOR=0` into the .bashrc and logging > out and back in again was not successfull for unknown reasons.) I put export QT_AUTO_SCREEN_SCALE_FACTOR=0 in my ~/.xprofile and everything works like it should.
Git commit ea66bff2af8466f2bb5acafcc43ac8f79b1f447f by Fabian Vogt. Committed on 21/01/2020 at 10:56. Pushed by fvogt into branch 'Plasma/5.18'. Also disable automatic scaling on Qt >= 5.14 Summary: Applications which set `Qt::AA_EnableHighDpiScaling` use the DPI of the monitor the window is on to calculate an additional scaling factor. Plasma sets `QT_SCREEN_SCALE_FACTORS` in the environment for manual specification of per-monitor scale, which combined with the automatic scaling may result in double scaling. To disable the automatic scaling, `QT_AUTO_SCREEN_SCALE_FACTOR=0` has to be set, even on Qt 5.14. As a side effect, this works around QTBUG-80967 as well. Test Plan: On X11, with a >144dpi monitor and a scaling factor of 2 set manually, scaling was doubled previously. Now it works as expected. Reviewers: #plasma, apol, davidedmundson, fvogt Reviewed By: #plasma, davidedmundson, fvogt Subscribers: acooligan, fvogt, asturmlechner, dfaure, davidedmundson, anthonyfieroni, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D26185 M +0 -2 startkde/startplasma.cpp https://commits.kde.org/plasma-workspace/ea66bff2af8466f2bb5acafcc43ac8f79b1f447f
(In reply to Fabian Vogt from comment #31) > Git commit ea66bff2af8466f2bb5acafcc43ac8f79b1f447f by Fabian Vogt. > Committed on 21/01/2020 at 10:56. > Pushed by fvogt into branch 'Plasma/5.18'. > > Also disable automatic scaling on Qt >= 5.14 > > Summary: > Applications which set `Qt::AA_EnableHighDpiScaling` use the DPI of the > monitor the window is on to calculate an additional scaling factor. > Plasma sets `QT_SCREEN_SCALE_FACTORS` in the environment for manual > specification of per-monitor scale, which combined with the automatic > scaling may result in double scaling. > To disable the automatic scaling, `QT_AUTO_SCREEN_SCALE_FACTOR=0` has to be > set, even on Qt 5.14. > > As a side effect, this works around QTBUG-80967 as well. > > Test Plan: On X11, with a >144dpi monitor and a scaling factor of 2 set > manually, scaling was doubled previously. Now it works as expected. > > Reviewers: #plasma, apol, davidedmundson, fvogt > > Reviewed By: #plasma, davidedmundson, fvogt > > Subscribers: acooligan, fvogt, asturmlechner, dfaure, davidedmundson, > anthonyfieroni, plasma-devel > > Tags: #plasma > > Differential Revision: https://phabricator.kde.org/D26185 > > M +0 -2 startkde/startplasma.cpp > > https://commits.kde.org/plasma-workspace/ > ea66bff2af8466f2bb5acafcc43ac8f79b1f447f That fix resolves most of the issue but Chrome seems to now run with a reduced environment. /proc/<chrome PID>/environ shows a very minimal environment. As a result, when Chrome launches Ark (click on item in the download bar) I get the same issue. I modified the .desktop file to force the QT_AUTO_SCREEN_SCALE_FACTOR=0 value and it works. I wouldn't want to have to create custom .desktop files just for Chrome. Should I file another ticket?
(In reply to Andrew Udvare from comment #32) > That fix resolves most of the issue but Chrome seems to now run with a > reduced environment. /proc/<chrome PID>/environ shows a very minimal > environment. As a result, when Chrome launches Ark (click on item in the > download bar) I get the same issue. I modified the .desktop file to force > the QT_AUTO_SCREEN_SCALE_FACTOR=0 value and it works. I wouldn't want to > have to create custom .desktop files just for Chrome. Should I file another > ticket? Yes, that seems unrelated.