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

[Pekka Paalanen]

On Fri, 8 Mar 2024 14:50:30 +0000
Terry Barnaby <terry1 at beam.ltd.uk> wrote:

> On 05/03/2024 12:26, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 17:59:25 +0000
> > Terry Barnaby <terry1 at beam.ltd.uk> wrote:
> >  

...

> >> I would have thought it better/more useful to have a Wayland API call
> >> like "stopCommiting" so that an application can sort things out for this
> >> and other things, providing more application control. But I really have
> >> only very limited knowledge of the Wayland system. I just keep hitting
> >> its restrictions.
> >>  
> > Right, Wayland does not work that way. Wayland sees any client as a
> > single entity, regardless of its internal composition of libraries and
> > others.
> >
> > When Wayland delivers any event, whether it is an explicit resize event
> > or an input event (or maybe the client just spontaneously decides to),
> > that causes the client to want to resize a window, it is then up to the
> > client itself to make sure it resizes everything it needs to, and keeps
> > everything atomic so that the end user does not see glitches on screen.
> >
> > Sub-surfaces' synchronous mode was needed to let clients batch the
> > updates of multiple surfaces into a single atomic commit. It is the
> > desync mode that was a non-mandatory add-on. The synchronous mode was
> > needed, because there was no other way to batch multiple
> > wl_surface.commit requests to apply simultaneously guaranteed. Without
> > it, if you commit surface A and then surface B, nothing will guarantee
> > that the compositor would not show A updated and B not on screen for a
> > moment.
> >
> > Wayland intentionally did not include any mechanism in its design
> > intended for communication between a single client's internal
> > components. Why use a display server as an IPC middle-man for something
> > that should be process-internal communication. After all, Wayland is
> > primarily a protocol - inter-process communication.  
> 
> Well as you say it is up to the client to perform all of the surface 
> resize work. So it seems to me, if the client had an issue with pixel 
> perfect resizing it could always set any of its desynced surfaces to 
> sync mode, or just stop the update to them, while it resizes. I don't 
> see why Wayland needs to ignore the clients request to set a subsurface 
> desynced down the tree.

You're right, but it's in the spec now. I've gained a bit more
experience in the decade after writing the sub-surface spec.

You can still work around it by setting all sub-surfaces always desync.

> In fact does it return an error to the client 
> when the Wayland server ignores this command ?

There is no "return error" in Wayland. Either a request succeeds, or
the client is disconnected with an error. It's all asynchronous, too.

Any possibility for graceful failure must be designed into protocol
extensions at one step higher level. If there is room for a graceful
failure, it will be mentioned in the XML spec with explicit messages to
communicate it.

Which command do you mean?

There is no "ignore" with wl_surface nor wl_subsurface.
wl_surface.commit is always acted upon, but the sub-surface sync mode
determines whether the state update goes to the screen or to a cache.
No state update is ignored unless you destroy your objects. The frame
callbacks that seem to go unanswered are not ignored, they are just
sitting in the cache waiting to apply when the parent surface actually
updates on screen.


Thanks,
pq
-------------- 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/20240308/b2359474/attachment-0001.sig>