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

[Esaki Tomohito]

Dear Daniel,

On 2016/11/02 4:09, Daniel Stone wrote:
> 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.

Yes, good to me.

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

Yes, good to me.

Thanks.

-- 
--------------------------
IGEL Co., Ltd.
Tomohito Esaki
etom at igel.co.jp