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>
The ChromeOS specific Android HAL support was overly-complex to support
linking an additional library, and then passing the built object into
the libcamera.so build.
Now that it has its own distinct libcamera-hal.so, simplify the CrOS
integration to build directly into that library.
The removal of the -Wno-shadow here is intentional, as it is not
required for compilation of the camera3_hal.o object.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The camera_device.cpp has grown a little too much, and it has quickly
become hard to maintain. Break out the handling of the static
information collected at camera initialization time to a new
CameraCapabilities class.
Break out from the camera_device.cpp file all the functions related to:
- Initialization of supported stream configurations
- Initialization of static metadata
- Initialization of request templates
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
HAL_PIXEL_FORMAT_RAW_OPAQUE is requested only for
Zero-Shutter-Lag (ZSL). ZSL requires RAW and YUV reprocessing.
Since either of them is not supported by libcamera, supporting
RAW_OPAQUE format doesn't make sense. Drop the format from the
supported format list.
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>
Report to the Android camera stack the list of supported test
pattern modes constructed by inspecting the values reported
by libcamera through the controls::draft::TestPatternMode control.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Implement the flush() camera operation in the CameraDevice class
and make it available to the camera framework by implementing the
operation wrapper in camera_ops.cpp.
Introduce a new camera state State::Flushing to handle concurrent
flush() and process_capture_request() calls.
As flush() can race with processCaptureRequest() protect it
by introducing a new State::Flushing state that
processCaptureRequest() inspects before queuing the Request to the
Camera. If flush() is in progress while processCaptureRequest() is
called, return the current Request immediately in error state. If
flush() has completed and a new call to processCaptureRequest() is
made just after, start the camera again before queuing the request.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
With the introduction of an additional mutex class member, the name of
the existing one is too generic.
Rename CameraDevice::mutex_ in CameraDevice::descriptorsMutex_ and use the
libcamera provided libcamera::Mutex type to align the style with the
rest of the code base.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Guard access to the camera state and the start/stop sequences
with a mutex.
Currently only stop() and the first call to processCaptureRequest()
start and stop the camera, and they're not meant to race with each
other. With the introduction of flush() the camera can be stopped
concurrently to a processCaptureRequest() call, hence access to the
camera state will need to be protected.
Prepare for that by guarding the existing paths with a mutex.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The CameraDevice class uses std::scoped_lock<> to guard access to the
class' descriptors_ member.
std::scoped_lock<> provides a set of features that guarantees safety
when locking multiple mutexes in a critical section, while for single
locks happening in a scoped block it does not provides benefits compared
to the simplest std::unique_lock<> which libcamera provides the
MutexLocker type for.
Replace usage of std::scoped_lock<> with libcamera::MutexLocker to make
the implementation consistent with the rest of the code base.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The CameraDevice class maintains the camera state in the 'running_'
boolean flag to check if the camera has to be started at the first
received process_capture_request() call which happens after the camera
had been stopped.
So far this was correct, as the operations that change the camera
could only start or stop the camera, so a simple boolean flag
was enough.
To prepare to handle the flush() operation that will introduce a new
'flushing' state, replace the simple plain boolean flag with an
enumeration of values that define the CameraState.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The current implementation of CameraDevice::requestComplete() which
handles event notification and calls the framework capture result
callback does not handle error notification precisely enough.
In detail:
- Error notification is an asynchronous callback that has to be notified
to the framework as soon as an error condition is detected, and it
independent from the process_capture_result() callback
- Error notification requires the HAL to report the precise error cause,
by specifying the correct CAMERA3_MSG_ERROR_* error code.
The current implementation only notifies errors of type
CAMERA3_MSG_ERROR_REQUEST at the end of the procedure, before the
callback invocation.
Rework the procedure to:
- Notify CAMERA3_MSG_ERROR_DEVICE and perform library tear-down in case
a Fatal error is detected
- Notify CAMERA3_MSG_ERROR_REQUEST if the libcamera::Request::status is
different than RequestCompleted and immediately call
process_capture_result() with all buffers in error state.
- Notify the shutter event as soon as possible
- Notify CAMERA3_MSG_ERROR_RESULT in case the metadata cannot be
generated correctly and call process_capture_result() with the right
buffer state regardless of metadata availability.
- Notify CAMERA3_MSG_ERROR_BUFFER for buffers whose post-processing
failed
While at it, return the CameraStream buffer by calling
cameraStream->putBuffer() regardless of the post-processing result.
No regression detected when running CTS in LIMITED mode.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Report ANDROID_SENSOR_FRAME_DURATION as an available result key for CTS
to read out the value of frame duration we set in
CameraDevice::getResultMetadata(). Failing to do so might fail the CTS
test:
- android.hardware.camera2.cts.CaptureRequestTest#testNoiseReductionModeControl
Fixes: 3beb1accac ("android: camera_device: Fix sensor frame duration")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
We need a separate control to report the nominal frame duration, but
it's also useful to report the min/max frame duration values that will
be used. Split the FrameDurations control into FrameDuration and
FrameDurationLimits respectively to support both of these.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Originally CameraHalManager is created in the libcamera start up
and destroyed in the libcamera termination. However,
CameraHalManager destructor can access other static objects that
has been destroyed.
Avoid this issue by destroying CameraHalManager when tear_down() is
called in ChromeOS or leaking it in other platforms.
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>
On gcc versions older than 9, the file system library, used by the
Android camera HAL configuration file parser, is implemented in a
separate static library. Furthermore, on gcc 7, it's provided in the
std::experimental namespace. This breaks compilation of the HAL on gcc
7, and linking on gcc 8.
Fix the compilation issue by conditionally including
<experimental/filesystem> and creating a namespace alias in std, and the
link issue by linking to libstdc++fs on gcc versions older than 9.
The inclusion of <experimental/filesystem> is a bit of a hack, and when
we'll start using the file system library in another compilation unit,
we should then move all this to an internal helper to abstract the
compiler version.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add utility functions to CameraMetadata to check if it has been resized,
and for outputting the actual entry and data count. This is meant to be
used to output information on resizing, to assist developers in
choosing proper initial sizes to avoid resizing. Also make CameraDevice
use these functions for static and result metadata.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Open the HAL configuration file in the Camera HAL manager and get
the camera properties for each created CameraDevice and initialize it
with them.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
The HAL layer was getting the min and max frame durations from the
camera, then rounding it to fps to report as available fps ranges. The
same min and max frame durations were then being reported as min and max
frame durations. Since the fps are integer values while the frame
durations are in ns, this caused a rounding error making it seem like we
were reporting an available max fps that was higher than what was
allowed by the minimum frame duration.
An example is if the minimum frame duration is reported as 33366700ns.
The HAL layer would then convert it to fps, which is 29.97, but it would
be rounded and reported as 30 fps. When 30 fps is converted to a frame
duration it is 33333333ns, which is less than the minimum frame duration
that we report. Thus the minimum frame duration that we report
contradicts the fps range that we report.
Fix this by recalculating the frame durations based on the rounded fps
values.
This allows the following CTS test to pass:
- android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
When stopping the camera worker, queuedRequest() calls may have queued
asynchronous function invocation messages to the worker thread, and some
of those messages may not have been processed yet. The messages will
stay in the thread's queue until the camera worker is restarted (when
the camera service will start a new capture session). At that point,
they will be dispatched, which will cause a crash due to the
CaptureRequest passed to processRequest() having been deleted by
CameraDevice::stop() calling descriptors_.clear().
Fix this by forcing dispatching of all function invocation messages when
stopping the camera worker thread. Note that this is inherently racy, as
more queueRequest() calls may arrive from the camera service while we're
stopping. This race condition will be addressed by a subsequent patch
series.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The CameraMetadata::updateEntry() functions cast the data pointer to a
void pointer, which is then used internally to call
update_camera_metadata_entry(). If the caller passes a pointer to an
incorrect data type, the behaviour is undefined, with possible crashes
if the incorrect data type is smaller than expected by the Android
metadata library.
To avoid crashes, make all public updateEntry() functions take typed
pointers, and pass the element size to the internal function. The
element size is then checked against the expected size, and an error
message logged if they don't match. This won't catch incorrect data
types that have the same size as the correct type, but will at least
avoid potential crashes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Previously we had to manually declare the size of CameraMetadata on
allocation, and its count could not be changed after construction.
Change CameraMetadata's behavior so that the user can simply add or
update entries, and the CameraMetadata will auto-resize (double the
size) as necessary. Also remove everything involved with calculating
the initial size for any CameraMetadata instances.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Calculate the value of the ANDROID_SENSOR_INFO_PHYSICAL_SIZE property
multiplying the number of sensor's readable pixels with the pixel unit
cell size if provided by the Camera.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Use the controls::SensorTimestamp value to populate
ANDROID_SENSOR_TIMESTAMP result metadata.
The Camera is assumed to provide the control in the Request metadata.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
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>
The LIBCAMERA_DECLARE_PRIVATE() macro, used by the library classes
that inherit from libcamera::Extensible in order to implement the
PIMPL pattern, expands to:
public: \
class Private; \
friend class Private;
The 'klass' argument is not used and it might confuse developers as
it might hint that the class that defines the pattern's implementation
can be freely named, while it is actually hardcoded to 'Private'.
Drop the argument from the macro definition.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hanlin Chen <hanlinchen@google.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
CameraDevice creates Camera3RequestDescriptor in
processCaptureRequest() and disallocates in requestComplete().
Camera3RequestDescriptor can never be destroyed if
requestComplete() is never called. This avoid the memory
leakage by storing them in map CameraRequestDescriptor.
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>
This adds CameraDevice::stop(), which cleans up the member
variables of CameraDevice. It is called in CameraDevice::close()
and CameraDevice::configureStreams().
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>
libcamera doesn't handle crop_rotate_scale_degrees. Therefore,
if it is requested, that is, crop_rotate_scale_degrees is not
CAMERA3_STREAM_ROTATION_0, the configuration should fail.
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>
libcamera doesn't handle |crop_rotate_scale_degrees| in
camera3_stream at all. This adds the validation of the requested
|crop_rotate_scale_degrees| in configuration, but still not
handle the specified values.
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>
Android Camera HAL 3 API used in ChromeOS has a ChromeOS own
extension, for example, crop_rotate_scale_degrees in
camera3_stream. As those extensions are not available on Android
platforms, introduce a OS_CHROMEOS macro that can be used to
compile CrOS-specific code conditionally. The macro is defined
if and only if android_platform is 'cros'.
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>
