summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2019-10-07libcamera: timer: Add start() method with absolute deadlineLaurent Pinchart
The Timer class is started using a timer duration. To help callers that require waiting for an absolute deadline, add a start() overload that takes a std::chrono::steady_clock::time_point value. This will be used by IPAs. 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-10-07libcamera: timer: Don't reset deadline after time outLaurent Pinchart
Users of the Timer class may benefit from retrieving the timer deadline after it times out. This is currently not possible as the deadline is reset to 0 when the timer times out or is stopped. Fix this by not resetting the deadline, and adding a new running_ field to the Timer class to implement isRunning(). 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-10-07libcamera: timer: Remove the interval() methodLaurent Pinchart
The libcamera timers are single-shot timers. They are started with a duration, but fire once only, not based on an interval. Remove the interval concept by removing the interval() method, and rename other occurences of interval to duration. 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-10-05libcamera: controls: Use ControlValidator to validate ControlListLaurent Pinchart
Replace the manual validation of controls against a Camera with usage of the new ControlValidator interface. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-10-05libcamera: controls: Rename ControlInfo to ControlRangeLaurent Pinchart
The ControlInfo class stores a range of valid values for a control. Its name is vague, as "info" has multiple meanings. Rename it to ControlRange. 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-10-05libcamera: controls: Remove ControlInfo::idLaurent Pinchart
The ControlInfo id member is only used in the toString() method of the class, and nowhere else externally. The same way that ControlValue doesn't store a ControlId, ControlInfo shouldn't. Remove 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-10-05libcamera: controls: Remove the unused ControlList::update() methodLaurent Pinchart
The ControlList::update() method is unused. While it is meant to fulfil a need of applications, having no user means that it is most probably not correctly designed. Remove the method, we will add it back later if needed. 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-10-05libcamera: controls: Auto-generate control_ids.h and control_ids.cppLaurent Pinchart
Bring back auto-generation of control ids. In this version, both the header and the source files are generated from a single YAML file that stores all control definitions. This allows centralising controls in a single file, while the previous version required keeping both declarations (in a header) and documentation (in a the source) in sync manually. Using YAML as a format to store control definitions is a trade-off between ease of use (there are many YAML parsers available) and simplicity (XML was considered, but would have lead to more complex processing). A new build time dependency is added on python3-yaml, which should be available as a package in all distributions and build environments. The YAML format is likely to change over time as we improve documentation of controls, the first version simply copies the information currently available. Future improvements should also include a YAML schema to validate the YAML source file. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-10-04libcamera: controls: Improve the API towards applicationsLaurent Pinchart
Rework the control-related classes to improve the API towards applications. The goal is to enable writing code similar to Request *req = ...; ControlList &controls = req->controls(); controls->set(controls::AwbEnable, false); controls->set(controls::ManualExposure, 1000); ... int32_t exposure = controls->get(controls::ManualExposure); with the get and set operations ensuring type safety for the control values. This is achieved by creating the following classes: - Control defines controls and is the main way to reference a control. It is a template class to allow methods using it to refer to the control type. - ControlId is the base class of Control. It stores the control ID, name and type, and can be used in contexts where a control needs to be referenced regardless of its type (for instance in lists of controls). This class replaces ControlIdentifier. - ControlValue is kept as-is. The ControlList class now exposes two template get() and set() methods that replace the operator[]. They ensure type safety by infering the value type from the Control reference that they receive. The main way to refer to a control is now through the Control class, and optionally through its base ControlId class. The ControlId enumeration is removed, replaced by a list of global Control instances. Numerical control IDs are turned into macros, and are still exposed as they are required to communicate with IPAs (especially to deserialise control lists). They should however not be used by applications. Auto-generation of header and source files is removed for now to keep the change simple. It will be added back in the future in a more elaborate form. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-10-04libcamera: controls: Use explicit 32-bit integer typesLaurent Pinchart
Make the control API more explicit when dealing with integer controls by specifying the size. We already do so for 64-bit integers, using int64_t and ControlTypeInteger64, do the same for 32-bit integers. 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-10-04libcamera: controls: Make ControlValue get/set accessors template methodsLaurent Pinchart
The ControlValue get accessors are implemented with functions of different names, whlie the set accessors use polymorphism to support different control types. This isn't very consistent and intuitive. Make the API clearer by using template methods. This will also have the added advantage that support for the new types will only require adding template specialisations, without adding new methods. 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-10-04libcamera: controls: Rename ControlValueType to ControlTypeLaurent Pinchart
The type of a control value is also the type of the control. Shorten the ControlValueType enumeration to ControlType, and rename ControlValue* to ControlType* for better clarity. 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-09-15libcamera: Move ipa includes to the same level as libcameraLaurent Pinchart
The ipa includes are located in include/libcamera/ipa/. This gives an incorrect impression that they are a sub-part of the rest of the libcamera API, while they are the API towards the IPA the same way that include/libcamera/ contains the API towards applications. To clarify this, move them to include/ipa/. The IPA headers are however still part of libcamera, so installing them to ${prefix}/include/ipa/ would make little sense. To fix this, move the application facing API to ${prefix}/include/libcamera/libcamera/ when installed, and the IPA to ${prefix}/include/libcamera/ipa/. When major versions of libcamera will be released, they could then be installed side by side in ${prefix}/include/libcamera-${version}/. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2019-09-14libcamera: Switch to the std::chrono APILaurent Pinchart
Replace the clock_gettime()-based API with durations expressed as integers with the std::chrono API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-08-19libcamera: camera_manager: Construct CameraManager instances manuallyLaurent Pinchart
The CameraManager class is not supposed to be instantiated multiple times, which led to a singleton implementation. This requires a global instance of the CameraManager, which is destroyed when the global destructors are executed. Relying on global instances causes issues with cleanup, as the order in which the global destructors are run can't be controlled. In particular, the Android camera HAL implementation ends up destroying the CameraHalManager after the CameraManager, which leads to use-after-free problems. To solve this, remove the CameraManager::instance() method and make the CameraManager class instantiable directly. Multiple instances are still not allowed, and this is enforced by storing the instance pointer internally to be checked when an instance is created. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2019-08-17libcamera: Add parent argument to constructors of Object-derived classesLaurent Pinchart
Now that the Object class implements parent-child relationships, make it possible to create EventNotifier and Timer instances with a parent by adding a parent argument to their constructors. 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-08-17libcamera: object: Create parent-child relationshipsLaurent Pinchart
Add a parent Object to Object instances, and track the parent-children relationships. Children are bound to the same thread as their parent, and moving an Object to a thread automatically moves all its children. 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-08-17libcamera: timer: Bind timers to threadsLaurent Pinchart
The Timer instances are registered with the event dispatcher instance of the CameraManager. This makes it impossible to use timers in other threads. Fix this by inheriting from Object, which allows binding instances to a thread, and register them with the event dispatcher for the thread they are bound to. 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-08-17libcamera: event_notifier: Bind event notifiers to threadsLaurent Pinchart
The EventNotifier instances are registered with the event dispatcher instance of the CameraManager. This makes it impossible to use event notifiers in other threads. Fix this by inheriting from Object, which allows binding instances to a thread, and register them with the event dispatcher for the thread they are bound to. 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-08-17libcamera: camera_manager: Bind CameraManager to threadsLaurent Pinchart
The CameraManager class uses the event dispatcher of the current thread. This makes the CameraManager::eventDispatcher() and CameraManager::setEventDispatcher() methods inconsistent, as they access different event dispatcher instances depending on the calling thread. Fix this by inheriting from the Object class, which binds the CameraManager to a thread, and use the event dispatcher of the bound thread. 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-08-17libcamera: object: Notify objects of thread moveLaurent Pinchart
Send a synchronous message to objects just before they get moved to a new thread. This allows the object to perform any required processing. EventNotifier and Timer objects will use this mechanism to move themselves to the new thread's event disaptcher. 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-08-17libcamera: object: Add an asynchronous method invocation methodLaurent Pinchart
Add a helper invokeMethod() to the Object class that allows asynchrnous invocation of any method of an Object instance. Asynchronous invocation occurs when control returns to the event dispatcher of the target object's thread, in the context of that thread. To support this, generalise the SignalMessage implementation to support automatic deletion of the associated BoundMethod, and rename the message to InvokeMessage to reflect the more generic purpose. 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-08-17libcamera: bound_method: Decouple from Signal implementationLaurent Pinchart
To make the BoundMethod classes more generic, replace direct access to private member from Signal classes with accessors or helper functions. This allows removal of friend statements from the BoundMethod classes. 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-08-17libcamera: signal: Split Slot implementation to reusable classesLaurent Pinchart
Move the Slot* classes to bound_method.{h,cpp} and rename them to Bound*Method*. They will be reused to implement asynchronous method invocation similar to cross-thread signal delivery. This is only a move and rename, no functional changes are included. 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-08-17libcamera: object: Make message() method protectedLaurent Pinchart
The message() method shouldn't be called externally (except by a few friend classes), make it protected. 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-08-12include: android: Add SPDX tagsJacopo Mondi
Add SPDX indentifier to Apache-2.0 licensed android headers. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-08-12include: android: Add Android headers from CrosJacopo Mondi
Copy the Android Camera3 HAL headers from the ChromiumOS build system and define a new inclusion directive in the meson build system for them. The header files have been copied from: https://chromium.googlesource.com/chromiumos/platform2 at revision 9e65ddd2c496e712f005ada9715decd2ff8e4a03 and provide: 1) Android CameraHAL3 HAL headers in include/android/hardware/ 2) The Android system headers in include/android/system/ 3) The Android camera metadata headers in include/android/metadata/ The original path in the Cros platform2/ repository is, respectively: camera/android/header_files/include/hardware camera/android/header_files/include/system camera/android/libcamera_metadata/include/ Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-17libcamera: logging: add syslog, stream, and nowhere logging targetsPaul Elder
Allow logging to syslog, or any given ostream, or to nowhere. The logging API is updated to accomodate these new logging destinations. LogMessage is modified to allow this. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-14libcamera: stream: Map external buffers to indexesJacopo Mondi
Add and use an operation to assign to Buffer representing external memory locations an index at queueRequest() time. The index is used to identify the memory buffer to be queued to the video device once the buffer will be queued in a Request. In order to minimize relocations in the V4L2 backend, this method provides a best-effort caching mechanisms that attempts to reuse BufferMemory previously mapped to the buffer's dmabuf file descriptors, if any. 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-07-14libcamera: buffer: Add an accessor to the BufferMemoryLaurent Pinchart
Buffer instances reference memory, which is modelled internally by a BufferMemory instance. Store a pointer to the BufferMemory in the Buffer class, and populate it when the buffer is queued to the camera through a request. This is useful for applications to access the buffer memory in the buffer or request completion handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-14libcamera: buffer: Add dmabuf file descriptorsJacopo Mondi
In addition to referencing buffer memory by index, add support to referencing it using dmabuf file descriptors. This will be used to reference buffer memory allocated outside of libcamera and import it. The dmabuf file descriptors are stored in an array in the Buffer class, and a new Stream::createBuffer() overload is added to construct a buffer from dmabuf file descriptor. 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-07-14libcamera: stream: Add Stream memory typeJacopo Mondi
Define the memory type a Stream uses and allow application to set it through the associated StreamConfiguration. A Stream can use either internal or external memory allocation methods, depending on where the data produced by the stream is actually saved. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-14libcamera: stream: Shorten access to the bufferPoolJacopo Mondi
All interactions with the Stream's buffers currently go through the BufferPool. In order to shorten accessing the buffers array, and eventually restrict access to the Stream's internal buffer pool, provide operations to access, create and destroy buffers. It is still possible to access the pool for pipeline handlers to populate it by exporting buffers from a video device to Stream's pool. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-14libcamera: v4l2_videodevice: Signal buffer completion at streamoff timeLaurent Pinchart
When stopping the stream buffers have been queued, in which case their completion is never be notified to the user. This can lead to memory leaks. Fix it by notifying completion of all queued buffers with the status set to error. As a result the base PipelineHandler implementation can be simplified, as all requests complete as the result of stopping the stream. The stop() method that manually completes all queued requests isn't needed anymore. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-14libcamera: buffer: Split memory information to BufferMemoryLaurent Pinchart
The Buffer class is a large beast the stores information about the buffer memory, dynamic metadata related to the frame stored in the buffer, and buffer reference data (in the index). In order to implement buffer import we will need to extend this with dmabuf file descriptors, making usage of the class even more complex. Refactor the Buffer class by splitting the buffer memory information to a BufferMemory class, and repurposing the Buffer class to reference a buffer and to store dynamic metadata. The BufferMemory class becomes a long term storage, valid and stable from the time buffer memory is allocated to the time it is freed. The Buffer class, on the other hand, becomes transient, is created on demand when an application requires a buffer, is given to a request, and is deleted when the request completes. Buffer and BufferMemory don't need to be copied, so their copy constructor and assignment operators are deleted. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-14libcamera: request: Add cookie to make request tracking easierLaurent Pinchart
Applications often have to map requests queued to a camera to external resources. To make this easy, add a 64-bit integer cookie to the Request class that is set when the request is created and can be retrieved at any time, especially in the request completion handler. The cookie is completely transparent for libcamera and is never modified. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-12libcamera: ipa_module_info: add license fieldPaul Elder
Add a field to IPAModuleInfo to contain the license of the module. This license field will be used to determine whether the IPA module should be run in an isolated process or not. If the license is open source, then the IPA module will be allowed to run without process isolation, if the user enables it. If the license is not open source, then the IPA module will be run with process isolation. Update the dummy IPA and IPA test to conform to the new struct layout. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-12libcamera: logging: add logging API for applicationsPaul Elder
Currently the log file and the log level can only be set via environment variables, but applications may also want to set the log file and the log level at run time. Provide an API for this. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-11libcamera: signal: Fix compilation on gccLaurent Pinchart
gcc complains that the recently template specialisation of the SlotBase::match() method is invalid as it is in a non-namespace scope. Luckily this can easily be fixed by removing the specialisation for the fully specialised implementation. As an additional safety measure, using std::enable_if<!std::is_same<Object, T>> on the template implementation ensures that it will never be called for an Object instance. Fixes: 56c2e653008a ("libcamera: signal: Fix Object handling in multiple inheritance cases") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-11libcamera: signal: Fix Object handling in multiple inheritance casesLaurent Pinchart
The SlotBase implementation stores the receiver object pointer as a void pointer internally. The pointer is then cast back to an Object pointer when the receiver object class derives from Object. When the receiver is an object that inherits from both the Object class and other classes, the Object data members may not be stored at the beginning of the object memory. The cast back to an Object pointer is thus incorrect. Fix this by casting the receiver object pointer to an Object pointer where the type of the receiver object is known, and pass it along with the receiver void pointer to the SlotBase class. The SlotBase class stores both pointers internally, and doesn't need the isObject_ field anymore as the same information is obtained from checking if the Object pointer is null. To avoid confusing the two pointers, use the same naming scheme through the whole implementation: "obj" points to a receiver object as an unknown type, and "object" to the receiver object cast to an Object. The latter is null when the receiver object doesn't inherit from the Object class. To further clarify the code, remove direct access to the SlotBase "obj" and "object" fields as much as possible. They are replaced by two new methods : - SlotBase::disconnect() to disconnect a signal from the slot's receiver object - SlotBase::match() to test if an object pointer matches the slot The match() method is a template method with a specialisation for the Object type, to compare either the obj or the object pointer depending on the type of the parameter. This is required as the Object destructor calls the SignalBase::disconnect() method for signal connected to the object, and passes a pointer to Object to that method, while the actual object may have a different address due to the issue explained above. The pointer must thus be compared with the stored Object pointer in that case, not to the pointer to the receiver object. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-11libcamera: signal: Support cross-thread signalsLaurent Pinchart
Allow signals to cross thread boundaries by posting them to the recipient through messages instead of calling the slot directly when the recipient lives in a different thread. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-11libcamera: thread: Add a messaging passing APILaurent Pinchart
Create a new Message class to model a message that can be passed to an object living in another thread. Only an invalid message type is currently defined, more messages will be added in the future. The Thread class is extended with a messages queue, and the Object class with thread affinity. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-11libcamera: Add thread supportLaurent Pinchart
The new Thread class wraps std::thread in order to integrate it with the Object, Signal and EventDispatcher classes. By default new threads run an internal event loop, and their run() method can be overloaded to provide a custom thread loop. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-09libcamera: Rework automatic version generation to avoid rebuildsLaurent Pinchart
Commit b817bcec6b53 ("libcamera: Auto generate version information") generates version information in order to automatically include it various locations (Sphinx and Doxygen documentation, libcamera::version variable available at runtime, and version.h available at compile time). Unfortunately this causes lots of unnecessary rebuilds when modifying the git tree state, which hinders development. The problem is caused by the generated version.h being listed as a dependency for the whole libcamera. This is required as meson (to the best of my knowledge) doesn't provide a way to explicitly specify the dependency of a single object file (camera_manager.o in this case, as camera_manager.cpp is the only consumer of the generated version string) on the custom target used to generate version.h. The dependency can't be automatically detected at build time, like dependencies on normal headers that are generated by parsing the source, because the version.h header may not exist yet. The build could then fail in a racy way. This change attempts at solving the issue by generating a version.cpp instead of a version.h to set the git-based version. This minimises the number of files that need to be rebuild when then git tree state changes, while retaining the main purpose of the original automatic version generation, the ability to access the git-based version string at runtime. We however lose the ability to access git-based version information at build time in an application building against libcamera, but there is no expected use case for this. The version string is moved from the libcamera namespace to the CameraManager class in order to avoid including version.h inside libcamera (in version.cpp and in camera_manager.cpp), which would create dependencies causing more rebuild steps, as described above. On the other hand, major, minor and patch level version numbers are useful at build time. This commit changes the generation of version.h in order to add three macros named LIBCAMERA_VERSION_MAJOR, LIBCAMERA_VERSION_MINOR and LIBCAMERA_VERSION_PATCH for this purpose. version.h is not included by any other libcamera header or source file, and thus doesn't force a rebuild of the library. The Sphinx and Doxygen documentation keep their git-based version information, which is set during the configuration of the build and then doesn't track git commits. We may want to investigate how to improve this, but given that git-based version for the documentation has very few use cases outside of tagging nightly builds, this isn't considered an issue at the moment. The documentation install directory now uses the base version string, in order to avoid increasing the number of documentation directories needlessly. This shouldn't cause any issue as the API should not change without a change to the version number. The version number generation and handling code now also standardises the version variables to not start with a 'v' prefix in meson, in order to simplify their handling. The prefix is added when generating the relevant files. Note that we go back to specifying the fallback version in the main meson.build, in the call to the project() function. For the time being I believe this should be a good compromise to avoid unnecessary recompilation, and moving the fallback version to a different file for tarball releases can be built on top of this. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-04libcamera: Auto generate version informationKieran Bingham
Generate a version string, and provide a global string object which allows applications to interrogate the current libcamera version information. The version header is automatically updated by meson on each build. The string roughly follows the semver [0] conventions of major.minor.patch-label as a value. [0] https://semver.org/ A script (utils/gen-version.sh) is provided which is modelled upon the processing from autoconf's git-version-gen. The gen-version.sh script will look for tags in the form vX.Y as starting points for the version string. While the repository does not have any matching tags, v0.0 will be assumed, resulting in versions with both major and minor being set to '0', and the patch count resulting from the number of patches in the history to that point. Finally, a uniquely identifying shortened hash is provided from git: v0.0.509+0ec0edf7 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-07-02libcamera: ipa_module_info: remove cplusplus guardsPaul Elder
IPA modules must be implemented in C++, which means we no longer need __cplusplus guards, so remove them. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-02libcamera: controls: Add a set of initial controlsLaurent Pinchart
Add an initial set of controls to demonstrate how controls are defined. Proper documentation for each control is missing. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2019-07-02libcamera: request: Add a ControlListKieran Bingham
Provide a ControlList on request objects to facilitate setting controls. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2019-07-02libcamera: controls: Extend ControlList to access controls by IDLaurent Pinchart
The ControlList class implements a map from control specifier to control ID. To avoid constant lookups of ControlInfo when using the class in the libcamera core or in pipeline handlers, the map uses ControlInfo pointers instead of ControlId values. This is however not very convenient for applications or pipeline handlers, as they would be forced to first look up the ControlInfo pointers for the controls they want to access. Facilitate ease of use of ControlLists by implementing an internal lookup of the ControlInfo from the controls provided by the Camera. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2019-07-02libcamera: camera: Provide a list of ControlInfoKieran Bingham
Extend the Camera class to expose the controls it supports. Each pipeline should generate a list of controls supported by each camera it creates. These are represented by a ControlInfoMap, and an associated ControlList of default values. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>