summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2021-08-31libcamera: camera_sensor: Transform CameraSensor::sizes()Umang Jain
In CameraSensor, the mbusCodes() and sizes() accessor functions retrieves all the supported media bus codes and the supported sizes respectively. However, this is quite limiting since the caller probably isn't in a position to match which range of sizes are supported for a particular mbusCode. Hence, the caller is most likely interested to know about the sizes supported for a particular media bus code. This patch transforms the existing CameraSensor::sizes() to CameraSensor::sizes(mbuscode) to achieve that goal. The patch also transforms existing CIO2Device::sizes() in IPU3 pipeline handler to CIO2Device::sizes(PixelFormat) on a similar principle. The function is then plumbed to CameraSensor::sizes(mbusCode) to enumerate the per-format sizes as required in PipelineHandlerIPU3::generateConfiguration(). Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-30libcamera: framebuffer: Add assertion to detect offset is unfilledHirokazu Honda
The offset variable is introduced to FrameBuffer::Plane. In order to detect that the plane is used while the offset is not set, this adds the assertion to FrameBuffer::planes(). It should be removed in the future. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30android: camera_device: Fill offset and right length in CreateFrameBuffer()Hirokazu Honda
CameraDevice::CreateFrameBuffer() fills the length of the buffer to each FrameBuffer::Plane::length. It should rather be the length of plane. This also changes CreateFrameBuffer() to fill offset of FrameBuffer::Plane. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: v4l2_videodevice: Create color-format planes in createBuffer()Hirokazu Honda
V4L2VideDevice::createBuffer() creates the same number of FrameBuffer::Planes as V4L2 format planes. Therefore, if the v4l2 format single is single-planar format, the created number of FrameBuffer::Planes is 1. It should rather create the same number of FrameBuffer::Planes as the color format planes. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30gstreamer: gstlibcameraallocator: Use offset in creating a bufferHirokazu Honda
The plane length is the length of the plane size. The buffer length to be allocated for a plane is the offset and the length of FrameBuffer::Plane. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30qcam: main_window: Use offset mapping FrameBufferHirokazu Honda
FrameBuffer::Plane has offset info now. This uses the offset in mapping FrameBuffer in MainWindow. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30ipa: rkisp1: Use offset in mapping IPABufferHirokazu Honda
IPABuffer is represented by FrameBuffer. FrameBuffer::Plane has now an offset. This uses the offset variable to map the IPABuffer. The mapped IPABuffer is represented and managed as MappedFrameBuffer. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30cam: file_sink: Use offset in mapping FrameBufferHirokazu Honda
This fixes the way of mapping FrameBuffer in FrameSink by using offset. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: mapped_framebuffer: Return plane begin address by ↵Hirokazu Honda
MappedBuffer::maps() MappedBuffer::maps() returns std::vector<MappedBuffer::Plane>. Plane has the address, but the address points the beginning of the buffer containing the plane. This makes the Plane point the beginning of the plane. So MappedBuffer::maps()[i].data() returns the address of i-th plane. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: framebuffer: Add offset to FrameBuffer::PlaneHirokazu Honda
This adds offset to FrameBuffer::Plane. It enables representing frame buffers that store planes in the same dmabuf at different offsets, as for instance required by the V4L2 NV12 pixel format. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27libcamera: camera configuration: Add at() function in docJacopo Mondi
The documentation suggests to use CameraConfiguration::operator[] to access the StreamConfiguration it contains, but as CameraConfiguration instances are generated by the Camera class and are returned wrapped in a unique_ptr<>, the usage of operator[] would require an awkward syntax such as (*config)[i]. Better to suggest the usage of the CameraConfiguration::at() function instead to access the StreamConfigurations. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: camera_buffer: Add stride/offset/size functionHirokazu Honda
This adds getter functions of stride, offset and size to CameraBuffer interface. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: camera_buffer: Map buffer in the first plane() callHirokazu Honda
CameraBuffer implementation maps a given buffer_handle_t in constructor. Mapping is redundant to only know the plane info like stride and offset. Mapping should be executed later in the first plane() call. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27android: generic_camera_buffer: Correct buffer mappingHirokazu Honda
buffer_handle_t doesn't provide sufficient info to map a buffer properly. cros::CameraBufferManager enables handling the buffer on ChromeOS, but no way is provided for other platforms. Therefore, we put the assumption that planes are in the same buffer and they are consecutive. This modifies the way of mapping in generic_camera_buffer with the assumption. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-26gstreamer: Fix usage of default size for fixationNicolas Dufresne
Pipeline managers sets a default value to StreamConfiguration::size. The original fixation code was attempting to use it, but as it was truncating the caps to its first structure it would never actually find a best match. In this patch, instead of truncating, we weight various matches using the product of the width and height delta. We also split delta from ranges apart and prefer fixed size over them as ranges are not reliable. This patch also removes the related todo, as it seems that libcamera core won't go further then providing this default value and won't be sorting the format and size lists. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-26libcamerasrc: Fix deadlock on EOSNicolas Dufresne
It's not allowed in GStreamer to push events while holding the object lock. This reduce the scope into which we hold the object lock. In fact we don't need to protect against gst_task_resume() concurrency when we stop the task as resume only do something if the task is paused. This fixes a deadlock when running multiple instances of libcamerasrc and closing one of the streaming window. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-26gstreamer: Fix concurrent access issues to CameraManagerNicolas Dufresne
It's not allowed to have multiple instances of CameraManager. This requirement is not easy for GStreamer were the device monitor and the camerasrc, or two camerasrc instances don't usually have any interaction between each other. Fix this by implementing a minimalist singleton around CameraManager constructor and start()/stop() operations. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-26gstreamer: Fix deadlock when last allocator ref is held by bufferNicolas Dufresne
This deadlock occurs when a buffer is holding the last reference on the allocator. In gst_libcamera_allocator_release() we must drop the object lock before dropping the last ref of that object since the destructor will lock it again causing deadlock. This was notice while switching camera or resolution in Cheese software. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-23ipa: ipu3: awb: remove local storage of the gridJean-Michel Hautbois
The IPASessionConfiguration now has the grid configuration stored. Use it it at prepare() and process() calls in AWB and pass it as a reference to the private functions when needed. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-23ipa: ipu3: agc: remove local storage of the gridJean-Michel Hautbois
The IPASessionConfiguration now has the grid configuration stored. Use it at process() call in AGC and pass it as a reference to the private functions when needed. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-21qcam: Replace MappedBuffer with Span<uint8_t>Laurent Pinchart
The MappedBuffer structure is a custom container that binds a data pointer with a length. This is exactly what Span is. Use it instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-20ipa: ipu3: Move IPU3 agc into algorithmsJean-Michel Hautbois
Now that the interface is properly used by the AGC class, move it into ipa::ipu3::algorithms and let the loops do the calls. As we need to exchange the exposure_ and gain_ by passing them through the FrameContext, use the calculated values in setControls() function to ease the reading. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: Move IPU3 awb into algorithmsJean-Michel Hautbois
Now that the interface is properly used by the AWB class, move it into ipa::ipu3::algorithms and let the loops do the calls. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: convert AGC to the new algorithm interfaceJean-Michel Hautbois
In preparation for using the AGC through the new algorithm interfaces, convert the existing code to use the new function types. Now that the process call is rewritten, re-enable the compiler flag to warn when a function declaration hides virtual functions from a base class (-Woverloaded-virtual). We never use converged_ so remove its declaration. The controls may not need to be updated at each call, but it should be decided on the context side and not by a specific call by using a lock status in the Agc structure for instance. As the params_ local variable is not useful anymore, remove it here too. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: convert AWB to the new algorithm interfaceJean-Michel Hautbois
When the stats are received, pass them with the context to the existing AWB algorithm. IPAFrameContext now has a new structure to store the gains calculated by the AWB algorithm. When an EventFillParams event is received, call prepare() and set the new gains accordingly in the params structure. There is no more a need for the IPU3Awb::initialise() function, as the params are always set in prepare(). Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: Introduce a modular tone mapping algorithmJean-Michel Hautbois
Introduce a new algorithm to manage the tone mapping handling of the IPU3. The initial algorithm is chosen to configure the gamma contrast curve which moves the implementation out of AWB for simplicity. As it is initialised with a default gamma value of 1.1, there is no need to use the default table at initialisation anymore. This demonstrates the way to use process() call when the EventStatReady comes in. The function calculates the LUT in the context of a frame, and when prepare() is called, the parameters are filled with the updated values. AGC is modified to take the new process interface into account. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: Introduce modular algorithmJean-Michel Hautbois
Implement a new modular framework for algorithms with a common context structure that is passed to each algorithm through a common API. This patch: - removes all the local references from IPAIPU3 and uses IPAContext - implements the list of pointers and the loop at configure call on each algorithm - loops in fillParams on each prepare() call on the algorithm list - loops in prepareStats on each process() call on the algorithm list Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: Add the functions to the Algorithm classJean-Michel Hautbois
Introduce three functions in the Algorithm class to manage algorithms: - configure which is called when IPA is configured only - prepare called on EventFillParams event at each frame when the request is queued - process called on EventStatReady event at each frame completion when the statistics have been generated. The existing AGC implementation already has a function named process(), though it has different arguments. Adding the new virtual process() interface causes a compiler warning due to the AGC implementation overloading a virtual function, even though the overload can be resolved correctly. Temporarily disable the warning in this commit to maintain bisection until the AGC is converted to the new interface. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: ipu3: Introduce a Context structureJean-Michel Hautbois
An increasing amount of data and information needs to be shared between the components that build up to implement image processing algorithms. Create a context structure which will allow us to work towards calling algorithms in a modular way, and sharing information between the modules. The IPA context is a global context set at configure time (IPASessionConfiguration) and a per-frame context (IPAFrameContext) used while streaming. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-20ipa: move libipa::Algorithm to ipa/ipu3/algorithmsJean-Michel Hautbois
The abstract Algorithm class was originally placed in libipa as an attempt define a generic algorithm container. This was a little optimistic and pushed a bit far too early. Move the Algorithm class into the IPU3 which is the only user of the class, as we adapt it to support modular algorithm components for the IPU3. Not documenting the namespace may cause issues with Doxygen in libipa. The file libipa.cpp is thus created as an empty file for now, but we can leverage it in the future to add more global libipa documentation, and possibly code too. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-19libcamera: ipc_pipe: Do not run memcpy with null argumentsUmang Jain
IPCMessage::payload() converts the IPCMessage into an IPCUnixSocket payload. However, if IPCMessage is constructed with one of the following constructors - IPCMessage::IPCMessage(), IPCMessage::IPCMessage(uint32_t cmd) IPCMessage::IPCMessage(const Header &header) The data_ vector of IPCMessage is empty and uninitialised. In that case, IPCMessage::payload will try to memcpy() an empty data_ vector which can lead to invoking memcpy() with a nullptr parameter, which is then identified by the address sanity checker.. Add a non-empty data_ vector check to avoid it. The issue is noticed by running a test manually, testing the vimc IPA code paths in isolated mode. It is only noticed when the test is compiled with -Db_sanitize=address,undefined meson built-in option. ipc_pipe.cpp:110:8: runtime error: null pointer passed as argument 2, which is declared to never be null Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-19libcamera: ipc_unixsocket: Do not run memcpy with null argumentsUmang Jain
In IPCUnixSocket, a payload can be sent/received with empty fd vector, which leads to passing a nullptr in memcpy() in both sendData() and recvData(). Add a null check for fd vector's data pointer to avoid invoking memcpy() with nullptr. The issue is noticed by running a test manually testing the vimc IPA code paths in isolated mode. It is only noticed when the test is compiled with -Db_sanitize=address,undefined meson built-in option. ipc_unixsocket.cpp:268:8: runtime error: null pointer passed as argument 2, which is declared to never be null ipc_unixsocket.cpp:312:8: runtime error: null pointer passed as argument 1, which is declared to never be null Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-08-19ipa: Use FileDescriptor instead of int in layers above IPC payloadPaul Elder
Regarding (de)serialization in isolated IPA calls, we have four layers: - struct - byte vector + fd vector - IPCMessage - IPC payload The proxy handles the upper three layers (with help from the IPADataSerializer), and passes an IPCMessage to the IPC mechanism (implemented as an IPCPipe), which sends an IPC payload to its worker counterpart. When a FileDescriptor is involved, previously it was only a FileDescriptor in the first layer; in the lower three it was an int. To reduce the risk of potential fd leaks in the future, keep the FileDescriptor as-is throughout the upper three layers. Only the IPC mechanism will deal with ints, if it so wishes, when it does the actual IPC. IPCPipeUnixSocket does deal with ints for sending fds, so the conversion between IPCMessage and IPCUnixSocket::Payload converts between FileDescriptor and int. Additionally, change the data portion of the serialized form of FileDescriptor to a 32-bit unsigned integer, for alightnment purposes and in preparation for conversion to an index into the fd array. Also update the deserializer of FrameBuffer::Plane accordingly. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-08-17ipa: raspberrypi: Fix bcm2835-isp inclusion type.Kieran Bingham
The bcm2835-isp.h is included with quotes rather than angle brackets. Quoted includes is reserved for internal includes, while the linux/bcm2835-isp.h header is exported from the Linux kernel. Fix the inclusion type. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-17pipeline: ipu3: Skip recording timestamp for cancelled buffersUmang Jain
There is no point in recording sensor's timestamp when V4L2VideoDevice has marked the frame buffers with FrameMetadata::FrameCancelled (happens when the streams are stopped). The metadata is mostly invalid for cancelled buffers hence, setting timestamp on invalid metadata does not make sense (however some metadata can be considered valid for e.g. returning cause of failure through metadata on cancelled buffers). Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-17libcamera: pipeline: Cast to derived pipeline handler with helpersLaurent Pinchart
Replace manual static casts from the PipelineHandler pointer to a derived class pointer with helper functions in the camera data classes. This simplifies code accessing the pipeline from the camera data. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-17libcamera: pipeline_handler: Drop controls() and properties() functionsLaurent Pinchart
The PipelineHandler controls() and properties() functions are only used by the Camera class. Now that the controls and properties are stored in the Camera::Private class, we can drop those functions and access the private data directly in Camera::controls() and Camera::properties(). Suggested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-17libcamera: pipeline_handler: Drop CameraData classLaurent Pinchart
The CameraData class isn't used anymore. Drop it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-17libcamera: pipeline: ipu3: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-17libcamera: pipeline: raspberrypi: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-17libcamera: pipeline: rkisp1: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-17libcamera: pipeline: vimc: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-16libcamera: pipeline: uvcvideo: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-16libcamera: pipeline: simple: Migrate to Camera::PrivateLaurent Pinchart
As part of the effort to remove the CameraData class, migrate the pipeline handler-specific camera data from CameraData to the Camera::Private class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-16libcamera: camera: Fix minor issues in Camera::Private documentationLaurent Pinchart
Improve the Camera::Private documentation by fixing minor spelling or style issues. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-16libcamera: pipeline_handler: Move CameraData members to Camera::PrivateLaurent Pinchart
With pipeline handlers now being able to subclass Camera::Private, start the migration from CameraData to Camera::Private by moving the members of the base CameraData class. The controlInfo_, properties_ and pipe_ members are duplicated for now, to allow migrating pipeline handlers one by one. The Camera::Private class is now properly documented, don't exclude it from documentation generation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-16libcamera: camera: Pass Private pointer to Camera constructorLaurent Pinchart
In order to allow subclassing Camera::Private in pipeline handlers, pass the pointer to the private data to the Camera constructor, and to the Camera::createCamera() function. The Camera::Private id_ and streams_ members now need to be initialized by the Camera constructor instead of the Camera::Private constructor, to allow storage of the streams in a pipeline handler-specific subclass of Camera::Private. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-16libcamera: base: extensible: Pass private pointer as unique_ptr<>Laurent Pinchart
The Extensible constructor takes a pointer to a Private instance, whose lifetime it then manages. Make this explicit in the API by passing the pointer as a std::unique_ptr<Private>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-16pipeline: vimc: Force complete of request on cancelled buffersUmang Jain
When the stream is stopped, the V4L2VideoDevice sends back all the queued buffers with FrameMetadata::FrameCancelled status. It is the responsibility of the pipeline handler to handle these buffers with FrameMetadata::FrameCancelled. VIMC is currently missing this handling path. As the FrameMetadata::FrameCancelled is set when the stream is stopped, we can be sure that no more queued and re-use of request shall happen. Hence, cancel all the requests' buffers force a complete with completeBuffer(). The issue is caught by the gstreamer_single_stream_test.cpp running with vimc. During the check with meson built-in option '-Db_sanitize=address,undefined' it was observed: ==118003==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e000037108 at pc 0x7f225160c9ac bp 0x7f224a47b620 sp 0x7f224a47b618 READ of size 4 at 0x60e000037108 thread T1 #0 0x7f225160c9ab in libcamera::Request::sequence() const ../include/libcamera/request.h:55 #1 0x7f22518297aa in libcamera::VimcCameraData::bufferReady(libcamera::FrameBuffer*) ../src/libcamera/pipeline/vimc/vimc.cpp:577 #2 0x7f225183b1ef in libcamera::BoundMethodMember<libcamera::VimcCameraData, void, libcamera::FrameBuffer*>::activate(libcamera::FrameBuffer*, bool) ../include/libcamera/base/bound_method.h:194 #3 0x7f22515cc91f in libcamera::Signal<libcamera::FrameBuffer*>::emit(libcamera::FrameBuffer*) ../include/libcamera/base/signal.h:126 #4 0x7f22515c3305 in libcamera::V4L2VideoDevice::streamOff() ../src/libcamera/v4l2_videodevice.cpp:1605 #5 0x7f225181f345 in libcamera::PipelineHandlerVimc::stop(libcamera::Camera*) ../src/libcamera/pipeline/vimc/vimc.cpp:365 The VimcCameraData::bufferReady seems to emit even after the stream is stopped. It's primarily due to vimc's lack of handling FrameMetadata::FrameCancelled in its pipeline handler. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-16ipa: vimc: Send and retrieve FrameBuffers from IPAUmang Jain
Plumb through VIMC mojo interface to enable buffers passing. VIMC does not have parameters or statistics buffers but we can mimick the typical case of passing IPA buffers from pipeline handler to IPA using mock buffers. The mock IPA buffers are FrameBuffers which are dmabuf backed (in other words, mmap()able through MappedFramebuffer inside the IPA). This commits shows: - Passing the parameter buffer from the pipeline handler to the IPA through functions defined in mojom interface. - Passing request controls ControlList to the IPA. Any tests using VIMC will now loop in the IPA paths. Any tests running in isolated mode will help us to test IPA IPC code paths especially around (de)serialization of data passing from pipeline handlers to the IPA. Future IPA interface tests can simply extend the vimc mojom interface to achieve/test a specific use case as required. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>