| Age | Commit message (Collapse) | Author |
|---|
|
The mojo parser is fine if there are types that are used in array/map
members that it does not know about. These are usually caught by the C++
compiler, because the generated code refers to unknown types. This
feature is necessary for us for supporting FrameBuffer::Plane as an
array/map member, since as long as the type has an IPADataSerializer and
the struct defined in C++, the generated code will run fine
(FrameBuffer::Plane is not defined anywhere in mojom but is used as an
array member in IPABuffer).
The types that are defined in controls.h (or any header included in
ipa_interface.h) will all be compiled by the C++ compiler fine, since
the generated files all include controls.h. The types that are there
that are not ControlInfoMap or ControlList (like ControlValue) will
still fail at the linker stage. For example:
struct A {
array<ControlValue> a;
};
will compile fine, but will fail to link, since
IPADataSerializer<ControlValue> doesn't exist. This behavior, although
not the best, is acceptable.
The issue is that if ControlInfoMap or ControlList are used as array/map
members without the libcamera prefix, the compiler will not complain, as
the types are valid, and the linker will also not complain, as
IPADataSerializer<ControlList> and IPADataSerializer<ControlInfoMap>
both exist. However, the code generator will not recognize them as
types that require a ControlSerializer (since mojo doesn't recognize
them, so they are different from the ones that it does recognize with
the libcamera namespace), and so the ControlSerializer will not be
passed to the serializer in the generated code. This is the cause of the
FATAL breakage:
FATAL IPADataSerializer ipa_data_serializer.cpp:437 ControlSerializer
not provided for serialization of ControlInfoMap
Since ControlInfoMap and ControlList are the only types that will run
into this issue, we solve this by simply detecting if they are used
without the prefix, and produce an error at that point in the code
generator. As the code generator stage no longer has information on the
source code file and line, we output the struct name in which the error
was found (ninja will output the file name).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-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>
|
|
Import the latest version of the Android headers from Chrome OS (commit
a30340e77ec8 ("camera: Uprev Android camera headers")). This brings in
the Camera HAL v3.5 support.
The headers are imported verbatim, except for the addition of the SPDX
headers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Paul Elder <paul.elder@ideasonboard.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>
|
|
Take the SPDX header from the mojom file. Error out if the mojom file
has no SPDX header.
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>
|
|
As reported by lwn.net in https://lwn.net/Articles/856543/ and
https://lwn.net/Articles/857140/, freenode, the largest IRC network and
the home of our IRC channel, is embroiled in a messy dispute. After
careful consideration, we have decided that it is not a suitable place
to host our community anymore.
Effective immediately, the #libcamera IRC channel is transferred to the
OFTC IRC network. We will continue our effort to make the channel a
welcoming place for everybody.
Usage of OFTC is governed by its network [1] and privacy [2] policies.
While we don't expect these to cause issues for anyone, please feel free
to contact OFTC or libcamera should you have any question or concern.
[1] https://www.oftc.net/Network_Policy/
[2] https://www.oftc.net/Privacy_Policy/
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@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>
|
|
We don't want to generate the same functional files for core.mojom as
the other mojom files, but we do want to generate the documentation cpp
files. Add core.mojom to the mojom files list after the main generation
is complete, so that the documentation generator can pick it up.
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>
|
|
Use meson's files() to list the mojom files instead of the file names
directly. This is so that we can still access the files from
src/libcamera/ipa/meson.build later for building documentation cpp
files from the mojom files.
While at it, fix some redundant string manipulation in building the
mojom modules.
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>
|
|
Add a script to extract doxygen documentation comments from mojom files.
It matches based on ^\/\*\*$ for start of block and ^ \*\/$ for end of
block, and simply copies the comments to the output file along with a
header and the libcamera namespace.
Also add it to the meson file so it is usable by other meson files.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@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>
|
|
Boolean options in the summary are printed as 'True' or 'False' by
default. Enable the bool_yn option, which prints them as 'YES' or 'NO',
in green and red respectively. This makes the summary more readable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
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>
|
|
The recent merge (and revert) of commit 34bee5e84ecb ("libcamera:
V4L2Device: Remove the controls order assumption in updateControls()")
showed that 64-bit controls were missing from unit tests.
Fix this by testing the VIVID_CID_INTEGER64 control in the V4L2 video
device controls test.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
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>
|
|
The ControlInfoMap of entityControls member in IPAConfigInfo struct,
was not able to correctly match to the ControlInfoMap defined in
core.mojom. This resulted in a FATAL breakage when IPU3 IPA is meant to
run:
FATAL IPADataSerializer ipa_data_serializer.cpp:437 ControlSerializer
not provided for serialization of ControlInfoMap
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>
|
|
Fix compiler warning about variable use before being initialized that
appears with gcc 11.1.0.
test/byte-stream-buffer.cpp:31:63: error: ‘data’ may be used uninitialized [-Werror=maybe-uninitialized]
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>
|
|
Update mojo from the Chromium repository. The commit from which this was
taken is:
9c138d992bfc1fb8f4f7bcf58d00bf19c219e4e2 "Updating trunk VERSION from
4523.0 to 4524.0"
The update-mojo.sh script was used for this update.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=34
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a script to ease updating mojo from a chromium source tree.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
Add to the README.rst file the list of depdendencies for the
Android Camera3 HAL.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
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>
|
|
IPAConfigInfo is a consolidated data structure passed from IPU3
pipeline-handler to IPU3 IPA. The structure can be extended with
additional parameters to accommodate the requirements of multiple
IPU3 IPA modules.
Adapt the in-tree IPU3 IPA to use IPAConfigInfo as well.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Generated IPA headers from mojom files need to be installed to
$INCLUDE_PATH in order to be available system-wide. Without this,
out-of-tree IPAs won't be able to link and build themselves.
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: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This matches the naming convention for IPA IPC.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraSensorInfo structure is designed to pass in camera sensor related
information from pipeline-handler to IPA. Since the pipeline-handler
and IPA are connected via mojom IPC IPA interface, the interface
itself provides a more suitable placement of CameraSensorInfo,
instead of camera_sensor.h (which is a libcamera internal header
ultimately, at this point).
As CameraSensorInfo is already defined in core.mojom, it is just
a matter of removing [skipHeader] tag to allow code-generation
of CameraSensorInfo.
Finally, update header paths to include CameraSensorInfo definition
from IPA interfaces instead of "libcamera/internal/camera_sensor.h".
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Moving the core.mojom documentation to its corresponding .cpp file
(core_ipa_interface.cpp). This will allow Doxygen to generate the
documentation for IPABuffer, IPASettings and IPAStream structures.
Since the .mojom files are placed in include/ directory, the .cpp file
will live in $sourcedir/src/libcamera/ipa/ - which can also contain
documentation for other mojom generated IPA interfaces in subsequent
commit.
Also hide the constructors in generated IPA interface from doxygen,
via #ifndef __DOXYGEN__. These constructors provide no major value in
documenting them, instead will spew out doxygen warnings during the
build.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When a thread stops, messages may be left in its message queue. Document
this in details, with a way to force processing of pending messages when
the thread is stopped.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The asynchronous signal delivery mechanism can't be used by application,
as it requires libcamera to be aware of the application event loop,
which has been dropped a long time ago. Drop the corresponding
documentation paragraph.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The Thread::dispatchMessages() function is meant to be called from
within the thread only. Catch incorrect usage with an ASSERT().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The Thread class is incorrectly documented as thread-safe, as the
dispatchMessages() function isn't thread-safe. Fix the documentation by
tagging individual functions as thread-safe as appropriate.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
