Re: [PATCH wayland-protocols v4] linux-dmabuf: add immediate dmabuf import path

[Daniel Stone]

Hey Varad,

On 12 May 2017 at 06:16, Varad Gautam  wrote:
> On Fri, Feb 10, 2017 at 1:28 PM, Varad Gautam  wrote:
>> provide a mechanism that allows clients to import the added dmabufs
>> and immediately use the newly created wl_buffers without waiting on
>> an event. this is useful to clients that are sure of their import
>> request succeeding, and wish to avoid the wl_buffer communication
>> roundtrip.
>>
>> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
>> versions.
>>
>> v2: specify using incorrectly imported dmabufs as undefined behavior
>> instead of sending success/failure events. (pq, daniels)
>> v3: preserve the optional protocol error added in v2 and explicitly
>> state the outcome of import success or failure (pq)
>> v4: clarify create_immed failure cases and error codes (pq)
>>
>> Signed-off-by: Varad Gautam 
>> Reviewed-by: Pekka Paalanen 
>> ---
>
> Could we get this merged into wayland-protocols, if there are no
> objections on the v4?

Er yeah, it's definitely been long enough. Pushed now, thanks!

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4] linux-dmabuf: add immediate dmabuf import path

[Varad Gautam]

Hi all,

On Fri, Feb 10, 2017 at 1:28 PM, Varad Gautam  wrote:
> From: Varad Gautam 
>
> provide a mechanism that allows clients to import the added dmabufs
> and immediately use the newly created wl_buffers without waiting on
> an event. this is useful to clients that are sure of their import
> request succeeding, and wish to avoid the wl_buffer communication
> roundtrip.
>
> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
> versions.
>
> v2: specify using incorrectly imported dmabufs as undefined behavior
> instead of sending success/failure events. (pq, daniels)
> v3: preserve the optional protocol error added in v2 and explicitly
> state the outcome of import success or failure (pq)
> v4: clarify create_immed failure cases and error codes (pq)
>
> Signed-off-by: Varad Gautam 
> Reviewed-by: Pekka Paalanen 
> ---

Could we get this merged into wayland-protocols, if there are no
objections on the v4?

Thanks,
Varad

>  unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 66 
> +++---
>  1 file changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> index ed2c4bb..63fbb2d 100644
> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> @@ -24,13 +24,13 @@
>  DEALINGS IN THE SOFTWARE.
>
>
> -  
> +  
>  
>Following the interfaces from:
>
> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>and the Linux DRM sub-system's AddFb2 ioctl.
>
> -  This interface offers a way to create generic dmabuf-based
> +  This interface offers ways to create generic dmabuf-based
>wl_buffers. Immediately after a client binds to this interface,
>the set of supported formats is sent with 'format' events.
>
> @@ -56,10 +56,23 @@
>To create a wl_buffer from one or more dmabufs, a client creates a
>zwp_linux_dmabuf_params_v1 object with a 
> zwp_linux_dmabuf_v1.create_params
>request. All planes required by the intended format are added with
> -  the 'add' request. Finally, a 'create' request is issued. The server
> -  will reply with either a 'created' event which provides the final
> -  wl_buffer or a 'failed' event saying that it cannot use the dmabufs
> -  provided.
> +  the 'add' request. Finally, a 'create' or 'create_immed' request is
> +  issued, which has the following outcome depending on the import 
> success.
> +
> +  The 'create' request,
> +  - on success, triggers a 'created' event which provides the final
> +wl_buffer to the client.
> +  - on failure, triggers a 'failed' event to convey that the server
> +cannot use the dmabufs received from the client.
> +
> +  For the 'create_immed' request,
> +  - on success, the server immediately imports the added dmabufs to
> +create a wl_buffer. No event is sent from the server in this case.
> +  - on failure, the server can choose to either:
> +- terminate the client by raising a fatal error.
> +- mark the wl_buffer as failed, and send a 'failed' event to the
> +  client. If the client uses a failed wl_buffer as an argument to any
> +  request, the behaviour is compositor implementation-defined.
>
>Warning! The protocol described in this file is experimental and
>backward incompatible changes may be made. Backward compatible changes
> @@ -105,7 +118,7 @@
>  
>
>
> -  
> +  
>  
>This temporary object is a collection of dmabufs and other
>parameters that together form a single logical buffer. The temporary
> @@ -138,6 +151,9 @@
>   summary="invalid width or height"/>
>   summary="offset + stride * height goes out of dmabuf bounds"/>
> +   + summary="invalid wl_buffer resulted from importing dmabufs via
> +   the create_immed request on given buffer_params"/>
>  
>
>  
> @@ -269,6 +285,42 @@
>  zlinux_buffer_params object.
>
>  
> +
> +
> +  
> +This asks for immediate creation of a wl_buffer by importing the
> +added dmabufs.
> +
> +In case of import success, no event is sent from the server, and the
> +wl_buffer is ready to be used by the client.
> +
> +Upon import failure, either of the following may happen, as seen fit
> +by the implementation:
> +- the client is terminated with one of the following fatal protocol
> +  errors:
> +  - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
> +in case of argument errors such as mismatch between the number
> +of planes and the format, bad format,