Inter-client surface embedding
mark-wayland-devel at efaref.net
Tue Feb 18 14:28:06 PST 2014
On Tue, 18 Feb 2014, Bill Spitzak wrote:
> On 02/18/2014 11:09 AM, Mark Thomas wrote:
>> 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.
I've essentially done that, although the uid is more of a nonce. Even a
random number can be guessed or snooped.
> Otherwise you are going to have to create a "hole" and
> "plug" object for every single Wayland object.
Only the ones you want to embed. It's a rare occurrence. Plus creating
objects is easy because the wayland protocol is very lightweight.
>> 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.
I suggest you read up on the subsurface protocol. A "subsurface" object
takes two "surface" arguments, one is the parent to attach to, and the
other is the child surface that becomes the subsurface.
>> 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.
I think things like firefox are potentially better served by passing
through the buffers from the plugin, rather than the plugin connecting to
wayland itself -- a parent-child relationship rather than a sibling one.
That way it gets to do things to the buffer synchronously as it passes
through (like crop or scale it)*. I think this is what is meant by the
It sounds like it could work, though I expect there would be lots of edge
cases to work through.
Until someone actually tries it, though, this is all just hot air.
* - I had an idea for smooth, synchronized resizing and scrolling, where
the outer client requests the inner client provide it a buffer with an
extra amount of rendered data around the outside of the subwindow that it
is providing. The outer window crops this buffer to the correct
dimensions (by asking the compositor to do so) and also draws the border
of the subwindow and its scroll bars. Then the outer client can scroll
and resize synchronously by repainting the existing buffer it has with a
differenct crop region, whilst asynchronously requesting a new buffer from
the inner client with the new geometry. I think this would work pretty
well for the "document viewer" class of use case. Just an idea, though.
I don't plan to do anything with it.
More information about the wayland-devel