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: 4b9bd6c3ad ("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>
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>
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>
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>
The V4L2Camera::getBufferFd() method doesn't need to run in the camera
thread. Call it directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
In the upcoming FrameBuffer API the memory mapping of buffers will be
left to the user of the FrameBuffer objects. Prepare the V4L2
compatibility layer to this upcoming change to ease conversion to the
new API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
With the upcoming FrameBuffer API a new library wide FrameMetadata
object will be added which will replace the specific implementation in
the V4L2 compatibility layer.
Avoid name collisions while the new FrameBuffer API is added by renaming
the V4L2 compatibility layer specific implementation until it can be
replaced with the library wide implementation.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add a test which exercises the whole FileDescriptor interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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>
Refactoring of the camera_proxy have left the 'ret' variable undeclared,
declare it.
../../src/v4l2/v4l2_camera_proxy.cpp:273:2: error: use of undeclared identifier 'ret'
ret = vcam_->invokeMethod(&V4L2Camera::configure,
^
../../src/v4l2/v4l2_camera_proxy.cpp:278:6: error: use of undeclared identifier 'ret'
if (ret < 0)
Fixes: fce110c6d9 ("v4l2: camera_proxy: Break out try_fmt")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Most of the ioctl handlers in the V4L2CameraProxy class have an empty
line between the tracing printouts and the immediately following buffer
type validation. Align the two occasions where such an empty line is missing
with the others.
Cosmetic change only.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Calling vidioc_s_fmt() calls vidioc_try_fmt() duplicating prinouts.
Breakout try format procedure and call it from both functions.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The set pixelformat field of struct v4l2_pix_format structure was
wrongly converted to PixelFormat by calling v4l2ToDrm(), with an already
converted 'format' argument.
Fix this by calling the right drmToV4l2() conversion function.
Fixes: 0ce8f2390b ("v4l2: v4l2_compat: Add V4L2 compatibility layer")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Commit 29c5508075 ("v4l2: camera_proxy: Create format info array")
introduced usage of the std::array template class, but didn't include
the corresponding header. This may cause a compilation breakage in the
future if the indirect include of <array> disappears due to unrelated
changes. Fix it.
Fixed: 29c5508075 ("v4l2: camera_proxy: Create format info array")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Create a PixelFormatInfo structure to store information about a format,
and add a global array of format info for all the formats currently
supported. Move the format helpers to use the information from the
array.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To clarify code, adopt the following rules for format helpers:
- All variables representing V4L2 pixel formats shall use uint32_t
- All variables representing DRM pixel formats shall use PixelFormat
- Functions returning positive values only shall not have a signed
return type
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Create a new FileOperations structure to hold all the dynamically-loaded
C library file operations. The file operations are now exposed publicly,
to prepare for usage of mmap in the V4L2CameraProxy.
A new template helper function is added to retrieve a symbol with
dlsym() with proper casting to simplify the V4L2CompatManager
constructor.
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>
Now that Object::invokeMethod() supports returning a value, use it and
drop the return value method argument.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Test that a signal can be connected to non-void static and member slots.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Test that Object::invokeMethod() can be used to invoke a non-void
method. Verify that the return value is correctly propagated to the
caller.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Most of the bound method classes are named with a BoundMethod prefix,
except for BoundMemberMethod and BoundStaticMethod. Rename them to
BoundMethodMember and BoundMethodStatic respectively to make the code
more coherent.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
