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

[Robert Foss]

On 01/30/2018 04:16 AM, Tomasz Figa wrote:
> 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.

Glad I asked, let's get that part over with, and continue with the accessors.

> 
>> 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?

Yes.

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

So this is where you and Rob Herring lose me, I don't think I understand quite 
how the gralloc1 call would be used, and how it would tie into this handle 
struct. I think I could do with some guidance on this.

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

I intentionally kept the list brief, but a more complete list would provide 
support for each element of the cros minigbm struct.

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

That's a good point.


Rob.