summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-18checkstyle: Add support for checking style on amendmentsNicolas Dufresne
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>
2020-01-18checkstyle: Add support for checking style on staged changesNicolas Dufresne
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>
2020-01-18checkstyle: Introduce a Commit classNicolas Dufresne
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>
2020-01-18checkstyle: Exit with 1 status if issues are foundNicolas Dufresne
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>
2020-01-18checkstyle: Move from pep8 to pycodestyleNicolas Dufresne
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>
2020-01-17README: Remove duplicated lineLaurent Pinchart
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>
2020-01-17meson: Bump required version to 0.47Nicolas Dufresne
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>
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-13rkisp1: add pipeline test for rkisp1Show Liu
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>
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-12test: camera: buffer_import: Update to FrameBuffer restrictionsNiklas Söderlund
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>
2020-01-12test: v4l2_videodevice: Switch to FrameBuffer interfaceNiklas Söderlund
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>
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>
2020-01-12libcamera: v4l2_videodevice: Extract exportDmabufFd()Niklas Söderlund
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>
2020-01-12libcamera: v4l2_videodevice: Align which type variable is used in queueBuffer()Niklas Söderlund
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>
2020-01-12libcamera: buffer: Drop private function setRequest()Niklas Söderlund
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>
2020-01-12libcamera: buffers: Remove Plane classNiklas Söderlund
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>
2020-01-12libcamera: buffer: Switch from Plane to FrameBuffer::PlaneNiklas Söderlund
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>
2020-01-12ipa: Switch to FrameBuffer interfaceNiklas Söderlund
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>
2020-01-12libcamera: buffer: Add FrameBuffer interfaceNiklas Söderlund
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>
2020-01-12libcamera: buffer: Add FrameMetadata container for metadata informationNiklas Söderlund
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>
2020-01-12v4l2: camera_proxy: Call V4L2Camera::getBufferFd() directlyLaurent Pinchart
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>
2020-01-12v4l2: camera: Handle memory mapping of buffers directlyNiklas Söderlund
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>
2020-01-12v4l2: Rename FrameMetadata to V4L2FrameMetadataNiklas Söderlund
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>
2020-01-12test: file_descriptor: Add testNiklas Söderlund
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>
2020-01-12libcamera: Add FileDescriptor to help pass numerical fds aroundNiklas Söderlund
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>
2020-01-12libcamera: request: remove prepare()Niklas Söderlund
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>
2020-01-09v4l2: camera_proxy: Fix compilation error use of undeclared identifier 'ret'Niklas Söderlund
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: fce110c6d961c3bb ("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>
2020-01-08v4l2: camera_proxy: Align trace message styleJacopo Mondi
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>
2020-01-08v4l2: camera_proxy: Break out try_fmtJacopo Mondi
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>
2020-01-08v4l2: camera_proxy: Fix try_fmt format conversionJacopo Mondi
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: 0ce8f2390b52 ("v4l2: v4l2_compat: Add V4L2 compatibility layer") Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>