[PATCH weston v2 3/3] compositor-drm: Support linux_dmabuf output for sprite planes without gbm

[Daniel Stone]

Dear Esaki-san,

On 30 September 2016 at 10:28, Tomohito Esaki <etom at igel.co.jp> wrote:
> Multiplanar formats are supported by using drmModeAddFB2 and bypassing
> gbm. If drmModeAddFB2 isn't available, the existing gbm bo import path
> is used and multiplanar formats are unsupported.

Thanks very much for these four patches - these three, plus the other
one to properly account for the viewport. I have merged patch 1/3
already into my local tree (with some very minor changes), and like
2/3, but have one comment below.

My current work is here:
git://git.collabora.com/git/user/daniels/weston#wip/2016-10/drm-plane-state

This includes the small changes I mentioned to patch 1/3: please let
me know if this change is OK with you. I think the series which is in
there is pretty good to review already, but needs a tiny bit more
testing. This is what I am currently rebuilding atomic on top of.

> @@ -1101,15 +1096,9 @@ drm_output_prepare_overlay_view(struct drm_output *output,
>         if (!found)
>                 return NULL;
>
> -       if ((dmabuf = linux_dmabuf_buffer_get(buffer_resource))) {
> +       if ((dmabuf = linux_dmabuf_buffer_get(buffer_resource)) &&
> +           b->no_addfb2 && b->gbm) {
>  #ifdef HAVE_GBM_FD_IMPORT
> -               /* XXX: TODO:
> -                *
> -                * Use AddFB2 directly, do not go via GBM.
> -                * Add support for multiplanar formats.
> -                * Both require refactoring in the DRM-backend to
> -                * support a mix of gbm_bos and drmfbs.
> -                */
>                 struct gbm_import_fd_data gbm_dmabuf = {
>                         .fd     = dmabuf->attributes.fd[0],
>                         .width  = dmabuf->attributes.width,

Here I think there is no benefit to using GBM import: I think it would
be more consistent if we always bypassed GBM and just used our own
non-GBM drm_fb type. What do you think? If we integrate this patch
into the drm_plane_state/atomic tree, the changes for this patch are
quite simple: mainly we need to add a BUFFER_DMABUF type to drm_fb,
and change the prepare_{overlay_scanout}_view paths to put the new
buffer into the plane state directly. I am happy to make this change
myself if you think it is OK.

My apologies for the slow response; I have been unwell lately, so not
able to put nearly as much time into Weston as I had hoped.

Cheers,
Daniel