| Age | Commit message (Collapse) | Author |
|---|
|
The libcamera Android Camera HAL generates camera configurations for the
StillCapture, Raw and ViewFinder stream roles. But there is only a check
if the configuration generation failed, for the StillCapture stream role.
This could lead to a NULL pointer dereference if a pipeline handler fails
to generate a default configuration for one of the other two stream roles.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
Creating a CameraBuffer instance doesn't map memory. Fix the error
message accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
CameraStream always sets the format of processor output buffer to
MJPEG. This fixes the issue.
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: Umang Jain <umang.jain@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>
|
|
Generation of thumbnail is not occuring currently because
ANDROID_JPEG_THUMBNAIL_SIZE is not set for request metadata passed
to PostProcessorJpeg::process(). The commit 1264628d3c92("android:
jpeg: Configure thumbnailer based on request metadata") introduced
the mechanism to retrieve the thumbanil size from request metadata,
however it didn't add the counterpart i.e. inserting the size in
the request metadata in request metadata template, at the first place.
The patch fixes this issue by setting ANDROID_JPEG_THUMBNAIL_SIZE in
the request metadata template populated by
CameraCapabilities::requestTemplatePreview(). The value for
ANDROID_JPEG_THUMBNAIL_SIZE is set to be the first non-zero size
reported by static metadata ANDROID_JPEG_AVAILABLE_THUMBNAIL_SIZES.
Fixes: 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
CameraMetadata's constructor take in number of entries and number of
bytes to be allocated for those entries. However, CameraMetadata is
already capable of resizing its container on the fly, in case more
entries are added to it. Hence, the numbers passed in during the
construction acts as hint values for initialization.
Clarify this in CameraCapabilities::requestTemplatePreview() and
remove the \todo, as the arguments and the \todo gives the perspective
that we need to be quite accurate with the numbers of entries / bytes,
which is not the case.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
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>
|
|
CameraStream creates PostProcessor and FrameBufferAllocator in
the constructor. CameraStream assumes that a used post processor
is JPEG post processor. Since we need to support various post
processors, we would rather move the creation to configure() so
as to return an error code if no proper post processor is found.
This also moves FrameBufferAllocator and Mutex creation for
consistency.
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>
|
|
Rectify variable renaming style for YPlaneSize, UVPlaneSize.
libcamera uses camelCase where first letter should be in lower case.
Fixes: e355ca0087cd9("android: jpeg: Split and pass the thumbnail planes to encoder")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
YUV post-processor doesn't need any instance reference from CameraDevice
class. Remove it.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
After multi-planar support was introduced for jpeg encoding as well,
EncoderLibJpeg::encode() expects a vector of planes as the source of
framebuffer to be encoded. Currently, we are passing a contiguous buffer
which is treated as only one plane (instead of two, as thumbnail is NV12).
Hence, split the thumbnail data into respective planes according to NV12.
This fixes a crash in encoding of thumbnails.
Fixes: 894ca69f6043("android: jpeg: Support multi-planar buffers")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Failure can still happen by CameraBufferManager during Unlock() and/or
Deregister() of camera3Buffer handles. We should be logging those
errors as well.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The JPEG post-processor uses MappedFrameBuffer to access pixel data, but
only uses data from the first plane. Pass the vector of planes to the
encode() function to correctly handle multi-planar formats (currently
limited to NV12).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When calculating the luma line address, the image width is used instead
of the stride. Without padding at the end of the line the the values
should be identical, but this is conceptually incorrect in any case. Fix
it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@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>
|
|
Add two helpers functions to the PixelFormatInfo class to compute the
byte size of a given plane, taking the frame size, the stride, the
alignment constraints and the vertical subsampling into account.
Use the new functions through the code base to replace manual
implementations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
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>
|
|
MappedFrameBuffer::maps() returns planes_. This renames the function
name to planes().
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>
|
|
The bufferLength_ member variabled is checked to have a positive value
before being used, to catch usage before the variable is set. The
variable is initialized to zero at construction time, which renders the
checks useless.
Fix this by initializing the variable to -1 at construction time.
Fixes: c5e2ed7806be ("android: camera_buffer: Map buffer in the first plane() call")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
If the camera devices does not support the MANUAL_SENSOR capabilities
there is no point in generating a request template for the Manual
capture use case.
This change fixes CTS tests
android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceManualTemplate
android.hardware.camera2.cts.NativeCameraDeviceTest#testCameraDeviceCreateCaptureRequest
For devices that do not support MANUAL_SENSOR capabilities.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
MappedBuffer::maps()
MappedBuffer::maps() returns std::vector<MappedBuffer::Plane>.
Plane has the address, but the address points the beginning of the
buffer containing the plane.
This makes the Plane point the beginning of the plane. So
MappedBuffer::maps()[i].data() returns the address of i-th 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>
|
|
This adds getter functions of stride, offset and size to CameraBuffer
interface.
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>
|
|
CameraBuffer implementation maps a given buffer_handle_t in
constructor. Mapping is redundant to only know the plane info like
stride and offset. Mapping should be executed later in the first
plane() call.
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>
|
|
buffer_handle_t doesn't provide sufficient info to map a buffer
properly. cros::CameraBufferManager enables handling the buffer on
ChromeOS, but no way is provided for other platforms.
Therefore, we put the assumption that planes are in the same buffer
and they are consecutive. This modifies the way of mapping in
generic_camera_buffer with the assumption.
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>
|
|
The Extensible constructor takes a pointer to a Private instance, whose
lifetime it then manages. Make this explicit in the API by passing the
pointer as a std::unique_ptr<Private>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Remove the need for callers to reference PROT_READ/PROT_WRITE directly
from <sys/mman.h> by instead exposing the Read/Write mapping options as
flags from the MappedFrameBuffer class itself.
While here, introduce the <stdint.h> header which is required for the
uint8_t as part of the Plane.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The MappedFrameBuffer is a convenience feature which sits on top of the
FrameBuffer and facilitates mapping it to CPU accessible memory with
mmap.
This implementation is internal and currently sits in the same internal
files as the internal FrameBuffer, thus exposing those internals to
users of the MappedFramebuffer implementation.
Move the MappedFrameBuffer and MappedBuffer implementation to its own
implementation files, and fix the sources throughout to use that
accordingly.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
cameraBuffer function in private constructor is unused.
Mark it as such.
Fixes: 33dd4fab9d39("libcamera: base: class: Don't pass Extensible pointer to Private constructor")
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
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>
Signed-off-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>
|
|
Nautilus has two in-built cameras, one UVC and one attached to IPU3.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@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>
|
|
Error out on any camera's location if set to "external", in the HAL
configuration file. The HAL configuration file is meant to override the
location property, and overriding an internal camera location to
external doesn't make sense.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Currently CameraDevice wrapper is created first and then HAL config
validity is checked. If the validity checks fail, the code path will
simply return, in which case, creating CameraDevice seems a futile
exercise.
This patch defers the creation of CameraDevice wrapper until the HAL
config validity is checked for internal cameras. This will also enable
us to infer a few things beforehand, by reading the config file before
creating the CameraDevice wrapper.
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>
|
|
The Extensible and Extensible::Private classes contain pointers to each
other. These pointers are initialized in the respective class's
constructor, by passing a pointer to the other class to each
constructor. This particular construct reduces the flexibility of the
Extensible pattern, as the Private class instance has to be allocated
and constructed in the members initializer list of the Extensible
class's constructor. It is thus impossible to perform any operation on
the Private class between its construction and the construction of the
Extensible class, or to subclass the Private class without subclassing
the Extensible class.
To make the design pattern more flexible, don't pass the pointer to the
Extensible class to the Private class's constructor, but initialize the
pointer manually in the Extensible class's constructor. This requires a
const_cast as the o_ member of the Private class is const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a MaxLatency control, and plumb it into the HAL accordingly.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=50
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add skeletal still and manual request templates so that we can expand
them for FULL support.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
We need to be able to add additional characteristics/request/result keys
into the corresponding list in the static metadata based on libcamera
camera capabilities. We also need to be able to easily check if the
lists have specific keys, for populating templates and result metadata.
Turn the characteristics, requests, and results keys vectors into sets,
and move them to member variables to achieve this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add helpers for setting android metadata from libcamera controls.
There are two versions, for scalars and collections, both of which take
a default value to fill in the android control if the libcamera control
is not found. They both return the value that was set.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add the infrastructure for checking and reporting capabilities. Use
these capabilities to determine the hardware level as well.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=55
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
