Inter-client surface embedding
spitzak at gmail.com
Tue Feb 18 11:22:39 PST 2014
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.
More information about the wayland-devel