http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c2 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hellcp@mailbox.org Flags| |needinfo?(hellcp@mailbox.or | |g) --- Comment #2 from Stefan Hundhammer --- Stasiek, any idea? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c4 Stasiek Michalski changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(hellcp@mailbox.or | |g) | --- Comment #4 from Stasiek Michalski --- I suspect that's not just Gnome changes. YaST CC and modules around it were heavily updated over the last year, introducing fixes to hidpi, svg icons etc. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c6 --- Comment #6 from Stefan Hundhammer --- I just did a fresh Leap 15.0 installation in a QEMU VM to test this. AFAICS that release does not have SVG icons yet for the YaST modules; it is limited to a small set of pre-rendered PNG icons in those sizes below /usr/share/YaST2/theme/icons: 22x22/ 32x32/ 48x48/ 64x64/ 256x256/ I can confirm that strange things happen when trying to increase the desktop scaling factor from 1.25 to 1.26, but in my case the content (both the icons and the texts) completely disappear. The YaST control center doesn't do anything special here; it just uses Qt defaults for both font and icon sizes. I am pretty sure that other Qt programs must have the same kind of problem in that scenario; this must be somewhere deep within Qt, very likely in the layer that implements the desktop settings that Qt (starting with Qt 5.x) now takes from its desktop. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c8 --- Comment #8 from Stefan Hundhammer --- Confirmed. I just checked with QDirStat, and it has the exact same problem: When choosing a "weird" scaling factor, I get only the menu in a really tiny font. I see icons in the menu, but all other window elements are gone - just flat grey. There is no tree, no treemap, nothing. When choosing another scaling factor like 1.5 or 2.0, the application scales nicely. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c10 --- Comment #10 from Stefan Hundhammer --- Created attachment 798758 --> http://bugzilla.suse.com/attachment.cgi?id=798758&action=edit Screenshot: QDirStat in Leap 15.0 with desktop scaling factor 1.74 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c12 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|YaST icons and fonts switch |Qt5 application rendering |to half size when Tweaking |broken with "odd" GNOME |font scale from 1,25 to |desktop scaling factors |1,26 (HiDPI) |like 1.26 instead of 1.25 / | |1.5 / 1.75 / 2.0 / ... --- Comment #12 from Stefan Hundhammer --- Changing the subject. Old subject: "YaST icons and fonts switch to half size when Tweaking font scale from 1,25 to 1,26 (HiDPI) " -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c14 --- Comment #14 from Stefan Hundhammer --- I just checked: It's the exact same in a reasonably recent Tumbleweed (tested with openSUSE-Tumbleweed-DVD-x86_64-Snapshot20190224-Media.iso). Test procedure: - Install with a GNOME desktop - Install any pure Qt application (used QDirStat here) - In the GNOME desktop, open the "Tweaks" application - In "Tweaks", switch to the "Fonts" page and change the "Scaling Factor" - Start the Qt application (QDirStat or whatever) - Check if the UI is rendered normally or with that tiny font scaling factor multiple of 0.25 -> works any other number (1.26, 1.01) -> fail -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shundhammer@suse.com Component|YaST2 |Other Assignee|yast-internal@suse.de |mlin@suse.com QA Contact|jsrain@suse.com |qa-bugs@suse.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alarrosa@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c17 --- Comment #17 from Fabian Vogt --- What GNOME shows as "scale factor" is actually just the font size. YaST does not scale at all in those screenshot as you can tell by the tiny buttons in the dock. It's still unexpected behaviour though, as text should not get smaller if the font size increases... What's the output of "xrdb -query | grep Xft"? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c19 --- Comment #19 from Stefan Hundhammer --- tux@g1:~> xrdb -query | grep Xft Xft.dpi: 120.9599609375 Xft.antialias: 1 Xft.hinting: 1 Xft.hintstyle: hintslight Xft.rgba: none tux@g1:~> QT_LOGGING_RULES=qt.qpa.screen.debug=true qdirstat . Logging to /tmp/qdirstat-tux/qdirstat.log tux@g1:~> fgrep '<Verbose>' /tmp/qdirstat-tux/qdirstat.log 2019-03-04 17:36:58.204 [2558] <Verbose> Failed to parse EDID data for output "XWAYLAND0" edid data: "" 2019-03-04 17:36:58.208 [2558] <Verbose> adding QXcbScreen(0x5596f81fc8b0, name="XWAYLAND0", geometry=1680x1050+0+0, availableGeometry=1680x1016+0+34, devicePixelRatio=1.0, logicalDpi=QPair(inf,inf), physicalSize=0.0x0.0mm, screenNumber=0, virtualSize=1680x1050 (1680.0x1050.0mm), orientation=Qt::LandscapeOrientation, depth=24, refreshRate=59.0, root=38c, windowManagerName="GNOME Shell") (Primary: true ) 2019-03-04 17:36:58.208 [2558] <Verbose> primary output is "XWAYLAND0" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c21 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |GNOME Assignee|mlin@suse.com |bnc-team-gnome@forge.provo. | |novell.com Flags|needinfo? | --- Comment #21 from Fabian Vogt --- (In reply to Stefan Hundhammer from comment #19)

tux@g1:~> xrdb -query | grep Xft Xft.dpi: 120.9599609375

This seems to be the culprit to me. Does it work after running "echo Xft.dpi: 120 | xrdb -nocpp -merge"? If that's not enough, does "QT_LOGGING_RULES=qt.qpa.screen.debug=true QT_FONT_DPI=120 qdirstat" work?

Xft.antialias: 1 Xft.hinting: 1 Xft.hintstyle: hintslight Xft.rgba: none

tux@g1:~> QT_LOGGING_RULES=qt.qpa.screen.debug=true qdirstat . Logging to /tmp/qdirstat-tux/qdirstat.log

tux@g1:~> fgrep '<Verbose>' /tmp/qdirstat-tux/qdirstat.log 2019-03-04 17:36:58.204 [2558] <Verbose> Failed to parse EDID data for output "XWAYLAND0" edid data: ""

2019-03-04 17:36:58.208 [2558] <Verbose> adding QXcbScreen(0x5596f81fc8b0, name="XWAYLAND0", geometry=1680x1050+0+0, availableGeometry=1680x1016+0+34, devicePixelRatio=1.0, logicalDpi=QPair(inf,inf), physicalSize=0.0x0.0mm, ^^^^^^^

That doesn't look right either, but it might be unrelated. It's caused by the invalid physicalSize value, so the safeguards there didn't work for some reason. I'll have a look at that tomorrow. What does xrandr show as geometry?

screenNumber=0, virtualSize=1680x1050 (1680.0x1050.0mm), orientation=Qt::LandscapeOrientation, depth=24, refreshRate=59.0, root=38c, windowManagerName="GNOME Shell") (Primary: true )

2019-03-04 17:36:58.208 [2558] <Verbose> primary output is "XWAYLAND0"

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 Yifan Jiang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qkzhu@suse.com, | |xwang@suse.com, | |yfjiang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c24 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #24 from Fabian Vogt --- (In reply to Stefan Hundhammer from comment #23)

(In reply to Fabian Vogt from comment #21)

...

(In reply to Stefan Hundhammer from comment #19)

...

tux@g1:~> xrdb -query | grep Xft Xft.dpi: 120.9599609375

This seems to be the culprit to me. Does it work after running "echo Xft.dpi: 120 | xrdb -nocpp -merge"?

Right; that fixes the problem indeed, both for QDirStat and for the YaST Qt control center.

Ok, that confirms that the root cause is GNOME not rounding Xft.dpi.

...

If that's not enough, does "QT_LOGGING_RULES=qt.qpa.screen.debug=true QT_FONT_DPI=120 qdirstat" work?

I tried this first (to leave the X resources undisturbed before changing them for the running X server with the "xrdb" command) and I can confirm that this also works.

Regarding the "QDpi(inf, inf)" issue - does that still appear if "Xft.dpi" is set to a valid integer? If so, can you give me access to the VM you saw it on? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c26 --- Comment #26 from Stefan Hundhammer --- When I round the Xft.dpi to an integer number, it also works fine. tux@g1:~> echo Xft.dpi: 121 | xrdb -nocpp -merge tux@g1:~> qdirstat . -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c28 --- Comment #28 from Fabian Vogt --- (In reply to Stefan Hundhammer from comment #27)

Wild shot into the blue: QVariant conversion gone wrong? Expecting and int and getting a double, so the toInt() conversion fails?

No, Qt simply expects that Xft.dpi is an integer, but it's not, so Xft.dpi is ignored and it uses whatever is the next source for the logical DPI (in this case the physical screen DPI). This needs to be fixed in GNOME. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c29 --- Comment #29 from Stefan Hundhammer --- I completely agree that the GNOME people should fix that on their level. But Qt could also do this a lot more defensively; AFAICS it would be a really trivial patch to also check for a double if the int conversion fails: https://github.com/qt/qtbase/blob/5.12/src/plugins/platforms/xcb/qxcbscreen.... static bool parseXftInt(const QByteArray& stringValue, int *value) { Q_ASSERT(value != 0); bool ok; *value = stringValue.toInt(&ok); return ok; } Maybe something like (untested) static bool parseXftInt(const QByteArray& stringValue, int *value) { Q_ASSERT(value != 0); bool ok; *value = stringValue.toInt(&ok); if (!ok) *value = round(stringValue.toDouble(&ok) return ok; } (Even the rounding is already the de luxe version) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1123424 http://bugzilla.suse.com/show_bug.cgi?id=1123424#c31 --- Comment #31 from Fabian Vogt --- (In reply to Fabian Vogt from comment #24)

Regarding the "QDpi(inf, inf)" issue - does that still appear if "Xft.dpi" is set to a valid integer? If so, can you give me access to the VM you saw it on?

It does and it's indeed simply because the physicalSize is invalid. Normally the X server takes care of not supplying invalid values there, but apparently it does anyway. So that's either a bug in Xwayland or gnome. In this case playing it safe in Qt and using 96 dpi for guessing the physical size (same what X normally does) might make sense, but unless we see any bugs directly caused by that it shouldn't be necessary. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1123424 https://bugzilla.suse.com/show_bug.cgi?id=1123424#c33 Stefan Hundhammer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dieter.jurzitza@t-online.de --- Comment #33 from Stefan Hundhammer --- *** Bug 1167341 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.