Bugzilla – Full Text Bug Listing
|Summary:||yast wrong geometry with one display in portrait mode|
|Product:||[openSUSE] openSUSE Distribution||Reporter:||Robert Simai <robert.simai>|
|Component:||YaST2||Assignee:||YaST Team <yast-internal>|
|Status:||CONFIRMED ---||QA Contact:||Jiri Srain <jsrain>|
|Priority:||P5 - None||CC:||jlopez, mrmazda|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
Description Robert Simai 2021-10-29 08:15:16 UTC
My setup consists of 3 regular HD monitors. First in portrait mode, second (main display, in the middle) and third in landscape mode. I'm running regular KDE. From xrandr: HDMI-1 connected 1080x1920+0+0 left (normal left inverted right x axis y axis) 509mm x 286mm DP-1 connected 1920x1080+1080+494 (normal left inverted right x axis y axis) 527mm x 296mm DP-2 connected 1920x1080+3000+494 (normal left inverted right x axis y axis) 527mm x 296mm I typically start applications from the middle display and I noticed that yast modules behave weird with their geometry, they seem to adapt to the portrait mode of the first display, regardless where they are started and displayed . Yast Control Center is correct but any module started from there is wrong. xwininfo tells me Corners: +1080+523 -3040+523 -3040-53 +1080-53 -geometry 800x1344+1080-53 You see 1344 is more than the available 1080. This requires to always correct the geometry to reach the buttons at the bottom, they are initially out of reach. Expected: the geometry should be taken from the active display, or at least must not exceed its resolution.
Comment 1 José Iván López González 2021-10-29 12:15:35 UTC
Hi Robert, I am not sure if YaST can decide about that. Let's ask to our expert. HuHa, any idea?
Comment 2 Felix Miata 2021-11-02 01:21:52 UTC
I don't seem to be able to reproduce this using either of the following layouts in 15.3: # inxi -Sy System: Host: gb250 Kernel: 5.3.18-59.27-default x86_64 bits: 64 Desktop: KDE Plasma 5.18.6 Distro: openSUSE Leap 15.3 # inxi -Gay Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: loaded: modesetting display-ID: :0 screens: 1 Screen-1: 0 s-res: 3640x2640 s-dpi: 120 s-size: 770x558mm (30.3x22.0") s-diag: 951mm (37.4") Monitor-1: HDMI-1 res: 1080x2560 hz: 60 Monitor-2: HDMI-2 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") Monitor-3: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27") OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 20.2.4 compat-v: 3.0 direct render: Yes # xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 3640 x 2640, maximum 16384 x 16384 HDMI-2 connected 1920x1200+1080+0 (normal left inverted right x axis y axis) 519mm x 324mm HDMI-1 connected 1080x2560+0+0 left (normal left inverted right x axis y axis) 673mm x 284mm DP-1 connected primary 2560x1440+1080+1200 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 2560x1080 60.00*+ 1920x1200 59.95*+ # # inxi -Gay Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: loaded: modesetting display-ID: :0 screens: 1 Screen-1: 0 s-res: 5560x2560 s-dpi: 120 s-size: 1176x541mm (46.3x21.3") s-diag: 1294mm (51") Monitor-1: HDMI-1 res: 1080x2560 hz: 60 Monitor-2: HDMI-2 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") Monitor-3: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27") OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 20.2.4 compat-v: 3.0 direct render: Yes # xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 5560 x 2560, maximum 16384 x 16384 HDMI-2 connected 1920x1200+3640+0 (normal left inverted right x axis y axis) 519mm x 324mm HDMI-1 connected 1080x2560+0+0 left (normal left inverted right x axis y axis) 673mm x 284mm DP-1 connected primary 2560x1440+1080+0 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 2560x1080 60.00*+ 1920x1200 59.95*+ #
Comment 3 Stefan Hundhammer 2021-11-02 10:40:52 UTC
Unlike the simple YaST Qt control center, the YaST Qt UI (libyui-qt) does not save its window size and position to a config file and restores it upon the next restart; rather, it has a quite elaborate algorithm to calculate the initial size of "default size" (wizard-style) windows: https://github.com/libyui/libyui/blob/master/libyui-qt/src/YQUI.cc#L360-L407 The starting point of this is whatever Qt considers the "primary screen": https://doc.qt.io/qt-5/qguiapplication.html#primaryScreen-prop So it will take the size of your primary screen, and since all of your screens are larger than 1024x786, it will use 70% of it for both dimensions. This usually works well. But if the dimensions or, as in your case, even the orientation of a multi-screen setup are radically different, problems like the one you described can occur: The initial calculation can be way off. The problem may be that Qt made a wrong decision what exactly is your primary screen. Maybe that can even be configured somewhere (in KDE? With xrandr?), but if yes, I don't know where. As a workaround (admittedly a kludge) I could offer using the -geometry command line option when starting a YaST module from the command line; like this: yast2 -geometry 1000x800 module_name or yast2 -geometry 1000x800+0+0 module_name
Comment 4 Stefan Hundhammer 2021-11-02 10:45:35 UTC
Of course, the solution that pops to everybody's mind would be to also save and restore the window position and dimensions when starting / terminating YaST, so it would be sufficient to fix them manually only once. If we should go that route, we'll have to make decisions such as storing them for all YaST modules or for each one separately (and that's not as easy as it sounds).
Comment 5 Stefan Hundhammer 2021-11-02 10:50:20 UTC
I am not sure if a generic method to avoid this situation wouldn't backfire for a number of other users. If we limit the size to the smaller screen, I could imagine users of embedded systems running into the opposite problem: If you have a very small display and a decent-sized one, would you really want to limit everything to the size of that small one, in many cases making YaST windows unusable? Before we start working on a dramatic change, please check if you can configure what Qt considers its "primary screen". It might be a setting in your KDE desktop somewhere.
Comment 6 José Iván López González 2021-11-02 11:13:23 UTC
We will take a deeper look. Adding to trello. Thanks!
Comment 7 Robert Simai 2021-11-02 12:19:01 UTC
(In reply to Stefan Hundhammer from comment #3) > The problem may be that Qt made a wrong decision what exactly is your > primary screen. Maybe that can even be configured somewhere (in KDE? With > xrandr?), but if yes, I don't know where. Many thanks for your explanations, this was helpful and I found the setting: "kcmshell5 kcm_kscreen" allows to set one of the devices to "primary" which works around this problem as then its geometry is used. I have no idea where this is stored. But: the modules always comes up on the same screen as the Control Center and this is what they should use. The downside pinning the geometry to the landscape mode display is, now the modules have "wrong" geometry when started from the portrait mode display, geometry then is 1344x756 on 1080x1920. The underlying issue appears to be that Qt can not deal with multiple displays at different geometries and expects them to be all the same. Not sure if you can fix that but thanks for looking into it, and good luck!
Comment 8 Stefan Hundhammer 2021-11-03 10:11:40 UTC
Robert, I understand you, and in a use case such as yours it's not optimal; fully agreed. But I fear when we start tinkering in this area, for every user we make happy (or let's say a little bit happier), there will be 5-10 that will become unhappy instead with a changed behaviour. We have to cover a lot of use cases. A very common one used to be laptop users who connect an external monitor; some of them won't use the laptop display at all when the external monitor is connected, some may use it, if only as a secondary display for their IRC client or some similar secondary task. If the laptop display has significantly less resolution, the user will probably want to disregard it for this initial size calculation. Similar with smallish displays for embedded devices (RasPI etc.) that also have an external monitor. So it's not easy at all what to consider for those initial dimensions; we can't simply iterate over all screens and limit our size to the smallest one (in both dimensions, of course). We have to choose carefully which ones should influence that decision and which ones should be disregarded. Your use case is extreme; we could at least try to limit the size to a normal aspect ratio: 9:16 (i.e. 16:9 in portrait orientation) with really large resolution is not useful for any YaST module. And then there are our friends, the HiDPI monitor users, who introduce yet another completely different aspect into this equation: They do use insane resolutions, and they need them to make fonts and icons big enough so they can read anything and recognize the icons. It's difficult; we are trying a one-size-fits-all approach here, and that's not so easy if you have to consider dwarves as well as giants as well as normal people. Or, as in your case, a Siamese twin consisting of a giant and a dwarf at the same time. ;-)
Comment 9 Stefan Hundhammer 2021-11-03 10:33:00 UTC
As for using the same screen as the control center: This is beyond our control (pun intended). The control center is a completely independent standalone application; there is no connection between it and and YaST module that it starts. Worse, what screen a new window is displayed on is completely at the mercy of the window manager; and window managers may use different strategies where to place a new window. That strategy may even be user-configurable. And here we also have a chicken-egg problem: The YaST module (or, more precisely, the application using libyui-qt) needs to know the screen dimensions to request its initial size (which incidentially is just a window manager *hint*, i.e. a most humble request) before the window is created; yet the window manager may easily base its decision which screen to use on that size. That's easy if in a multi-screen setup all screens have the same size; but if they are radically different, it's not. Maybe we can add an environment variable like $Y2_GEOMETRY that users with such an unusual setup could use. Probably we should limit the default height to a reasonable aspect ratio; 9:16 is clearly beyond that, but e.g. 4:3 (the classical 1024x768 etc.) or 5:4 (1280x1024) should still work. Maybe limit it to 1:1. That would already help in your case; in others it may not.
Comment 10 Robert Simai 2021-11-03 12:30:44 UTC
Once more many thanks for all the background, I understand there's no easy solution and I at least know how to work around for my setup. One correction however, in my case it's not Siamese twins but triplets ;-)