| Age | Commit message (Collapse) | Author |
|---|
|
processCaptureRequest()
Add a check on processCaptureRequest() if a given capture
request contains a camera stream that has been configured.
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>
|
|
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 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>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
CameraDevice::getResultMetadata() doesn't change either
|descriptor| and member variables. It should be marked as a
const function and |descriptor| should be passed with const
lvalue reference.
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>
|
|
CameraMetadata stored in requestTemplates_ in CameraDevice is
not necessary to be a raw pointer. This reduces the manual
new/delete code by changing the type to std::unique_ptr.
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>
|
|
staticMetadata_ in CameraDevice is not necessary to be a raw
pointer. This reduces the manual new/delete code by changing the
type to std::unique_ptr.
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>
|
|
Camera3RequestDescriptor has a length and an allocated buffer
for camera_stream_buffer_t array. This replaces the variables
with std::vector.
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>
|
|
CameraDevice::camera() originally returns shared_ptr. It is
mandatory to make a copy by calling camera() in this way. There
is no need of copying if a caller needs the reference of the
camera like const shared_ptr<Camera> &cam = camera(). That is, it
is a caller that copying is required. This changes the return
type of camera() to const shared_ptr&, so that we are able to
reduce one redundant copy in the above case.
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>
|
|
CameraDevice takes the ownership of Camera. Therefore,
shared_ptr would rather be used than const shared_ptr&.
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>
|
|
CameraDevice is owned by CameraHalManager. The ownership of the
object is not shared with other classes. So CameraHalManager
should manage CameraDevice with std::unique_ptr.
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>
|
|
The capture request template for video recording use cases requires
a fixed FPS range. Generate the request templates for the VIDEO_RECORD
and VIDEO_SNAPSHOT capture intents using the preview template and
updating the supported FPS range.
This change fixes the CTS tests
android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceRecordingTemplate
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The destination buffer for the post-processing component is
currently first mapped in the CameraDevice class and then passed
to CameraStream which simply calls the post-processor interface.
Move the mapping to CameraStream::process() to tie the buffer
mapping to the lifetime of the CameraBuffer instance.
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>
|
|
The settings in an android capture request may be null, in which case
the settings from the most recently submitted capture request should be
used. Cache the request settings to achieve this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
In ChromeOS the camera make and model is saved in
/var/cache/camera/camera.prop. Load and save these values at
construction time, if available.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Handle the SCALER_CROP_REGION control and dynamic metadata by
translating it from the Android format to the associated libcamera
control when processing a request, and the other way around when
handling a request completion.
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>
|
|
When a Camera3RequestDescriptor instance is created to wrap a
camera3_capture_request_t the settings associated with the request
are cloned for later re-use.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The Camera3RequestDescriptor class can access the number of buffers
and the frame number from the camera3_capture_request_t instead of
having the caller passing them to the constructor.
This change allows to access other fields of the capture request, such
as the capture settings.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Report the pipeline depth in the capture results if the pipeline
reports it.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
CameraDevice::toPixelFormat() doesn't change the state of the
CameraDevice. Marks it a const function so that it can be called
in const functions.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Use the postfixed '_' member variable naming style for the
Camera3RequestDescriptor structure, which in turn ensures that variable
shadowing does not occur in the member initializer list of the
constructor.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a CameraWorker class member to the CameraDevice class and
queue capture requests to it to delegate its handling. Start and
stop the CameraWorker when the libcamera::Camera is started or
stopped.
Tie the CaptureRequest lifetime to the Camera3RequestDescriptor's one
by storing it as unique_ptr<> in the descriptor to simplify handling
of request creation and deletion.
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>
|
|
Return the Camera wrapped by the CameraDevice as a shared_ptr.
This will be required to construct the FrameBuffer allocator in
the CameraStream class.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Move the JPEG processing procedure to the individual CameraStream
by augmenting the class with a CameraStream::process() method.
This allows removing the CameraStream::encoder() method.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Pass the android camera3_stream_t, and a libcamera::StreamConfiguration
to identify the source and destination parameters of this stream.
Pass a CameraDevice pointer to the CameraStream constructor to allow
retrieval of the StreamConfiguration associated with the CameraStream.
Also change the format on which the CameraDevice performs checks to
decide if post-processing is required, as the libcamera facing format is
not meaningful anymore, but the Android requested format should be used
instead.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Break CameraStream out of the CameraDevice class.
No functional changes, only the code is moved.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Complete the transformation of CameraStream into a class and provide
a read-only interface that allows to access its parameters but not
modify them at run-time.
No functional changes intended but this change aims to make the code
more robust by enforcing a stricter interface in the CameraStream class.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Make the CameraStream encoder a private unique pointer and require its
initialization at construction time. This ties the encoder lifetime to
the CameraStream it has been created with, allowing to remove the
CameraStream destructor.
This change dis-allow creating a CameraStream and set the Encoder later,
which shall not happen now that we create CameraStream once we have all
the required information in place.
No functional changes intended but this change aims to make the code
more robust enforcing a stricter CameraStream interface.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraDevice::streams_ vector of CameraStream instances is
currently mostly accessed by index. The current implementation
creates all the CameraStream during the first loop that inspects the
camera3_stream instances and then update the index of the
StreamConfiguration associated with the CameraStream during a second
loop that inspects MJPEG streams. A third loop creates the JPEG encoder
associated with camera streams that produce MJPEG format.
As the index-based association is hard to follow and rather fragile,
rework the creation and handling of CameraStream:
1) Make the StreamConfiguration index a constructor parameter and a
private struct member. This disallows the creation of CameraStream
without a StreamConfiguration index assigned.
2) Create CameraStream only after the associated StreamConfiguration
has been identified. The first loop creates CameraStream for non-JPEG
streams, the second for the JPEG ones after having identified the
associated StreamConfiguration. Since we have just created the
CameraStream, create the JPEG encoder at the same time instead of
deferring it.
This change removes all accesses by index to the CameraDevice::streams_
vector.
No functional changes intended, but this change aims to make the code
easier to follow and more robust.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The resolutions supported for the RAW formats cannot be tested from
a list of known sizes like the processed ones. This is mainly due to the
fact RAW streams are produced by capturing frames at the CSI-2 receiver
output and their size corresponds to the sensor's native sizes.
In order to obtain the RAW frame size generate a temporary
CameraConfiguration for the Role::StillCaptureRAW role and inspect the
map of StreamFormats returned by the pipeline handler.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
As the RAW stream sizes needs to be calculated differently from the
processed one, break out the procedure to calculate the processed
(RGB/YUV) resolutions from initializeStreamConfigurations() in order to
prepare for RAW sizes calculation.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a public member function to get the libcamera::Camera pointer
associated with the CameraDevice. This will help to find the CameraDevice
object in CameraHalManager when the hotplug support is extended in the
Android layer.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice needs to be wrapper into the std::shared_ptr instead
of std::unique_ptr to enable refcounting. The refcounting will help
us to support hotplug and hot-unplug CameraHalManager operations
in the subsequent commit.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
MJPEG streams must be created referencing a libcamera stream.
This stream may already be provided by the request configuration,
in which case the existing stream is utilised.
If no compatible stream is available to encode, a new stream is requested
from the libcamera configuration.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Currently the request template returned from
CameraDevice::constructDefaultRequestSettings() is the same for all
the supported template types.
To prepare to adjust the template depending on the use case, break out
the template generation to a dedicated function that supports the
PREVIEW use case. All the other template types use the
requestTemplatePreview() function and just update the capture intent
property.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The request capture templates stored in the
CameraDevice::requestTemplates_ should not be modified once created.
Store a const pointer to the request templates in the class member
map.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The documentation says the HAL_PIXEL_FORMAT_* defines shall be used for
formats instead of ANDROID_SCALER_AVAILABLE_FORMATS_* for the
ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS and
ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS tags.
This have worked in the past as the numerical value of the two sets are
the same for the formats supported.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Construct a FrameBuffer for every buffer given in the camera3Request
and add it to the libcamera Request on the appropriate stream.
The correct stream is obtained from the private data of the camera3_stream
associated with the camera3_buffer.
Comments regarding supporting only one buffer are now removed, and
FrameBuffers have their lifetime tracked in the Camera3RequestDescriptor
to ensure they are released when the Request is completed.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Introduce a vector storing a CameraStream to track and maintain
state between an Android stream (camera3_stream_t) and a libcamera
Stream.
Only the index of the libcamera stream is stored, to facilitate identifying
the correct index for both the StreamConfiguration and Stream vectors.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Move the code which constructs a FrameBuffer from the Android buffer handle
to it's own function to simplify the code flow and readability.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
