summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
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>
2020-01-07libcamera: bound_method: Fix memory leak with direct connectionsLaurent Pinchart
When BoundMethodBase::activatePack() is called with the connection type set to ConnectionTypeDirect, the method isn't deleted even if deleteMethod is true, as is the case when called from Object::invokeMethod(). This causes a memory leak. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07libcamera: control_serializer: Initialize serial_Laurent Pinchart
The ControlSerializer::serial_ member variable isn't initialized. Add a constructor to the class to initialize it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07libcamera: ipc_unixsocket: Don't send uninitialized bytes over the socketLaurent Pinchart
IPCUnixSocket::send() sends a IPCUnixSocket::Header allocated on the stack. All the fields of the header are initialized, but the padding bytes are not. This results in random data being sent over the UNIX socket, potentially leaking information. Fix this by initializing the whole header to 0. Fixes: 13dd7a01ecbe ("libcamera: ipc: unix: Add a IPC mechanism based on Unix sockets") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-04v4l2: Fix compilation of __open_2() and __openat_2() with gccLaurent Pinchart
The __open_2() and __openat_2() functions are defined by glibc as taking 2 and 3 arguments respectively, with variadic arguments for the file mode as open() and openat() do. The V4L2 compatibility layer defines them as aliases for open() and openat(), which results in compilation failures with gcc: ../../src/v4l2/v4l2_compat.cpp: In function ‘int __openat_2(int, const char*, int)’: ../../src/v4l2/v4l2_compat.cpp:58:14: error: invalid conversion from ‘int’ to ‘const char*’ [-fpermissive] 58 | return open(dirfd, path, oflag); | ^~~~~ | | | int ../../src/v4l2/v4l2_compat.cpp:31:39: note: initializing argument 1 of ‘int open(const char*, int, ...)’ 31 | LIBCAMERA_PUBLIC int open(const char *path, int oflag, ...) | ~~~~~~~~~~~~^~~~ ../../src/v4l2/v4l2_compat.cpp:58:21: error: invalid conversion from ‘const char*’ to ‘int’ [-fpermissive] 58 | return open(dirfd, path, oflag); | ^~~~ | | | const char* ../../src/v4l2/v4l2_compat.cpp:31:49: note: initializing argument 2 of ‘int open(const char*, int, ...)’ 31 | LIBCAMERA_PUBLIC int open(const char *path, int oflag, ...) | Fix this by defining the two functions as wrappers around open() and openat() without variadic arguments. Fixes: 0ce8f2390b52 ("v4l2: v4l2_compat: Add V4L2 compatibility layer") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-01-03v4l2: v4l2_compat: Add V4L2 compatibility layerPaul Elder
Add libcamera V4L2 compatibility layer. This initial implementation supports the minimal set of V4L2 operations, which allows getting, setting, and enumerating formats, and streaming frames from a video device. Some data about the wrapped V4L2 video device are hardcoded. Add a build option named 'v4l2' and adjust the build system to selectively compile the V4L2 compatibility layer. For now we match the V4L2 device node to a libcamera camera based on a devnum that a pipeline handler may optionally map to a libcamera camera. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-01-03libcamera: pipeline_handler: uvcvideo: register all Cameras along with a devnumPaul Elder
Register all UVC Cameras along with their device numbers, to eventually allow the V4L2 compatibility layer to match against it. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2020-01-03libcamera: camera_manager, pipeline_handler: allow retrieving cameras by ↵Paul Elder
device numbers The V4L2 compatibility layer will need a way to map device numbers to libcamera Camera instances. Expose a method in the camera manager to retrieve Camera instances by devnum. The mapping from device numbers to Camera instances is optionally declared by pipeline handlers when they register cameras with the camera manager. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-01-03libcamera: v4l2_device, v4l2_videodevice: call open system call directlyPaul Elder
We are preparing to integrate the V4L2 adaptation layer, which will intercept open() calls (among others) via LD_PRELOAD. To prevent libcamera's own open() calls from being intercepted, replace them with a direct syscall. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-01-03libcamera: utils: Add strlcpyPaul Elder
strlcpy is available in libbsd, bionic, musl, and ulibc, but not in glibc. Instead of checking for strlcpy availability and modifying dependencies, implement it in utils, as a wrapper around strncpy. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2020-01-03libcamera: pipeline: uvcvideo: Fix crash when default entity is not foundLaurent Pinchart
Commit e441f2c7f46d ("libcamera: pipeline: uvcvideo: Add controls support") broke handling of UVC devices without a default entity by turning the error check into an always false check. Fix it. Fixes: e441f2c7f46d ("libcamera: pipeline: uvcvideo: Add controls support") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2019-12-16libcamera: Remove buffer index from loggingNiklas Söderlund
The buffer index is a V4L2 concept that will be hidden from users with the introduction of a new FrameBuffer class. In preparation for this, remove the index from log messages. Keep and move one debug log message where the index is available as the V4L2 buffer is being dequeued for the video device and it's useful when debugging. 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-12-16libcamera: pipelines: Align bookkeeping in queueRequest()Niklas Söderlund
Expecting pipeline handler implementations of queueRequest() to call the base class queueRequest() at the correct point have led to different behaviors between the pipelines. Fix this by splitting queueRequest() into a base class implementation which handles the bookkeeping and a new queueRequestDevice() that is to be implemented by pipeline handlers and only deals with committing the request to the device. 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-12-09libcamera: object: Document danger of deleting object from other threadLaurent Pinchart
Object instances receive messages dispatched from the event loop of the thread they belong to. Deleting an object from a different thread is thus dangerous, unless the caller ensures that no message delivery is in progress. Document this in the Object class documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-27libcamera: thread: Fix race condition when dispatching messagesLaurent Pinchart
The Object class stores the number of pending messages that have been posted for it, while the actual messages are stored in a per-thread list in the ThreadData class. When dispatching messages, the message is removed from the list, passed to the receiver, and the number of pending messages is updated. In order to avoid too much contention on the list lock, the lock is dropped to pass the message to the receiver and then taken again. This creates a race condition window with Thread::removeMessages(), as the number of pending messages for a receiver is briefly out of sync with the pending messages list. The assertion at the end of removeMessages() thus sometimes fails. Fix this by decrementing the pending messages counter before releasing the lock in Thread::dispatchMessages(). This fixes the slow message receiver test in MessageTest. Fixes: 01b930964acd ("libcamera: thread: Add a messaging passing API") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-27libcamera: thread: Fix locking when moving objectLaurent Pinchart
When moving an Object to a Thread, messages posted for the object are move to the target thread's message queue. This requires locking the message queues of the current and target threads, as the target thread may (and is usually) running. The implementation is faulty as it locks the thread data instead of the message queue. This creates a race condition with a tiny but exploitable time window. The issue was noticed by the event-thread test rarely but reproducibly failing with the following assertion error: [1:39:33.850878042]FATAL default thread.cpp:440 assertion "data_ == receiver->thread()->data_" failed The issue only occurred when libcamera was compiled in release mode, further hinting of a race condition. Fixes: 01b930964acd ("libcamera: thread: Add a messaging passing API") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-26libcamera: Print backtrace on fatal errorsLaurent Pinchart
When a fatal error occurs the program aborts, and all the logger provides is the location of the line that caused the error. Extend this with a full backtrace to help debugging. The backtrace is generated using the backtrace() call, a GNU extension to the C library. It is available in glibc and uClibc but not in musl. Test for availability of the function to condition compilation of the backtrace printing. Implementing backtrace support with musl is an exercise left to the reader if desired. The LogOutput class is extended to support writing string messages directly to the output. Strings written directly will be considered as LogDebug messages when written to the Syslog. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-11-26cam: options: Fix unitialized variable warningLaurent Pinchart
gcc 8 and 9 complain about the OptionValue::integer_ member being possibly used initialized when compiled in release mode. I haven't been able to find where this could be the case, and the compiler error message isn't helpful: In file included from ../../src/cam/options.cpp:14: ../../src/cam/options.h: In member function ‘bool OptionsBase<T>::parseValue(const T&, const Option&, const char*) [with T = std::__cxx11::basic_string<char>]’: ../../src/cam/options.h:84:7: error: ‘<anonymous>.OptionValue::integer_’ may be used uninitialized in this function [-Werror=maybe-uninitialized] class OptionValue ^~~~~~~~~~~ ../../src/cam/options.h: In member function ‘bool OptionsBase<T>::parseValue(const T&, const Option&, const char*) [with T = int]’: ../../src/cam/options.h:84:7: error: ‘<anonymous>.OptionValue::integer_’ may be used uninitialized in this function [-Werror=maybe-uninitialized] class OptionValue ^~~~~~~~~~~ Furthermore valgrind doesn't report any issue. This is likely a false positive, but fix it nonetheless as the fix is cheap. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-11-20libcamera: Fix typo related to serializationLaurent Pinchart
Oxford English spells "serialize", not "serialise". Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>