[PATCH 1/7] protocol: add linux_dmabuf extension RFCv1
Daniel Vetter
daniel at ffwll.ch
Thu Dec 18 01:25:09 PST 2014
On Fri, Dec 12, 2014 at 04:51:02PM -0500, Louis-Francis Ratté-Boulianne wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>
> An experimental (hence the 'z' prefix) linux_dmabuf Wayland protocol
> extension for creating dmabuf-based wl_buffers in a generic manner.
>
> This does not include proper dmabuf metadata negotiation because
> there is no way to communicate all dmabuf constraints from the
> compositor to a client before-hand. The client has to create a
> wl_buffer wrapping one or more dmabuf buffers and then listen at
> the feedback object returned to know if the operation was successful.
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb at collabora.com>
So I have no idea about how wayland protos work, so please take that into
account ;-)
Generally I think we should try to follow what the drm addfb2 ioctl does
in drm, since in the end we need to be able to handle pretty much all the
same issues. Well wayland needs to solve a few more since it also must
cope with buffer layouts which can only be used for rendering but not
scanned out.
Wrt tiling layouts and compressed buffers and similar vendor specific
things: The current proposal is to add a new uint64_t layout qualifier to
addfb with opaque #defines (probably a new header), with an 8:56 bit split
between vendor identifier and opaque vendor specified content. It will
also be per-buffer (like pitches/offsets). The abi isn't locked down yet,
but definitely something to keep in mind.
It will definitely complicate the protocol though since the specific
layout modifiers which are acceptable change dynamically at runtime: Some
scanout formats become invalid when we run out of fifo space, some can
only be used on specific planes and ofc this all depends upon whether gl
compositing or hw planes are used to pick the right one.
Some more random comments below.
Cheers, Daniel
> ---
> Makefile.am | 7 +-
> protocol/linux-dmabuf.xml | 224 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 229 insertions(+), 2 deletions(-)
> create mode 100644 protocol/linux-dmabuf.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 494266d..0462fdd 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -91,7 +91,9 @@ nodist_weston_SOURCES = \
> protocol/presentation_timing-protocol.c \
> protocol/presentation_timing-server-protocol.h \
> protocol/scaler-protocol.c \
> - protocol/scaler-server-protocol.h
> + protocol/scaler-server-protocol.h \
> + protocol/linux-dmabuf-protocol.c \
> + protocol/linux-dmabuf-server-protocol.h
>
> BUILT_SOURCES += $(nodist_weston_SOURCES)
>
> @@ -1101,7 +1103,8 @@ EXTRA_DIST += \
> protocol/presentation_timing.xml \
> protocol/scaler.xml \
> protocol/ivi-application.xml \
> - protocol/ivi-hmi-controller.xml
> + protocol/ivi-hmi-controller.xml \
> + protocol/linux-dmabuf.xml
>
> man_MANS = weston.1 weston.ini.5
>
> diff --git a/protocol/linux-dmabuf.xml b/protocol/linux-dmabuf.xml
> new file mode 100644
> index 0000000..c48121c
> --- /dev/null
> +++ b/protocol/linux-dmabuf.xml
> @@ -0,0 +1,224 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="linux_dmabuf">
> +
> + <copyright>
> + Copyright © 2014 Collabora, Ltd.
> +
> + Permission to use, copy, modify, distribute, and sell this
> + software and its documentation for any purpose is hereby granted
> + without fee, provided that the above copyright notice appear in
> + all copies and that both that copyright notice and this permission
> + notice appear in supporting documentation, and that the name of
> + the copyright holders not be used in advertising or publicity
> + pertaining to distribution of the software without specific,
> + written prior permission. The copyright holders make no
> + representations about the suitability of this software for any
> + purpose. It is provided "as is" without express or implied
> + warranty.
> +
> + THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> + SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> + FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> + SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> + ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> + THIS SOFTWARE.
> + </copyright>
> +
> + <interface name="zlinux_dmabuf" version="1">
> + <description summary="factory for creating dmabuf-based wl_buffers">
> + Following the interfaces from:
> + https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> +
> + This interface offers a way 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.
> + </description>
> +
> + <enum name="error">
> + <entry name="invalid_format" value="1"/>
> + <entry name="invalid_dmabuf" value="2"/>
> + <entry name="format_dmabufs_mismatch" value="3"/>
> + <entry name="invalid_dmabuf_params" value="4"/>
> + </enum>
> +
> + <enum name="format">
> + <!-- The drm format codes match the #defines in drm_fourcc.h.
> + The formats actually supported by the compositor will be
> + reported by the format event. -->
Is there some way we could autogenerate this from drm_fourcc.h? We need to
do changes to the kernel header to facilitate that we should do so imo.
Or should we just mandate that this must be a fourcc code from
drm_fourcc.h and not list them all as enums?
> + <entry name="c8" value="0x20203843"/>
> + <entry name="rgb332" value="0x38424752"/>
> + <entry name="bgr233" value="0x38524742"/>
> + <entry name="xrgb4444" value="0x32315258"/>
> + <entry name="xbgr4444" value="0x32314258"/>
> + <entry name="rgbx4444" value="0x32315852"/>
> + <entry name="bgrx4444" value="0x32315842"/>
> + <entry name="argb4444" value="0x32315241"/>
> + <entry name="abgr4444" value="0x32314241"/>
> + <entry name="rgba4444" value="0x32314152"/>
> + <entry name="bgra4444" value="0x32314142"/>
> + <entry name="xrgb1555" value="0x35315258"/>
> + <entry name="xbgr1555" value="0x35314258"/>
> + <entry name="rgbx5551" value="0x35315852"/>
> + <entry name="bgrx5551" value="0x35315842"/>
> + <entry name="argb1555" value="0x35315241"/>
> + <entry name="abgr1555" value="0x35314241"/>
> + <entry name="rgba5551" value="0x35314152"/>
> + <entry name="bgra5551" value="0x35314142"/>
> + <entry name="rgb565" value="0x36314752"/>
> + <entry name="bgr565" value="0x36314742"/>
> + <entry name="rgb888" value="0x34324752"/>
> + <entry name="bgr888" value="0x34324742"/>
> + <entry name="xrgb8888" value="0x34325258"/>
> + <entry name="xbgr8888" value="0x34324258"/>
> + <entry name="rgbx8888" value="0x34325852"/>
> + <entry name="bgrx8888" value="0x34325842"/>
> + <entry name="argb8888" value="0x34325241"/>
> + <entry name="abgr8888" value="0x34324241"/>
> + <entry name="rgba8888" value="0x34324152"/>
> + <entry name="bgra8888" value="0x34324142"/>
> + <entry name="xrgb2101010" value="0x30335258"/>
> + <entry name="xbgr2101010" value="0x30334258"/>
> + <entry name="rgbx1010102" value="0x30335852"/>
> + <entry name="bgrx1010102" value="0x30335842"/>
> + <entry name="argb2101010" value="0x30335241"/>
> + <entry name="abgr2101010" value="0x30334241"/>
> + <entry name="rgba1010102" value="0x30334152"/>
> + <entry name="bgra1010102" value="0x30334142"/>
> + <entry name="yuyv" value="0x56595559"/>
> + <entry name="yvyu" value="0x55595659"/>
> + <entry name="uyvy" value="0x59565955"/>
> + <entry name="vyuy" value="0x59555956"/>
> + <entry name="ayuv" value="0x56555941"/>
> + <entry name="nv12" value="0x3231564e"/>
> + <entry name="nv21" value="0x3132564e"/>
> + <entry name="nv16" value="0x3631564e"/>
> + <entry name="nv61" value="0x3136564e"/>
> + <entry name="yuv410" value="0x39565559"/>
> + <entry name="yvu410" value="0x39555659"/>
> + <entry name="yuv411" value="0x31315559"/>
> + <entry name="yvu411" value="0x31315659"/>
> + <entry name="yuv420" value="0x32315559"/>
> + <entry name="yvu420" value="0x32315659"/>
> + <entry name="yuv422" value="0x36315559"/>
> + <entry name="yvu422" value="0x36315659"/>
> + <entry name="yuv444" value="0x34325559"/>
> + <entry name="yvu444" value="0x34325659"/>
> + </enum>
> +
> + <request name="destroy" type="destructor">
> + <description summary="unbind the factory">
> + </description>
> + </request>
> +
> + <request name="create_batch">
> + <description summary="create a collection of dmabufs">
> + This temporary object is used to collect multiple dmabuf handles
> + into a single batch.
> + </description>
> + <arg name="batch_id" type="new_id" interface="dmabuf_batch"/>
> + </request>
> +
> + <request name="create_buffer">
> + <description summary="create a dmabuf-based wl_buffer">
> + The result of the operation will be returned via the provided
> + zlinux_dmabuf_create_feedback object.
> +
> + The dmabuf_batch object must be destroyed immediately after
> + after this request.
> +
> + Any errors in importing the set of dmabufs can be delivered as
> + protocol errors immediately or later.
> + </description>
> + <arg name="batch" type="object" interface="dmabuf_batch"/>
> + <arg name="width" type="int"/>
> + <arg name="height" type="int"/>
> + <arg name="format" type="uint" summary="from format enum"/>
> + <arg name="feedback" type="new_id" interface="zlinux_dmabuf_create_feedback"/>
> + </request>
> +
> + <event name="format">
> + <description summary="supported buffer format">
> + This event advertises one buffer format that the server support.
> + All the supported formats advertised once when the client
> + binds to this interface. A roundtrip after binding guarantees,
> + that the client has received all supported formats.
> + </description>
> + <arg name="format" type="uint" summary="from format enum"/>
> + </event>
> +
> + </interface>
> +
> + <interface name="zlinux_dmabuf_create_feedback" version="1">
> + <description summary="feedback for buffer creation">
> + This interface is used to keep track of a buffer creation
> + operation.
> + </description>
> +
> + <event name="create_successful">
> + <description summary="buffer creation succeeded">
> + This event indicates that the attempted buffer creation was
> + successful. It contains the id of the wl_buffer wrapping
> + the dmabuf.
> +
> + Upon receiving this event, the client should destroy the
> + zlinux_dmabuf_create_feedback object.
> + </description>
> + <arg name="buffer_id" type="new_id" interface="wl_buffer"/>
> + </event>
> + <event name="create_failed">
> + <description summary="buffer creation failed">
> + This event indicates that the attempted buffer creation was
> + has failed. It usually means that one of the dmabuf constraints
> + has not been fulfilled.
> +
> + Upon receiving this event, the client should destroy the
> + zlinux_dmabuf_create_feedback object.
> + </description>
> + </event>
> + </interface>
> +
> + <interface name="dmabuf_batch" version="1">
> + <description summary="a collection of dmabufs">
> + This is a collection of dmabufs, forming a single logical buffer.
> + Usually only one dmabuf is needed, but some multi-planar formats
> + may require more.
> +
> + The order of dmabufs added for this object is significant, and must
> + match the expectations of the format argument to
> + linux_dmabuf.create_buffer.
> + </description>
> +
> + <request name="destroy" type="destructor">
> + <description summary="delete this object, used or not">
> + </description>
> + </request>
> +
> + <request name="add">
> + <description summary="add a dmabuf to the wl_buffer">
> + Multi-planar formats may require using more than one
> + dmabuf for passing all the data for one logical buffer.
> + This request adds one dmabuf to the set in this dmabuf_batch.
> +
> + When one dmabuf has several planar channels, offset1 & stride1 and
> + offset2 & stride2 must be used to denote them without sending a
> + new add_dmabuf request which would create a new fd in the server
> + while still pointing at the same dmabuf.
> +
> + offset0 and stride0 must always be set. Other unused offsets and
> + strides must be zero.
> + </description>
> +
> + <arg name="name" type="fd"/>
> + <arg name="offset0" type="int"/>
> + <arg name="stride0" type="int"/>
> + <arg name="offset1" type="int"/>
> + <arg name="stride1" type="int"/>
> + <arg name="offset2" type="int"/>
> + <arg name="stride2" type="int"/>
> + </request>
Hm, with addfb we just ask userspace to pass the same fb 3/2 times for
planar data that's all in the same buffer object.
> +
> + </interface>
> +
> +</protocol>
> --
> 2.1.0
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the wayland-devel
mailing list