Inter-client surface embedding

[Bill Spitzak]

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.

> 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.