Hi, On Fri, Feb 23, 2024 at 06:14:11AM +0000, Terry Barnaby wrote: > I have tried using "weston-debug scene-graph" and I am coming to the > conclusion that qtwayland 6.5.0 is not really using native Wayland surfaces > when Qt::WA_NativeWindow is used. From what I can see (and I could easily be > wrong) the Wayland protocol shows wl_surfaces being created and two > QWidget's QPlatformNativeInterface nativeResourceForWindow("surface", > windowHandle()) function does return different wl_surface pointers but even > at the QWidget level (ignoring gstreamer), a QPainter paint into each of > these QWidgets actually uses Wayland to draw into just the one top level > surface and "weston-debug scene-graph" shows only one application > xdg_toplevel surface and no subsurfaces. I don't know how to determine the > Wayland surface ID from a wl_surface pointer unfortunately to really check > this. I suppose this is to expected given that you don't actually see the video. > > If my Video QWidget(0) is a top level QWidget, then video is shown and > "weston-debug scene-graph" shows the application xdg_toplevel and two > wl_subsurfaces as children. > > Unfortunately I think "weston-debug scene-graph" only shows surfaces that > are actually "active" so I can't see all of the surfaces that Weston > actually knows about (is there a method of doing this ?). Mapped or not, Weston will print out views associated with a surface, if those views are part of a layer. I don't know what active means in this case, but you won't be activating wl_surfaces but rather the top-level xdg-shell window. Depending on the Weston version it would explicit say that or not (surface/view being not mapped). > > My feeling is that although Qtwayland is creating native surfaces, it > actually only uses the one top level one and presumably doesn't "activate" > (set a role, do something ?) with the other surfaces. WAYLAND_DEBUG=1 could tell if it creates or not subsurfaces underneath. > > Does anyone know a good list/place where I can ask such detailed qtwayland > questions ? https://bugreports.qt.io/projects/QTBUG/issues/QTBUG-122683?filter=allopenissues > > I guess I can work around this by manually creating a Wayland subsurface > from the Qt top level surface and handing that to waylandsink and then > manage this subsurface, like hiding, showing and resizing, when the QWidget > is hidden/shown/resized. > > Or could there be a way of "activating" the child QWidget's Wayland surface > ? > > > > On 22/02/2024 18:44, Terry Barnaby wrote: > > Hi Marius, > > > > Many thanks for the info. > > > > Some notes/questions below: > > > > Terry > > On 22/02/2024 17:49, Marius Vlad wrote: > > > Hi, > > > On Thu, Feb 22, 2024 at 03:21:01PM +0000, Terry Barnaby wrote: > > > > Hi, > > > > > > > > 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. > > > I'm tempted to say if this happens on a desktop with the same Qt > > > version and > > > other compositors to be an issue with Qt rather than waylandsink or > > > the compositor. Note that on NXP they have their own modified Weston > > > version. > > > > That is my current feeling and is one reason why I tried it on Fedora > > with whatever Wayland compositor KDE/Plasma is using. > > > > > > > > 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. > > > So the assumption is that aren't there other widgets which obscures this > > > one, when you move it below others? > > > > My simple test example has two QWidgets with the one for video being > > created as a child of the first so it should be above all others. I have > > even tried drawing in it to make sure and it displays its Qt drawn > > contents fine, just not the video stream. > > > > > > > > It appears that waylandsink does: > > > > > > > > Creates a surface callback: > > > > > > > > callback = wl_surface_frame (surface); > > > > > > > > wl_callback_add_listener (callback, &frame_callback_listener, self); > > > > > > > > Then adds a buffer to a surface: > > > > > > > > gst_wl_buffer_attach (buffer, priv->video_surface_wrapper); > > > > wl_surface_set_buffer_scale (priv->video_surface_wrapper, > > > > priv->scale); > > > > wl_surface_damage_buffer (priv->video_surface_wrapper, 0, > > > > 0, G_MAXINT32, > > > > G_MAXINT32); > > > > wl_surface_commit (priv->video_surface_wrapper); > > > > > > > > But never gets a callback and just sits in a loop awaiting that > > > > callback. > > > > > > > > I assume that the surface waylandsink is using, which is created > > > > using the > > > > original QWidget surface (sub-surface ? with window ?) is not > > > > "active" for > > > > some reason. > > > Possibly when QWidget is below in hierarcy to be a child of of a parent, > > > as described in > > > https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_parent, > > > so I assume to have a different surface than the parent one. This would > > > be easy to determine with WAYLAND_DEBUG. Seems unlikely to a itself a > > > sub-surface of a surface. > > > > I haven't really got the gist of whats going on, but waylandsink > > certainly creates a subsurface from the QWidget surface, in fact it > > seems to create a few things. > > > > I assume a subsurface is used so the video can be displayed in that > > subsurface separately from the parent (de synced from it). > > > > > > > > > > > > I am trying to debug this, but this graphics stack is quite > > > > complicated with > > > > waylandsink, qtwayland, wayland-lib and Weston not to mention the NXP > > > > hardware levels. My thoughts are that it is something qtwayland > > > > is doing > > > > with the surface stack or thread locking issues (gstreamer uses > > > > separate > > > > threads). I also don't understand Wayland or Weston in detail. So some > > > > questions: > > > > > > > > 1. Anyone seen something like this ? > > > Someone else reported something similar but that by causing damage, > > > or moving pointer to make the video sub-surface to show up: > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/843. > > > > Thanks, I will have a look. Moving the mouse cursor in my case (at least > > with Weston) does not affect things. > > > > > > > > 2. Anyone any idea one where to look ? > > > > > > > > 3. Given the wl_surface in the Qt app or in waylandsink is there > > > > a way I can > > > > print out its state and the surface hierarchy easily ? > > > In Weston there's something called scene-graph. You can grab it by > > > starting Weston with with the --debug argument, then you can print > > > with `weston-debug scene-graph` command. A more recent Weston version > > > would indent sub-surfaces by their (main) surface parent. > > > > Thanks, that could be useful. > > > > > > > > 4. Any idea on any debug methods to use ? > > > WAYLAND_DEBUG=1 as env variable. > > > > Any idea on how to get a surfaces ID from a C pointer so I can match up > > the QtWidget/waylandsink surface with the Wayland debug output ? > > > > > > > > Cheers > > > > > > > > Terry > > > > > > > > >
signature.asc
Description: PGP signature