[Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Rob Herring]

On Tue, Dec 5, 2017 at 11:01 AM, Robert Foss <robert.foss at collabora.com> wrote:
> On Tue, 2017-12-05 at 18:22 +0900, Tomasz Figa wrote:
>> On Sat, Dec 2, 2017 at 4:43 AM, Rob Herring <robh at kernel.org> wrote:
>> > On Fri, Dec 1, 2017 at 8:44 AM, Tomasz Figa <tfiga at chromium.org>
>> > wrote:
>> > > On Fri, Dec 1, 2017 at 11:20 PM, Rob Herring <robh at kernel.org>
>> > > wrote:
>> > > > On Fri, Dec 1, 2017 at 7:30 AM, Robert Foss <robert.foss at collab
>> > > > ora.com> wrote:
>> > > > > On Thu, 2017-11-30 at 11:14 -0600, Rob Herring wrote:
>> > > > > > On Thu, Nov 30, 2017 at 12:11 AM, Tapani Pälli <tapani.pall
>> > > > > > i at intel.co
>> > > > > > m> wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > > On 11/30/2017 06:13 AM, Tomasz Figa wrote:
>> > > > > > > >
>> > > > > > > > On Thu, Nov 30, 2017 at 3:43 AM, Robert Foss <robert.fo
>> > > > > > > > ss at collabo
>> > > > > > > > ra.com>
>> > > > > > > > wrote:
>> >
>> > [...]


>> > > However I fully agree that there are other upstream components
>> > > (e.g.
>> > > drm_hwcomposer), which would benefit from it and nobody wants to
>> > > include Mesa in the build just for one header. Should we have a
>> > > separate freedesktop project for it?
>> >
>> > I'm still going to say libdrm. If that's really a problem, then we
>> > can
>> > split it out later.
>>
>> At least for Chromium OS, libdrm would work fine indeed.
>
> Excellent, so with the question of where (libdrm) covered, that leaves
> us with what.
>
> Currently this is what what the XXX_handle structs look like:
> gbm_gralloc: https://github.com/robherring/gbm_gralloc/blob/master/gral
> loc_drm_handle.h#L36
>
> minigbm: https://chromium.googlesource.com/chromiumos/platform/minigbm/
> +/master/cros_gralloc/cros_gralloc_handle.h#20
>
> intel-minigbm: https://github.com/intel/minigbm/blob/master/cros_grallo
> c/cros_gralloc_handle.h#L20
>
> A lot seems to be shared between the 3, gbm_gralloc seems to have
> modifier support, but lack multi-planar YUV support.
>
> DRV_MAX_PLANES sounds to be a bit of a misnomer, as (I think) it refers
> to YUV planes and not planes supported by the driver/hw.
>
> I would assume that all shared variables would be available in the
> libdrm-struct, as well the ones planar YUV support.
>
> As for the non-obvious ones, maybe the should be listed so that we can
> dig into if they are really needed, implementation specific or unused.

My plan is similar to what I was thinking in the move to hwc. Move the
struct as is to libdrm and get the dependencies (gbm_gralloc,
drm_gralloc?, drm_hwc, mesa) switched over to use it. Then start
modifying the struct contents. Here's my list:

- versioning of the handle
- remove .name (GEM handles. only dmabuf support)
- better way to do buffer registration tracking (than a pid and ptr)?
- multi-planar
- switch format to fourcc (or add the fourcc format)
- switch to accessor functions or library calls

Rob