| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
