summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
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>
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-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>
2020-01-08v4l2: camera_proxy: Include <array>Laurent Pinchart
Commit 29c5508075c1 ("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: 29c5508075c1 ("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>
2020-01-07v4l2: camera_proxy: Create format info arrayLaurent Pinchart
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>
2020-01-07v4l2: camera_proxy: Rationalize arguments to format helpersLaurent Pinchart
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>
2020-01-07v4l2: compat_manager: Move file operations to new struct FileOperationsLaurent Pinchart
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>
2020-01-07v4l2: Use Object::invokeMethod() return valueLaurent Pinchart
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>
2020-01-07libcamera: bound_method: Propagate method return valueLaurent Pinchart
Propagate the return value of the bound method all the way to the caller of activate(). The value is stored in the arguments pack for indirect invocation. As C++ doesn't allow instantiating a variable of type void, we need to specialize the template class BoundMethodPack for methods returning void. This in turn requires template specialization for the BoundMethodArgs class in order to store the return value in the pack, and for the BoundMemberMethod class to extract the return value from the pack. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07libcamera: bound_method: Manage BoundMethodPack through std::shared_ptrLaurent Pinchart
The bound method arguments pack will need to be accessed by the method invoker in order to retrieve the method return value when using a blocking connection type. We thus can't delete the pack unconditionally in the bound method target thread. We also can't delete it unconditionally in the invoker's thread, as for queued connections the pack will be used in the target thread after the invoker completes. This shows that ownership of the arguments pack is shared between two contexts. As a result, manage it using std::shared_ptr<>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07libcamera: bound_method: Support bindings to non-void methodsLaurent Pinchart
The bound method implementation is restricted to binding to void methods as return values are not supported. This complicates usage of bound methods, as non-void methods used a slots or Object::invokeMethod() targets need to be wrapped in a void method. Simplify this by supporting arbitrary return types and ignoring the return value. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>