summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-09-22qcam: format_converter: Add configurable stride supportLaurent Pinchart
Make the stride configurable to support conversion of images with padding at the end of lines. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-22qcam: viewfinder: Pass stride value to viewfinderLaurent Pinchart
qcam currently assumes that no padding is used at end of lines, and uses the image width as the stride. This leads to rendering failures with some formats on some platforms. To prepare for stride support, add a stride parameter to the ViewFinder::setFormat() function to pass the stride from the stream configuration to the viewfinder. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-22android: camera_device: Configure one stream for identical stream requestsHirokazu Honda
An Android HAL client may request multiple identical streams. It is redundant that a native camera device produces a separate stream for each of the identical requests. Configure the camera with a single stream in that case. The other identical HAL streams will be produced by the YUV post-processor. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-22android: camera_stream: Support PostProcessorYuv in CameraStreamHirokazu Honda
CameraStream creates PostProcessorYuv if the destination format is NV12. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-22android: camera_stream: Create post processor in configure()Hirokazu Honda
CameraStream creates PostProcessor and FrameBufferAllocator in the constructor. CameraStream assumes that a used post processor is JPEG post processor. Since we need to support various post processors, we would rather move the creation to configure() so as to return an error code if no proper post processor is found. This also moves FrameBufferAllocator and Mutex creation for consistency. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-21android: jpeg: Rectify variable naming style.Umang Jain
Rectify variable renaming style for YPlaneSize, UVPlaneSize. libcamera uses camelCase where first letter should be in lower case. Fixes: e355ca0087cd9("android: jpeg: Split and pass the thumbnail planes to encoder") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-21android: yuv: Remove CameraDevice forward-declareUmang Jain
YUV post-processor doesn't need any instance reference from CameraDevice class. Remove it. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-19libcamera: base: Add libatomic dependencyFabrice Fontaine
Add libatomic dependency which is needed since the addition of the base support library in commit 27aff949fbc1 ("libcamera/base: Move extended base functionality") to avoid the following build failure: /tmp/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/9.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: src/libcamera/base/libcamera-base.so.p/message.cpp.o: in function `libcamera::Message::registerMessageType()': message.cpp:(.text+0x290): undefined reference to `__atomic_fetch_add_4' Fixes: 27aff949fbc1 ("libcamera/base: Move extended base functionality") Fixes: http://autobuild.buildroot.org/results/6e3471df8e9312a1789ca05ae70cc2283bfeec23 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-19test: v4l2_compat: Report test as skipped if no compatible driver foundLaurent Pinchart
The V4L2 compatibility layer test includes a list of supported devices, as V4L2 compatibility isn't officially supported with all devices yet. If no supported device is present, the test reports success, while it actually hasn't run. Report it being skipped in that case. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-15test: serialization: Prevent parallelisationKieran Bingham
The ipa_data_serializer_test is configured to be able to run in parallel with other tests. If the test tries to acquire the VIMC sensor B while it is in use, it would skip require skipping the test. Instead, inform meson that it can not be run in parallel to ensure that the test is able to obtain the resources it requires for execution. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-14libcamera: v4l2_videodevice: Handle unexpected buffersKieran Bingham
A kernel bug can lead to unexpected buffers being dequeued where we haven't entered the buffer in our queuedBuffers_ list. This causes invalid accesses if not handled correctly within libcamera, and while it is a kernel issue, we can protect against unpatched kernels to provide a more suitable error message. This is fixed in the kernel by commit c592b46907ad ("media: videobuf2-core: dequeue if start_streaming fails") [0] [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c592b46907ad Handle unexpected buffers by returning a nullptr, and move cache management after the validation of the buffer. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-14ipa: ipu3: Clear incoming parameter use flagsKieran Bingham
The incoming params buffer may contain uninitialised data, or the parameters of previously queued frames. Clearing the entire buffer may be an expensive operation, and the kernel will only read from structures which have their associated use-flag set. It is the responsibility of the algorithms to set the use flags accordingly for any data structure they update during prepare(). Clear the use flags of the parameter buffer before passing the buffer to the algorithms during their prepare() operations. Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-14README: Fix android dependenciesKieran Bingham
While the distribution is unspecified, The README.rst gives debian/ubuntu named dependencies for all except the android requirements. Update the android dependencies to match the others, by showing that the -dev package is required. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-10utils: ipc: proxy worker: Fix indentation in call deserializationPaul Elder
The indentation of the deserialization call on the proxy worker side inside the case statement was one level too shallow. Fix it. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-10test: v4l2_compat_test: Fix v4l2-compliance version parsingPaul Elder
v4l2-compliance changed their version string: v4l2-compliance 1.21.0-4618 v4l2-compliance SHA: cc211b76476aca2c072ffa83a9b003957d5f3909, 64 bits, 64-bit time_t v4l2-compliance 1.21.0-4838, 64 bits, 64-bit time_t The current parsing takes the last result of split, which works for the former, but not the latter. Take the second result of split instead, and strip away any commas. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-10v4l2: v4l2_camera_proxy: Set the compressed flag in enum_fmtPaul Elder
Set the compressed flag in ENUM_FMT if the format is MJPEG. As the only compressed format that libcamera currently supports is MJPEG, this should be sufficient. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10v4l2: v4l2_camera_proxy: Report the proper format name in enum_fmtPaul Elder
Now that libcamera has the V4L2 format names, retrieve and report those names in ENUM_FMT. While at it, refactor the code slightly with PixelFormatInfo. This fixes the test failures on v4l2-compliance with the v4l2 compatilibity layer that were observed in version v4l2-compliance version 1.21.0-4838. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10libcamera: v4l2_pixelformat: Add helper function to get the descriptionPaul Elder
Add a helper function to V4L2PixelFormat for retrieving the V4L2 description string. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10libcamera: v4l2_pixelformat: Add entries for NV24 and NV42Paul Elder
The entries for NV24 and NV42 were missing from the V4L2PixelFormat map. Add them. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10libcamera: v4l2_pixelformat: Add V4L2 description stringsPaul Elder
Add V4L2 description strings to the map of V4L2 formats. To achieve this, create an Info struct to wrap them. Update the one current user of the old map. This will be used later in the V4L2 compatibility layer to report the V4L2 format description. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10v4l2: v4l2_compat_manager: Don't print "camera not found" on openat()Paul Elder
Some applications (like Firefox) run open() many times on video device nodes. This may lead to user confusion when they see "INFO V4L2Compat v4l2_compat_manager.cpp:146 No camera found for /dev/videoX" over and over again. Lower the log level to debug so that we can still get this information on debug, and so users won't see it all the time. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-09android: jpeg: Split and pass the thumbnail planes to encoderUmang Jain
After multi-planar support was introduced for jpeg encoding as well, EncoderLibJpeg::encode() expects a vector of planes as the source of framebuffer to be encoded. Currently, we are passing a contiguous buffer which is treated as only one plane (instead of two, as thumbnail is NV12). Hence, split the thumbnail data into respective planes according to NV12. This fixes a crash in encoding of thumbnails. Fixes: 894ca69f6043("android: jpeg: Support multi-planar buffers") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-09libcamera: controls: Use a const ControlValidatorKieran Bingham
The ControlValidator passed to a ControlList constructor is used, but not modified. Make it const. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-09test: gstreamer: Fix the destructor of GstreamerTest base classVedant Paranjape
The destructor tried to check if pipeline_ is a parent of libcameraSrc_. This was needed to be checked as if it is, cleanup of libcameraSrc_ would be handled by pipeline itself. Since, the destructor can be called anytime, even when pipeline_ hasn't been created, the use of pipeline_ to check if libcameraSrc_ has an ancestor as pipeline_ caused a segmentation fault. Fixes: f58768092277 ("test: gstreamer: Fix the destructor of GstreamerTest base class") Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-09android: mm: cros_camera_buffer: Log failure error on cleanupUmang Jain
Failure can still happen by CameraBufferManager during Unlock() and/or Deregister() of camera3Buffer handles. We should be logging those errors as well. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-08test: gstreamer: Factor out code into a base classVedant Paranjape
A lot of code used in the single stream test is boiler plate and common across every gstreamer test. Factor out this code into a base class called GstreamerTest. Also update the gstreamer_single_stream_test to use the GstreamerTest base class. Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-07v4l2: Sum bytesused for all planes when dequeuing bufferLaurent Pinchart
The V4L2 compatibility layer supports the single-planar API only, and thus exposes a single V4L2 buffer plane to applications, regardless of the number of planes in the FrameBuffer. For multi-planar frame buffers, the bytesused value isn't correct as it only takes the first plane into account. Fix it by summing the bytesused values for all FrameBuffer planes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-07qcam: viewfinder_qt: Support multi-planar buffersLaurent Pinchart
Now that the ViewFinderQt receives an Image, move the Converter API to take an Image as well, and enable multi-planar buffer support. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07qcam: viewfinder_gl: Support multi-planar buffersLaurent Pinchart
Now that the ViewFinderGL receives an Image, it can trivially support multi-planar buffers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07qcam: Use Image class to access pixel dataLaurent Pinchart
Replace the manual implementation of frame buffer mapping with the Image class to improve code sharing. The ViewFinder API is updated to take an Image pointer in the render() function to prepare for multi-planar buffer support. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07qcam: Print bytesused for all planesLaurent Pinchart
Fix the debug message that prints frame metadata to print the number of bytes used for each plane, not just the first one. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: drm: Avoid importing the same dmabuf multiple timesLaurent Pinchart
When creating a DRM frame buffer, the dmabufs for the planes are imported as GEM objects. For multi-planar formats, all planes may use the same dmabuf, which results in multiple imports. This doesn't cause any issue at import time, as DRM detects this situation and returns the same GEM object. However, when destroying the frame buffer, the same GEM object ends up being closed multiple times, which generates an error. Fix this by avoiding multiple imports of the same dmabuf for the same frame buffer. While the issue may theoretically occur with identical dmabufs for different frame buffers, this is quite unlikely and is thus not addressed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: drm: Set per-plane offsets when creating DRM frame bufferLaurent Pinchart
Now that libcamera supports per-plane offsets, pass the values to drmModeAddFB2(). The KMS sink in cam is now capable of rendering multi-planar formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: drm: Support per-plane stride valuesLaurent Pinchart
The stride is not always identical for all planes for multi-planar formats. Semi-planar YUV formats without horizontal subsampling often have a chroma stride equal to twice the luma stride, and tri-planar YUV formats with a 1/2 horizontal subsampling often have a chroma stride equal to half the luma stride. This isn't correctly taken into account when creating a DRM frame buffer, as the same stride is set for all planes. libcamera doesn't report per-plane stride values yet, but uses chroma strides that match the above description for all currently supported platforms. Calculation the chrome strides appropriately in the KMSSink class, and pass them to DRM::createFrameBuffer(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: file_sink: Use Image class to access pixel dataLaurent Pinchart
Replace the manual implementation of frame buffer mapping with the Image class to improve code sharing. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: Add Image classLaurent Pinchart
The new Image class represents a multi-planar image with direct access to pixel data. It currently duplicates the function of the MappedFrameBuffer class which is internal to libcamera, and will serve as a design playground to improve the API until it is considered ready to be made part of the libcamera public API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07android: jpeg: Support multi-planar buffersLaurent Pinchart
The JPEG post-processor uses MappedFrameBuffer to access pixel data, but only uses data from the first plane. Pass the vector of planes to the encode() function to correctly handle multi-planar formats (currently limited to NV12). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07android: jpeg: Use stride instead of image width for line addressLaurent Pinchart
When calculating the luma line address, the image width is used instead of the stride. Without padding at the end of the line the the values should be identical, but this is conceptually incorrect in any case. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-07android: camera_device: Don't assume all planes use the same fdLaurent Pinchart
Now that libcamera correctly supports frame buffers with different dmabuf for each plane, remove the assumption that a single dmabuf is used. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: framebuffer: Prevent modifying the number of metadata planesLaurent Pinchart
The number of metadata planes should always match the number of frame buffer planes. Enforce this by making the vector private and providing accessor functions. As this changes the public API, update all in-tree users accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: framebuffer: Allocate metadata planes at construction timeLaurent Pinchart
The metadata planes are allocated by V4L2VideoDevice when dequeuing a buffer. This causes the metadata planes to only be allocated after a buffer gets dequeued, and doesn't provide any strong guarantee that their number matches the number of FrameBuffer planes. The lack of this invariant makes the FrameBuffer class fragile. As a first step towards fixing this, allocate the metadata planes when the FrameBuffer is constructed. The FrameMetadata API should be further improved by preventing a change in the number of planes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: v4l2_videodevice: Use utils::enumerate()Laurent Pinchart
Replace a manual counter with the utils::enumerate() utility function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: v4l2_videodevice: Split planes when dequeuing bufferLaurent Pinchart
When dequeueing a buffer from a V4L2VideoDevice, the number of planes in the FrameBuffer may not match the number of V4L2 buffer planes if the PixelFormat is multi-planar (has multiple colour planes) and the V4L2 format is single-planar (has a single buffer plane). In this case, we need to split the single V4L2 buffer plane into FrameBuffer planes. Do so, and add checks to reject invalid V4L2 buffers in case of a driver issue. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: v4l2_videodevice: Coalesce planes when queuing bufferLaurent Pinchart
When queueing a buffer to a V4L2VideoDevice, the number of planes in the FrameBuffer may not match the number of V4L2 buffer planes if the PixelFormat is multi-planar (has multiple colour planes) and the V4L2 format is single-planar (has a single buffer plane). In this case, we need to coalesce all FrameBuffer planes into a single V4L2 buffer plane. Do so, and add validity checks to reject frame buffers that can't be described using a single V4L2 buffer plane. This change prepares for proper multi-planar support, but isn't expected to result in a change of behaviour with existing pipeline handlers, as none of them queue an output buffer with multiple FrameBuffer planes or use non-contiguous buffers for either capture or output. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: v4l2_videodevice: Take stride into account to compute offsetsLaurent Pinchart
When creating FrameBuffer instances, the V4L2VideoDevice computes plane offsets using minimal stride for the format. This doesn't always produce a valid result when the device requires padding at the end of lines. Fix it by computing offsets using the stride reported by V4L2. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: v4l2_videodevice: Document plane handling in createBuffer()Laurent Pinchart
The V4L2VideoDevice::createBuffer() calculates offsets manually when using a multi-planar pixel format and a single-planar V4L2 format. The process isn't trivial, document it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: v4l2_videodevice: Cache PixelFormatInfoLaurent Pinchart
Cache the PixelFormatInfo instead of looking it up in every call to createBuffer(). This prepares for usage of the info in queueBuffer(), to avoid a looking every time a buffer is queued. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: framebuffer: Add a function to check if planes are contiguousLaurent Pinchart
Multi-planar frame buffers can store their planes contiguously in memory, or split them in discontiguous memory areas. Add a private function to check in which of these two categories the frame buffer belongs. This will be used to correctly handle the differences between the V4L2 single and multi planar APIs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: framebuffer: Move planes check to constructorLaurent Pinchart
The FrameBuffer::planes() function checks that planes are correctly initialized with an offset. This can be done at construction time instead, as the planes are constant. The backtrace generated by the assertion will show where the faulty frame buffer is created instead of where it is used, easing debugging. As the runtime overhead is reduced, there's no real need to drop the assertion in the future anymore, it can be useful to ensure that the planes are correctly populated by the caller. Drop the comment that calls for removing the check. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: formats: Support V4L2 non-contiguous formatsLaurent Pinchart
V4L2 describes multi-planar formats with different 4CCs depending on whether or not the planes are stored contiguously in memory. Support this when translating between PixelFormat and V4L2PixelFormat. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>