[RFC] protocol: Introduce logical surface protocol

[Daniel Stone]

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 ...)

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130329/5da50d63/attachment.html>