[Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Rob,

On Tue, Jan 30, 2018 at 1:17 AM, Robert Foss <robert.foss at collabora.com> wrote:
> Hey Tomasz,
>
> I'm tempted to split this work into two parts.
> 1) Move gbm&drm gralloc struct

Alright, if we look at this only as an attempt to converge gbm_ and
drm_gralloc, it's out of my scope and no concern anymore.

> 2) Accessor functions
>
> I would like to get 1) out the door to support John Stultzs current HiKey
> 960 efforts. As for 2), it would seem that we have some more discussing to
> do. But I'll keep pushing that forward.
>
> Separately, I'd like to know if the below sketch of a func ptr solution is
> what you had in mind. From what I've gathered this is exactly what you've
> requested, but I would like to confirm it too.

I assume you mean the ones below?

>
> I'll send out a v2, that covers 1) later today.
>
>
> Rob.
>
>
> On 01/29/2018 01:03 PM, Robert Foss wrote:
[snip]
>>
>>>
>>>>      uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>      uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t plane);
>>>>      uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>      uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>      ...
>>>> } gralloc_funcs_t;

These ones?

Yeah, if we could retrieve such function pointer struct using perform
or any equivalent (like the implementation-specific methods in
gralloc1, but not sure if that's going to be used in practice
anywhere), it could work for us.

I think we could also add .get_fourcc(handle) and
.get_num_planes(handle) callbacks, so that we could do away with the
whole sophisticated format guessing based on Android HAL format and
lock_ycbcr results.

Perhaps an integer version field would also be useful, in case we end
up adding some more callbacks.

Best regards,
Tomasz