On Sat, Mar 17, 2018 at 2:33 PM, Stefan Schake <stschake@xxxxxxxxx> wrote:
> Hey John,
>
> On Fri, Mar 16, 2018 at 10:48 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>> In trying to integrate the new gralloc_handle.h with the
>> drm_hwcomposer, I started seeing the following compilation
>> errors:
>>
>> In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
>> external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of type 'struct gralloc_handle_t *'
>> return handle;
>> ^~~~~~
>> 1 error generated.
Somehow this is not throwing an error for me...
>> This seems to be due to the gralloc_handle_create() definition
>> claiming to return a native_handle_t * type, rather then a
>> gralloc_handle_t *, which is what the code actually returns.
>>
>> This function isn't actually used in the current drm_hwcomposer,
>> so I'm not totally sure that this fix is correct (rather then
>> returning the gralloc_handle_t's embadedded native_handle_t ptr).
>
> This changed in 009634e49309 ("android: fix gralloc_handle_create() problems")
> to make the return value from gralloc_handle_create opaque to its user.
>
> Since the only one that would use gralloc_handle_create is the gralloc
> implementation itself (and libdrm isn't one) and using getters/setters was
> rejected (IIRC), I would think there is no reason to obscure the return type.
Not rejected, just not required at the start and not in a lib. And I
am working on adding helper functions and I'm using buffer_handle_t
everywhere.
> Since buffer_handle_t is native_handle_t* is gralloc_handle_t* it's also
> correct. The alternative to changing the declaration here is returning
> nhandle instead of handle.
BTW, returning buffer_handle_t doesn't work though because it is const.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
