Inter-client surface embedding

Jasper St. Pierre jstpierre at
Tue Feb 18 15:09:59 PST 2014

On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak <spitzak at> wrote:

> On 02/18/2014 11:09 AM, Mark Thomas wrote:
>  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.
> I proposed that the "uid" be an encrypted number so clients can't guess
> them (or "dipping" as you call it). Basically if the server is asked for
> the object for a given uid it fails if it is not a number recently
> delivered by it to another client. Otherwise you are going to have to
> create a "hole" and "plug" object for every single Wayland object.

I have no idea what an "encrypted number" is.

> Also you can't create a subsurface without both
>> surfaces available, so there is a chicken-and-egg issue, too.
> I don't understand this. Obviously when the subsurface is created there is
> only one surface available (the parent) because the subsurface is not
> created yet. That is why I have A create the subsurface. B is still in
> charge of the buffers so there seems to be no problem here.
>  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.
> I don't like the idea that we are saying that things like Firefox have to
> be shell plugins.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list