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