Inter-client surface embedding
mark-wayland-devel at efaref.net
Tue Feb 18 11:09:45 PST 2014
On Mon, 17 Feb 2014, Bill Spitzak wrote:
> Mark Thomas wrote:
>> I've pushed some doc updates to the protocol.xml file my git repo. But
>> in terms of Jonas Ådahl's proposal, my protocol works the other way round:
>> A creates a main surface
>> A creates a "hole" on that surface and sets its position and size
>> A gets the uid (handle) from the server
>> A passes that uid to B via IPC
>> B creates a surface
>> B creates a "plug" on that surface with the uid it got from A
>> B receives a configure event from the server with the size of the hole
>> B creates a buffer of the correct size and renders its image to the
> I do believe users are looking for something more like this than for
> implementing a subcompositor. Subcompositor really worries me as it relies on
> the buffers being passed through the intermediate client as fast as possible
> (ie without copying), and information that clients use to figure out how to
> allocate their buffers being passed the opposite direction. I can't believe
> every client is going to get this right, and would seem to make it impossible
> for a sub-client to take advantage of any new wayland api until the parent
> client is updated.
Subcompositor worries me too, particularly for something like a panel,
which does very little, really. We have one compositor already so it
seems strange for it to abdicate responsibility for compositing just
because the parts of the image come from two different clients - surely
the whole point of the compositor is to composite bits from different
I understand there is the issue synchronization when interactively
resizing, but even that isn't completely solved with a subcompositor, as
what should it do if the nested client isn't responsive?
For my purposes I don't plan to resolve this. I'm going to make a
mate-panel-specific pair of interfaces that are used by mate-panel and
libmatepanelapplet respectively, and not worry about the interactive
resize issue because you can't interactively resize panels.
> I think the above description can be greatly simplified by removing the
> "hole" and "plug" objects and just using a subsurface:
> A creates a main surface
> A creates a subsurface for the "hole"
> A gets the uid of the subsurface from the compositor
> A passes that uid to B via IPC
> B uses this uid to get access to the subsurface
> B can now attach buffers and do other actions to the subsurface
The "hole" and "plug" are meaningful objects and are needed, at least
server-side, for some associated state. They're also helpful for limiting
the amount of uid-dipping a client can do, as only holes and plugs have
uids. Also you can't create a subsurface without both surfaces available,
so there is a chicken-and-egg issue, too.
> I proposed this before but I think I am failing to communicate what I wanted.
> The term "uid" seems pretty good and maybe makes it clearer. It's purpose is
> so B can't just guess at objects and get access to them, and to be a simple
> piece of data (probably a big number) that can be passed through IPC, in
> particular as part of the argv sent to exec the child.
Having thought about it, I think I'm in agreement with Pekka and the
others that a generic interface is probably not appropriate, as the
requirements change depending on the use case. What's probably more
useful is making it easy for shell plugins to do it the way they want.
So that's my plan.
> As far as I can tell Wayland will have no difficulties with two clients both
> owning a subsurface and trying to update it, as it will serialize all the
> requests and perform them in whatever order they appear. Either client can
> destroy the surface and the other will cleanly hear about it.
I don't think that's true, at least for weston. That may just be an
implementation detail, though.
More information about the wayland-devel