summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-07libcamera: bound_method: Drop unused BoundMethodBase::connectionType()Laurent Pinchart
The BoundMethodBase::connectionType() method isn't used, drop it. While it at make the connectionType_ member private as it is only used by the class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07libcamera: bound_method: Mark overriden methods with overrideLaurent Pinchart
Mark the activate() and invoke() methods with the override keyword where appropriate. 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: object: Use activate() in invokeMethod()Laurent Pinchart
The Object::invokeMethod() implementation duplicates pack creation code from BoundMemberMethod::activate(). Call activate() instead of activatePack() to share code. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07test: object-invoke: Test direct invocationLaurent Pinchart
Test the ConnectionTypeDirect type when the object lives in a different thread. This test passes but generates a memory leak. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2020-01-07utils: checkstyle.py: Support single line hunksKieran Bingham
The checkstyle script expects hunks to be declared with a start line and line count, however the unified diff format [0] declares that a single line hunk will only have the start line: > If a hunk contains just one line, only its start line number appears. > Otherwise its line numbers look like ‘start,count’. An empty hunk is > considered to start at the line that follows the hunk. [0] https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html#Detailed-Unified Attempting to parse a single line hunk results in the following error: File "./utils/checkstyle.py", line 110, in __init__ raise RuntimeError("Malformed diff hunk header '%s'" % line) RuntimeError: Malformed diff hunk header '@@ -1 +1,2 @@ The DiffHunk class only makes use of the start line, and does not utilise the line count, thus update the regex to make the unused groups optional. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2020-01-07utils: checkstyle.py: Fix regex string literalKieran Bingham
The checkstyle.py patch has a fault which it identified in itself when updating the regex string. --- utils/checkstyle.py +++ utils/checkstyle.py #105: : W605 invalid escape sequence '\+' + diff_header_regex = re.compile('@@ -([0-9]+)(,[0-9]+)? \+([0-9]+)(,?[0-9]+)? @@') --- 1 potential style issue detected, please review This is documented further at: https://www.flake8rules.com/rules/W605.html Update the string literal prefix to declare a raw byte string for the regex parser. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
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: object: Support reference arguments in invokeMethod()Laurent Pinchart
Invoking a method that takes a reference argument with Object::invokeMethod() results in a compilation error: ../test/object-invoke.cpp:131:11: error: no matching member function for call to 'invokeMethod' object_.invokeMethod(&InvokedObject::methodWithReference, ~~~~~~~~^~~~~~~~~~~~ ../include/libcamera/object.h:33:7: note: candidate template ignored: deduced conflicting types for parameter 'Args' (<const int &> vs. <int>) void invokeMethod(void (T::*func)(Args...), ConnectionType type, Args... args) This is due to the fact that implicit type conversions (from value to reference in this case) takes place after template argument type deduction, during overload resolution. A similar issue would occur if T::func took a long argument and invokeMethod() was called with an in argument. Fix this by specifying to sets of argument types in the invokeMethod() template, one for the arguments to the invoked method, and one for the arguments to invokeMethod() itself. The compiler can then first perform type deduction separately, and implicit conversion in a second step. Reported-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2020-01-03test: object-invoke: Test invocation of method taking a reference argumentLaurent Pinchart
Object::invokeMethod() fails with a compilation error when the invoked method takes a reference argument. Add a test case for this issue. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@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-12-08include: linux: Update Linux headers readme to v5.2Paul Elder
When the Linux headers were updated to v5.2, the version announced in the README was not, so update it. Fixes: 4984973679ec ("include: linux: Update headers to Linux v5.2") Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-27test: object-invoke: Delete InvokeObject after thread terminationLaurent Pinchart
The InvokeObject instance is created on the stack in the run() method, and is thus destroyed before the thread the object is bound to terminates. This creates a race condition as the object message handler could be running when the object is deleted. Fix this by moving the InvokeObject to a member field. 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-27test: message: Add slow receiver testLaurent Pinchart
There's a race in the message delivery against object deletion. Add a test that triggers it reliably. This test is expected to fail with an assertion error. 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-27test: message: Fix message handling in MessageReceiverLaurent Pinchart
Forward messages that we don't handle to the base Object class, to avoid both blocking the ThreadMove message and mistaking it as the test message. 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-25test: controls: control_list: Add status checkJacopo Mondi
Since commit fac471e812a9 ("test: Extract CameraTest class out of camera tests to libtest") the control_list is a subclass of CameraTest, and the status returned by the base class init() operation should be inspected to avoid accessing uninitialized fields during the run() operation execution. If the VIMC test module is not loaded, executing the test results in a segfault. Fix this by adding the init() operation where to status_ flag is checked for errors. Fixes: fac471e812a9 ("test: Extract CameraTest class out of camera tests to libtest") Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2019-11-21meson: Really define _FORTIFY_SOURCE for optimised buildsLaurent Pinchart
Commit 965c5bf7fbf5 ("meson: Define _FORTIFY_SOURCE for optimised builds") tried to define _FORTIFY_SOURCE for optimised builds with clang, but updated the common_arguments after it was used. This resulted in the _FORTIFY_SOURCE option not being applied. Fix it. Fixes: 965c5bf7fbf5 ("meson: Define _FORTIFY_SOURCE for optimised builds") 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>
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>
2019-11-20test: ipa: Add IPA wrappers testLaurent Pinchart
Wrap an IPAInterface in an IPAInterfaceWrapper in an IPAContextWrapper, and verify that the translation between C and C++ APIs work correctly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20ipa: Allow short-circuiting the ipa_context_opsLaurent Pinchart
When an IPA module is loaded without isolation and implements the IPAInterface internally, going through ipa_context_ops is a waste of time. Add an operation to retrieve the IPAInterface, and use it directly in the IPAContextWrapper. For debugging purpose, make it possible to forcing usage of the C API by defining the LIBCAMERA_IPA_FORCE_C_API environment variable. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-11-20ipa: Declare the ipaCreate() function prototypeLaurent Pinchart
IPA modules have to implement a public ipaCreate() function, but its prototype isn't declared in any header file. This allows for modules to get the prototype wrong without being warned by the compiler. Fix it. 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-20ipa: Switch to the plain C APIJacopo Mondi
Switch IPA communication to the plain C API. As the IPAInterface class is easier to use for pipeline handlers than a plain C API, retain it and add an IPAContextWrapper that translate between the C++ and the C APIs. On the IPA module side usage of IPAInterface may be desired for IPAs implemented in C++ that want to link to libcamera. For those IPAs, a new IPAInterfaceWrapper helper class is introduced to wrap the IPAInterface implemented internally by the IPA module into an ipa_context, ipa_context_ops and ipa_callback_ops. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20ipa: Define a plain C APILaurent Pinchart
The C++ objects that are expected to convey data through the IPA API will have associated methods that would require IPAs to link to libcamera. Even though the libcamera license allows this, suppliers of closed-source IPAs may have a different interpretation. To ease their mind and clearly separate vendor code and libcamera code, define a plain C IPA API. The corresponding C objects are stored in plain C structures or have their binary format documented, removing the need for linking to libcamera code on the IPA side. The C API adds three new C structures, ipa_context, ipa_context_ops and ipa_callback_ops. The ipa_context_ops and ipa_callback_ops contain function pointers for all the IPA interface methods and signals, respectively. The ipa_context represents a context of operation for the IPA, and is passed to the IPA oparations. The IPAInterface class is retained as it is easier to use than a plain C API for pipeline handlers, and wrappers will be developed to translate between the C and C++ APIs. Switching to the C API internally will be done in a second step. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20ipa: Pass ControlInfoMap references to IPAInterface::configure()Laurent Pinchart
The IPAInterface::configure() operation receives a map of ControlInfoMap instances. Pass const references instead to avoid copies when not required (the callee can still make manual copies), and to allow for the future serialization layer to keep references to the original object. 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-20test: Add control serialization testJacopo Mondi
Add a test that exercises the ControlSerializer to serialize and deserialize ControlInfoMap and ControlList. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20libcamera: Add controls serializerLaurent Pinchart
Add a new ControlSerializer helper to serialize and deserialize ControlInfoMap and ControlList instances. This will be used to implement the C IPA protocol and the communication with IPA through IPC. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20test: Add ByteStreamBuffer testLaurent Pinchart
The test exercises the API of the ByteStreamBuffer class in both read and write modes, including carve out buffers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20libcamera: Add ByteStreamBufferJacopo Mondi
The ByteStreamBuffer class wraps a memory area, expected to be allocated by the user of the class and provides operations to perform sequential access in read and write modes. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-11-20ipa: Define serialized controlsJacopo Mondi
Define data structures to be used during interaction between IPA modules and pipeline handlers to serialize control lists and control info maps. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> 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-20libcamera: buffer: Add const accessor to Buffer planesLaurent Pinchart
In order to inspect planes of a const Buffer, add a const accessor. 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>
2019-11-20libcamera: v4l2_controls: Fix control range construction for boolLaurent Pinchart
V4L2 controls of type V4L2_CTRL_TYPE_BOOLEAN are incorrectly described with a ControlRange of int32_t values. Fix it. 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> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-11-20libcamera: controls: Catch type mismatch in ControlInfoMapLaurent Pinchart
ControlInfoMap requires the ControlId and ControlRange of each entry to have identical types. Check for this and log an error if a mismatch is detected. 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>
2019-11-20libcamera: controls: Store reference to the InfoMapJacopo Mondi
Store a reference to the ControlInfoMap used to create a ControlList and provide an operation to retrieve it. This will be used to implement serialization of ControlList. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20libcamera: controls: Make ControList constructor publicLaurent Pinchart
We need to construct empty ControlList objects to serialization. Make the constructor public. 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>
2019-11-20libcamera: controls: Make ControlId constructor publicJacopo Mondi
In order to be able to create a ControlId from serialized data, make its constructor public. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-11-20libcamera: controls: Add move constructor to ControlInfoMapLaurent Pinchart
The ControlInfoMap class has a move assignment operator from a plain map, but no corresponding move constructor. Add one. 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> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>