[RFC] protocol: Introduce logical surface protocol

[Jason Ekstrand]

On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Jason,
>
> On 29 March 2013 16:55, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>
>> A few quick thoughts, more to come.  First, your get_export_surface has
>> two new_id arguments. I don't think that's intended.
>
> Oops, thanks!
>>
>> Second, we currently have no way for a client to retrieve data from a
>> buffer. This will be a problem for client-side compositing.
>
> Yeah, we need to define API here.  For EGL, it'd be a matter of the EGL
> implementation sending an event in between register_buffer and
> buffer_available, such that when you called eglCreateImageKHR(egl_dpy,
> EGL_WAYLAND_FOREIGN_BUFFER_WL, buffer), it would be able to supply an
> EGLImage.  To go to a SHM buffer would almost certainly require a round
> trip, in order to ensure synchronisation with GL.  (Which would hopefully be
> done by the client rather than the compositor, especially if it involves
> ReadPixels ...)

Ok, I guess I can see that working.  It still seems somewhat
ill-defined to me, but maybe that's because I just don't know mesa
internals well enough.

One question worth answering: Why don't we just have a
wl_embeded_compositor interface and make the web pages or whatever
clients to this?  It could be a really simple interface.  It really
doesn't take that much work to set up the basics for a compositor.  If
you're worried about having to write code to handle inputs, you'll
have to do that yourself anyway if the client is planning to composite
the foreign surface itself.  I'm not seeing a whole lot of benefit
over the nested compositors approach particularly when you think about
the complexity we're adding.

> But yeah, this is why I split the events: one to provide the new_id for the
> buffer, another to let the client know it was available for use, and then
> all manner of private protocol in between to actually enable those target
> APIs to use the buffer.
>
> Thanks for taking a look!
>
> Cheers,
> Daniel
>
>>
>> On Mar 29, 2013 11:06 AM, "Daniel Stone" <daniel at fooishbar.org> wrote:
>>>
>>> Hi Jonas,
>>>
>>> On 17 March 2013 09:13, Jonas Ådahl <jadahl at gmail.com> wrote:
>>>>
>>>> A logical surface is a special kind of surface that never gets its own
>>>> buffer attached, or opaque region set etc. It is obtained by using a
>>>> surface handle that can be shared in some way between clients. A handle
>>>> is a server wide unique identifier retrieved from the server given a
>>>> real surface. Currently a logical surface is limited to only be usable
>>>> as a sub-surface.
>>>
>>>
>>> I've been thinking about exactly the same thing, but with additional
>>> complications to the usecases.  There are two I think we need to support:
>>>   - export a surface from client A such client B can create a subsurface
>>> with it
>>>   - export a surface from client A such that client B can act as its own
>>> compositor, i.e. being notified of incoming buffers and being able to import
>>> them
>>>
>>> The latter is required for things like WebGL where you end up rendering
>>> to a transformed surface.
>>>
>>> I do really like the acquire_handle vs. release_handle semantics, but
>>> I've gone a slightly different way here.  For the exporting client (let's
>>> call it the child), the surface becomes a new surface role, which is only
>>> capable of being exported; it can't, e.g., be a shell surface at the same
>>> time.  For the importing client, it gets a new surface type which can either
>>> be used as a child to construct a new surface, or provide the importing
>>> client with notifications that a new buffer has been attached and is
>>> available for usage.
>>>
>>> If used in the latter mode, in theory new buffers could be used as
>>> EGLImages or SHM buffers, as well as being attachable to an existing
>>> surface.  To support resizes, the surface would still need an out-of-band
>>> notification that a resize was beginning, as well as the target size, but
>>> the dx/dy/width/height parameters in buffer_available should hopefully be
>>> enough to provide the acknowledgement from the exporter to importer that the
>>> resize has been completed.  In this sense, it works quite similarly to the
>>> wl_subsurface parent vs. independent commit modes.
>>>
>>> I've gone the separate object route rather than sharing objects, because
>>> I think that way is seriously painful, and is wide open for abuse, with
>>> multiple clients stepping on each others' toes in an X11 fashion.  I think
>>> having the clean separation is really useful, and has the minimum potential
>>> for anything to go wrong.
>>>
>>> So it's a little more complicated (and comes without a proof of concept),
>>> but I think hopefully should cover everything.  Any comments?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>