| Age | Commit message (Collapse) | Author |
|---|
|
As part of an effort to make the vimc IPA usable for testing, extend it
with a configure function. The configuration is currently ignored by the
IPA.
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>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
All the IPU3 Camera controls are currently initialized by the pipeline
handler which initializes them using the camera sensor configuration and
platform specific requirements.
However, some controls are better initialized by the IPA, which might,
in example, cap the exposure times and frame duration to the constraints
of its algorithms implementation.
Also, moving forward, the IPA should register controls to report its
capabilities, in example the ability to enable/disable 3A algorithms on
request.
Move the existing controls initialization to the IPA, by providing
the sensor configuration and its controls to the IPU3IPA::init()
function, which initializes controls and returns them to the pipeline
through an output parameter.
The existing controls initialization has been copied verbatim from the
pipeline handler to the IPA, if not a for few line breaks adjustments
and the resulting Camera controls values are not changed.
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: Umang Jain <umang.jain@ideasonboard.com>
|
|
Introduce a new field in the controls serialization protocol to
allow discerning which ControlIdMap a ControlInfoMap refers to.
The newly introduced IdMapType enumeration describes the possible
info maps:
- Either the globally available controls::controls and
properties::properties maps, which are valid across IPC boundaries
- A ControlIdMap created locally by the V4L2 device, which is not valid
across the IPC boundaries
At de-serialization time the idMapType field is inspected and
- If the idmap is a globally defined one, there's no need to create
new ControlId instances when populating the de-serialized
ControlInfoMap. Use the globally available map to retrieve the
ControlId reference and use it.
- If the idmap is a map only available locally, create a new ControlId
as it used to happen before this patch.
As a direct consequence, this change allows us to perform lookup by
ControlId reference on de-serialized ControlIdMap that refers to the
libcamera defined controls::controls and properties::properties.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
ControlInfoMap does not have a ControlId map associated, but rather
creates one with the generateIdMap() function at creation time.
As a consequence, when in the need to de-serialize a ControlInfoMap all
the ControlId it contains are created by the deserializer instance, not
being able to discern if the controls the ControlIdMap refers to are the
global libcamera controls (and properties) or instances local to the
V4L2 device that has first initialized the controls.
As a consequence the ControlId stored in a de-serialized map will always
be newly created entities, preventing lookup by ControlId reference on a
de-serialized ControlInfoMap.
In order to make it possible to use globally available ControlId
instances whenever possible, create ControlInfoMap with a reference to
an externally allocated ControlIdMap instead of generating one
internally.
As a consequence the class constructors take and additional argument,
which might be not pleasant to type in, but enforces the concepts that
ControlInfoMap should be created with controls part of the same id map.
As the ControlIdMap the ControlInfoMap refers to needs to be allocated
externally:
- Use the globally available controls::controls (or
properties::properties) id map when referring to libcamera controls
- The V4L2 device that creates ControlInfoMap by parsing the device's
controls has to allocate a ControlIdMap
- The ControlSerializer that de-serializes a ControlInfoMap has to
create and store the ControlIdMap the de-serialized info map refers to
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
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>
|
|
To prepare for the Camera::Private structure being used by pipeline
handlers, turn all its members to private. Members that are useful for
pipeline handlers will be made public again, or will be exposed through
accessor functions, on a case-by-case basis.
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>
|
|
The Camera::Private class is defined in camera.cpp. To prepare for
allowing it to be subclassed by pipeline handlers, move it to a new
internal/camera.h header.
The \file comment block in camera.cpp now needs to explicitly tell which
camera.h file it refers to.
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>
|
|
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>
|
|
The Extensible::_d() functions are meant to be called by users of the
class. Document them.
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 type safety by turning the MapFlag and OpenModeFlag enum into enum
class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced Flags<> class to store a bitfield of
File::OpenMode in a type-safe way. The existing File::OpenMode enum is
renamed to File::OpenModeFlag to free the File::OpenMode for the Flags<>
type alias.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced Flags<> class to store a bitfield of
File::MapFlag in a type-safe way.
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 Flags template class that provide type-safe bitwise operators on
enum values. This allows using enum types for bit fields, without giving
away type-safety as usually done when storing combined flags in integer
variables.
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>
|
|
It would be convenient to be able to iterate over available boolean
values, for example for controls that designate if some function can be
enabled/disabled. The current min/max/def constructor is insufficient,
as .values() is empty, so the values cannot be easily iterated over, and
creating a Span of booleans does not work for the values constructor.
Add new constructors to ControlInfo that takes a set of booleans (if
both booleans are valid values) plus a default, and another that takes
only one boolean (if only one boolean is a valid value).
Update the ControlInfo test accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The comment block at the beginning of the core.mojom file is meant to
provide an overview of how to use libcamera defined types in the definition
of mojom interfaces.
As the IPA/IPC interface definition mechanism evolved, the documentation
has not been updated accordingly.
Update the file comments to match the most recent IPA/IPC
interface definition and generation mechanism.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The createIPA() template function starts with code that doesn't depend
on the template parameters. Split it to a non-template function to avoid
code duplication in the binary.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The IPAManager::createIPA() function has its minVersion and maxVersion
parameters inverted. This doesn't cause any issue at the moment as both
the minimum and maximum version are set to 1 by all callers, but it's
still a bug. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Implement the D-Pointer design pattern in the FrameBuffer class to allow
changing internal data without affecting the public ABI.
Move the request_ field and the setRequest() function to the
FrameBuffer::Private class. This allows hiding the setRequest() function
from the public API, removing one todo item. More fields may be moved
later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that all Extensible classes expose a _d() function that performs
appropriate casts, the LIBCAMERA_D_PTR brings no real additional value.
Replace it with direct calls to the _d() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Despite sharing the same name, the private data class created by the
Extensible design pattern and the C++ private access specifier have
different goals. The latter specifies class members private to the
class, while the former stores data not visible to the application.
There are use cases for accessing the private data class from other
classes inside libcamera. Make this possible by exposing public _d()
functions in the class deriving from Extensible. This won't allow access
to the private data by applications as the definition of the Private
class isn't visible outside of libcamera.
The _d() functions need to be defined as template functions to delay
their evaluation, as the static_cast() operator in the Extensible::_d()
functions needs the Private class to be fully defined. The template
argument is defaulted and ignored, as only its presence is required to
delay evaluation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
libcamera names header files based on the classes they define. The
buffer.h file is an exception. Rename it to framebuffer.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
device_enumerator.h doesn't need to include linux/media.h. Drop
inclusion of the header.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
We use isValid() instead of valid() through the code base, make
MediaDevice consistent.
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 commit adds support for monochrome (greyscale) raw sensors. These
are sensors that have no colour filter array, so all pixels are the
same and there are no distinct colour channels.
These sensors still require many of an ISP's processing stages, such
as denoise, tone mapping, but not those that involve colours (such as
demosaic, or colour matrices).
Signed-off-by: David Plowman <david.plowman@raspberrypi.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>
|
|
The utils::hex() function is defined as a function template that has
implementations for integer arguments only. When given a different
argument type, the compiler will not catch the issue, but linking will
fail:
src/libcamera/libcamera.so.p/camera_sensor.cpp.o: in function `libcamera::CameraSensor::validateSensorDriver()':
camera_sensor.cpp:(.text+0x1e6b): undefined reference to `libcamera::utils::_hex libcamera::utils::hex<libcamera::ControlId const*>(libcamera::ControlId const*, unsigned int)'
Move the failure to compilation time by enabling the function for
integer arguments only. This provides better diagnostics:
../../src/libcamera/camera_sensor.cpp: In member function ‘int libcamera::CameraSensor::validateSensorDriver()’:
../../src/libcamera/camera_sensor.cpp:199:77: error: no matching function for call to ‘hex(const libcamera::ControlId*&)’
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Headers which must not be exposed as part of the public libcamera API
should include base/private.h.
Any interface which includes the private.h header will only be able to
build if the libcamera_private dependency is used (or the
libcamera_base_private dependency directly).
Build targets which are intended to use the private API's will use the
libcamera_private to handle the automatic definition of the inclusion
guard.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move span, and adjust the Doxygen exclusion as well.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the event notifier, and associated header updates.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The File abstraction is a base helper and not part of the libcamera
API. Move it to to allow usage by users of the base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
Move the class support infrastructure to the base library.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the utils functionality to the libcamera/base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera-base.so will feature internal support functionality
that is utilised by libcamera, and can be shared in other places.
This new library provides a layer beneath libcamera which provides
common abstractions to internal objects.
A pkg-config file is generated and named libcamera-base.pc which allows
components such as external IPA modules to link directly to this library
if they need. Normal applications will reference this library through
the Requires: statement provided by the libcamera.pc package
configuration, and linkage will be handled automatically through the
pkg-config mechanisms.
No code is moved to this library yet, this patch only introduces the
framework, construction and linkage.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
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 libcameraSourcePath and libcameraBuildPath helper functions are
internal and specific to libcamera needs while operating with the meson
build system.
In preparation for the upcoming move of utils to a common library, move
these helpers out of utils and into their own build unit.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
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 LogCategory instances are constructed on first use as static
variables in accessor functions, following the Meyers singleton pattern.
As a result, their destruction order is not guaranteed. This can cause
issues as the global Logger object, constructed in a similar fashion, is
accessed from the LogCategory destructor and may be destroyed first.
To fix this, keep the same singleton pattern, but allocate the
LogCategory instances dynamically. As they get registered with the
global Logger instance, we can destroy them in the Logger destructor.
This only avoids destruction order issues between LogCategory and
Logger, and doesn't address yet the fact that LOG() calls from
destructors of global objects may access an already destroyed Logger.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chormium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This enables retrieving supported test pattern modes through
CameraSensorInfo.
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: Jacopo Mondi <jacopo@jmondi.org>
|
|
The V4L2 specification defines the sensor test pattern modes
through a menu control, where a numerical index is associated to
a string that describes the test pattern. The index-to-pattern
mapping is driver specific and requires a corresponding representation
in the library.
Add to the static list of CameraSensorProperties a map of indexes to
libcamera::controls::TestPatternModes values to be able to map the
indexes returned by the driver to the corresponding test pattern mode.
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: Jacopo Mondi <jacopo@jmondi.org>
|
|
This adds a support of v4l2 menu. The control info for v4l2 menu
contains indices without names and 64bit values of querymenu.
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: Jacopo Mondi <jacopo@jmondi.org>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
