| Age | Commit message (Collapse) | Author |
|---|
|
As the Android framework sends to the camera device settings
incrementally (only the ones that change are updated), the CameraDevice
class in the Android camera HAL keeps a copy of the last received
settings to be able to apply controls to the libcamera Camera and to
populate metadata correctly.
When a valid 'camera3Request->settings' is provided, it gets saved to
'lastSettings_' but 'descriptor->settings_' is not initialized until
the next frame (assuming it does not contain more settings).
Fix this by assigning to 'descriptor->settings_' the last saved
settings unconditionally.
Signed-off-by: Fang Hui <hui.fang@nxp.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
|
The Android CameraDevice class adds a sourceStream for each Mapped
stream requested by the framework.
When mapping multiple framework streams to the same sourceStream, the
implementation of CameraDevice::processCaptureRequest wrongly erases the
just added sourceStream from the list of streams to request to
libcamera.
Fix this by adding the stream instead of erasing it.
Fixes: 7ea83eba0df6 ("android: camera_device: Postpone mapped streams handling")
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@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>
|
|
Now that the ControlList::get() function returns an instance of
std::optional<>, we can replace the ControlList::contains() calls with a
nullopt check on the return value of get(). This avoids double lookups
of controls through the code base.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Previously, ControlList::get<T>() would use default constructed objects to
indicate that a ControlList does not have the requested Control. This has
several disadvantages: 1) It requires types to be default constructible,
2) it does not differentiate between a default constructed object and an
object that happens to have the same state as a default constructed object.
std::optional<T> additionally stores the information if the object is valid
or not, and therefore is more expressive than a default constructed object.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When a request completes, a debug message is generated to help
identify the request and the number of streams it contains.
The printed number of streams is however the number of output buffers
requested by the camera framework, not the number of streams generated
by libcamera. In facts, some output buffers are generated by
post-processing, and not directly from the camera.
As the debug message prints the libcamera identifier for the Request, it
is more logical to print the number of streams generated by the camera
instead of the total number of streams.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When creating the list of StreamConfiguration to be requested to the camera,
map NV12 streams of equal size and format together, so that they will be
generated by using the YUV post-processor.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Mapped streams are generated by post-processing and always require a
source buffer to process image data from.
In case a Mapped stream is requested but its source stream is not, it
is required to allocate a buffer on the fly and add it to the
libcamera::Request.
Make sure a source stream is available for all mapped streams, and if
that's not the case, add a dedicated buffer to the request for that
purpose.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a sourceStream field to the CameraStream class, meant to contain a
reference to the direct stream which produces actual image data for
streams of type CameraStream::Mapped.
The sourceStream of mapped streams will be used in later patches to make
sure for each Mapped stream at least one libcamera::Stream is queued to
the libcamera::Camera.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
Now that geometry 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>
|
|
Specifically document:
- CameraDevice::sendCaptureResults()
- CameraDevice::completeDescriptor()
- CameraDevice::streamProcessingComplete()
- CameraStream::PostProcessorWorker class
- Camera3RequestDescriptor::StreamBuffer structure
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>
|
|
Increase the initial size of the result metadata, as we will be adding
more entries in the near future.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The problem is happening because we seem to add a CameraStream
associated buffer (depending on the CameraStream::Type) to the Request,
in CameraDevice::processCaptureRequest().
However, when the camera stops, all the current buffers are marked with
FrameMetadata::FrameCancelled and proceed to completion. But the buffer
associated with the CameraStream (that was previously added to the
request) has now been cleared out with a part of streams_.clear(), even
before the camera stop() has been invoked. Any access to those request
buffers after they have been cleared, will result in a crash.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-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: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
There is a possibility that an out-of-order completion of capture
request happens by calling process_capture_result() directly on error
paths. The framework expects that errors should be notified as soon as
possible, but the request completion order should remain intact.
An existing instance of this is abortRequest(), which sends the capture
results on flushing state, without considering order-of-completion.
Since we have a queue of Camera3RequestDescriptor tracking each
capture request placed by framework to libcamera HAL, we should be only
sending back capture results from a single location, by inspecting
the queue. As per the patch, this now happens in
CameraDevice::sendCaptureResults().
Each descriptor is now equipped with its own status to denote whether
the capture request is complete and ready to be send back to the
framework or needs to be waited upon. This ensures that the order of
completion is respected for the requests.
Since we are fixing out-of-order request completion in abortRequest(),
change the function to read from the Camera3RequestDescriptor directly,
instead of camera3_capture_request_t. The descriptor should have all the
information necessary to set the request buffers' state to error.
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>
|
|
abortRequest() and notifyError() do not modify any members of
CameraDevice hence, these functions can be const.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The descriptors_ map holds Camera3RequestDescriptor(s) which are
per-capture requests placed by the framework to libcamera HAL.
CameraDevice::requestComplete() looks for the descriptor for which the
camera request has been completed and removes it from the map.
Since the requests are placed in form of FIFO and the framework expects
the order of completion to be FIFO as well, this calls for a need of
a queue rather than a std::map.
This patch still keeps the same lifetime of Camera3RequestDescriptor as
before i.e. in the requestComplete(). Previously, a descriptor was
extracted from the map and its lifetime was bound to requestComplete().
The lifetime is kept the same by manually calling .pop_front() on the
queue. In the subsequent commit, this is likely to change with a
centralized location of dropping descriptors from the queue for request
completion.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use Camera3RequestDescriptor as cookie for the Capture Request.
The cookie is used to lookup descriptors map in
CameraDevice::requestComplete(). The map will be transformed to a
queue in subsequent commit.
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>
|
|
Acquire fences for streams of type Mapped generated by
post-processing are not correctly handled and are currently
ignored by the camera HAL.
Fix this by adding CameraStream::waitFence(), executed before
starting the post-processing in CameraStream::process().
The change applies to all streams generated by post-processing (Mapped
and Internal) but currently acquire fences of Internal streams are
handled by the camera worker. Postpone that to post-processing time by
passing -1 to the Worker for Internal streams.
Also correct the release_fence handling for failed captures, as the
framework requires the release fences to be set to the acquire fence
value if the acquire fence has not been waited on.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Camera3RequestDescriptor containing the capture request is added to
the descriptors_ map after a call to CameraWorker::queueRequest(). This
is a race condition since CameraWorker::queueRequest() queues requests
to libcamera::Camera asynchronously. The requests may thus complete
before they get added to descriptors_, in which case requestComplete()
will fail to lookup the request in the map.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Returning a non-managed pointer can cause leaks. Use a unique_ptr<>
instead to avoid possible future issues.
The std::move() for the planes argument to the FrameBuffer constructor
is dropped as it's misleading. FrameBuffer has no constructor that takes
an rvalue reference to planes, so the vector was copied despite the
move. This only clarifies the intent, no functional change is
introduced.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
An Android HAL client may request multiple identical streams. It is
redundant that a native camera device produces a separate stream for
each of the identical requests. Configure the camera with a single
stream in that case. The other identical HAL streams will be produced by
the YUV post-processor.
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraStream creates PostProcessorYuv if the destination format
is NV12.
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Now that libcamera correctly supports frame buffers with different
dmabuf for each plane, remove the assumption that a single dmabuf is
used.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
CameraDevice::CreateFrameBuffer() fills the length of the buffer to
each FrameBuffer::Plane::length. It should rather be the length of
plane. This also changes CreateFrameBuffer() to fill offset of
FrameBuffer::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>
|
|
Remove leftover inclusions of the sys/mman header file.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Propagate the requested test pattern mode to libcamera::Camera
through libcamera::Request and also set the android metadata to
the test pattern mode contained by the complete Request.
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: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Currently, all UVC cameras are reported with CameraLocationExternal [1]
by libcamera-core since there is no universal information or standard,
to know the location of these cameras. However, in the libcamera HAL
layer, we can make an informed decision whether it's external or
internal, simply by checking its presence in the HAL configuration
file.
The CameraHalManager will now assign the numerical id of the camera
accordingly when initializing the CameraDevice, based on the camera
facing value set in the HAL config file.
[1] 76809320bb1a ("libcamera: pipeline: uvcvideo: Treat all UVC cameras
as external")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
