Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston

[Pekka Paalanen]

On Mon, 4 Mar 2024 08:12:10 +0000
Terry Barnaby <terry1 at beam.ltd.uk> wrote:

> While I am trying to investigate my issue in the QtWayland arena via the 
> Qt Jira Bug system, I thought I would try taking Qt out of the equation 
> to simplify the application a bit more to try and gain some 
> understanding of what is going on and how this should all work.
> 
> So I have created a pure GStreamer/Wayland/Weston application to test 
> out how this should work. This is at: 
> https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz
> 
> This tries to implement a C++ Widget style application using native 
> Wayland. It is rough and could easily be doing things wrong wrt Wayland. 
> However it does work to a reasonable degree.
> 
> However, I appear to see the same sort of issue I see with my Qt based 
> system in that when a subsurface of a subsurface is used, the Gstreamer 
> video is not seen.
> 
> This example normally (UseWidgetTop=0) has a top level xdg_toplevel 
> desktop surface (Gui), a subsurface to that (Video) and then waylandsink 
> creates a subsurface to that which it sets to de-sync mode.
> 
> When this example is run with UseWidgetTop=0 the video frames from 
> gstreamer are only shown shown when the top subsurface is manually 
> committed with gvideo->update() every second, otherwise the video 
> pipeline is stalled.

This is intentional. From wl_subsurface specification:

      Even if a sub-surface is in desynchronized mode, it will behave as
      in synchronized mode, if its parent surface behaves as in
      synchronized mode. This rule is applied recursively throughout the
      tree of surfaces. This means, that one can set a sub-surface into
      synchronized mode, and then assume that all its child and grand-child
      sub-surfaces are synchronized, too, without explicitly setting them.

This is derived from the design decision that a wl_surface and its
immediate sub-surfaces form a seamlessly integrated unit that works
like a single wl_surface without sub-surfaces would. wl_subsurface
state is state in the sub-surface's parent, so that the parent controls
everything as if there was just a single wl_surface. If the parent sets
its sub-surface as desynchronized, it explicitly gives the sub-surface
the permission to update on screen regardless of the parent's updates.
When the sub-surface is in synchronized mode, the parent surface wants
to be updated in sync with the sub-surface in an atomic fashion.

When your surface stack looks like:

- main surface A, top-level, root surface (implicitly desynchronized)
  - sub-surface B, synchronized
    - sub-surface C, desynchronized

Updates to surface C are immediately made part of surface B, because
surface C is in desynchronized mode. If B was the root surface, all C
updates would simply go through.

However, surface B is a part of surface A, and surface B is in
synchronized mode. This means that the client wants surface A updates to
be explicit and atomic. Nothing must change on screen until A is
explicitly committed itself. So any update to surface B requires a
commit on surface A to become visible. Surface C does not get to
override the atomicity requirement of surface A updates.

This has been designed so that software component A can control surface
A, and delegate a part of surface A to component B which happens to the
using a sub-surface: surface B. If surface B parts are further
delegated to another component C, then component A can still be sure
that nothing updates on surface A until it says so. Component A sets
surface B to synchronized to ensure that.

That's the rationale behind the Wayland design.


Thanks,
pq

> Waylandsink is stuck in a loop awaiting a Wayland 
> callback after committing its subsurface.
> If the Video Widget is a top level widget (UseWidgetTop=1) this works 
> fine (only one subsurface deep ?).
> 
> I have tried using both Gstreamer's waylandsink and glimagesink 
> elements, both show the same issue.
> 
> This seems to suggest that the de-synced subsurface system is not 
> working properly with Weston, I miss-understand how this should work or 
> I have a program error.
> This has been tested on Fedora37 running Weston 10.0.1 under KDE/Plasma/X11.
> 
> 1. Should de-synced subsurfaces under other subsurfaces work under 
> Weston 10.0.1 ?
> 
> 2. Do I miss-understand how this should work ?
> 
> 3. Do I have some coding issue (sorry the code is a bit complex with 
> Wayland callbacks and C++ timers etc) ?
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240304/068b5279/attachment.sig>