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>
>>>>>>> uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>>>> uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>>>>>>> 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 , which
> returns a pointer to given function. The list of standard functions is
> defined in the gralloc1.h header , 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.
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.
mesa-dev mailing list