summaryrefslogtreecommitdiff
path: root/src/android
AgeCommit message (Collapse)Author
2021-12-22android: camera_metadata: Add setEntry helperPaul Elder
Add setEntry() helper, that automatically detects if updateEntry() or addEntry() should be used. Note that updateEntry() will fail if the entry was not yet added, and addEntry() will fail is the entry was already added. They are silent failures that cause unexpected values to find their way into the android metadata instance. Previously this helper was not necessary, as (with respect to the current use case) the preview template generator would always add a key so the other template generators that used the preview template as boilerplate could reliably use updateEntry(). The preview template generator will soon decide based on capabilities whether or not to add keys, so the other template generators need a helper to decide whether to use updateEntry() or addEntry(). For now only implement it for enums and arithmetic values, as they will mainly be used in populating templates. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-12-22android: camera_capabilities: Set read sensor settings capabilityPaul Elder
A libcamera camera that supports the manual sensor capability also satisfies all the requirements for the read sensor settings capability. Set it. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-12-22android: camera_capabilities: Add messages for lack of FULL supportPaul Elder
Print messages when some feature is missing that causes hardware level FULL to not be supported. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-12-11android: Remove CameraWorkerJacopo Mondi
The CameraWorker class purpose was to handle acquire fences for incoming capture requests directed to libcamera. Now that fences are handled by the core library, it is not required to handle them in the HAL and the CameraWorker and CaptureRequest classes can be dropped. Update the core in CameraDevice class accordingly to queue Requests directly to the libcamera::Camera and set the release_fence to the value of the FrameBuffer::fence() for streams of type ::Direct. While at it make CameraRequest::StreamBuffer::fence a UniqueFD to ease the management of the fences file descriptor values. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-07android: Apply 1% tolerance to minFrameDuration cappingUmang Jain
We have some stream resolution which can provide slightly better frame duration than what we cap (i.e. 1/30 fps). The problem with this is CTS complains if the camera goes faster during the test than minFrameDuration reported for that resolution. For instance, 1080p minFrameDuration: - Nautilus : 33282000ns - Soraka : 33147000ns Both are less than capped minFrameDuration 1/30 fps (33333333.33ns). This patch considers this situation and doesn't cap the minFrameDuration if the hardware can provide frame durations slightly better. The tolerance considered is 1% only from the cap. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-12-06android: camera_stream: Use PlatformFrameBufferAllocatorHirokazu Honda
CameraStream originally creates FrameBuffers by FrameBufferAllocator and thus buffers are allocated in V4L2 API. This replaces the allocator in CameraStream with PlatformFrameBufferAllocator. It allocates a buffer in a platform dependent graphic buffer allocation API. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-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-12-04libcamera: base: Rename FileDescriptor to SharedFDLaurent Pinchart
Now that we have a UniqueFD class, the name FileDescriptor is ambiguous. Rename it to SharedFD. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-12-01android: camera_request: Add thread safety annotationHirokazu Honda
This applies clang thread safety annotation to Camera3RequestDescriptor. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: camera_device: Add thread safety annotationHirokazu Honda
This applies clang thread safety annotation to CameraDevice. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: camera_device: Fix variables access without protectionHirokazu Honda
This fixes the code accessing descriptors and Camera3RequestDescriptor::pendingStreamsToProcess_ without holding descriptorsMutex_ and Camera3RequestDescriptor::streamProcessMutex_ in CameraDevice. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: camera_stream: Add thread safety annotationHirokazu Honda
This applies clang thread safety annotation to CameraStream. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: camera_stream: Protect buffers initialization by mutex_Hirokazu Honda
The initialization on buffers_ in CameraStrean::configure() is not protected by mutex_. It is no problem because configure() is not invoked simultaneously while other functions are called. This protects it to keep the thread safety consistency for buffers access. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: camera_hal_manager: Add thread safety annotationHirokazu Honda
This applies clang thread safety annotation to CameraHalManager. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01libcamera: Correct include headers for Mutex classesHirokazu Honda
Mutex classes are defined in mutex.h. This replaces thread.h include for the Mutex classes with mutex.h. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01android: Consolidate mutex classes to Mutex and MutexLockerHirokazu Honda
std::mutex and std::unique_lock are used in android directories, mixing Mutex and MutexLocker. This consolidates them to Mutex and MutexLocker. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-01libcamera: base: Introduce ConditionVariableHirokazu Honda
ConditionVariable is alias to std::condition_variable. This replaces std::condition_variable with the ConditionVariable. It enables replacing ConditionVariable implementation easily in the following patches. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-11-30android: camera_device: Provide toString() helper for stream_typeUmang Jain
Provide a directionToString() helper to return a human-friendly name for camera3_stream_t->stream_type. Replace the int value being printed in configureStreams() INFO log with directionToString(). Signed-off-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> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-11-24android: Convert to pragma onceKieran Bingham
Remove the verbose #ifndef/#define/#endif pattern for maintaining header idempotency, and replace it with a simple #pragma once. This simplifies the headers, and prevents redundant changes when header files get moved. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-11-08android: Camera3RequestDescriptor: Provide a constructor for StreamBufferUmang Jain
Provide a constructor for StreamBuffer and use that while populating Camera3RequestDescriptor::buffers_ vector. Also provide the default move-constructor (required as StreamBuffer is stored in a vector in Camera3RequestDescriptor) and destructor for the StreamBuffer struct. Also declare a default move assignment operator and disable the copy constructor and move operator explicitly with LIBCAMERA_DISABLE_COPY(). While at it, initialize pointers members in the StreamBuffer struct to nullptr, with StreamBuffer::status set to Status::Success by default. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-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-10-26android: post_processor: Make post processing asyncUmang Jain
Introduce a dedicated worker class derived from libcamera::Thread. The worker class maintains a queue for post-processing requests and waits for a post-processing request to become available. It will process them as per FIFO before de-queuing it from the queue. The entire post-processing handling iteration is locked under streamsProcessMutex_ which helps us to queue all the post-processing request at once, before any of the post-processing completion slot (streamProcessingComplete()) is allowed to run for post-processing requests completing in parallel. This helps us to manage both synchronous and asynchronous errors encountered during the entire post processing operation. Since a post-processing operation can even complete after CameraDevice::requestComplete() has returned, we need to check and complete the descriptor from streamProcessingComplete() running in the PostProcessorWorker's thread. This patch also implements a flush() for the PostProcessorWorker class which is responsible to purge post-processing requests queued up while a camera is stopping/flushing. It is hooked with CameraStream::flush(), which isn't used currently but will be used when we handle flush/stop scenarios in greater detail subsequently (in a different patchset). The libcamera request completion handler CameraDevice::requestComplete() assumes that the request that has just completed is at the front of the queue. Now that the post-processor runs asynchronously, this isn't true anymore, a request being post-processed will stay in the queue and a new libcamera request may complete. Remove that assumption, and use the request cookie to obtain the Camera3RequestDescriptor. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-26android: post_processor: Drop return value for process()Umang Jain
PostProcessor::process() is invoked by CameraStream class in case any post-processing is required for the camera stream. The failure or success is checked via the value returned by CameraStream::process(). Now that the post-processor notifies about the post-processing completion operation, we can drop the return value of PostProcessor::process(). The status of post-processing is passed to CameraDevice::streamProcessingComplete() by the PostProcessor::processComplete signal's slot. 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-10-26android: Track and notify post processing of streamsUmang Jain
Notify that the post processing for a request has been completed, via a signal. The signal is emitted with a context pointer along with status of the buffer. The function CameraDevice::streamProcessingComplete() will finally set the status on the request descriptor and complete the descriptor if all the streams requiring post processing are completed. If buffer status obtained is in error state, notify the status to the framework and set the overall error status on the descriptor via setBufferStatus(). We need to track the number of streams requiring post-processing per Camera3RequestDescriptor (i.e. per capture request). Introduce a std::map to track the post-processing of streams. The nodes are dropped from the map when a particular stream post processing is completed (or on error paths). A std::map is selected for tracking post-processing requests, since we will move post-processing to be asynchronous in subsequent commits. A vector or queue will not be suitable as the sequential order of post-processing completion of various requests won't be guaranteed then. A streamsProcessMutex_ has been introduced here as well, which will be applicable to guard access to descriptor's pendingStreamsToProcess_ when post-processing is moved to be asynchronous in subsequent commits. 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-10-26android: post_processor: Consolidate contextual informationUmang Jain
Save and provide the context for post-processor of a camera stream via Camera3RequestDescriptor::StreamBuffer. We extend the structure to include source and destination buffers for the post processor, along with CameraStream::Type::Internal buffer pointer (if any). In addition to that, a back pointer to Camera3RequestDescriptor is convenient to get access to overall descriptor (status, metadata settings etc.). Also, migrate CameraStream::process() and PostProcessor::process() signature to use Camera3RequestDescriptor::StreamBuffer only. This will be helpful when we move to async post-processing in subsequent commits. 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-10-26android: camera_device: Refactor descriptor status and sendCaptureResults()Umang Jain
Currently, we use Camera3RequestDescriptor::Status to determine: - When the descriptor has been completely processed by HAL - Whether any errors were encountered, during its processing Both of these are essential to know whether the descriptor is eligible to call process_capture_results() through sendCaptureResults(). When a status(Success/Error) is set on the descriptor, it is ready to be sent back via sendCaptureResults(). However, this might lead to undesired results especially when sendCaptureResults() runs in a different thread (for e.g. stream's post-processor async completion slot). This patch decouples the descriptor status (Success/Error) from the descriptor's completion status (pending or complete). The advantage of this is we can set the completion status when the descriptor has been processed fully by the layer and we can set the error status on the descriptor wherever an error is encountered, throughout the lifetime of the descriptor in the HAL layer. While at it, introduce a wrapper completeDescriptor() around sendCaptureResults(). completeDescriptor() as the name suggests will mark the descriptor as complete, so it is ready to be sent back. The locking mechanism is moved from sendCaptureResults() to this wrapper since the intention is to use completeDescriptor() in place of existing sendCaptureResults() calls. Also make sure the sequence of abortRequest() call happens in the same order at all places i.e. after its added to the descriptors_ queue. Fix one of the abortRequest() call accordingly. 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-10-26android: post_processor_jpeg: Replace encoder_ nullptr checkUmang Jain
Instead of simply returning if encoder_ is nullptr, fail hard via an assertion. It is quite unlikely that encoder_ could only be null as a result of a fatal bug in the code, so be loud about the failure. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-26android: camera_stream: Replace post-processor nullptr checkUmang Jain
Instead of checking postProcessor for nullptr, replace this check with an assertion that checks if the camera stream's type is not Type::Direct. Since it makes no sense to call CameraStream::process() on a Type::Direct camera stream. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-21android: camera_device: Cleanup header includesLaurent Pinchart
camera_device.cpp doesn't use the PostProcessor class, the post_processor.h header shouldn't be included. Removing it causes a compilation failure as the CameraBuffer class is not defined anymore, include camera_buffer.h instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-19android: camera_metadata: Rename get() to getMetadata()Umang Jain
Rename CameraMetadata::get() to CameraMetadata::getMetadata() to avoid confusion with std::unique_ptr::get() when CameraMetadata is used with a std::unique_ptr. No functional changes intended in this patch. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_stream: Define explicit move constructor and destructorsLaurent Pinchart
There's no need for the move constructor and the destructor to be inline. Define them explicitly, with default implementations. This allows usage of the CameraStream class without a complete definition of the PostProcessor class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_stream: Don't close fence if wait failsLaurent Pinchart
The camera HAL APIs requires that any acquire fence that hasn't been waited on to be sent back to the framework as a release fence. The CameraDevice already copies the acquire fence to the release fence when signaling request completion, but the CameraStream incorrectly closes the fence when a wait fails and sets it to -1. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_request: Don't embed full camera3_stream_buffer_tLaurent Pinchart
The camera3_stream_buffer_t structure is meant to communicate between the camera service and the HAL. They are short-live structures that don't outlive the .process_capture_request() operation (when queuing requests) or the .process_capture_result() callback. We currently store copies of the camera3_stream_buffer_t passed to .process_capture_request() in Camera3RequestDescriptor::StreamBuffer to store the structure members that the HAL need, and reuse them when calling the .process_capture_result() callback. This is conceptually not right, as the camera3_stream_buffer_t pass to the callback are not the same objects as the ones received in .process_capture_request(). Store individual fields of the camera3_stream_buffer_t in StreamBuffer instead of copying the whole structure. This gives the HAL full control of how data is stored, and properly decouples request queueing from result reporting. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-10-19android: camera_device: Use abortRequest() instead of open-coding itLaurent Pinchart
Call abortRequest() in CameraDevice::requestComplete() instead of open-coding it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_stream: Return non-const pointer from camera3Stream()Laurent Pinchart
The camera3_stream_t instances are used to interact with the camera service, whose API uses non-const pointers. Replace the const reference returned by CameraStream::camera3Stream() with a non-const pointer. It turns out that nobody calls this function, but new users will be introduced in subsequent commits. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_stream: Pass StreamBuffer to process()Laurent Pinchart
Now that we have a proper structure to model a stream buffer, pass it to CameraStream::process() instead of the camera3_stream_buffer_t. This will allow accessing other members of StreamBuffer in subsequent commits. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19android: camera_device: Create struct to track per stream bufferUmang Jain
The Camera3RequestDescriptor structure stores, for each stream, the camera3_stream_buffer_t and the libcamera FrameBuffer in two separate vectors. This complicates buffer handling, as the code needs to keep both vectors in sync. Create a new structure to group all data about per-stream buffers to simplify this. As a side effect, we need to create a local vector of camera3_stream_buffer_t in CameraDevice::sendCaptureResults() as the camera3_stream_buffer_t instances stored in the new structure in Camera3RequestDescriptor are not contiguous anymore. This is a small price to pay for easier handling of buffers, and will be refactored in subsequent commits anyway. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-19android: camera_stream: Plumb process() with Camera3RequestDescriptorUmang Jain
Data (or broader context) required for post processing of a camera request is saved via Camera3RequestDescriptor. Instead of passing individual arguments to CameraStream::process(), pass the Camera3RequestDescriptor pointer to it. All the arguments necessary to run the post-processor can be accessed from the descriptor. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-19android: camera_device: Build capture_result dynamicallyLaurent Pinchart
The camera3_capture_result_t is only needed to convey capture results to the camera service through the process_capture_result() callback. There's no need to store it in the Camera3RequestDescriptor. Build it dynamically in CameraDevice::sendCaptureResults() instead. This requires storing the result metadata created in CameraDevice::requestComplete() in the Camera3RequestDescriptor. A side effect of this change is that the request metadata lifetime will match the Camera3RequestDescriptor instead of being destroyed at the end of requestComplete(). This will be needed to support asynchronous post-processing, where the request completion will be signaled to the camera service asynchronously from requestComplete(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-10-19android: camera_request: Turn struct into a classLaurent Pinchart
The Camera3RequestDescriptor structure is growing into an object with member functions. Turn it into a class, uninline the destructor to reduce code size, explicitly disable copy as requests are not copyable, and delete the default constructor to force all instances to be fully constructed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19camera_device: Remove private scope of Camera3RequestDescriptorUmang Jain
Camera3RequestDescriptor is a utility structure that groups information about a capture request. It can be and will be extended to preserve the context of a capture overall. Since the context of a capture needs to be shared among other classes (for e.g. CameraStream) having a private definition of the struct in CameraDevice class doesn't help. Hence, de-scope the structure so that it can be shared with other components (through references or pointers). Splitting the structure to a separate file will help avoiding circular dependencies when using it through the HAL implementation. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-19android: Re-order out-of-order completion pathJacopo Mondi
When the camera HAL detects an out-of-order completion of a request, it sends to the camera framework a CAMERA3_MSG_ERROR_DEVICE error. Such error not only forces the service to close the camera as prescribed by the camera3 specification, but in some implementation (specifically the ChromeOS one) it causes the camera service to abort and exit. This prevents any error messages from being printed by libcamera, as the library gets terminated before getting to that point, and also hides the printout of error messages that lead to out-of-order completion, making it impossible to get from the output log what happened. Move the call to notifyError() at the end of the error path and demote the error message to LogLevels::Error from Fatal to let the service implementation decide how to handle CAMERA3_MSG_ERROR_DEVICE errors. Before this patch, when waiting on a fence fails and the capture request is not queued to the Camera, we get an out-of-order completion but no backtrace. With this patch applied the error path is visible: ERROR HAL camera_worker.cpp:122 Failed waiting for fence: 82: Timer expired ERROR HAL camera_device.cpp:1110 '\_SB_.PCI0.I2C2.CAM0': Out-of-order completion for request 0x00007e6de4004c70 Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19Revert "android: camera_device: Configure one stream for identical stream ↵Jacopo Mondi
requests" Commit d165f7da34b8 ("android: camera_device: Configure one stream for identical stream requests") introduced the ability to generate through post-processing YUV streams of identical size and format. However the change didn't fully take into account the situation where only mapped streams are contained in the request submitted by the camera service to the HAL. In this case the Request will be queued with no buffers and refused by the Camera. Even if this seems a corner case it causes a few CTS to fail, and more problematically it triggers out-of-order completion of requests, causing the camera service to abort. ERROR Camera camera.cpp:1031 Request contains no buffers ERROR HAL camera_device.cpp:1109 '\_SB_.PCI0.I2C2.CAM0': Out-of-order completion for request 0x00007a1f1800ccd0 ERROR cros_camera_service[15706:15711]: [camera_device_adapter.cc(744)] (15711) Notify(): Fatal device error; aborting the camera service Revert the commit until a proper solution is implemented. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-15android: capabilities: Cap frame rate to 30 FPSJacopo Mondi
Limit the reported minumum frame duration to 30 FPS. The reason to do is to bring the libcamra HAL in par with the Intel HAL implementation on IPU3 platform, where 30FPS is the frame rate used to perform quality tuning in the closed-source IPA module and has been validated as the most efficient rate for the power/performace budget. This change bring into the HAL a platform specific constraints, which might be opportune for most platforms but should rather be configurable by system integrators. Record that with a \todo entry. Also record that, even if we report a lower frame rate, we currently do not limit what the camera actually produce. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-15android: capabilties: Fix ANDROID_CONTROL_AE_AVAILABLE_TARGET_FPS_RANGESJacopo Mondi
As reported by the CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES documentation in the Android developer reference: "For devices advertising any color filter arrangement other than NIR, or devices not advertising color filter arrangement, this list will always include (min, max) and (max, max) where min <= 15 and max = the maximum output frame rate of the maximum YUV_420_888 output size." Collect the higher FPS of the larger YUV stream and use it with the minimum FPS rate the camera can produce to populate the ANDROID_CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES static metadata. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: Populate streams and duration in the same loopJacopo Mondi
The ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS and ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS static metadata are populated by looping on the streamConfigurations_ vector. Unify them in a single loop to avoid repeating it. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: capabilities: Print output stream listJacopo Mondi
Add a debug statement to print out the list of collected output stream and their characteristics. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: Filter preview streams on FPSJacopo Mondi
Register as preview streams only streams capable of producing at least 30 FPS. This requirement comes from inspecting the existing HAL implementation on Intel IPU3 platform and from inspecting the CTS RecordingTests results. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: capabilities: Collect absolute max frame durationsJacopo Mondi
While building the list of supported stream configurations also collect the absolute max frame durations to be used to populate the sensor maximum frame duration. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: capabilties: Correctly populate STALL durationsJacopo Mondi
We currently hardcode 2560x1920@30FPS as the only stalling frame duration. This is of course not correct, and all the required information to properly populate the ANDROID_SCALER_AVAILABLE_STALL_DURATIONS static metadata are available from initializeStaticMetadata(). Use the collected stalling durations and sizes to properly popoulate the static property. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>