summaryrefslogtreecommitdiff
path: root/test/camera/buffer_import.cpp
AgeCommit message (Collapse)Author
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: 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-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-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: 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>
2019-11-20test: Extract CameraTest class out of camera tests to libtestLaurent Pinchart
Many tests other than the camera/ tests use a camera. To increase code sharing, move the base CameraTest class to the test library. The class becomes a helper that doesn't inherit from Test anymore (to avoid diamond inheritance issues when more such helpers will exist). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-10-28libcamera: Switch PixelFormat to DRM FourCC valuesJacopo Mondi
Use DRM FourCC values for the newly defined PixelFormat. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-09-16test: buffer_import: Initialize video_ to nullptrJacopo Mondi
When the vivid module used to test buffer importing is not loaded, the test correctly bails out, but during the clean up procedure tries to access the video_ field, which, if not correctly initialized to nullptr contains random values and accessing it causes a segfault. Fix this by initializing video_ field to nullptr to make sure it is properly handled in cleanup(). Fixes: e1a5873701a9 ("test: camera: Add buffer import and mapping test") Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2019-08-19test: camera: Use the CameraManager from the CameraTest base classLaurent Pinchart
Make the camera manager a protected field of the CameraTest class, and use it instead of CameraManager::instance() in the camera tests. This prepares for the removal of CameraManager::instance(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2019-08-11libcamera: pipeline: vimc: Switch to using the RGB/YUV Capture video nodeNiklas Söderlund
Linux commit 85ab1aa1fac17bcd ("media: vimc: deb: fix default sink bayer format") which is part of v5.2 changes the default media bus format for the debayer subdevices. This leads to a -EPIPE error when trying to use the raw capture video device nodes. Fix this by moving the vimc pipeline to use the RGB/YUV Capture capture video node. As a consequence of this change the scaler in the vimc pipeline is used and a hard coded upscale of 3 is present in the video pipeline. This limits the sizes exposed and accepted by libcamera to multiples of 3. Update the buffer import test case to match this new format constraint by setting the resolution to 1920x1080, a resolution which works with both vimc and vivid. With this new resolution the buffer import test takes a bit more time to complete 60 buffers and it's runtime also needs to be increased. The raw capture video node still needs to be handled by the pipeline as its format needs to be updated to allow the pipeline format validation to pass. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-08-01test: camera: buffer_import: clear video pointerKieran Bingham
The FrameSink::cleanup() call checks if video_ is set before cleaning up and then deleting the object. If the cleanup() call is called twice for any reason, this will encounter a use-after-free as the video_ pointer is not cleared after deletion. Whilst cleanup() is not currently called twice consecutively, to prevent errors in the future, make it explicit that the object has been deleted by clearing the stale pointer. 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>
2019-07-14test: camera: Add buffer import and mapping testJacopo Mondi
Test buffer importing and mapping by streaming the VIMC camera to VIVID video output device performing zero-copy memory sharing using dmabuf file descriptors. The test cycle 20 buffers between the camera and the output with a 1:1 buffer index to dmabuf fd mapping, then randomises the mapping with the same number of buffers on each side for 20 more frames, to finally increase the number of buffers on the output side for the 20 last frames. No remapping of dmabuf fd to buffer index should occur for the first 40 frames. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>