On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak <spit...@gmail.com> wrote:
> 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. > I have no idea what an "encrypted number" is. > 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 > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
