Details
-
Bug
-
Resolution: Invalid
-
P1: Critical
-
None
-
6.5.0, 6.5.1
-
None
Description
We are developing a video processing system that runs on an NXP imx8 processor using a Yocto embedded Linux system that has Qt6, GStreamer, Wayland and Weston.
We are having a problem displaying the video stream from GStreamer on a QWidget. In the past we had this working with Qt5 and older GStreamer, Wayland and Weston.
A simple test program also shows the issue on Fedora37 with QT6 and KDE/Plasma/Wayland.
The technique we are using is to get the Wayland surface from the QWidget is using (It has been configured to use a Qt::WA_NativeWindow) and pass this to the GStreamer's waylandsink which should then update this surface with video frames (via hardware). This works when the QWidget is a top level Window widget (QWidget(0)), but if this QWidget is below others in the hierarchy no video is seen and the gstreamer pipeline line is stalled.
With some investigation with a Weston server running under Fedora37 Plasma/X11 I find that although Qt creates an application top Wayland surface for the firs/top QWidget(0) and a second surface for the sub QWidget(parent) the second surface is not "mapped" in the Weston server.
It also appears, while looking at the Wayland protocol stream, That if you use QPainter to draw into the sub QWidget the Wayland draw requests are to the tope most surface rather that the QWidgets surface.
So it looks like the Qt::WA_NativeWindow is only partially functional ?
There is a wayland-devel@lists.freedesktop.org mail list thread "Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston" with more info and a test case.