33d74f3f58
The legacy infrastructure does not map very well to the modern one: it turns out that, somewhat counterintuitively, targeting a QRhiSwapChain for a QWindow may still mean rendering into a texture, when using OpenGL on certain platforms. For example, the Wayland platform plugin implements client-side decorations by binding an FBO upon making a context current on a surface for a (decorated) window, and it also makes defaultFramebufferObject() on the context return the FBO id. The expectation is that this is why errors such as GL_INVALID_OPERATION are encountered in glDrawBuffers on Linux. The QRhi GL backend's assumption that the QRhiRenderTarget being a QRhiResource::SwapChainRenderTarget implies that the target really is the color buffer(s) of a window surface is not in practice sufficient on these platforms. The bound FBO was already correct always (whatever defaultFbo reports), but the code path hit was the wrong one. And there is different code for MRT support (textures only) and stereo rendering (window surface only). Make sure defaultFbo() is queried before taking the decision which path to hit. Pick-to: 6.8 Fixes: QTBUG-122819 Fixes: QTBUG-132780 Change-Id: Iaaab57b031f430178ee4611a4f7a02c854010441 Reviewed-by: Andy Nichols <andy.nichols@qt.io> (cherry picked from commit 3869106cc5914fb4a8eda30ae1bd5f68dcee2fda) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>