| Age | Commit message (Collapse) | Author |
|---|
|
The V4L2VideoDevice::exportBuffers(),
PipelineHandler::exportFrameBuffers() and
FrameBufferAllocator::allocate() functions all return the number of
allocated buffers on success, but are documented as returning 0 in that
case. Fix their documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The slots list is touched from most of the Signal template functions. In
order to prepare for thread-safety, move handling of the list to a small
number of non-template functions in the SignalBase class.
This incidently fixes a bug in signal disconnection handling where the
signal wasn't removed from the object's signals list, as pointed out by
the signals unit test.
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>
|
|
Add two tests that exercise the Signal::disconnect(Object *) and
Signal::disconnect() methods, to verify that they correctly remove the
signal from the connected object's list of signals. This triggers an
issue that was detected through manual code inspection, and is expected
to crash or at least generate valgrind warnings.
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>
|
|
We use static local variables to indicate errors in methods that return
a const reference. The local variables can thus be const, make them so.
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>
|
|
Now that we're using C++-14, replace the manual implementation of
std::integer_sequence with std::index_sequence, a specialization of
std::integer_sequence with the integer type equal to std::size_t. The
template parameter S that denotes a sequence is replaced with I to align
with the usage examples of cppreference.com.
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>
|
|
ConnectionTypeBlocking always invokes the method through inter-thread
message passing, which results in deadlocks if the sender and receiver
live in the same thread. The deadlock can easily be avoided by turning
the invocation into a direct call in this case. Do so to make
ConnectionTypeBlocking easier to use when some of the senders live in
the same thread as the receiver while the other senders don't.
Extend the object-invoke test to cover this usage.
While at it reformat the documentation to avoid long \brief lines.
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 viewfinder is drawn using a QLabel. This could support scaling
through QLabel::setScaledContents(), but in a very inefficient way. To
maintain reasonable efficiency, turn the viewfinder into a QWidget and
draw the image directly using a QPainter.
No performance change was noticed running on a fast x86 machine, and
performance was 60% higher when scaling up to full screen compared to
QLabel.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The current thread ID is useful when debugging concurrency issues. Print
it in log messages. The syslog target is left out as the thread ID would
have little use there, and partly duplicates the process ID.
The log messages now look as follows.
[19:10:33.206560546] [22096] INFO Camera camera_manager.cpp:274 libcamera v0.0.0+993-32696686
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The current thread ID is useful when logging message to debug
concurrency issues. Add a method to retrieve it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The BufferSource::allocate() return value isn't propagated correctly,
resulting in a test failure when the test should be skipped due to a
missing vivid device. Fix it.
While at it, return valid status codes from BufferSource::allocate() in
all error cases, with proper diagnostic messages.
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>
|
|
This capability tells the application that mmap() is supported. GStreamer
would return an error saying there there is no input/output method supported
by this device otherwise. This was tested with:
LD_PRELOAD=$(pwd)/build/src/v4l2/v4l2-compat.so GST_DEBUG="v4l2*:7" gst-launch-1.0 v4l2src ! videoconvert ! autovideosink
With this patch, GStreamer will reach playing state. It then blocks waiting on
poll() which is not implemented yet on our side.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This adds support for pre-commit hook workflow. In pre-commit hook we
check the style on the changes currently staged or the combination
of the index and the last commit if "git commit --amend" is being used.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This introduces a new argument "--amend" and a new special type of
commit "Amendment". It will check the style of changes that are in
the index combined with the changes of the last commit. So this is
the changes that would be applied by "git commit --amend" hence the
name of the argument.
This is needed to implement pre-commit hook.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This introduces a new command line "--staged" and a new special type of
commit "StagedChanges". It will check the style of changes that are in
the index, so the changes that would be committed by "git commit".
"--staged" was chosen to match with "git diff --staged" command line.
Other valid name could have been "--index" or "--cached". This was
my personal preference, aliases can be added later. Note that we must
not confuse this with working tree changes, as these changes are not
picked by "git commit".
This feature is needed to implement pre-commit hook.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This introduces a Commit class used in the final revlist list. All the
git commands are moved into that class. This class will be used to
introduce new types of commit (StagedChanges and Amendment) needed to implement
pre-commit hook support.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Makes the tool return 1 if there is any potential issues. This is
needed when using this tool for pre-commit hook in order to abort
the commit process.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The tool has been renamed in 2016 to make it more obvious what it
is doing. There is no other changes needed on our side.
See https://github.com/PyCQA/pycodestyle/issues/466
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The commit 2de78434ca71 ("meson: Bump required version to 0.47")
included an extra duplicated line (my bad, the issue happened when
applying). Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This is needed to use option type 'feature'. This is a tri-state
(auto/enabled/disabled) which comes with utility to enable them all, or
disabled them all to avoid any dynamic selection happening. It can also
be used as value to any "required" field.
This will be used in GStreamer support. If you don't have a recent enough
meson in your distribution, you can always install or upgrade your version
using pip3.
pip3 install --user meson
pip3 install --user --upgrade meson
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When inserting an element with emplace(), the element is constructed
in-place with the parameters to the emplace() method being forwarded to
the constructor of the element. For std::map containers, the element is
an std::pair<const Key, T>. The constructors of std::pair<T1, T2> fall
into three categories:
(1) Default, copy and move constructors (and related versions)
(2) Constructors that take lvalue or rvalue references to T1 and T2
(3) A forwarding constructor that forwards parameters to the
constructors of T1 and T2
The first category isn't useful in most cases for std::map::emplace(),
as the caller usually doesn't have an existing std::pair<const Key, T>
for the element to be inserted.
The constructor from the third category is useful to avoid constructing
intermediate Key or T instances when the caller doesn't have them
available. This constructor takes two std::tuple arguments that contain
the arguments for the Key and T constructors, respectively. Due to
template deduction rules, usage of such a constructor couldn't be
deduced by the compiler automatically in all cases, so the constructor
takes a first argument of type std::piecewise_construct_t that lets the
caller force the usage ot the forwarding constructor (also known for
this reason as the piecewise constructor). The caller uses a construct
such as
map.emplace(std::piecewise_construct,
std::forward_as_tuple(args_for_Key, ...),
std::forward_as_tuple(args_for_T, ...));
This syntax is a bit heavy, but is required to construct Key and T
in-place from arguments to their non-default constructor (it is also the
only std::pair non-default constructor that can be used for non-copyable
non-movable types).
When the caller of std::map::emplace() already has references to a Key
and a T, they can be passed to the std::pair piecewise constructor, and
this will create std::tuple instance to wrap the Key and T references
arguments to ultimately pass them to the Key and T copy constructors.
map.emplace(std::piecewise_construct,
std::forward_as_tuple(Key_value),
std::forward_as_tuple(T_value));
While this mechanism works, it's unnecessary complex. A constructor of
std::pair that takes references to Key and T can be used without any
performance penalty, as it will also call the copy constructor of Key
and T. In this case we can use a simpler constructor of std::pair, and
thus a simpler call of std::map::emplace.
map.emplace(Key_value, T_value);
We have a couple occurrences of this above misuse of piecewise
construction. Simplify them, which simplifies the code and reduces the
generated code size.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that we're using C++-14, drop utils::make_unique for
std::make_unique.
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>
|
|
C++14 is a minor release that doesn't introduce major new concepts or
paradigms compared to C++11, but brings two useful changes for us:
- std::make_unique allows dropping our custom implementation in utils.
- Functions returning constexpr are not assumed to be const anymore,
which is needed to create a standard-conformant span implementation.
All the g++ and clang++ versions we support and test (g++-5 onwards and
clang++6 onwards) support C++14. However, due to a defect in the
original C++14 specification, solved in N4387 ([1]), compilation would
fail on g++-5 due to the use of std::map::emplace() with a non-copyable
value type. It turns out we can easily fix it by switching to the
explicit piecewise emplace() overload.
There is thus really nothing holding back the switch. Let's do it, and
update the coding style accordingly.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387
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>
|
|
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>
|
|
Add an initial simple test tool for the rkisp1 pipeline based upon the
IPU3 pipeline test.
Signed-off-by: Show Liu <show.liu@linaro.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
With the buffer allocator in use it's possible to cache the dmabuf
memory mappings when starting the camera instead of mapping and
unmapping them each time.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the buffer allocator in use it's possible to cache the dmabuf
memory mappings when starting the camera instead of mapping and
unmapping them each time.
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>
|
|
With the FrameBuffer interface the V4L2 buffer indexes are not visible
outside the V4L2VideoDevice so it's not possible to to test that the
expected indexes are used when using external buffers (allocated
directly from a V4L2 video device) with a Camera. Rewrite the test to
this limitation.
The idea of the test stays the same, test that buffers allocated from a
V4L2 video device (vivid) can be imported and used on a Camera (vimc).
As an added bonus the rewrite makes use of the FrameBuffer interface for
the allocation of buffers at the source (vivid) and imports them to the
Camera which still uses the Buffer interface internally.
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 all test cases to use it.
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>
|
