Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
Terry Barnaby
terry1 at beam.ltd.uk
Fri Feb 23 09:29:11 UTC 2024
Hi David,
Many thanks for the reply and the info on how to get the ID.
I have added a basic example with some debug output at:
https://portal.beam.ltd.uk/public//test016-qt6-video-example.tar.gz
If there are any ideas of things I could look at/investigate I am all ears!
In a previous email I stated:
> 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.
>
> 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 ?).
>
> 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.
>
> Does anyone know a good list/place where I can ask such detailed
> qtwayland questions ?
>
> 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 ?
Terry
On 23/02/2024 08:35, David Edmundson wrote:
> On Fri, Feb 23, 2024 at 6:15 AM Terry Barnaby <terry1 at beam.ltd.uk> wrote:
>> I don't know how to determine the Wayland surface ID from a
>> wl_surface pointer unfortunately to really check this.
> wl_proxy_get_id(static_cast<wl_proxy*>(myWlSurface));
>
>
>>>> Possibly when QWidget is below in hierarcy to be a child of of a parent,
>>>> as described in
> That's fine.
>
> A QWidget with WA_NativeWindow will create a QWindow with a parent. A
> QWindow with a parent will create a subsurface in wayland terms.
> But it is a subsurface where Qt is managing it and you're also
> committing on it, which can be a bit confusing and going through
> widgets to create a subsurface isn't really needed.
> There's a bunch of other options there.
>
>
> ---
>
> Can you link your test app. You can send me a private email and I'll
> take a look. It doesn't seem like a core wayland problem more a
> Qt/application setup issue so far. Then we can follow it up on Qt's
> Jira if there is a Qt issue.
>
> David Edmundson - QtWayland Maintainer
More information about the wayland-devel
mailing list