Regression: GUI screen resolution seems wrong

harding commented at 6:04 pm on October 15, 2019: contributor

Affects 0.18.1 and 0.19.0rc1.

Before 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 from PR #16254 (backported to 0.18.1 in #16035), icons and text in the GUI seem to correspond to each other nicely. With that commit applied, the text size on the main window hasn’t changed but the icons seem huge and the window size is double its normal size. On dialogs, the text seems like it might even be smaller than before and the dialogs don’t entirely fit on my laptop screen.

Running export QT_AUTO_SCREEN_SCALE_FACTOR=0 before starting bitcoin-qt (0.19.0rc1 binaries from BitcoinCore.org) fixes the problem. (Documentation for this option)

Example images provided at the bottom of this post. Assorted information about my system below. Note: I tested 0.19.0rc1 on my host operating system; builds of 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 and 099e4b9ad3d9967051d5c3d45c6315d1b30fea05^ were run using ssh -X into an lxc container running the same version of Debian (I don’t think this should cause any differences, but it could).

 0$ uname -a
 1Linux ganymede 4.19.0-5-amd64 [#1](/bitcoin-bitcoin/1/) SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
 2
 3$ cat /etc/issue
 4Debian GNU/Linux 10 \n \l
 5
 6$ xrandr | head -n1
 7Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
 8
 9$ dpkg -l '*qt*core*'
10Desired=Unknown/Install/Remove/Purge/Hold
11| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
12|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
13||/ Name                       Version          Architecture Description
14+++-==========================-================-============-========================================
15ii  libqt5core5a:amd64         5.11.3+dfsg1-1   amd64        Qt 5 core module
16ii  libqt5webenginecore5:amd64 5.11.3+dfsg-2+b1 amd64        Web content engine library for Qt - Core
17ii  libqtcore4:amd64           4:4.8.7+dfsg-18  amd64        Qt 4 core module
18un  lxqt-core                  <none>           <none>       (no description available)
19ii  qtcore4-l10n               4:4.8.7+dfsg-18  all          Qt 4 core module translations
20
21$ xdpyinfo | head -n5
22name of display:    :0
23version number:    11.0
24vendor string:    The X.Org Foundation
25vendor release number:    12004000
26X.Org version: 1.20.4

Expected images taken from parent of 099e4b9ad3d9967051d5c3d45c6315d1b30fea05

2019-10-15-07_35_48_663572601

2019-10-15-07_41_49_185306639

Unexpected images taken from 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 and matching 0.19.0rc1

2019-10-15-07_33_37_732384254

2019-10-15-07_43_20_985722563

harding added the label Bug on Oct 15, 2019

harding commented at 6:05 pm on October 15, 2019: contributor

CC: @hebasto (author of #16254 and for helping me investigate)

fanquake added the label GUI on Oct 15, 2019

MarcoFalke added the label Linux/Unix on Oct 15, 2019

MarcoFalke commented at 6:08 pm on October 15, 2019: member

So this only happens when self-compiling on Debian, and not with the static gitian binaries?

harding commented at 6:09 pm on October 15, 2019: contributor

@MarcoFalke no, I first observed it in 0.19.0rc1 (I apparently never upgraded from 0.18.0, so I didn’t notice it in 0.18.1).

Edit: in the 0.19.0rc1 binaries distributed from bitcoincore.org.

hebasto commented at 6:37 pm on October 15, 2019: member

I’m in…

hebasto commented at 6:47 pm on October 15, 2019: member

@harding X11 or Wayland?

hebasto commented at 6:52 pm on October 15, 2019: member

@harding Could you try to pass -resetguisettings? #16254 (comment)

harding commented at 6:52 pm on October 15, 2019: contributor

@hebasto X11, exact version is in the xdpyinfo dump in the OP. Something I should’ve mentioned in the OP is that I use the i3 window manager rather than a more popular DE like Gnome or KDE. I do use a few other Qt applications (all distributed in Debian main/) and haven’t noticed any problems with them.

harding commented at 7:01 pm on October 15, 2019: contributor

@hebasto bitcoin-qt -regtest -resetguisettings produces no change in the alignment between icon and text sizes described in the OP for 0.19.0rc1 (misaligned sizes), 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 (misaligned), and 099e4b9ad3d9967051d5c3d45c6315d1b30fea05^ (expected sizes).

When testing on 0.19.0rc1, I ran it in a loop 10 times because Jonas’s comment indicated it might be inconsistent, but I consistently received the same (undesired) results.

MarcoFalke commented at 7:03 pm on October 15, 2019: member

Your screen is not HiDPI, right?

harding commented at 7:11 pm on October 15, 2019: contributor

@MarcoFalke I don’t think so. Wikipedia says:

HDPI or HiDPI High density ≈213–240 dots per inch

My system says:

0$ xdpyinfo | command grep -B 2 resolution
1screen [#0](/bitcoin-bitcoin/0/):
2  dimensions:    1920x1080 pixels (508x285 millimeters)
3  resolution:    96x96 dots per inch

My monitor is a “14” Full HD eDP LED LCD Screen (Non touch) 1920 x 1080" used with my Thinkpad T450s laptop.

hebasto commented at 7:42 pm on October 15, 2019: member

My monitor is a “14” Full HD eDP LED LCD Screen (Non touch) 1920 x 1080" used with my Thinkpad T450s laptop.

Could it be something wrong when EDID information is passed from LCD to Thinkpad?

harding commented at 9:10 pm on October 15, 2019: contributor

@hebasto do you have any suggestions for testing that hypothesis? E.g., is there some command output I can check?

I did a web search to see what information I could get related to EDID and have pasted it below; it all looks correct to me. E.g., the resolution returned by xrandr matches my display resolution (tested by comparing to images of that resolution at 1:1 scale) and the physical size is +/- 10mm per my measurement.

However, the physical dimensions returned by xrandr of 308mm x 173mm (correct) don’t match the dimensions returned by xdpyinfo of 508mm x 285mm (too big), so the true DPI is about 158x158. That’s still not high enough to be HiDPI per the Wikipedia article above, so even with this disagreement, I don’t think applications should be using HiDPI.

Another note I’d add for posterity is that this is an after-market monitor (my original broke and I replaced it with an equivalent one from a third-party seller). However, that replacement was months ago and I haven’t noticed problems with any other applications, including Qt applications.

In short, my guess would be that the EDID information is being correctly communicated, at least to the OS.

Section “Monitor” Identifier "" ModelName "" VendorName “CMN” # Monitor Manufactured week 14 of 2015 # EDID version 1.4 # Digital Display DisplaySize 310 170 Gamma 2.20 Option “DPMS” “false” Modeline “Mode 0” -hsync -vsync EndSection

$ xrandr –verbose Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP-1 connected primary 1920x1080+0+0 (0x48) normal (normal left inverted right x axis y axis) 308mm x 173mm Identifier: 0x42 Timestamp: 8671731 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff000daea71400000000 0e190104951f117802fda59255529428 24505400000001010101010101010101 010101010101b43b804a71383440503c 680034ad10000018000000fe004e3134 304847452d4541410a20000000fe0043 4d4e0a202020202020202020000000fe 004e3134304847452d4541410a200037 scaling mode: Full aspect supported: Full, Center, Full aspect Broadcast RGB: Automatic supported: Automatic, Full, Limited 16:235 link-status: Good supported: Good, Bad CONNECTOR_ID: 65 supported: 65 non-desktop: 0 range: (0, 1) 1920x1080 (0x48) 152.840MHz -HSync -VSync *current +preferred h: width 1920 start 2000 end 2060 total 2250 skew 0 clock 67.93KHz v: height 1080 start 1086 end 1094 total 1132 clock 60.01Hz

0</details>

hebasto commented at 10:01 am on October 16, 2019: member

@harding Are there any errors when you run

0QT_FATAL_WARNINGS=1 bitcoin-qt -regtest -debug=qt

?

hebasto commented at 10:13 am on October 16, 2019: member

@harding Also could you try to run:

0QT_SCREEN_SCALE_FACTORS=1 bitcoin-qt -regtest

?

hebasto commented at 11:15 am on October 16, 2019: member

Tested on Debian 10 with i3 window manager.

 0hebasto@debian:~$ uname -a
 1Linux debian 4.19.0-6-amd64 [#1](/bitcoin-bitcoin/1/) SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
 2hebasto@debian:~$ cat /etc/issue
 3Debian GNU/Linux 10 \n \l
 4
 5hebasto@debian:~$ xrandr | head -n1
 6Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
 7hebasto@debian:~$ xdpyinfo | head -n5
 8name of display:    :0
 9version number:    11.0
10vendor string:    The X.Org Foundation
11vendor release number:    12004000
12X.Org version: 1.20.4

VirtualBox_Debian Core_16_10_2019_14_09_18

It works as expected. Will investigate further…

hebasto commented at 12:02 pm on October 16, 2019: member

@harding

My system says:

0$ xdpyinfo | command grep -B 2 resolution
1screen [#0](/bitcoin-bitcoin/0/):
2  dimensions:    1920x1080 pixels (508x285 millimeters)
3  resolution:    96x96 dots per inch

However, the physical dimensions returned by xrandr of 308mm x 173mm (correct) don’t match the dimensions returned by xdpyinfo of 508mm x 285mm (too big)…

I assume that the wrong DPI given by the X server is the root of the observed issue.

Could you try to fix the DPI displayed by xdpyinfo?

laanwj commented at 1:11 pm on October 16, 2019: member

I don’t think a wrong DPI may cause this issue. Things become too large, or too small to read, but they shouldn’t become inconsistent. Text and icons are supposed to be scaled at the same rate, if DPI is handled correctly (~~and apparently it did before~~ this isn’t clear, maybe they just happened to be in the same ballpark).

X11’s view of DPI is a very deep rabbit hole with a long history (xdpyinfo will pretty much always return 96x96 due to historical reasons), and I think it’s a distraction here.

However, the physical dimensions returned by xrandr of 308mm x 173mm (correct) don’t match the dimensions returned by xdpyinfo of 508mm x 285mm (too big),

This is very much as expected. xrandr’s output is what comes from the kernel so should be more or less correct.

emilengler commented at 1:11 pm on October 16, 2019: contributor

I don’t have huge experiences with i3, but maybe it is because of your layout

laanwj commented at 1:27 pm on October 16, 2019: member

One guess is that the consistency issue between images and icons is a font issue (locally, on your system). That it somehow cannot find a font with the right size to fit the DPI. (If it did, things would be too large for your taste, but one thing at at time…) This is a random guess and I don’t know how to troubleshoot this.

so the true DPI is about 158x158.

Hmm—this is “higher DPI”, given that the default assumption for most OSes always used to be 96x96. It’s about 1.5× higher but not “real” HiDPI. It’s the scale that causes the most issues also in my experience, because different things have different thresholds and some things might fall below the threshold (so round down to 1×) while others fall above (and go to 2×). Ugh.

harding commented at 5:44 pm on October 16, 2019: contributor

@hebasto

Are there any errors when you run QT_FATAL_WARNINGS=1 bitcoin-qt -regtest -debug=qt?

No on 0.19.0rc1 from BitcoinCore.org and run in host OS
Yes on 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 self-compiled and run via ssh -X
Yes on 099e4b9ad3d9967051d5c3d45c6315d1b30fea05^ self-compiled and run via ssh -X

On both of the failures, the only thing printed to screen was “Aborted” almost instantly after running the command. Nothing was printed to my ~/.bitcoin/regtest/debug.log. I ran both again without the environment variable and collected their logs:

Looking at the logs and extrapolating from the instantaneous failure, my guess is the the fatal warning was:

2019-10-16T17:30:05Z GUI: QObject::connect: invalid null parameter

Given its name and since it occurs on both commits, I’m guessing it’s unrelated (but I’m happy to test further, of course).

hebasto commented at 7:44 pm on October 16, 2019: member

@harding

Given its name and since it occurs on both commits, I’m guessing it’s unrelated (but I’m happy to test further, of course).

I quite agree with you. That error was fixed in a2aabfb749198bce896c9e597082acd67d3b863e, IIRC.

harding commented at 10:38 pm on October 16, 2019: contributor

@hebasto

Also could you try to run: QT_SCREEN_SCALE_FACTORS=1 bitcoin-qt -regtest ?

Tried on all three versions and this produced no change from the default behavior (i.e. 0.19.0rc1 had inconsistent icon/font size, 099e4b9ad3d9967051d5c3d45c6315d1b30fea05 was inconsistent, 099e4b9ad3d9967051d5c3d45c6315d1b30fea05^ had consistent icon/font size).

Could you try to fix the DPI displayed by xdpyinfo?

This seems to have had an effect. I started a second X session from a ptty using startx /usr/bin/i3 -- :1 -dpi 158 and was greeted by physically larger font sizes in the window manager. Opening 0.19.0rc1, it’s icon and font sizes matched (screenshot at end of post). Xrandr prints the same information as before, but xdpyinfo’s output no longer says 96x96 dpi and now says 158x159dpi, and it also reports the correct screen size:

0screen [#0](/bitcoin-bitcoin/0/):
1  dimensions:    1920x1080 pixels (308x173 millimeters)
2  resolution:    158x159 dots per inch

This makes it look like it could indeed be a system issue on my side. Or maybe it still isn’t per @laanwj’s remarks. Working around this issue is easy for me, so I’m ok with it stagnating for a while or being closed in the absence of other people reporting similar problems. @emilengler

I don’t have huge experiences with i3, but maybe it is because of your layout

I tested without a window manager (from a ptty, startx /usr/bin/rxvt -- :1) and still had the problem, so I don’t think it’s an i3 issue.

2019-10-16-12_12_56_626798412

(Lightedly edited to redact some irrelevant output from ls.)

hebasto commented at 5:36 am on October 17, 2019: member

@harding

Could you try to fix the DPI displayed by xdpyinfo?

This seems to have had an effect. I started a second X session from a ptty using startx /usr/bin/i3 -- :1 -dpi 158 and was greeted by physically larger font sizes in the window manager. Opening 0.19.0rc1, it’s icon and font sizes matched (screenshot at end of post).

Thank you for testing.

n1kcha commented at 8:01 pm on November 27, 2019: none

I have the same issue since 0.18 on Fedora 31 (wayland) on my Dell laptop (Vostro 5481). I have not the same issue with Fedora 31 (wayland also) on my desktop pc… Same software, different hardware and different behaviour. I don’t know if it helps but on laptop i use Intel graphic card and open drivers and at desktop Nvidia card and Nvidia drivers.

hebasto commented at 7:48 am on November 28, 2019: member

@n1kcha Could you try the latest 0.19 version?

n1kcha commented at 11:48 am on November 28, 2019: none

@hebasto I have installed 0.19 already . Same behavior: Laptop big size /Desktop normal size…

hebasto commented at 12:10 pm on November 28, 2019: member

@n1kcha Qt behaves weird on wayland for me too. Will investigate further.

laanwj referenced this in commit 07efb3fe2b on Jan 8, 2020

fanquake commented at 7:25 am on August 10, 2020: member

@harding Thanks for the extensive debugging / info here. Could you port your issue over to the GUI repo. I’m assuming this is still an issue and hasn’t been resolved in 0.20.0, master or with newer versions of Qt?

fanquake closed this on Aug 10, 2020

harding commented at 3:54 pm on September 20, 2020: contributor

Update: I continued having this problem through 0.20.0 (bitcoincore.org binaries) but I just (1) updated my build container from Debian oldstable to current stable and (2) built and installed master at commit 38fd1bdcd4a5abbd0dbbf4ec93de9010cffa4055 and this problem is resolved. I don’t see any recent merges to explain this fix but if anyone needs to me investigate and pin down exactly what resolved this issue, let me know here or in the GUI repository.

DrahtBot locked this on Feb 15, 2022

Regression: GUI screen resolution seems wrong #17153