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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
