| Age | Commit message (Collapse) | Author |
|---|
|
gralloc.h is a very old API that has been deprecated at least since
Android P (9).
Switch over to a higher level abstraction of gralloc from libui, which
is compatible with Android 11 and up.
Libui:
* is provided in the VNDK (so it's available to vendors).
* is also used in the camera vts test named VtsAidlHalCameraProvider_TargetTest.
Notes:
* GraphicsBufferAllocator being a Singleton, buffer lifecycle
management is easier.
* The imported headers from Android generate the -Wextra-semi warning.
To avoid patching the files, a pragma has been added before inclusion.
* libdl was used for dlclosing() the legacy hal, so the dep has been dropped
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
PlatformFrameBufferAllocator is an abstraction over gralloc.
Right now hardwareModule_ points towards a CAMERA_HARDWARE_MODULE_ID.
When gralloc_open() is called we observe:
libcamera: DEBUG HAL camera3_hal.cpp:75 Open camera gpu0
libcamera: ERROR Camera camera.cpp:524 Camera in Configured state trying acquire() requiring state Available
01-23 14:14:04.742 370 416 E libcamera: FATAL HAL generic_frame_buffer_allocator.cpp:105 gralloc_open() failed: -87
Which is wrong, gralloc_open() is attempting to re-open the camera HAL,
instead of the gralloc HAL.
Point to a GRALLOC_HARDWARE_MODULE_ID instead so that we can request
buffers from gralloc in android.
Note: this adds new dependencies on android's libhardware [1] and on libdl.
[1] https://android.googlesource.com/platform/hardware/libhardware
Fixes: c58662c5770e ("android: Introduce PlatformFrameBufferAllocator")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
HALFrameBuffer is derived from FrameBuffer with access to
buffer_handle_t, which is needed for JEA usage.
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Private members of the FrameBuffer class are split between FrameBuffer
and FrameBuffer::Private. There was no real justification for this
split, and keeping some members private in the FrameBuffer class causes
multiple issues:
- Future modifications of the FrameBuffer class without breaking the ABI
may be more difficult.
- Mutable access to members that should not be modified by applications
require a friend statement, or going through the Private class.
Move all remaining private members to the Private class to address the
first issue, and add a Private::metadata() function to address the
second problem.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The existing FrameBufferAllocator is not allowed to allocate a
new buffer while Camera is running. This introduces
PlatformFrameBufferAllocator. It allocates FrameBuffer using
cros::CameraBufferManager on ChromeOS and gralloc on non ChromeOS
platform. The allocated FrameBuffer owns the underlying buffer
but must be destroyed before PlatformFrameBufferAllocator is
destroyed.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
