summaryrefslogtreecommitdiff
path: root/src/android/mm
AgeCommit message (Collapse)Author
2024-05-09libcamera: Drop remaining file name from header comment blocksLaurent Pinchart
Source files in libcamera start by a comment block header, which includes the file name and a one-line description of the file contents. While the latter is useful to get a quick overview of the file contents at a glance, the former is mostly a source of inconvenience. The name in the comments can easily get out of sync with the file name when files are renamed, and copy & paste during development have often lead to incorrect names being used to start with. Readers of the source code are expected to know which file they're looking it. Drop the file name from the header comment blocks in all remaining locations that were not caught by the automated script as they are out of sync with the file name. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-05-08libcamera: Drop file name from header comment blocksLaurent Pinchart
Source files in libcamera start by a comment block header, which includes the file name and a one-line description of the file contents. While the latter is useful to get a quick overview of the file contents at a glance, the former is mostly a source of inconvenience. The name in the comments can easily get out of sync with the file name when files are renamed, and copy & paste during development have often lead to incorrect names being used to start with. Readers of the source code are expected to know which file they're looking it. Drop the file name from the header comment block. The change was generated with the following script: ---------------------------------------- dirs="include/libcamera src test utils" declare -rA patterns=( ['c']=' \* ' ['cpp']=' \* ' ['h']=' \* ' ['py']='# ' ['sh']='# ' ) for ext in ${!patterns[@]} ; do files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done) pattern=${patterns[${ext}]} for file in $files ; do name=$(basename ${file}) sed -i "s/^\(${pattern}\)${name} - /\1/" "$file" done done ---------------------------------------- This misses several files that are out of sync with the comment block header. Those will be addressed separately and manually. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2023-05-30android: mm: Stub libhardware for build testsLaurent Pinchart
Commit 66c618f378aa ("android: mm: generic: use GRALLOC_HARDWARE_MODULE_ID") made libhardware a required dependency for the Android camera HAL on non-Chrome OS platforms. This isn't an issue for real devices, as Android provides libhardware, but it prevents compile-testing the camera HAL on traditional Linux systems. To restore the compile-test coverage, stub the libhardware function used by the camera HAL when libhardware isn't found. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # meson build test Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-05-30android: mm: generic: use GRALLOC_HARDWARE_MODULE_IDMattijs Korpershoek
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>
2023-02-10android: framebuffer: Add HALFrameBuffer and replace FrameBufferHarvey Yang
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>
2022-10-10libcamera: framebuffer: Move remaining private data to Private classLaurent Pinchart
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>
2022-05-04libcamera: Replace toString with operator<<() for format classesLaurent Pinchart
Now that format classes implement the stream formatting operator<<(), use it instead of the toString() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-12-06android: Introduce PlatformFrameBufferAllocatorHirokazu Honda
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>
2021-11-08android: mm: Null check for CameraBufferManagerUmang Jain
cros::CameraBufferManager can be nullptr if there is an error in its creation. Place a null-check guard to check it. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-09android: mm: cros_camera_buffer: Log failure error on cleanupUmang Jain
Failure can still happen by CameraBufferManager during Unlock() and/or Deregister() of camera3Buffer handles. We should be logging those errors as well. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: formats: Add planeSize() helpers to PixelFormatInfoLaurent Pinchart
Add two helpers functions to the PixelFormatInfo class to compute the byte size of a given plane, taking the frame size, the stride, the alignment constraints and the vertical subsampling into account. Use the new functions through the code base to replace manual implementations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-06android: Cleanup libcamera namespace usageUmang Jain
Usually .cpp files are equipped with using namespace libcamera; Hence, it is unnecessary mentioning the explicit namespace of libcamera at certain places. While at it, a small typo in a comment was noticed and fixed as part of this patch. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-08-31android: generic_camera_buffer: Fix bufferLength_ initializationLaurent Pinchart
The bufferLength_ member variabled is checked to have a positive value before being used, to catch usage before the variable is set. The variable is initialized to zero at construction time, which renders the checks useless. Fix this by initializing the variable to -1 at construction time. Fixes: c5e2ed7806be ("android: camera_buffer: Map buffer in the first plane() call") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-30libcamera: mapped_framebuffer: Return plane begin address by ↵Hirokazu Honda
MappedBuffer::maps() MappedBuffer::maps() returns std::vector<MappedBuffer::Plane>. Plane has the address, but the address points the beginning of the buffer containing the plane. This makes the Plane point the beginning of the plane. So MappedBuffer::maps()[i].data() returns the address of i-th plane. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: camera_buffer: Add stride/offset/size functionHirokazu Honda
This adds getter functions of stride, offset and size to CameraBuffer interface. 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: camera_buffer: Map buffer in the first plane() callHirokazu Honda
CameraBuffer implementation maps a given buffer_handle_t in constructor. Mapping is redundant to only know the plane info like stride and offset. Mapping should be executed later in the first plane() call. 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: generic_camera_buffer: Correct buffer mappingHirokazu Honda
buffer_handle_t doesn't provide sufficient info to map a buffer properly. cros::CameraBufferManager enables handling the buffer on ChromeOS, but no way is provided for other platforms. Therefore, we put the assumption that planes are in the same buffer and they are consecutive. This modifies the way of mapping in generic_camera_buffer with the assumption. 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-10libcamera: Give MappedFrameBuffer its own implementationKieran Bingham
The MappedFrameBuffer is a convenience feature which sits on top of the FrameBuffer and facilitates mapping it to CPU accessible memory with mmap. This implementation is internal and currently sits in the same internal files as the internal FrameBuffer, thus exposing those internals to users of the MappedFramebuffer implementation. Move the MappedFrameBuffer and MappedBuffer implementation to its own implementation files, and fix the sources throughout to use that accordingly. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-06android: mm: cros_camera_buffer: Fix unused parameterHirokazu Honda
cameraBuffer function in private constructor is unused. Mark it as such. Fixes: 33dd4fab9d39("libcamera: base: class: Don't pass Extensible pointer to Private constructor") Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-03libcamera: base: class: Don't pass Extensible pointer to Private constructorLaurent Pinchart
The Extensible and Extensible::Private classes contain pointers to each other. These pointers are initialized in the respective class's constructor, by passing a pointer to the other class to each constructor. This particular construct reduces the flexibility of the Extensible pattern, as the Private class instance has to be allocated and constructed in the members initializer list of the Extensible class's constructor. It is thus impossible to perform any operation on the Private class between its construction and the construction of the Extensible class, or to subclass the Private class without subclassing the Extensible class. To make the design pattern more flexible, don't pass the pointer to the Extensible class to the Private class's constructor, but initialize the pointer manually in the Extensible class's constructor. This requires a const_cast as the o_ member of the Private class is const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-07-11libcamera: buffer: Rename buffer.h to framebuffer.hLaurent Pinchart
libcamera names header files based on the classes they define. The buffer.h file is an exception. Rename it to framebuffer.h. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-06-28android: mm: cros_camera_buffer: Drop undefined functionsLaurent Pinchart
The CameraBuffer::Private::planeAddr() functions are declared but not defined (and of course not used). Drop them. Fixes: d8d6a78f223e ("android: Introduce Chromium OS buffer manager") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-06-25libcamera/base: Move extended base functionalityKieran Bingham
Move the functionality for the following components to the new base support library: - BoundMethod - EventDispatcher - EventDispatcherPoll - Log - Message - Object - Signal - Semaphore - Thread - Timer While it would be preferable to see these split to move one component per commit, these components are all interdependent upon each other, which leaves us with one big change performing the move for all of them. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-06-25android: mm: cros_camera_buffer: Fix wrong indexing in plane()Hirokazu Honda
CameraBuffer::plane() should be accessed in zero based index. Fix the wrong indexing in CameraBuffer::plane() in cros_camera_buffer.cpp. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2021-06-01android: Fix unused parameter warnings on Chrome OSLaurent Pinchart
The Chrome OS-specific code has multiple function parameters that are not used. This results in compilation warnings. Fix them with [[maybe_unused]]. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-05-31android: Don't rely on indirect inclusion of unistd.hLaurent Pinchart
The standard C library close() and lseek() functions require inclusion of the unistd.h header. Include it explicitly where needed instead of relying on indirect inclusion. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-05src: android: Rectify internal header's #include pathUmang Jain
libcamera internal headers are not installed system-wide. Hence, any inclusion of internal headers should follow the #include directive form: #include "libcamera/internal/header.h" This was not the case for a few of the class in android HAL. Fix them. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-04-04android: mm: cros: Fix compilationLaurent Pinchart
Commit 7d7879833812 ("android: mm: cros: Handle buffer registration failure") mistakenly tried to initialize the CameraBuffer::Private registered member variable instead of registered_. This reults in a compilation failure. Fix it. Fixes: 7d7879833812 ("android: mm: cros: Handle buffer registration failure") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-04-04android: mm: cros: Handle buffer registration failureHirokazu Honda
cros::CameraBufferManager::Register() fails if a buffer handle is invalid. We should mark CameraBuffer as invalid on the failure of Register(). While the cros::CameraBufferManager Unlock() and Deregister() functions should be able to handle buffers that haven't been locked and registered, this isn't an API guarantee, and errors will be logged. Avoid this by skipping unlocking and unregistration of buffers that haven't been locked or registered. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-03android: Introduce Chromium OS buffer managerJacopo Mondi
Introduce the CameraBuffer backend for the Chromium OS operating system and the associated meson option. The Chromium OS CameraBuffer implementation uses the cros::CameraBufferManager class to perform mapping of 1 plane and multiplane buffers and to retrieve size information. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: mm: Provide helper macro for PIMPLJacopo Mondi
Each memory backend has to declare a CameraBuffer class implementation that bridges the API calls to each CameraBuffer::Private implementation. As the code is likely the same for most (if not all) backends, provide a convenience macro that expands to the CameraBuffer class declaration. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: camera_buffer: Add method to get the JPEG blob sizeJacopo Mondi
To maintain compatibility with platforms that do not provide a memory backend implementation add a method to be return the size of the buffer used for JPEG encoding capped to a maximum size. Platforms that implement a memory backend will always calculate the correct buffer size. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: post_processor: Use CameraBuffer APIJacopo Mondi
Use the newly introduced CameraBuffer class as the type for the destination buffer in the PostProcessor class hierarchy in place of the libcamera::MappedFrameBuffer one and use its API to retrieve the length and the location of the CameraBuffer plane allocated for JPEG post-processing. Remove all the assumption on the underlying memory storage and only go through the CameraBuffer API when dealing with memory buffers. To do so rework the Encoder interface to use a raw pointer and an explicit size to remove access to the Span<uint8_t> maps that serve as memory storage for the current implementation but might not be ideal for other memory backend. Now that the whole PostProcessor hierarchy has been converted to use the CameraBuffer API remove libcamera::MappedBuffer as base class of the CameraBuffer interface and only reply on its interface. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: camera_buffer: Implement libcamera::ExtensibleJacopo Mondi
In order to prepare to support more memory backends, make the CameraBuffer class implement the PIMPL (pointer-to-implementation) pattern by inheriting from the libcamera::Extensible class. Temporary maintain libcamera::MappedBuffer as the CameraBuffer base class to maintain compatibility of the CameraStream::process() interface that requires a MappedBuffer * as second argument and will be converted to use a CameraBuffer in the next patch. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: camera_buffer: Drop 'const' from buffer_handle_tJacopo Mondi
The buffer_handle_t type is defined as 'const native_handle_t*'. Drop the 'const' specifier from the parameter of the CameraBuffer class constructor and in the Android generic memory backend. Also rename 'camera3buffer' in 'camera3Buffer' to comply with the coding style guidelines. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: Introduce CameraBuffer interfaceJacopo Mondi
In order to provide support for different memory backends, move the MappedCamera3Buffer class definition outside of the CameraDevice class to its own file and rename it in CameraBuffer. The interface defined in camera_buffer.h will be implemented by different backends that will be placed in the src/android/mm subdirectory. Provide a first implementation for the 'generic android' backend which matches the existing one. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>