|
Bugzilla – Full Text Bug Listing |
| Summary: | Wrong resolution at Installation / Window background not cleared | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Johannes Sudermann <outside> |
| Component: | Installation | Assignee: | Stefan Hundhammer <shundhammer> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | fvogt, glorp.gleep, jhura, johnf, jreidinger, kanderssen, lmtzw5ld, maint-coord, mrmazda, outside, snwint, tamara.schmitz, thenerdiestguy |
| Version: | Current | ||
| Target Milestone: | Current | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| URL: | https://trello.com/c/ST2Xm5iz | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Picture of the Yast2 installer
Yast2 Logs Another set of logfiles look of installer at 1366x768 Screenshot: YaST partitioner Screenshot: YaST partitioner scaled to 1.7 in "Add Partition" Screenshot: YaST partitioner during installation overwriting content Screenshot: Using style.qss Screenshot: Widget tree in simplified wizard Screenshot: installation.qss from SLE also overwriting previous content Screenshot after the fix |
||
please attach yast logs. It will help us to see what resolution installer picks up and how hw probing result. Thanks Howto: https://en.opensuse.org/openSUSE:Report_a_YaST_bug Created attachment 858541 [details]
Yast2 Logs
I've added the y2logs.tgz to the attachments. Hope this is the right one. Just adding that on lower resolution (1366 x 768) the installer only shows a very partial image of the installer and thus basically isn't usable at all because not all buttons can be reached. I can confirm this bug, it happens when I click on configure network adapter 1080p screen, latest ISO, OSTW offline image On a Lenovo IdeaPad S340 laptop I think OP already posted the logs but forgot to clear the needinfo request, so I cleared it with this post. Or is there more info needed? Values from X Server detection looks correct |-- X-Server is ready: 4608 Stage [call]: Monitor size: eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm Stage [call]: Monitor width mm: 344 Stage [call]: Monitor width px: 1920 Stage [call]: Monitor dpi: 144 Stage [call]: Xft.dpi set to: 144 |-- Allow big memory allocation: overcommit_memory=1 |-- Starting YaST2: |-- MODULE_NAME: installation |-- MODE_FLAGS: |-- MODULE_ARGS: --arg initial |-- MODE: qt |-- UI_ARGS: --noborder --auto-fonts --fullscreen |-- QT_IM_MODULE: xim HuHa do you think that it can accidentally use hidpi scalling? Yeah, using 144dpi (1.5x scaling) sounds right for those dimensions and YaST should also fit. I tried that locally by setting Xft.dpi: 144 in a live CD and the installer looks and behaves as expected, also with disk and network configuration. With 1366px horizontal resolution YaST should not scale at all. Not only is it unlikely to have a HiDPI display with that resolution, even at only 1.5x scale there wouldn't be enough (logical) pixels. (Qt previously forced the scale to 1 at such resolutions). I don't think this is a HiDPI problem. If you look at the screenshot, it looks much more like a compositor problem: There are several levels of popups, and they all appear to be transparent; the popup window's background is never cleared before the content of the new one is drawn. I wouldn't be surprised to see that in the installed system (broken graphics driver? broken compositor? weird window manager?); but in the inst-sys it's very unusual. Created attachment 858824 [details]
Another set of logfiles
After failing the first tine, I think I now manahed to correctly write the logs to an usb stick. Maybe having a second logfile from a different machine will be helpful
Created attachment 858825 [details]
look of installer at 1366x768
Corresponding image for the uploaded second batch of logfiles. The installer o ly shows the "main window" of the installer at full screen. The progress side ar is completely omitted. Also has the issue of things rendering "atop each other" as shown in the original screenshot and some elemebts like network co figuratio. go beyond the actual screen area
> Stage [call]: Monitor width mm: 256
> Stage [call]: Monitor width px: 1366
> Stage [call]: Monitor dpi: 144
> Stage [call]: Xft.dpi set to: 144
That's definitely broken and a bug in YaST - scaling is only feasible with more pixels.
Knut: I see your PR that fixes dependencies of systemd is only for update channel and also sr is rejected https://github.com/yast/yast-installation/pull/1042 Maybe it deserve to be in GA? I can confirm this on the MicroOS installer (on the Snapshot released on 2022-05-16). I can confirm this too. Booting with QT_AUTO_SCREEN_SCALE_FACTOR=0 fixes the issue in part. It shows all ui elements and also stops merging of ui elements from different screens but text scaling is off. > Yeah, using 144dpi (1.5x scaling) sounds right for those dimensions and YaST > should also fit. ... > That's definitely broken and a bug in YaST - scaling is only feasible with more > pixels. You should try a career as layer... Anyway, we are talking about https://github.com/yast/yast-installation/pull/1019 here. To check if these xrdb calls are really the problem, please try this: - boot with startshell=1 - at the bash prompt, remove xrdb (rm /usr/bin/xrdb) - exit and continue the installation Does the issue disappear? ... as lawyer, obviously :-) > To check if these xrdb calls are really the problem, please try this:
>
> - boot with startshell=1
> - at the bash prompt, remove xrdb (rm /usr/bin/xrdb)
> - exit and continue the installation
>
> Does the issue disappear?
Yes, the issue does dissapear and the installer looks normal with all ui elements ok, including the text scale.
Thanks! Then we definitely need to rethink the logic in that patch mentioned in comment 16. (In reply to Steffen Winterfeldt from comment #19) > Thanks! > > Then we definitely need to rethink the logic in that patch mentioned > in comment 16. Just going based on my monitor, the DPI should be around 141 putting it under the threshhold for scaling. But line 82 in Yast2.call ends in a result of 144. This seems to be due to a division by 48, rounding followed by multiplication by 48 (($MON_WIDTH_PX/($MON_WIDTH_MM*0.0393701)/48).round)*48 In my case as an example: $MON_WIDTH_PX = 1920 $MON_WIDTH_MM = 344 ($MON_WIDTH_PX/($MON_WIDTH_MM*0.0393701) = 141.7673653 Should this be rounded and used as a value it would fall under the 144 cut-off point. Probably adding a $DPIR as $MON_WIDTH_PX/($MON_WIDTH_MM*0.0393701)).round and using that in the if statement at line 119 while still using $DPI for set_xft_dpi would correct the issue. I am not a developer so i might be totally wrong here, I'm just trying to help. As a first step, I've extended the boot options to allow 'faking' a monitor. With that I could reproduce the reported issues. https://github.com/openSUSE/linuxrc/pull/297 Added to YaST Kanban board. > I am not a developer so i might be totally wrong here, I'm just trying to help.
Thanks, that's appreciated. We can of course tweak the logic a bit to cover
one or two more cases but IMHO there's something wrong with our approach
in general.
I have been looking into this too and what i proposed before doesn't exactly work either. Since i don't have screens to test this on, i have been using sven.de/dpi/ for dpi estimates based on resolution and screen size. Just going based on the dpi of the screen doesn't seem to be the best solution. For example, a 1920x1080 screen at 15.6" will have the same calculated dpi as a 4k screen at 32". While the latter needs dpi scaling, the former does not. Since the function to evaluate the dpi already exports $MON_WIDTH_PX, that could probably be used in setting the dpi too. This could use some testing on actual displays but most likely any screen on 1080p or lower should not have any kind of dpi scaling, while higher resolution screens should have. 4k @ 50" (might not be a common screen for installation) at this time would have no scaling with the current evaluation though i would argue it needs it. (In reply to Sorin Fatu from comment #24) > a 1920x1080 screen at 15.6" will have the same > calculated dpi as a 4k screen at 32". Similar, yes, but not the same. 15.6 is 141.3. 32 is 137.7 (if 32 is in fact 32 and not 31.5). > While the latter needs dpi scaling, > the former does not. All else being equal, two different sized screens having the same density (DPI) will render objects at the exact same physical size regardless of the screen resolution that produced it. What matters in determining whether scaling is indicated is the relationship between density and viewing distance. Without knowing the viewing distance it can only be guessed whether scaling might be called for. Note that when the current problem with the installer is known, we have from linuxrc e.g. XVideo=1680x1050,108 that would scale up sizes on that 15.6" 1920x1080 laptop screen considerably, and e.g. XVideo=1920x1080,132 to do considerably more scaling on that 4+ times larger 32" 4k. *** Bug 1200302 has been marked as a duplicate of this bug. *** Another possible temporary fix is to use this: (Steffen Winterfeldt from comment #21) > As a first step, I've extended the boot options to allow 'faking' a monitor. > With that I could reproduce the reported issues. > > https://github.com/openSUSE/linuxrc/pull/297 To use it, edit the entry on the installation bootloader and add edid=XXXXxXXXX to the end of the line that starts with linux (after splash=silent) where XXXXxXXXX is your screen resolution. For example edid=1920x1080 If that doesn't work try to use a different dpi than the default (on my system it worked with dpi 119 or below) For example edid=1920x1080,119 (Tested on the latest MicroOS - 20220708) I just checked the installer again with the latest ISO and this issue seems to be fixed. Since I didn't see a change in the way the dpi is calculated, I suspect the bug did not come from there. The tool to set the DPI has been changed but the logic and the values are the same, with what i suspect are the same results. However at this point at least on my 1920x1080 display the installer looks fine. I dug a bit deeper in the logs and have found something of interest between my current logs and the ones provided by Johannes. We both have this in y2start.log : Stage [call]: Monitor size: eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm Stage [call]: Monitor width mm: 344 Stage [call]: Monitor width px: 1920 Stage [call]: Monitor dpi: 144 Stage [call]: Xft.dpi set to: 144 But if we take a look at y2log we see a wrong resolution being detected on the old log Johannes has this: 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQUI.cc(YQUI):107 This is libyui-qt 4.4.0 .. 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQUI.cc(processCommandLineArgs):251 Qt argument: --fullscreen 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQUI.cc(calcDefaultSize):370 -fullscreen: using 960 x 540for `opt(`defaultsize) 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQUI.cc(calcDefaultSize):404 Default size: 960 x 540 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQApplication.cc(pickAutoFonts):471 Selecting auto fonts - normal: 10, heading: 12 (bold) Mine from today: 2022-08-01 10:21:51 <1> install(4271) [qt-ui] YQUI.cc(YQUI):108 This is libyui-qt 4.4.1 .. 2022-08-01 10:21:52 <1> install(4271) [qt-ui] YQUI.cc(processCommandLineArgs):257 Qt argument: --fullscreen 2022-08-01 10:21:52 <1> install(4271) [qt-ui] YQUI.cc(calcDefaultSize):376 -fullscreen: using 1920 x 1080for `opt(`defaultsize) 2022-08-01 10:21:52 <1> install(4271) [qt-ui] YQUI.cc(calcDefaultSize):410 Default size: 1920 x 1080 2022-08-01 10:21:52 <1> install(4271) [qt-ui] YQApplication.cc(pickAutoFonts):471 Selecting auto fonts - normal: 18, heading: 24 (bold) I now suspect there must have been an issue in libyui-qt. I no longer have an older iso around to test this but either way, at least for my display this seems to be fixed. For reference: YQApplication::pickAutoFonts(): https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQApplication.cc#L420-L474 This is a very basic 'if' cascade to choose a font depending on the "default size", i.e. the standard size of a YaST main window. Notice that this is only a full-screen window up to a certain size. YQUI::calcDefaultSize(): https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQApplication.cc#L420-L474 This is where that "default size" is calculated, using the size of what Qt considers the "primary screen". In certain multi-monitor configurations it might make a difference if screens of different resolutions are used, or if the first one is turned to portrait orientation while the other(s) are in landscape orientation. Add to that the fact that Qt does some magic behind the scenes to shelter applications from gory details of HiDPI scenarios; if it detects HiDPI, it might choose to modify those values so it looks like a normal monitor to the application. (In reply to Stefan Hundhammer from comment #29) > YQUI::calcDefaultSize(): > > https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQApplication. > cc#L420-L474 Wrong link; correct one: https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L366-L413 But one way or the other, the main problem here is that the window background is not cleared before rendering new content. HiDPI and font sizes are only a secondary concern. There is a SLE-15 SP4 bug for this as well. See also bug #1191112 (SLE-15 SP4, not public). I am very sure that this is a duplicate of bug #1191112. The symptoms are the same: Window background not cleared before rendering new content. *** This bug has been marked as a duplicate of bug 1191112 *** You are not authorized to access bug #1191112. (In reply to Stefan Hundhammer from comment #31) > But one way or the other, the main problem here is that the window > background is not cleared before rendering new content. HiDPI and font sizes > are only a secondary concern. > > There is a SLE-15 SP4 bug for this as well. Wait, so this bug is specifically opened for the wrong resolution being used thus causing hidpi and fonts to be rendered incorrectly and now that's a secondary concern ? As already mentioned this bug seems to have fixed itself with the update from libyui-qt from 4.4.0 to 4.4.1 Side note, duplicate of a bug that we can't see ? What were the causes there ? What were the steps to reproduce, what was discussed? Oh well... Bug #1191112 is now public. I had a quick look at this and was able to reproduce it easily on the live cd by booting in runlevel 3 and running "QT_SCREEN_SCALE_FACTORS=Virtual-1=1.5 start-install.sh". Through ssh I could start gammaray and examine. The cause seems to be libyui-qt. With a scale factor of >=1.5, YaST decides to use a different "mode" for the installer and instead of showing the sidebar with steps in a YQWizard, in the broken case the content is directly part of YQDialog. YQDialog unlike YQWizard doesn't draw a background though. As YaST has multiple YQDialogs shown at the same time (libyui-qt just sets them to enabled = false, but not visible = false), all of them are drawn on top of each other without separation. This is perfectly reproducible unlike what's originally reported in bug 1191112, so I don't think this is a duplicate. (In reply to Fabian Vogt from comment #37) > I had a quick look at this and was able to reproduce it easily on the live > cd by booting in runlevel 3 and running > "QT_SCREEN_SCALE_FACTORS=Virtual-1=1.5 start-install.sh". Experimenting with that QT_SCREEN_SCALE_FACTORS is a good tip. Thank you for that. That scaling also works in the installed system in a virtual machine which makes everything a lot easier; for example using the UI demos from yast-ycp-ui-bindings/examples or from yast-widget-demo. Created attachment 861078 [details]
Screenshot: YaST partitioner
Screenshot the YaST partitioner in an up-to-date Tumbleweed in a VirtualBox VM with a 640x480 resolution, started with
QT_SCREEN_SCALE_FACTORS=2 sudo yast2 partitioner
The fonts are obviously way too large, but notice that new content from the partitioner main window is properly cleared, not overwritten by the pop-up that appears with "Edit Partition".
Created attachment 861080 [details]
Screenshot: YaST partitioner scaled to 1.7 in "Add Partition"
Similar screenshot, this time with scaling factor 1.7 and using the same "Add Partition" pop-up that shows the original problem from the "Picture of the Yast2 installer" attachment here.
Some widgets are cut off because they don't fit on the screen anymore; that is expected. But notice that here also no old content remains and is overwritten by the content of the pop-up.
(In reply to Stefan Hundhammer from comment #39) > The fonts are obviously way too large, but notice that new content from the > partitioner main window is properly cleared, not overwritten by the pop-up > that appears with "Edit Partition". (In reply to Stefan Hundhammer from comment #40) > Some widgets are cut off because they don't fit on the screen anymore; that > is expected. But notice that here also no old content remains and is > overwritten by the content of the pop-up. I suspect that only the actual installer is affected, as the difference appears to be whether it uses the wizard layout (with sidebar) or not. Created attachment 861170 [details]
Screenshot: YaST partitioner during installation overwriting content
Finally, I was able to reproduce this problem in a normal installation environment:
- Create a VirtualBox VM to run an installation in
- Boot with the current Leap 15.4 NET installation ISO
- Use boot parameter
QT_SCREEN_SCALE_FACTORS=2
(and possibly more like sshd=1 self_update=0)
Any parameter not known to linuxrc simply goes to the environment.
-> The Qt / X11 -based installation starts, of course with grossly oversized fonts.
Proceeding to the partitioning installation step, I chose the expert partitioner, clicked on a partition and then "Edit"; resulting in the attached screenshot where the old content is overwriting the main window content.
Notice that there is no wizard side-bar in the main window, no title bar, nothing like that.
Created attachment 861171 [details] Screenshot: Using style.qss Switching to the default widget theme "style.qss" with the Shift-F3 key combination fixed the problem. See also https://github.com/libyui/libyui/pull/64 Notice that as long as a popup is open, you can still use any "Cancel" button that is visible and clickable on the screen; they all send widget ID :cancel which behaves consistently. Switching to any other widget theme with Shift-F3 also results in a garbled screen. So the next thing to investigate is: Do we have a common bug in our installation .qss style sheets that sets transparency somewhere, even if not appropriate? Failing that, does the Qt stylesheet widget theme have a bug that causes the same effect? It's still possible that this is the same underlying problem as bug #1191112; but if that's the case, this bug here might become the main bug report for it. AFAICS if screen space is running out, the Wizard.rb Ruby part of our wizard decides to omit things like the side bar or the title bar, and the widget hierarchy looks a bit differently. That may (!) result in .qss widget specifications not being appropriate anymore, setting transparency in parts of the widget hierarchy that shouldn't be transparent. We'll need to investigate that. Screen space running out may be caused by actually having a very small screen resolution, or by fonts being way too large. Wrong EDID detection / HiDPI detection might be a cause for that; we'll need to investigate. Created attachment 861173 [details]
Screenshot: Widget tree in simplified wizard
(In reply to Stefan Hundhammer from comment #46) > AFAICS if screen space is running out, the Wizard.rb Ruby part of our wizard > decides to omit things like the side bar or the title bar, and the widget > hierarchy looks a bit differently. Yes, that's what I explained in comment #31. > That may (!) result in .qss widget specifications not being appropriate > anymore, setting transparency in parts of the widget hierarchy that > shouldn't be transparent. We'll need to investigate that. That sounds like a probable explanation. > Screen space running out may be caused by actually having a very small > screen resolution, or by fonts being way too large. Wrong EDID detection / > HiDPI detection might be a cause for that; we'll need to investigate. Yes, see comment #12. https://github.com/openSUSE/branding/blob/leap-15.4/yast/installation.qss#L6 /* Richtext: installation_richtext.css */ QMainWindow { background: #EEEEEE; } QFileDialog { background: #EEEEEE; } QDialog { background: #EEEEEE; } YQWizard { background: #EEEEEE; } YQDialog { background: #EEEEEE; color:#333; } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Removing that YQDialog line fixes the problem. I don't know why, and in particular, why that would make any difference; all that it does is to set the background and the foreground color. Just removing the "color:#333;" part does not make any difference. But any valid value for "background:" seems to trigger transparency for the complete dialog, resulting in the overwriting problem that we saw. AFAICS that line is present in all our openSUSE .qss style sheets (except style.qss, the default one), but NOT in the SLE .qss style sheets. BTW it's quite easy to experiment in the inst-sys environment started like in comment #42: Just copy the offending style sheet from to /tmp (the RAM disk) and bind-mount that individual file: cp /mounts/mp_0001/usr/share/YaST2/theme/current/wizard/installation.qss /tmp/installation.qss cp /mounts/mp_0001/usr/share/YaST2/theme/current/wizard/installation.qss /tmp/installation-old.qss (to have a backup because the original file will be shadowed in a moment) mount -o bind /tmp/installation.qss /mounts/mp_0001/usr/share/YaST2/theme/current/wizard/installation.qss vi /tmp/installation.qss And in the YaST main window use Shift-F3 to switch to another style sheet and back to reload it. Similar line in the SLE theme: https://github.com/yast/yast-theme/blob/master/theme/SLE/wizard/installation.qss#L685-L693 QLabel, YQDialog { color: #ffffff; background-color: #2b2e38; selection-background-color: #404147; selection-color: #ffffff; margin-top: 2px; margin-bottom: 6px; } Created attachment 861175 [details]
Screenshot: installation.qss from SLE also overwriting previous content
Copying installation.qss from SLE into the inst-sys shows the exact same problem.
Fix for the broken transparency / rendering: https://github.com/libyui/libyui/pull/81 Fabian, please have a look. Notice that this does not fix this bug completely; it's only about the first level, i.e. the broken rendering. The fonts being much too large is another problem. (In reply to Stefan Hundhammer from comment #49) > https://github.com/openSUSE/branding/blob/leap-15.4/yast/installation.qss#L6 > > /* Richtext: installation_richtext.css */ > QMainWindow { background: #EEEEEE; } > QFileDialog { background: #EEEEEE; } > QDialog { background: #EEEEEE; } > YQWizard { background: #EEEEEE; } > YQDialog { background: #EEEEEE; color:#333; } > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Removing that YQDialog line fixes the problem. I don't know why, and in > particular, why that would make any difference; all that it does is to set > the background and the foreground color. > > Just removing the "color:#333;" part does not make any difference. But any > valid value for "background:" seems to trigger transparency for the complete > dialog, resulting in the overwriting problem that we saw. > > AFAICS that line is present in all our openSUSE .qss style sheets (except > style.qss, the default one), but NOT in the SLE .qss style sheets. FWICT it's because YQDialog does: setAutoFillBackground( true ); the documentation about that property says: Warning: Use this property with caution in conjunction with Qt Style Sheets. When a widget has a style sheet with a valid background or a border-image, this property is automatically disabled. No idea why that is the case though. Setting the StyledBackground attribute to force background drawing works, but IMO fixing the widget stack by only having one of them visible is the better option. I'll review the PR. Now for the font sizes. Analyzing the first set of y2logs from comment #2 (jsudermann): Xorg.0.log: [ 82.995] (II) modeset(0): clock: 152.8 MHz Image Size: 344 x 193 mm [ 82.995] (II) modeset(0): h_active: 1920 h_sync: 2000 h_sync_end 2054 h_blank_end 2250 h_border: 0 [ 82.995] (II) modeset(0): v_active: 1080 v_sync: 1086 v_sync_end 1094 v_blanking: 1132 v_border: 0 y2start.log: Stage [call]: Monitor size: eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm Stage [call]: Monitor width mm: 344 Stage [call]: Monitor width px: 1920 Stage [call]: Monitor dpi: 144 Stage [call]: Xft.dpi set to: 144 y2log: 2022-04-29 14:43:46 <1> install(4700) [qt-ui] YQApplication.cc(pickAutoFonts):471 Selecting auto fonts - normal: 10, heading: 12 (bold) YQApplication.cc(currentFont):339 Loaded 10 pixel font: Sans Serif,-1,10,5,50,0,0,0,0,0 This sounds very reasonable so far. Except for this: YQUI.cc(calcDefaultSize):370 -fullscreen: using 960 x 540 for `opt(`defaultsize) YQUI.cc(calcDefaultSize):404 Default size: 960 x 540 ?!? Why does it use 960 x 540 for -fullscreen? https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L370 QSize availableSize = screen->availableSize(); So Qt thinks we are in HiDPI mode, scaling everything? It's using half the resolution values of 1920 x 1080 in both dimensions. And we also requested only a moderate font size: 10 px for normal text, 12 px for headings. Yet the screenshots show that those are massively scaled up; probably to 20 px for normal text (I can only guess). We are requesting automatic scaling during initialization of the Qt UI: https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L159 QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); according to https://doc-snapshots.qt.io/qt5-5.15/highdpi.html#high-dpi-support-in-qt "The Qt::AA_EnableHighDpiScaling application attribute, introduced in Qt 5.6, enables automatic scaling based on the monitor's pixel density." (In reply to Stefan Hundhammer from comment #55) > Now for the font sizes. > > Analyzing the first set of y2logs from comment #2 (jsudermann): > > > Xorg.0.log: > > [ 82.995] (II) modeset(0): clock: 152.8 MHz > Image Size: 344 x 193 mm > > [ 82.995] (II) modeset(0): h_active: 1920 h_sync: 2000 > h_sync_end 2054 h_blank_end 2250 h_border: 0 > > [ 82.995] (II) modeset(0): v_active: 1080 v_sync: 1086 > v_sync_end 1094 v_blanking: 1132 v_border: 0 > > > y2start.log: > > Stage [call]: Monitor size: eDP-1 connected primary 1920x1080+0+0 > (normal left inverted right x axis y axis) 344mm x 193mm > > Stage [call]: Monitor width mm: 344 > Stage [call]: Monitor width px: 1920 > Stage [call]: Monitor dpi: 144 > Stage [call]: Xft.dpi set to: 144 > > > y2log: > > > 2022-04-29 14:43:46 <1> install(4700) [qt-ui] > > YQApplication.cc(pickAutoFonts):471 Selecting auto fonts - > normal: 10, heading: 12 (bold) > > YQApplication.cc(currentFont):339 Loaded 10 pixel font: > Sans Serif,-1,10,5,50,0,0,0,0,0 > > > This sounds very reasonable so far. Except for this: > > > YQUI.cc(calcDefaultSize):370 -fullscreen: using 960 x 540 > for `opt(`defaultsize) > > YQUI.cc(calcDefaultSize):404 Default size: 960 x 540 > > > ?!? Why does it use 960 x 540 for -fullscreen? > > https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L370 > > QSize availableSize = screen->availableSize(); > > So Qt thinks we are in HiDPI mode, scaling everything? Yes, QScreen::availableSize returns "device-independent pixels", so physical pixels / scale factor. > It's using half the resolution values of 1920 x 1080 in both dimensions. Which sounds wrong. With 1080 horizontal pixels HiDPI scaling should not be enabled, or at most use 1.5x scaling. > And we also requested only a moderate font size: 10 px for normal text, 12 > px for headings. Yet the screenshots show that those are massively scaled > up; probably to 20 px for normal text (I can only guess). AFAICS our QSS style sheets use font sizes in point while the Qt UI uses sizes in pixels. I hope we don't have a clash here between fonts that are scaled when Qt uses auto-scaling vs. fonts that are NOT scaled. https://github.com/openSUSE/branding/blob/leap-15.4/yast/installation.qss#L10 font-size: 10.5pt My steadily growing collection of notes about this DPI and font size issue: https://gist.github.com/shundhammer/79d534b8452554b16fb2f667f58290f9 One noteworthy intermediate result is that Qt introduced a "rounding policy" for its scale factor with Qt 5.14 (i.e. not so long ago; right now we have 5.15 in TW), and it defaults to "Round", i.e. it will be rounded to the next integer number; so in practice, it's either 1.0 or 2.0, not 1.5 or similar which it might have used in the past; thus maybe the drastic increase of font sizes from a certain DPI value on. AFAICS we have two heuristics which are now (since the introduction of that scale factor rounding) defeating each other: - We calculate a DPI value from the physical screen dimensions in millimeters that "xrandr" reports and "clean it up", i.e. we make sure it's a number that can be divided by 48 (but no less than 96), i.e. one of 96, 144, 192, 240, 288 (but no more than that) and set the "Xft.dpi" X resource to that value. - Qt reads that X resource and stores the value as QXcbScreen::logicalDpi() - It uses that value and a default dpi value of 96 to calculate a scaling factor, e.g. 144 / 96 = 1.5 (which would be a reasonable factor) - It uses its new default rounding policy for that factor to round it to the next integer number; in this case 2. - It now uses that nicely rounded scaling factor for everything: Window size, widget sizes including borders and line widths; and fonts. As a result, the fonts are now insanely oversized; no longer 150% of what we previously used, but 200%. And since all other geometry values in our YaST Qt UI depend on the font sizes, everything becomes way too large: Static texts, buttons, list content, everything. So AFAICS while using a nice dpi value that can be divided by 48 probably prevents drawing artifacts for rendering fonts, at the same time scaling it up to 200% is way over the top. Desktop scaling factors e.g. in KDE Plasma use multiples of 25%, i.e. 100%, 125%, 150%, 200%; and that seems to work quite well. I don't see a reason why that shouldn't work for our YaST installer. So we should make Qt not enforce such rigid scaling factors and rather stick with what we tell it with the Xft.dpi X resource; that's already rounded well enough. I'll try different scale factor rounding policies; that seems to be the root of the problem here. First rough PR to fix the scaling / font size problem: https://github.com/yast/yast-installation/pull/1057 The pull request has now matured: https://github.com/yast/yast-installation/pull/1057 (contains screenshots and exhaustive documentation) This will arrive in Tumbleweed as yast2-installation-4.5.6. Created attachment 861473 [details]
Screenshot after the fix
Screenshot of the first installation dialog on a HiDPI laptop: A 4k 13" DELL XPS.
Relevant part of /var/log/YaST2/y2start.log:
Stage [call]: HiDPI Check...
Stage [call]: ==============
|-- Monitor size: eDP-1 connected primary 3840x2400+0+0
(normal left inverted right x axis y axis)
288mm x 180mm
|-- Monitor width px: 3840
|-- Monitor width mm: 288
|-- Monitor dpi: 336
|-- Reference DPI: 144
|-- QT_SCALE_FACTOR: 2.25
|-- QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough
Notice that you can now also set the monitor width in millimeters manually from the boot prompt of the installation ISO, e.g. YAST_MON_WIDTH_MM=260 This may be useful if the display does not report its physical size correctly with its EDID data. I hope this is now fixed to everybody's satisfaction. SR to OBS: https://build.opensuse.org/request/show/1003561 SR to IBS: https://build.suse.de/request/show/279929 Backport of the transparency problem to SLE-15 SP4 / Leap 15.4: https://github.com/libyui/libyui/pull/83 Maintenance team: This should become an installer self-update. (In reply to Stefan Hundhammer from comment #68) > Backport of the transparency problem to SLE-15 SP4 / Leap 15.4: > > https://github.com/libyui/libyui/pull/83 > > Maintenance team: This should become an installer self-update. Hello, could you confirm which packages are needed in the INSTALLER channels? Are those 2 needed: libyui16 libyui ? All libyui*16* packages. That's why we build them all together from one single Git repository; the idea is to prevent subtle problems. SUSE-RU-2023:2550-1: An update that has nine recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1191112, 1198097, 1199020, 1202234, 1209565, 1210591, 1211354, 1212187, 1212189 Sources used: openSUSE Leap Micro 5.3 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 openSUSE Leap 15.4 (src): libyui-ncurses-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-bindings-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1, yast2-pkg-bindings-devel-doc-4.4.6-150400.3.6.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1 openSUSE Leap 15.5 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise High Performance Computing 15 SP4 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Server 15 SP4 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Manager Server 4.3 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Desktop 15 SP4 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Manager Retail Branch Server 4.3 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Manager Proxy 4.3 (src): libyui-ncurses-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libyui-qt-pkg-4.3.7-150400.3.3.1, libyui-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise High Performance Computing 15 SP5 (src): libzypp-17.31.13-150400.3.32.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Server 15 SP5 (src): libzypp-17.31.13-150400.3.32.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Server for SAP Applications 15 SP5 (src): libzypp-17.31.13-150400.3.32.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Desktop 15 SP5 (src): libzypp-17.31.13-150400.3.32.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Micro 5.3 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 SUSE Linux Enterprise Micro 5.4 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 Basesystem Module 15-SP4 (src): libyui-ncurses-4.3.7-150400.3.3.1, zchunk-1.1.16-150400.3.4.1, libyui-qt-graph-4.3.7-150400.3.3.1, libyui-4.3.7-150400.3.3.1, libyui-ncurses-pkg-4.3.7-150400.3.3.1, libzypp-17.31.13-150400.3.32.1, autoyast2-4.4.45-150400.3.19.1, yast2-pkg-bindings-4.4.6-150400.3.6.1, libyui-qt-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 Basesystem Module 15-SP5 (src): libzypp-17.31.13-150400.3.32.1, zchunk-1.1.16-150400.3.4.1, libsolv-0.7.24-150400.3.8.1 Desktop Applications Module 15-SP4 (src): libyui-qt-pkg-4.3.7-150400.3.3.1 Development Tools Module 15-SP4 (src): libyui-rest-api-4.3.7-150400.3.3.1, libyui-ncurses-rest-api-4.3.7-150400.3.3.1, libyui-qt-rest-api-4.3.7-150400.3.3.1, libsolv-0.7.24-150400.3.8.1 Development Tools Module 15-SP5 (src): libsolv-0.7.24-150400.3.8.1 SUSE Package Hub 15 15-SP5 (src): zchunk-1.1.16-150400.3.4.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. |
Created attachment 858532 [details] Picture of the Yast2 installer After booting the medium and starting the Yast2 installer, the full interface is too large and texts, buttons and tables merge into each other. I have the problem both on a notebook (FHD 1920x1080) and on a normal monitor (FHD 1920x1080) connected to a PC. It has occurred since about the last two to three snapshot versions of Tumbleweed.