summaryrefslogtreecommitdiff
path: root/src/libcamera/pipeline/rkisp1/rkisp1_path.cpp
AgeCommit message (Collapse)Author
2022-08-03libcamera: v4l2_videodevice: Reintroduce toV4L2PixelFormat()Jacopo Mondi
This is a partial revert of commit 395d43d6d75b ("libcamera: v4l2_videodevice: Drop toV4L2PixelFormat()") The function was removed because it incorrectly maps non-contiguous V4L2 format variants (ie V4L2_PIX_FMT_YUV420M) to the API version supported by the video device (singleplanar API and multiplanar API). It was decided at the time to remove the function and let its users call directly V4L2PixelFormat::fromPixelFormat() which accepts a 'multiplanar' flags. As we aim to associate multiple V4L2PixelFormat to a single libcamera format, the next patches will verify which of them is actually supported by the video device. For now, return the contiguous version unconditionally. Re-introduce V4L2VideoDevice::toV4L2PixelFormat() and convert all the V4L2PixelFormat::fromPixelFormat() users to use it. The V4L2 compatibility layer is the only outlier as it doesn't have a video device to poke, hence it still uses V4L2PixelFormat::fromPixelFormat(). Next patches will implement the device format matching logic and handle the non-contiguous plane issue in V4L2VideoDevice::toV4L2PixelFormat(). Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-05-04libcamera: Replace toString with operator<<() for format classesLaurent Pinchart
Now that format classes implement the stream formatting operator<<(), use it instead of the toString() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-05-04libcamera: Replace toString with operator<<() for geometry classesLaurent Pinchart
Now that geometry classes implement the stream formatting operator<<(), use it instead of the toString() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-03-25pipeline: rkisp1: Match sensor aspect ratio when generating configurationsLaurent Pinchart
The RkISP1Path::generateConfiguration() function limits the maximum resolution to the sensor resolution, to avoid upscaling. It however doesn't take the sensor aspect ratio into account, which leads to a maximum (and default) resolution of 1920x1920 when using the self path with a sensor that has a higher resolution. Fix it by constraining the minimum and maximum resolutions to match the sensor's aspect ratio. 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-07libcamera: v4l2_videodevice: Drop toV4L2PixelFormat()Laurent Pinchart
The V4L2VideoDevice::toV4L2PixelFormat() function is incorrectly implemented, as it will pick a multi-planar format if the device supports the multi-planar API, even if only single-planar formats are supported. This currently works because the implementation calls V4L2PixelFormat::fromPixelFormat(), which ignores the multiplanar argument and always returns a single-planar format. Fixing this isn't trivial. As we don't need to support multi-planar V4L2 formats at this point, drop the function instead of pretending everything is fine, and call V4L2PixelFormat::fromPixelFormat() directly from pipeline handlers. As the single-planar case is the most common, set the multiplanar argument to false by default to avoid long lines. 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> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2020-12-09libcamera: v4l2_device: Return a unique pointer from fromEntityName()Laurent Pinchart
The fromEntityName() function returns a pointer to a newly allocated V4L2Device instance, which must be deleted by the caller. This opens the door to memory leaks. Return a unique pointer instead, which conveys the API semantics better than a sentence in the documentation. 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-12-09libcamera: v4l2_subdevice: Return a unique pointer from fromEntityName()Laurent Pinchart
The fromEntityName() function returns a pointer to a newly allocated V4L2Subdevice instance, which must be deleted by the caller. This opens the door to memory leaks. Return a unique pointer instead, which conveys the API semantics better than a sentence in the documentation. 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-11-23libcamera: pipeline: rkisp1: fix crop configurationHelen Koike
Crop rectangle was not being configured on the isp output pad nor in the resizer input pad, causing an unecessary crop in the image and an unecessary scaling by the resizer when streaming with a higher resolution then the default 800x600. Example: cam -c 1 -C -s width=3280,height=2464 In the pipeline: sensor->isp->resizer->dma_engine isp output crop is set to 800x600, which limits the output format to 800x600, which is propagated to the resizer input format set to 800x600, and the resizer output format is set to the desired end resolution 3280x2464. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-11-07libcamera: Drop unnecessary explicit initialization of V4L2DeviceFormatLaurent Pinchart
The V4L2DeviceFormat class now has default initializers for all members, explicit initialization isn't needed anymore. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-10-01libcamera: pipeline: rkisp1: Add support for XRGB8888Niklas Söderlund
The self path supports XRGB8888, list it as a supported format. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-10-01libcamera: pipeline: rkisp1: Add support for R8Niklas Söderlund
Both the main and self path support R8, list it as a supported format. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-10-01libcamera: pipeline: rkisp1: Add support for RGB656Niklas Söderlund
The self path supports RGB565, list it as a supported format. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-10-01libcamera: pipeline: rkisp1: Fix media bus propagation for NV{12,21}Niklas Söderlund
The upstream driver has changed how the link formats are validated when starting to stream [1]. This revealed that libcamera did not adjust the media bus format from the link between {main,self} resizer source pad and the capture video device as expected by the driver. The media bus code YUYV8_2X8 was hardcoded to MEDIA_BUS_FMT_YUYV8_2X8 for all pixel formats while it must be adjusted to YUYV8_1_5X8 for NV12 and NV21, fix this. 1. 6803a9e0e1e43e9e ("media: staging: rkisp1: cap: simplify link validation by comparing media bus code") Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-10-01libcamera: pipeline: rkisp1: Remove support for YVYU and VYUYNiklas Söderlund
The upstream driver has dropped support for YVYU and VYUY [1], remove support from the pipeline handler. 1. 3acb3e06baf64e28 ("media: staging: rkisp1: cap: remove unsupported formats") Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-09-30libcamera: pipeline: rkisp1: Move path link handling to RkISP1PathNiklas Söderlund
Move the path link handling to RkISP1Path, there is no functional change. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-09-30libcamera: pipeline: rkisp1: Move start and stop of path to RkISP1PathNiklas Söderlund
Move the start and stop of a path to RkISP1Path. This allows the importing of buffers to be moved closer the path start/stop simplifying the code. Also by adding a simple running tracker the error logic in PipelineHandlerRkISP1 can be simplified as stop() can always be called. This also removes all external users of RkISP1Path::video_ so it can be made private. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-09-30libcamera: pipeline: rkisp1: Move path configuration generation and ↵Niklas Söderlund
validation to RkISP1Path Move the path configuration generation and validation to RkISP1Path. This is done to increase code reuse and to encapsulate the main and self path differences inside the RkISP1Path class. There is no functional change. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-09-30libcamera: pipeline: rkisp1: Move path configuration to RkISP1PathNiklas Söderlund
Move the path configuration to RkISP1Path to increase code reuse and make the V4L2 subdevice resizer private to the path. There is no functional change. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-09-30libcamera: pipeline: rkisp1: Breakout basic path handling to own classNiklas Söderlund
The self and main paths are very similar and the introduction of support for two simultaneous streams have made it clear their handling could be abstracted in a separate class. This is the first step to create such a class by breaking out the initialization and storage of the video and subdevices. There is no functional change in this patch. 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>