[Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm
tfiga at chromium.org
Tue Jan 30 03:16:43 UTC 2018
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.
> On 01/29/2018 01:03 PM, Robert Foss wrote:
>>>> 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;
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
Perhaps an integer version field would also be useful, in case we end
up adding some more callbacks.
More information about the mesa-dev