Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
6.5
-
None
Description
Add the following debug print to QWindow::create():
diff --git a/src/gui/kernel/qwindow.cpp b/src/gui/kernel/qwindow.cpp index 81a4469a9e..4d379bb135 100644 --- a/src/gui/kernel/qwindow.cpp +++ b/src/gui/kernel/qwindow.cpp @@ -514,6 +514,7 @@ void QWindowPrivate::create(bool recursive, WId nativeHandle) // QPlatformWindow will poll geometry() during construction below. Set the // screen here so that high-dpi scaling will use the correct scale factor. if (q->isTopLevel()) { + qDebug() << geometry; if (QScreen *screen = screenForGeometry(geometry)) setTopLevelScreen(screen, false); }
Running an application with xcb on Linux prints
QRect(0,0 0x0)
Same for eglfs. And there this is very fatal when multiple screens are involved since there can only be one QWindow per QScreen with that platform: QTBUG-113038.
Checking the center point of the empty rect always resets the window's screen to the screen at virtual position (0, 0). This is particularly bad with Qt Quick, where the Window item might have its 'screen' property set explicitly by the application, but then the value is lost and ignored once QWindow::create() runs.
On other platforms the behavior might be different. On Windows, there is apparently a valid geometry printed. However, even on platforms where the automatic screen assignment works, it is in practice incorrect: if the screen is explicitly set (e.g. on the Window item), Qt shouldn't second guess and override it.
One quick fix is to add a !geometry.isEmpty() check in the condition so at least the eglfs case gets unblocked.
Attachments
Issue Links
- relates to
-
QTBUG-113038 Output to two displays broken (when only screen is set on the window, without the correct virtual geometry)
- Closed