| Age | Commit message (Collapse) | Author |
|---|
|
The gen-controls.py script hardcodes the path to the python interpreter
to /usr/bin/python3 in the first line of the script. This hardcodes
usage of the host python3, even when building in cross-compilation
environments that may ship their own version of python. Fix it by
setting the interpreter to '/usr/bin/env python3'.
Reported-by: Madhavan Krishnan <madhavan.krishnan@linaro.org>
Suggested-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Doxygen generates the following warning:
src/libcamera/ipa_interface.cpp:262: warning: explicit link request to 'dup()' could not be resolved
Fix it by disabling link generation by prefixing the function name with
a %.
Fixes: 4b9bd6c3ad94 ("libcamera: ipa_interface: Document the ownership of dmabufs passed to map_buffers()")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
map_buffers()
The ownership of the dmabuf file handles passed to map_buffers() is not
clear. Explicitly document that they are borrowed from the caller and
only guaranteed to be valid for the duration of the map_buffers() call.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the FrameBuffer rework completed there is no reason to keep the
camera prepared state around as buffer allocations are now decoupled
from the camera state. Remove the camera state simplifying the API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the FrameBuffer interface in place there is no need for the Camera
to call into the specific pipelines allocation and freeing of buffers as
it no longer needs to be synchronized with buffer allocation by the
application.
Remove the function prototypes in the pipeline handler base class and
fold the functionality in the pipelines start() and stop() functions
where needed. A follow up patch will remove the now no-op
Camera::allocateBuffers() and Camera::freeBuffers().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Delete all dead code after switching to the FrameBuffer interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Buffer interface is no longer in use and can be removed. While doing
so clean up the two odd names (dequeueFrameBuffer() and
queuedFrameBuffers_) that had to be used when adding the FrameBuffer
interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch to the FrameBuffer interface where all buffers are treated as
external buffers and are allocated outside the camera. Applications
allocating buffers using libcamera are switched to use the
FrameBufferAllocator helper.
Follow-up changes to this one will finalize the transition to the new
FrameBuffer interface by removing code that is left unused after this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
buffers
The FrameBuffer interface is based on the idea that all buffers are
allocated externally to libcamera and are only used by it. This is meant
to create a simpler API centered around usage of buffers, regardless of
where they come from.
Linux however lacks a centralized allocator at the moment, and not all
users of libcamera are expected to use another device that could provide
suitable buffers for the camera. This patch thus adds a helper class to
allocate buffers internally in libcamera, in a way that matches the
needs of the FrameBuffer-based API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Extend the pipeline handlers to support the FrameBuffer API with three
new methods to handle allocation, importing and freeing of buffers. The
new methods will replace allocateBuffers() and freeBuffers().
The FrameBuffer API will use the methods on a stream level and either
allocate or import buffers for each active stream controlled from the
Camera class and an upcoming FrameBufferAllocator helper. With this new
API the implementation in pipeline handlers can be made simpler as all
streams don't need to be handled in allocateBuffers().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2VideoDevice class can now operate using a FrameBuffer interface,
switch the IPU3 CIO2 and statistics buffer to use it. We can not convert
the application-facing buffers yet.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2VideoDevice class can now operate using a FrameBuffer interface,
switch the RkISP1 statistics and parameters buffer to use it. We can not
convert the application-facing buffers yet.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It's common for applications to create and queue a new request in a
previous request completion handler. When the new request gets queued to
the RkISP1 pipeline handler it tries to find a parameters and statistic
buffer to be used with the request. The problem is if the pipeline depth
is already filled there are no internal buffers free to be used by the
new request.
This was solved by allocation one more parameters and statistic buffer
then the pipeline depth, this is waste full. Instead free the resources
of the request that has completed before it is signaled to the
application, this way if the pipeline depth is full it can reuse the
internal resources and the wasteful allocation can be removed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a new interface in parallel with the existing Buffer implementation
to also support FrameBuffer. The reason it's added in parallel is to aid
in the migration from Buffer to FrameBuffer throughout libcamera. With
this change discrete parts of libcamera can be migrated and tested
independently.
As the new interface is added in parallel there are some oddities in
this change which will be undone in a follow up patch once libcamera
have migrated away from the Buffer interface.
- There is a nasty hack in V4L2VideoDevice::bufferAvailable(). It is
needed to allow both interfaces to exist and function at the same
time. The idea is if buffers are allocated using the FrameBuffer
interface V4L2VideoDevice::cache_ is set and we know to call the
FrameBuffer 'buffer ready' signal, and likewise if it's not to call
the Buffer variant.
- There is some code duplication between the two interfaces as they aim
to solve the same thing in slightly different ways. As all Buffer
related code is soon to be removed no effort to create code sharing
between them have been made.
- Some function and variables which can't be distinguished by their
argument types have been given a frameBuffer prefix instead of a
buffer prefix. They are clearly documented in the code and will be
renamed to the correct buffer prefix when the Buffer interface is
removed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In preparation for the FrameBuffer interface add a class that will deal
with keeping the cache between dmabuf file descriptors and V4L2 video
device buffer indexes.
This initial implementation ensures that no hot association is lost
while its eviction strategy could be improved in the future.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the metadata retrieved when dequeuing a V4L2 buffer into a
FrameMetadata object. This is done as a step to migrate to the
FrameBuffer interface as the functions added to Buffer around
FrameMetadata match the ones in FrameBuffer.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In the FrameBuffer interface the stream will not be available from the
buffer object as the buffer might be allocated externally. The
application needs to explicitly state which stream the buffer is being
added for to the request.
Extend the addBuffer() function to get this information explicitly from
the caller.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The part in createPlane() that exports a dma buffer from a video device
will be used directly by the FrameBuffer interface. Break it out to a
separate function.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Reading V4L2VideoDevice::queueBuffer() is confusing since buf.type is
first set to bufferType_ but then both variables are used in V4L2 macros
to operate based on which type of buffer is being processed. Align on
only using buf.type since it has the most existing users.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There is no need to have a private helper function to access a private
data member when a friend statement is needed anyhow. Remove the helper
function to simplify the code and make it clear that a private member of
Buffer is accessed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There are no users left of the Plane class, drop it.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It is not libcamera's responsibility to handle memory mappings. Switch
from the soon to be removed Plane class which deals with memory
mappings to FrameBuffer::Plane which just describes it. This makes the
transition to the full FrameBuffer easier.
As the full FrameBuffer interface has not yet spread to all parts of
libcamera core it is hard to create efficient caching of memory mappings
in the qcam application. This will be fixed in a later patch, for now
the dmabuf is mapped and unmapped each time it is seen by the
application.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch the IPA interfaces and implementations to use the Framebuffer
interface.
- The IPA interface is switched to use the simpler FrameBuffer::Plane
container when carrying dmabuf descriptions (fd and length) over the
pipeline/IPA boundary.
- The RkISP1 IPA implementation takes advantage of the new simpler and
safer (better control over file descriptors) FrameBuffer interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a new FrameBuffer class to describe memory used to store frames.
This change just adds the new interface, future patches will migrate all
parts of libcamera to use this and replace the old Buffer interface.
This change needs to specify the const keyword for Plane::length() as to
not get Doxygen confused with FrameBuffer::Plane::length added in this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the introduction of FrameBuffer objects, the metadata information
related to captured frames will not be stored directly in the frame
buffer object. Add a new FrameMetadata class to hold this information.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a helper to make it easier to pass file descriptors around. The
helper class duplicates the fd which decouples it from the original fd
which could be closed by its owner while the new FileDescriptor remains
valid.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The association of buffers to a request can be done directly in
addBuffer() instead of when the request is queued to the camera. Keep
the check that a request contains buffers by moving it to
Camera::queueRequest() where prepare() was previously called.
As a bonus we can remove a friend statement in Request.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Propagate the return value of the bound method all the way to the caller
of activate(). The value is stored in the arguments pack for indirect
invocation.
As C++ doesn't allow instantiating a variable of type void, we need to
specialize the template class BoundMethodPack for methods returning
void. This in turn requires template specialization for the
BoundMethodArgs class in order to store the return value in the pack,
and for the BoundMemberMethod class to extract the return value from the
pack.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The bound method arguments pack will need to be accessed by the method
invoker in order to retrieve the method return value when using a
blocking connection type. We thus can't delete the pack unconditionally
in the bound method target thread. We also can't delete it
unconditionally in the invoker's thread, as for queued connections the
pack will be used in the target thread after the invoker completes.
This shows that ownership of the arguments pack is shared between two
contexts. As a result, manage it using std::shared_ptr<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The bound method implementation is restricted to binding to void methods
as return values are not supported. This complicates usage of bound
methods, as non-void methods used a slots or Object::invokeMethod()
targets need to be wrapped in a void method. Simplify this by supporting
arbitrary return types and ignoring the return value.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When BoundMethodBase::activatePack() is called with the connection type
set to ConnectionTypeDirect, the method isn't deleted even if
deleteMethod is true, as is the case when called from
Object::invokeMethod(). This causes a memory leak. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The ControlSerializer::serial_ member variable isn't initialized. Add a
constructor to the class to initialize it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
IPCUnixSocket::send() sends a IPCUnixSocket::Header allocated on the
stack. All the fields of the header are initialized, but the padding
bytes are not. This results in random data being sent over the UNIX
socket, potentially leaking information.
Fix this by initializing the whole header to 0.
Fixes: 13dd7a01ecbe ("libcamera: ipc: unix: Add a IPC mechanism based on Unix sockets")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Register all UVC Cameras along with their device numbers, to eventually
allow the V4L2 compatibility layer to match against it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
device numbers
The V4L2 compatibility layer will need a way to map device numbers to
libcamera Camera instances. Expose a method in the camera manager to
retrieve Camera instances by devnum. The mapping from device numbers to
Camera instances is optionally declared by pipeline handlers when they
register cameras with the camera manager.
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 are preparing to integrate the V4L2 adaptation layer, which will
intercept open() calls (among others) via LD_PRELOAD. To prevent
libcamera's own open() calls from being intercepted, replace them with a
direct syscall.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
strlcpy is available in libbsd, bionic, musl, and ulibc, but not in glibc.
Instead of checking for strlcpy availability and modifying dependencies,
implement it in utils, as a wrapper around strncpy.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit e441f2c7f46d ("libcamera: pipeline: uvcvideo: Add controls
support") broke handling of UVC devices without a default entity by
turning the error check into an always false check. Fix it.
Fixes: e441f2c7f46d ("libcamera: pipeline: uvcvideo: Add controls support")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The buffer index is a V4L2 concept that will be hidden from users with
the introduction of a new FrameBuffer class. In preparation for this,
remove the index from log messages.
Keep and move one debug log message where the index is available as the
V4L2 buffer is being dequeued for the video device and it's useful when
debugging.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Expecting pipeline handler implementations of queueRequest() to call
the base class queueRequest() at the correct point have led to different
behaviors between the pipelines.
Fix this by splitting queueRequest() into a base class implementation
which handles the bookkeeping and a new queueRequestDevice() that is
to be implemented by pipeline handlers and only deals with committing the
request to the device.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Object instances receive messages dispatched from the event loop of the
thread they belong to. Deleting an object from a different thread is
thus dangerous, unless the caller ensures that no message delivery is in
progress. Document this in the Object class documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The Object class stores the number of pending messages that have been
posted for it, while the actual messages are stored in a per-thread list
in the ThreadData class. When dispatching messages, the message is
removed from the list, passed to the receiver, and the number of pending
messages is updated.
In order to avoid too much contention on the list lock, the lock is
dropped to pass the message to the receiver and then taken again. This
creates a race condition window with Thread::removeMessages(), as the
number of pending messages for a receiver is briefly out of sync with
the pending messages list. The assertion at the end of removeMessages()
thus sometimes fails.
Fix this by decrementing the pending messages counter before releasing
the lock in Thread::dispatchMessages(). This fixes the slow message
receiver test in MessageTest.
Fixes: 01b930964acd ("libcamera: thread: Add a messaging passing API")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When moving an Object to a Thread, messages posted for the object are
move to the target thread's message queue. This requires locking the
message queues of the current and target threads, as the target thread
may (and is usually) running. The implementation is faulty as it locks
the thread data instead of the message queue. This creates a race
condition with a tiny but exploitable time window.
The issue was noticed by the event-thread test rarely but reproducibly
failing with the following assertion error:
[1:39:33.850878042]FATAL default thread.cpp:440 assertion "data_ == receiver->thread()->data_" failed
The issue only occurred when libcamera was compiled in release mode,
further hinting of a race condition.
Fixes: 01b930964acd ("libcamera: thread: Add a messaging passing API")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When a fatal error occurs the program aborts, and all the logger
provides is the location of the line that caused the error. Extend this
with a full backtrace to help debugging.
The backtrace is generated using the backtrace() call, a GNU extension
to the C library. It is available in glibc and uClibc but not in musl.
Test for availability of the function to condition compilation of the
backtrace printing. Implementing backtrace support with musl is an
exercise left to the reader if desired.
The LogOutput class is extended to support writing string messages
directly to the output. Strings written directly will be considered as
LogDebug messages when written to the Syslog.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Oxford English spells "serialize", not "serialise". Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When an IPA module is loaded without isolation and implements the
IPAInterface internally, going through ipa_context_ops is a waste of
time. Add an operation to retrieve the IPAInterface, and use it directly
in the IPAContextWrapper.
For debugging purpose, make it possible to forcing usage of the C API by
defining the LIBCAMERA_IPA_FORCE_C_API environment variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
IPA modules have to implement a public ipaCreate() function, but its
prototype isn't declared in any header file. This allows for modules to
get the prototype wrong without being warned by the compiler. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Switch IPA communication to the plain C API. As the IPAInterface class
is easier to use for pipeline handlers than a plain C API, retain it and
add an IPAContextWrapper that translate between the C++ and the C APIs.
On the IPA module side usage of IPAInterface may be desired for IPAs
implemented in C++ that want to link to libcamera. For those IPAs, a new
IPAInterfaceWrapper helper class is introduced to wrap the IPAInterface
implemented internally by the IPA module into an ipa_context,
ipa_context_ops and ipa_callback_ops.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The C++ objects that are expected to convey data through the IPA API
will have associated methods that would require IPAs to link to
libcamera. Even though the libcamera license allows this, suppliers of
closed-source IPAs may have a different interpretation. To ease their
mind and clearly separate vendor code and libcamera code, define a plain
C IPA API. The corresponding C objects are stored in plain C structures
or have their binary format documented, removing the need for linking to
libcamera code on the IPA side.
The C API adds three new C structures, ipa_context, ipa_context_ops and
ipa_callback_ops. The ipa_context_ops and ipa_callback_ops contain
function pointers for all the IPA interface methods and signals,
respectively. The ipa_context represents a context of operation for the
IPA, and is passed to the IPA oparations. The IPAInterface class is
retained as it is easier to use than a plain C API for pipeline
handlers, and wrappers will be developed to translate between the C and
C++ APIs.
Switching to the C API internally will be done in a second step.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The IPAInterface::configure() operation receives a map of ControlInfoMap
instances. Pass const references instead to avoid copies when not
required (the callee can still make manual copies), and to allow for the
future serialization layer to keep references to the original object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
