<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 02/18/2014 11:09 AM, Mark Thomas wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the above description can be greatly simplified by removing<br>
the "hole" and "plug" objects and just using a subsurface:<br>
<br>
 A creates a main surface<br>
 A creates a subsurface for the "hole"<br>
 A gets the uid of the subsurface from the compositor<br>
 A passes that uid to B via IPC<br>
 B uses this uid to get access to the subsurface<br>
 B can now attach buffers and do other actions to the subsurface<br>
</blockquote>
<br>
The "hole" and "plug" are meaningful objects and are needed, at least<br>
server-side, for some associated state.  They're also helpful for<br>
limiting the amount of uid-dipping a client can do, as only holes and<br>
plugs have uids.<br>
</blockquote>
<br></div>
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.<br>

</blockquote><div><br></div><div>I have no idea what an "encrypted number" is.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also you can't create a subsurface without both<br>
surfaces available, so there is a chicken-and-egg issue, too.<br>
</blockquote>
<br></div>
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.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having thought about it, I think I'm in agreement with Pekka and the<br>
others that a generic interface is probably not appropriate, as the<br>
requirements change depending on the use case.  What's probably more<br>
useful is making it easy for shell plugins to do it the way they want.<br>
So that's my plan.<br>
</blockquote>
<br></div>
I don't like the idea that we are saying that things like Firefox have to be shell plugins.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>