On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org> wrote: > Hi Rob, > > On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.f...@collabora.com> > 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; >>> >>> >>> 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. > > This would be very similar to gralloc0 perform call. gralloc1 > implementations need to provide getFunction() callback [1], which > returns a pointer to given function. The list of standard functions is > defined in the gralloc1.h header [2], but we could take some random > big number and use it for our function that fills in provided > gralloc_funcs_t struct with necessary pointers. > > [1] > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300 > [2] > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
This is a deadend because it won't work with a HIDL based implementation (aka gralloc 2.0). You can't set function pointers (or any pointers) because gralloc runs in a different process. Yes, currently gralloc is a pass-thru HAL, but AIUI that will go away. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
