| Age | Commit message (Collapse) | Author |
|---|
|
Implement the flush() camera operation in the CameraDevice class
and make it available to the camera framework by implementing the
operation wrapper in camera_ops.cpp.
Introduce a new camera state State::Flushing to handle concurrent
flush() and process_capture_request() calls.
As flush() can race with processCaptureRequest() protect it
by introducing a new State::Flushing state that
processCaptureRequest() inspects before queuing the Request to the
Camera. If flush() is in progress while processCaptureRequest() is
called, return the current Request immediately in error state. If
flush() has completed and a new call to processCaptureRequest() is
made just after, start the camera again before queuing the request.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the introduction of an additional mutex class member, the name of
the existing one is too generic.
Rename CameraDevice::mutex_ in CameraDevice::descriptorsMutex_ and use the
libcamera provided libcamera::Mutex type to align the style with the
rest of the code base.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Guard access to the camera state and the start/stop sequences
with a mutex.
Currently only stop() and the first call to processCaptureRequest()
start and stop the camera, and they're not meant to race with each
other. With the introduction of flush() the camera can be stopped
concurrently to a processCaptureRequest() call, hence access to the
camera state will need to be protected.
Prepare for that by guarding the existing paths with a mutex.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The CameraDevice class uses std::scoped_lock<> to guard access to the
class' descriptors_ member.
std::scoped_lock<> provides a set of features that guarantees safety
when locking multiple mutexes in a critical section, while for single
locks happening in a scoped block it does not provides benefits compared
to the simplest std::unique_lock<> which libcamera provides the
MutexLocker type for.
Replace usage of std::scoped_lock<> with libcamera::MutexLocker to make
the implementation consistent with the rest of the code base.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The CameraDevice class maintains the camera state in the 'running_'
boolean flag to check if the camera has to be started at the first
received process_capture_request() call which happens after the camera
had been stopped.
So far this was correct, as the operations that change the camera
could only start or stop the camera, so a simple boolean flag
was enough.
To prepare to handle the flush() operation that will introduce a new
'flushing' state, replace the simple plain boolean flag with an
enumeration of values that define the CameraState.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Capture requests are queued by the PipelineHandler base class to each
pipeline handler implementation using the virtual queueRequestDevice()
function.
However, if the pipeline handler fails to queue the request to the
hardware, the request gets silently deleted from the list of queued
ones, without notifying application of the error.
Reporting to applications that a Request has failed to queue by
cancelling and then completing it allows applications to maintain their
request-tracking mechanism consistent with the one internal to the library.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a cancel() function to the Request class that allows to forcefully
complete the request and its associated buffers in error state.
Only pending requests can be forcefully cancelled. Enforce that
by asserting the request state to be RequestPending.
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>
|
|
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>
|
|
The IPU3 IPA interface does not define a return value from configure().
This prevents errors from being reported back to the pipeline handler
when they occur in the IPA.
Update the IPU3 IPA interface and add return values to the checks in
IPAIPU3::configure() accordingly
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ipu3_agc.h forward-declares the IPACameraSensorInfo structure, but
incorrectly declares it as a class. This causes a compilation error with
clang:
include/libcamera/ipa/core_ipa_interface.h:24:1: error: 'IPACameraSensorInfo' defined as a struct here but previously declared as a class; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Werror,-Wmismatched-tags]
struct IPACameraSensorInfo
^
../../src/ipa/ipu3/ipu3_agc.h:21:1: note: did you mean struct here?
class IPACameraSensorInfo;
^~~~~
struct
Fix it.
Fixes: 384a53d3cdf7 ("ipa: ipu3: Calculate line duration from IPACameraSensorInfo")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Convert the core AGC and Lux controller code to use
utils::Duration for all exposure time related variables and
calculations.
Convert the exposure/shutter time fields in AgcStatus and DeviceStatus
to use utils::Duration.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch the AgcAlgorithm API functions to use utils::Duration for all
time based variables.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch the ipa and cam_helper code to use libcamera::utils::Duration for
all time based variables. This improves code readability and avoids
possible errors when converting between time bases.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
A new utils::Duration class is defined to represent a std::chrono::duration type
with double precision nanosecond timebase. Using a double minimises the loss of
precision when converting timebases. This helper class may be used by IPAs to
represent variables such as frame durations and exposure times.
An operator << overload is defined to help with displaying utils::Duration value
in stream objects. Currently, this will display the duration value in
microseconds.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Frame duration is hard-coded for CTS as per [1]. Ideally, to accurately
calculate the frame duration, it needs the VBLANK value from every
frame's exposure. However, this particular bit is yet to be implemented
in IPAIPU3.
Meanwhile, we can at least head in the right direction by not hard
coding the value, instead using the default VBLANK value as reported
by the sensor. Update the existing \todo, to use the derived VBLANK
value as and when it's available from each frame exposure.
[1] 6c5f3fe6ced7 ("ipa: ipu3: Set output frame duration metadata")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
IPACameraSensorInfo members will be needed at various places in the
IPAIPU3 class, in subsequent commits. Hence, it seems trivial to copy
this structure for wider availability throughout the class.
This commit does not introduce any functional changes.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Squash \todo by calculating line duration from IPACameraSensorInfo,
now passed in, to IPU3Agc::initialise().
Since line duration is now calculated from real values, store it as a
private member in IPU3Agc class. As a further step, replace the
associated global constant, kMaxExposureTime, with a private IPU3Agc
class member as well, and assign its value correspondingly in
IPU3Agc::initialise(), similar to previous precedence.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@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>
|
|
The return value from generateConfiguration() was not checked. Only assert
was added as a guard which checked if the size of the generated camera
config was equal to size of roles passed to it.
If the roles variable has an invalid/unsupported role, it will return
a nullptr and then trying to access a member on a nullptr for size comparison
will result in a segmentation fault. So, if the function returns a nullptr,
simply push an error message on GstBus and gracefully exit.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The original updateControls() has the assumption that ctrls and
v4l2Ctrls lists are in the same order. It is dependent on the
caller implementation though. This changes updateControls()
implementation so that it works without the assumption.
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>
|
|
Some external components such as the unit tests include headers
generated for the IPA's. This is not fully described in meson for each
external component which results in one or more races in the build
system. Instead of playing whack-a-mole add the generated IPA headers to
libcamera_dep.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Brief specifications available at
https://www.sony-semicon.co.jp/products/common/pdf/ProductBrief_IMX258_20151015.pdf
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>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Add libatomic dependency due to std::shared_ptr which is used by qcam
since its addition in commit 97e8b3a2eb321884fe1e15fb584f41a38cc33d51:
https://en.cppreference.com/w/cpp/memory/shared_ptr.
This will avoid the following build failure:
/srv/storage/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: src/qcam/qcam.p/main_window.cpp.o: undefined reference to symbol '__atomic_fetch_add_4@@LIBATOMIC_1.0'
Fixes:
- http://autobuild.buildroot.org/results/d0726b2253f1f3d006e057f3b32c646c4b9b5f7a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Report ANDROID_SENSOR_FRAME_DURATION as an available result key for CTS
to read out the value of frame duration we set in
CameraDevice::getResultMetadata(). Failing to do so might fail the CTS
test:
- android.hardware.camera2.cts.CaptureRequestTest#testNoiseReductionModeControl
Fixes: 3beb1accac1d ("android: camera_device: Fix sensor frame duration")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Chrome OS-specific code has multiple function parameters that are
not used. This results in compilation warnings. Fix them with
[[maybe_unused]].
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
A custom gamma LUT is used, but the table is not calculated at startup,
resulting in an all 0's frame.
Use the drfault LUT specified in the Linux kernel as a first estimation.
Reported-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
When compiling with optimization, gcc 9 and newer throw an unitialized
variable warning:
../../src/libcamera/pipeline/ipu3/imgu.cpp: In function ‘void libcamera::{anonymous}::calculateBDSHeight(libcamera::ImgUDevice::Pipe*, const libcamera::Size&, const libcamera::Size&, unsigned int, float)’:
../../src/libcamera/pipeline/ipu3/imgu.cpp:172:17: error: ‘bdsHeight’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
172 | unsigned int bdsIntHeight = static_cast<unsigned int>(bdsHeight);
Neither clang not gcc versions older than 9 complain. This seems to be
a false positive.
However, there's an obvious error in the code. The second while () loop
in the first part of calculateBDSHeight() modifies the bdsHeight
variable set by the first loop even if the second loop doesn't find a
suitable height. This can result in an incorrect bdsHeight value. Fix
this, which also gets rid of the compiler warning.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
GLib 2.62 has deprecated g_memdup(), which is used inline in GStreamer's
gstbytereader.h header. This results in a compilation warning:
In file included from /usr/include/gstreamer-1.0/gst/base/base.h:35,
from ../../src/gstreamer/gstlibcamerasrc.cpp:39:
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h: In function ‘guint8* gst_byte_reader_dup_data_unchecked(GstByteReader*, guint)’:
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h:365:41: error: ‘void* g_memdup(gconstpointer, guint)’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations]
365 | return (guint8 *) g_memdup (data, size);
GLib has a mechanism to silence warnings introduced in newer versions,
to allow compilation without warnings on multiple versions of the
library. This is done by setting the GLIB_VERSION_MIN_REQUIRED macro to
the minimum GLib version required.
As we depend on GStreamer >= 1.14, set the minimum GLib version to 2.40.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
The standard C library close() and lseek() functions require inclusion
of the unistd.h header. Include it explicitly where needed instead of
relying on indirect inclusion.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
This reverts commit 5b015e96ccdbcd87b4ba6484199652fec5cdb38a.
The ImgU pipe configuration debug is useful to test the correctness
of the parameters computation against the Intel Python script.
However, the number of debug messages which is printed out by the
configuration procedure is so high it floods the logs, up to the point
that starting the Android camera3 HAL, which tests several configurations
at startup, becomes so slow it is barely usable.
Revert the patch that adds the excessive debug statements, which are mostly
useful only when testing the configuration procedure.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Plumb meson to build the cpp files from the mojom files for the purpose
of containing the documentation for the IPA interfaces.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Move the documentation back to the mojom file from the cpp file. While
at it, move the documentation for IPAInterface::init() and
IPAInterface::stop() to the IPA guide.
While at it, update the todo comment in all of the mojom files
accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
[umang.jain@ideasonboard.com: Update todos]
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The sensor frame duration should be set by the IPA. Hardcode it for now.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The sensor frame duration should be set by IPA. Get the information for
the result metadata from libcamera.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
We need a separate control to report the nominal frame duration, but
it's also useful to report the min/max frame duration values that will
be used. Split the FrameDurations control into FrameDuration and
FrameDurationLimits respectively to support both of these.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Originally CameraHalManager is created in the libcamera start up
and destroyed in the libcamera termination. However,
CameraHalManager destructor can access other static objects that
has been destroyed.
Avoid this issue by destroying CameraHalManager when tear_down() is
called in ChromeOS or leaking it in other platforms.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Pass in frame timestamps from IPU3 pipeline handler to IPU3 IPA via
IPU3Event. Frame timestamps are helpful to IPA algorithms to
convergence, by setting them via IPA stats.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fixes: 2fac95b400b7 ("libcamera: pipeline: ipu3: Ensure that IPU3Frames::info is not used after delete")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
On gcc versions older than 9, the file system library, used by the
Android camera HAL configuration file parser, is implemented in a
separate static library. Furthermore, on gcc 7, it's provided in the
std::experimental namespace. This breaks compilation of the HAL on gcc
7, and linking on gcc 8.
Fix the compilation issue by conditionally including
<experimental/filesystem> and creating a namespace alias in std, and the
link issue by linking to libstdc++fs on gcc versions older than 9.
The inclusion of <experimental/filesystem> is a bit of a hack, and when
we'll start using the file system library in another compilation unit,
we should then move all this to an internal helper to abstract the
compiler version.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The <filesystem> header isn't needed in camera_hal_config.h, move its
inclusion to camera_hal_config.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add utility functions to CameraMetadata to check if it has been resized,
and for outputting the actual entry and data count. This is meant to be
used to output information on resizing, to assist developers in
choosing proper initial sizes to avoid resizing. Also make CameraDevice
use these functions for static and result metadata.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Add camera HAL configuration file for IPU3 Soraka.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Open the HAL configuration file in the Camera HAL manager and get
the camera properties for each created CameraDevice and initialize it
with them.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Add a CameraHalConfig class to the Android Camera3 HAL layer.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The HAL layer was getting the min and max frame durations from the
camera, then rounding it to fps to report as available fps ranges. The
same min and max frame durations were then being reported as min and max
frame durations. Since the fps are integer values while the frame
durations are in ns, this caused a rounding error making it seem like we
were reporting an available max fps that was higher than what was
allowed by the minimum frame duration.
An example is if the minimum frame duration is reported as 33366700ns.
The HAL layer would then convert it to fps, which is 29.97, but it would
be rounded and reported as 30 fps. When 30 fps is converted to a frame
duration it is 33333333ns, which is less than the minimum frame duration
that we report. Thus the minimum frame duration that we report
contradicts the fps range that we report.
Fix this by recalculating the frame durations based on the rounded fps
values.
This allows the following CTS test to pass:
- android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The new sensor database has introduced several sensors, but ov5693 is
missing.
It is used on most MS Surface tablets, add it to the database.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
updateControls()"
This reverts commit 34bee5e84ecba01e0ded5cacbc46c277c5a0edba.
The commit introduced a breakage in the master branch, reported by
linux-surface users already. Let's revert it while discussing the
propert fix.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The supportedDevices may contain entries which have the same driver
but different converters. For example, if we add these two entries:
{ "mtk-seninf", "mtk-mdp", 3 },
{ "mtk-seninf", "mtk-mdp3", 3 },
the simple pipeline handler will always take the first one where it
can acquire the driver and skip the rest.
So, make the changes to support this usecase.
Signed-off-by: Phi-Bang Nguyen <pnguyen@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The original updateControls() has the assumption that ctrls and
v4l2Ctrls lists are in the same order. It is dependent on the
caller implementation though. This changes updateControls()
implementation so that it works without the assumption.
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>
|
|
When stopping the camera worker, queuedRequest() calls may have queued
asynchronous function invocation messages to the worker thread, and some
of those messages may not have been processed yet. The messages will
stay in the thread's queue until the camera worker is restarted (when
the camera service will start a new capture session). At that point,
they will be dispatched, which will cause a crash due to the
CaptureRequest passed to processRequest() having been deleted by
CameraDevice::stop() calling descriptors_.clear().
Fix this by forcing dispatching of all function invocation messages when
stopping the camera worker thread. Note that this is inherently racy, as
more queueRequest() calls may arrive from the camera service while we're
stopping. This race condition will be addressed by a subsequent patch
series.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
There can be multiple IPAs per pipeline-handler or platform.
They can live in-tree or externally linked. It is up to the vendor
whether to use in-tree IPA for a platform or provide it externally.
In the case of IPAs being external, building in-tree IPAs might be
futile hence, provide a clear and explicit mechanism to choose whether
to build the in-tree IPA for the platform or not.
By default, all in-tree IPAs are built when a matching Pipeline handler
is also enabled.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
