[libcamera-devel] [PATCH v3 0/4] android: switch over to modern gralloc API via libui

Mattijs Korpershoek mkorpershoek at baylibre.com
Sat Sep 30 10:19:08 CEST 2023


On lun., sept. 25, 2023 at 10:56, Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:

> Hi Mattijs,
>
> On Mon, Sep 25, 2023 at 09:09:42AM +0200, Mattijs Korpershoek wrote:
>> On dim., sept. 24, 2023 at 18:42, Laurent Pinchart wrote:
>> > On Sat, Sep 23, 2023 at 06:23:30PM +0200, Mattijs Korpershoek via libcamera-devel wrote:
>> >> gralloc.h is a very old API that has been deprecated at least since
>> >> Android P (9).
>> >> 
>> >> Devices are encouraged to switch over to HIDL interface named
>> >> android.hardware.graphics.allocator@<VERSION>, where <VERSION> can be
>> >> 2.0 ,3.0 or 4.0.
>> >> 
>> >> This is mandatory since Android Q (10) [1]
>> >> 
>> >> Fortunately, Android provides an abstraction on top of
>> >> android.hardware.graphics.allocator which is compatible with each
>> >> version.
>> >> This abstraction is implemented in libui, which is available in the
>> >> VNDK.
>> >
>> > What are the pros and cons of using libui compared to direct usage of
>> > android.hardware.graphics.allocator ?
>> 
>> libui's GraphicBufferAllocator has the following pros compared to
>> android.hardware.graphics.allocator:
>> * Supports multiple version of android.hardware.graphics.allocator (2.0, 3.0, 4.0)
>>   https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/ui/GraphicBufferAllocator.cpp;l=50
>> 
>>   I suspect (no proof) that future versions of
>>   android.hardware.graphics.allocator will be added there as well.
>> 
>>   Also, the trend seem to be Google migrating from HIDL to AIDL, making
>>   using an abstraction on top seems a better choice
>> 
>> * Is implemented as singleton so very easy to interact with. No need to
>>   query the hwservice manager to retrieve an instance of android.hardware.graphics.allocator
>> 
>> * GraphicBufferAllocator::allocate() and GraphicBufferAllocator::free()
>>   are higher level of abstraction so easier to use.
>> 
>> The cons I can think of are:
>> * GraphicBufferAllocator has more include/dependencies than android.hardware.graphics.allocator.
>>   I have not counted them.
>> 
>> Hope that answers.
>> Should I add this to the cover letter?
>
> Thanks for the explanation. Including it in the cover letter of v4 would
> be nice indeed.

Will do.

>
>> >> Import all necessary headers from AOSP and switch over the
>> >> generic_frame_buffer_allocator to use GraphicBufferAllocator.
>> >> 
>> >> This series has been build-tested on a linux host and functionally
>> >> tested on an AM62x SK EVM with Android 13. (preview and capture).
>> >> 
>> >> [1] https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/main/compatibility_matrices/compatibility_matrix.4.xml#195
>> >> 
>> >> Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
>> >> ---
>> >> Changes in v3:
>> >> - Fixed patch 3 missing whitespace (Jacopo)
>> >> - Added libui meson import build in patch 3 (more consistent) (Jacopo)
>> >> - Removed member reference to GraphicBufferAllocator in patch 4 (Jacopo)
>> >> - Link to v2: https://lists.libcamera.org/pipermail/libcamera-devel/2023-September/038942.html
>> >> 
>> >> Changes in v2:
>> >> - Dropped additional ; in graphic_buffer_allocator_stub.cpp. (Kieran)
>> >> - Surrounded problematic includes with #pragma to avoid clang compile
>> >>   errors related to -Wextra-semi. (Kieran)
>> >> - Link to v1: https://lists.libcamera.org/pipermail/libcamera-devel/2023-September/038927.html
>> >> 
>> >> Tested on linux with:
>> >> CC=clang CXX=clang++ meson setup build -Dandroid=enabled -Dandroid_platform=generic
>> >> ninja -C build
>> >> And clang version clang++ (clang 16.0.6 "clang version 16.0.6 (Fedora 16.0.6-2.fc38)")
>> >> 
>> >> ---
>> >> Mattijs Korpershoek (4):
>> >>       android: Import libutils/libui headers from vndk v33
>> >>       android: Import GraphicBufferAllocator header from vndk v33
>> >>       android: Stub GraphicBufferAllocator for build tests
>> >>       android: mm: generic: Use GraphicBufferAllocator instead of gralloc.h
>> >> 
>> >>  .../libs/ui/include/ui/GraphicBufferAllocator.h    |  81 ++++++++
>> >>  .../native/libs/ui/include/ui/PixelFormat.h        |  75 +++++++
>> >>  include/android/meson.build                        |   2 +
>> >>  .../system/core/libutils/include/utils/Compat.h    |  94 +++++++++
>> >>  .../system/core/libutils/include/utils/Errors.h    |  78 ++++++++
>> >>  .../system/core/libutils/include/utils/Mutex.h     | 219 +++++++++++++++++++++
>> >>  .../system/core/libutils/include/utils/Singleton.h | 102 ++++++++++
>> >>  .../system/core/libutils/include/utils/Timers.h    | 103 ++++++++++
>> >>  src/android/mm/generic_frame_buffer_allocator.cpp  |  68 +++----
>> >>  src/android/mm/graphic_buffer_allocator_stub.cpp   |  54 +++++
>> >>  src/android/mm/libhardware_stub.c                  |  17 --
>> >>  src/android/mm/meson.build                         |  11 +-
>> >>  12 files changed, 835 insertions(+), 69 deletions(-)
>> >> ---
>> >> base-commit: 1d616141420d1f51e5999d758e3e0cc721a46290
>> >> change-id: 20230824-gralloc-api-v4-e3388fd364c6
>
> -- 
> Regards,
>
> Laurent Pinchart


More information about the libcamera-devel mailing list