[Bug 1192148] New: yast wrong geometry with one display in portrait mode
https://bugzilla.suse.com/show_bug.cgi?id=1192148 Bug ID: 1192148 Summary: yast wrong geometry with one display in portrait mode Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers@suse.de Reporter: robert.simai@suse.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c1 Jos� Iv�n L�pez Gonz�lez <jlopez@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlopez@suse.com Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #1 from Jos� Iv�n L�pez Gonz�lez <jlopez@suse.com> --- Hi Robert, I am not sure if YaST can decide about that. Let's ask to our expert. HuHa, any idea? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c3 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #3 from Stefan Hundhammer <shundhammer@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c4 --- Comment #4 from Stefan Hundhammer <shundhammer@suse.com> --- 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). -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c5 --- Comment #5 from Stefan Hundhammer <shundhammer@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c6 --- Comment #6 from Jos� Iv�n L�pez Gonz�lez <jlopez@suse.com> --- We will take a deeper look. Adding to trello. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 Jos� Iv�n L�pez Gonz�lez <jlopez@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED URL| |https://trello.com/c/n0tcEE | |LH Assignee|yast2-maintainers@suse.de |yast-internal@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c7 --- Comment #7 from Robert Simai <robert.simai@suse.com> --- (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! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c8 --- Comment #8 from Stefan Hundhammer <shundhammer@suse.com> --- 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. ;-) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c9 --- Comment #9 from Stefan Hundhammer <shundhammer@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1192148 https://bugzilla.suse.com/show_bug.cgi?id=1192148#c10 --- Comment #10 from Robert Simai <robert.simai@suse.com> --- 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 ;-) -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com