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 surfaceI 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 clients.
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.
-- Mark.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
