Hi Rob, On Tue, Jan 30, 2018 at 1:17 AM, Robert Foss <robert.f...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
