summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2020-02-13libcamera: ipa_manager: Use utils::split()Laurent Pinchart
Replace the custom string splitting implementation with utils::split(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [Kieran: Re-fit to master branch] Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-02-13libcamera: utils: Add string splitter utility functionLaurent Pinchart
Add a utils::split() function that splits a string for the purpose of iterating over substrings. It returns an object of unspecified type that can be used in range-based for loops. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-02-13libcamera: pipeline: rkisp1: sync topology with upstream driverHelen Koike
rkisp1 kernel driver was merged upstream with minor changes in the topology from the original driver libcamera based it's first support to rkisp1. Adapt libcamera pipeline to work with upstream driver. * Remove subdevice dphy from the pipeline. * Add resizer in the pipeline. * Fix links. * Update entity names. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13android: Remove internal threadLaurent Pinchart
Now that libcamera creates threads internally and doesn't rely on an application-provided event loop, remove the thread from the Android Camera HAL layer. The CameraProxy class becomes meaningless, remove it and communicate directly from the CameraHalManager to the CameraDevice. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org>
2020-02-13v4l2: Remove internal threadLaurent Pinchart
Now that libcamera creates threads internally and doesn't rely on an application-provided event loop, remove the thread from the V4L2 compatibility layer. The split between the V4L2CameraProxy and V4L2Camera classes is still kept to separate the V4L2 adaptation from camera operation. This may be further refactored later. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13libcamera: pipeline_handler: Document the threading modelLaurent Pinchart
Document the threading model of the PipelineHandler class (and all its derived classes). The model is already enforced by the Camera class, so no change in the implementation is required. As for the Camera class, disconnection is currently left out. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13libcamera: camera: Implement the threading modelLaurent Pinchart
Document the threading model of the Camera class and implement it. Selected functions become thread-safe, and require a few functions of the PipelineHandler class to be called through cross-thread invocation as the pipeline handlers live in the camera manager thread, while the Camera class is mostly accessed from the application thread. The PipelineHandler is made to inherit from the Object class to support this. Disconnection is currently left out as it is not implemented in pipeline handlers, and isn't fully supported in the Camera class either. This will be revisited when implementing proper hotplug support. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13libcamera: camera_manager: Run the camera manager in a threadLaurent Pinchart
Relying on the application event loop to process all our internal events is a bad idea for multiple reasons. In many cases the user of libcamera can't provide an event loop, for instance when running through one of the adaptation layers. The Android camera HAL and V4L2 compatibility layer create a thread for this reason, and the GStreamer element would need to do so as well. Furthermore, relying on the application event loop pushes libcamera's realtime constraints to the application, which isn't manageable. For these reasons it's desirable to always run the camera manager, the pipeline handlers and the cameras in a separate thread. Doing so isn't too complicated, it only involves creating the thread internally when starting the camera manager, and synchronizing a few methods of the Camera class. Do so as a first step towards defining the threading model of libcamera. The event dispatcher interface is still exposed to applications, to enable cross-thread signal delivery if desired. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13libcamera: signal: Make connection and disconnection thread-safeLaurent Pinchart
Make the signal connection and disconnection thread-safe, and document them as such. This is required to make objects connectable from different threads. The connect(), disconnect() and emit() methods are now all protected by a global mutex, which may generate a high lock contention. This could be improved with finer-grained locks or with a pool of mutexes. 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>
2020-02-13libcamera: Document thread-safety attributes of core classesLaurent Pinchart
Define the thread-safety attributes of the classes and methods that are either thread-safe or thread-bound. The CameraManager, Camera and PipelineHandler will be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-13libcamera: Define the threading modelLaurent Pinchart
Document the design of libcamera's threading support, and prepare to document thread-safety of classes and functions with a doxygen alias command. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-02-11qcam: Switch default stream role to viewfinderNaushir Patuck
qcam currently only displays a standard viewfinder. As such set the StreamRole parameter to Viewfinder so that the pipeline handlers can setup the appropriate resolutions and formats. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-02-10libcamera: ipa_module: Use ElfW() macro for native word sizeLaurent Pinchart
Access the ELF types corresponding to the native word size using the ElfW() macro instead of template types. This is the standard method and simplifies the code. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-02-04libcamera: framebuffer_allocator: Fix spellingKieran Bingham
Fix two trivial issues in the documentation of the FrameBufferAllocater class. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-02-04libcamera: pipeline_handler: Fix the compilation issue in muslMadhavan Krishnan
sys/sysmacros.h was an incorrect choice, which doesn't work with musl. POSIX mandates dev_t to be defined by sys/types.h, so utilise that header instead. Fixes: effe4d6ced88 ("libcamera: camera_manager, pipeline_handler: allow retrieving cameras by device numbers") Signed-off-by: Madhavan Krishnan <madhavan.krishnan@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-01-31libcamera: log: Expand log level namesKieran Bingham
When the log severity names were added, there was only 4 characters reserved for their printing. When the FATAL level was added, this increased to 5, and thus both DBG and ERR can be expanded to their full spelling. This also brings the levels in line with the representation that can be used when calling logSetLevel(). Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-01-23libcamera: camera: Centralize state checks in Private classLaurent Pinchart
Move all accesses to the state_ and disconnected_ members to functions of the Private class. This will make it easier to implement synchronization, and simplifies the Camera class implementation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-23libcamera: camera: Move private data members to private implementationLaurent Pinchart
Use the d-pointer idiom ([1], [2]) to hide the private data members from the Camera class interface. This will ease maintaining ABI compatibility, and prepares for the implementation of the Camera class threading model. The FrameBufferAllocator class accesses the Camera private data members directly. In order to hide them, this pattern is replaced with new private member functions in the Camera class, and the FrameBufferAllocator is updated accordingly. [1] https://wiki.qt.io/D-Pointer [2] https://en.cppreference.com/w/cpp/language/pimpl Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-23libcamera: camera_manager: Return a copy of the vector from cameras()Laurent Pinchart
Making CameraManager::cameras() thread-safe requires returning a copy of the cameras vector instead of a reference. This is also required for hot-plugging support and is thus desirable. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-23libcamera: camera_manager: Move private data members to private implementationLaurent Pinchart
Use the d-pointer idiom ([1], [2]) to hide the private data members from the CameraManager class interface. This will ease maintaining ABI compatibility, and prepares for the implementation of the CameraManager class threading model. [1] https://wiki.qt.io/D-Pointer [2] https://en.cppreference.com/w/cpp/language/pimpl 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>
2020-01-22libcamera: Fix documentation of buffer allocation/export functionsLaurent Pinchart
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>
2020-01-22libcamera: signal: Make slots list privateLaurent Pinchart
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>
2020-01-22libcamera: Declare static local variables as const where applicableLaurent Pinchart
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>
2020-01-20libcamera: bound_method: Avoid deadlock with ConnectionTypeBlockingLaurent Pinchart
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>
2020-01-20qcam: Support scaling of the viewfinderLaurent Pinchart
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>
2020-01-20libcamera: log: Print the thread ID in the logLaurent Pinchart
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>
2020-01-20libcamera: thread: Add a method to return the ID of the current threadLaurent Pinchart
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>
2020-01-20v4l2: Extend device caps with V4L2_CAP_STREAMINGNicolas Dufresne
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>
2020-01-16libcamera: Remove std::piecewise_construct where not necessaryLaurent Pinchart
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>
2020-01-14libcamera: Switch from utils::make_unique to std::make_uniqueLaurent Pinchart
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>
2020-01-14meson.build: Switch to C++14Laurent Pinchart
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>
2020-01-14libcamera: gen-controls.py: Don't hardcode path to python interpreterLaurent Pinchart
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>
2020-01-14libcamera: ipa_interface: Fix doxygen warningLaurent Pinchart
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>
2020-01-12libcamera: ipa_interface: Document the ownership of dmabufs passed to ↵Niklas Söderlund
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>
2020-01-12libcamera: camera: Remove the prepared stateNiklas Söderlund
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>
2020-01-12libcamera: pipeline: Remove explicit buffer handlingNiklas Söderlund
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>
2020-01-12qcam: Cache buffer memory mappingNiklas Söderlund
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>
2020-01-12cam: Cache buffer memory mappingNiklas Söderlund
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>
2020-01-12libcamera: Remove dead code after switch to FrameBufferNiklas Söderlund
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>
2020-01-12libcamera: v4l2_videodevice: Remove Buffer interfaceNiklas Söderlund
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>
2020-01-12libcamera: Switch to FrameBuffer interfaceNiklas Söderlund
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>
2020-01-12libcamera: allocator: Add FrameBufferAllocator to help applications allocate ↵Niklas Söderlund
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>
2020-01-12libcamera: pipeline: Add FrameBuffer handlersNiklas Söderlund
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>
2020-01-12libcamera: pipeline: ipu3: Switch to FrameBuffer interface for cio2 and statNiklas Söderlund
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>
2020-01-12libcamera: pipeline: rkisp1: Switch to FrameBuffer interface for stat and paramNiklas Söderlund
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>
2020-01-12libcamera: pipeline: rkisp1: Destroy frame information before completing requestNiklas Söderlund
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>
2020-01-12libcamera: v4l2_videodevice: Add FrameBuffer interfaceNiklas Söderlund
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>
2020-01-12libcamera: v4l2_videodevice: Add V4L2BufferCache to deal with index mappingNiklas Söderlund
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>
2020-01-12libcamera: buffer: Move captured metadata to FrameMetadataNiklas Söderlund
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>
2020-01-12libcamera: request: In addBuffer() do not fetch stream from BufferNiklas Söderlund
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>