| Age | Commit message (Collapse) | Author |
|---|
|
If an unregistered timer is given to QtEventDispatcher::unregisterTimer()
an error is printed and Qt gets confused and locks up. Fix this by
following the libcamera documentation that passing a unregistered timer
is a no-op.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When setting the format on the ViewFinder, a new image_ is allocated.
Any change in format deletes the existing allocation, but it is not
cleaned up on shutdown:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f0bf8a7e17f in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10e17f)
#1 0x564c7205f7b0 in ViewFinder::setFormat(unsigned int, unsigned int, unsigned int) ../src/qcam/viewfinder.cpp:43
#2 0x564c71fec467 in MainWindow::startCapture() ../src/qcam/main_window.cpp:152
#3 0x564c71fe6c1a in MainWindow::MainWindow(libcamera::CameraManager*, OptionsParser::Options const&) ../src/qcam/main_window.cpp:40
#4 0x564c71fdf133 in main ../src/qcam/main.cpp:76
#5 0x7f0bf5944b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)
Provide a ViewFinder destructor, and delete the allocation as
appropriate.
Fixes: 97e8b3a2eb32 ("qcam: Add Qt-based GUI application")
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When enumerating IPAs, the system IPA directory and all the directories
listed in the LIBCAMERA_IPA_MODULE_PATH environment variable are listed
in turn. Failing to list any of those directories results in an error
message being printed for every failure. This is particularly common
when developing libcamera, as IPAs may not have been installed locally.
To avoid unnecessarily worrying error messages, rework the enumeration
procedure to only print a message when no IPA can be found at all.
Individual missing directories are not considered as an issue anymore.
The message is also downgraded from an error to a warning as the
situation may still be normal.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
If the IPAProxyLinux constructor fails to locate the proxy worker, the
socket_ and proc_ member pointers will be left uninitialised, leading
the a crash in the destructor. Initialise them both to nullptr.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The ipa_dummy.cpp and ipa_dummy_isolate.cpp only differ in the license
reported in the IPAModuleInfo structure. Drop the second file and
generate the two .so from ipa_dummy.cpp, with the license defined
through the command line.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The libcamera private headers are listed in src/libcamera/meson.build,
while they are located in src/libcamera/include/. The lack of a
meson.build in src/libcamera/include/ increases the risk of forgetting
to add new headers to the libcamera_headers array. Fix it by moving it
to src/libcamera/include/meson.build, and add the missing
v4l2_controls.h entry.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
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>
|
|
In preparation for standardisation of the std::chrono::steady_clock as
the libcamera default clock, define aliases for the clock, duration and
time point, and add helper functions to convert a duration to a timespec
and a time point to a string. More helpers will be added later as
needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
gcc-9 has introduced a deprecated-copy warning that is triggered by Qt
header files. The issue has been fixed in Qt 5.13. Fix compilation with
earlier Qt versions by disabling the warning. In order to still benefit
from the warning when possible, only disable it for gcc-9 and Qt < 5.13.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Some media devices, such as V4L2 M2M devices, share the same device node
for multiple entities. The udev enumerator used to support this, but
commit 6e620349009d ("libcamera: device_enumerator: fix udev media graph
loading dependency") broke this.
To fix the problem, rework the media device to V4L2 devices matching
code. A new MediaDeviceDeps internal struct stores unmet device number
dependencies for a media device, and is stored in a list of pending
media devices. To avoid linear lookups, the dependencies are cached in a
reverse map of device number to media device dependencies.
Fixes: 6e620349009d ("libcamera: device_enumerator: fix udev media graph loading dependency")
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>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
DeviceEnumeratorUdev::populateMediaDevice() searches for orphan devices
in an std::list, and if found removes them using std::list::remove().
This ends up looking up the entry twice. Replace the remove() call with
erase() to fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
When populating media devices, we look up device nodes for every entity
in the media device, regardless of if the entity is present in the
orphans list. This causes unnecessary lookups (that may also fail as the
device node may not be ready yet at that time). Move the lookup at a
later time, when the device node is actually needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The lookupDeviceNode() method is declared as pure virtual in the base
DeviceEnumerator class, but is only called by derived classes. Move it
to the DeviceEnumeratorSysfs and DeviceEnumeratorUdev. This allows
changing the udev version to take a dev_t instead of separate
major/minor, as that's what both the caller and the callee end up using.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
On some architectures, atomic binutils are provided by the libatomic
library from gcc. Linking with libatomic is therefore necessary,
otherwise the build fails with:
src/libcamera/4ab8042@@camera@sha/message.cpp.o: In function `libcamera::Message::registerMessageType()':
message.cpp:(.text+0x178): undefined reference to `__atomic_fetch_add_4'
collect2: error: ld returned 1 exit status
This is often for example the case on sparc v8 32 bits.
Fixes:
- http://autobuild.buildroot.org/results/1f0b8338f5f39aa86b9d432598dae2f53c5f7c84
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Kieran: Updated commit message to refer to build failure on current
master, rather than the old code currently built by buildroot]
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When a MediaDevice is enumerated and populated by the
DeviceEnumeratorUdev, there is a possibility that the member device
nodes of the media graph would not be ready (either not created, or
without proper permissions set by udev yet). The MediaDevice is still
passed up to the pipeline handler, where an attempt to access the device
nodes will fail in EPERM. This whole issue is especially likely to
happen when libcamera is run at system init time.
To fix this, we first split DeviceEnumerator::addDevice() into three
methods:
- createDevice() to simply create the MediaDevice
- populateMediaDevice() to populate the MediaDevice
- addDevice() to pass the MediaDevice up to the pipeline handler
DeviceEnumeratorSysfs calls these methods in succession, similar to what
it did before when they were all together as addDevice().
DeviceEnumeratorUdev additionally keeps a map of MediaDevices to a list
of pending device nodes (plus some other auxillary maps), and a simple
list of orphan device nodes. If a v4l device node is ready and there
does not exist any MediaDevice node for it, then it goes to the orphan
list, otherwise it is initialized and removed from the pending list of
the corresponding MediaDevice in the dependency map. When a MediaDevice
is populated via DeviceEnumeratorUdev::populateMediaDevice(), it first
checks the orphan list to see if the device nodes it needs are there,
otherwise it tries to initialize the device nodes and if it fails, then
it adds the device nodes it wants to its list in the dependency map.
This allows MediaDevice instances to be created and initialized properly
with udev when v4l device nodes in the media graph may not be ready when
the MediaDevice is populated.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Report the list of available static metadata tags (characteristicKeys),
of supported controls (requestKeys) and produced metadata (resultKeys)
in the static metadata pack.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
According to the Android camera HALv3 documentation, the request
template metadata pack should not be modified after it is returned to
the camera stack from the HAL.
Currently, the same metadata pack is used for all types of template
request, without updating the capture intent there contained to match
the requested template type, as correctly reported by the
cros_camera_test test application.
In order to avoid modifying the single request template already returned
to the camera stack in order to update the capture intent it contains,
create a map that associates a dedicated template to each supported
capture type.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Simplify the implementation of metadata handling in the CameraDevice
class by using the new CameraMetadata helper class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The new CameraMetadata helper class wraps the Android camera_metadata_t
to simplify its usage.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use more opportune sizes, manually calculated, for the generated request
template.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add two missing tags from the request template generated by the HAL.
The tags are reported as missing by the cros_camera_test tool.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Remove metadata tags wrongly added to the request template constructed
by the libcamera HAL.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use more opportune sizes for the static metadata pack, and for the
dynamic metadata sizes which where wrongly set to use the ones defined
for the static pack.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add all the static metadata keys part of the BC (backward compatible)
metadata group, which represent the minimum requirement for devices
supporting the LIMITED hardware level.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The error messages are copied from getControls() without being updated
for the set controls case, fix this.
Fixes: eb068f4e67eedacd ("libcamera: v4l2_device: Implement get and set controls")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Casting the return value of a function to (void) doesn't ignore the
unused result warning with gcc. Use a #pragma to fix this properly, to
fix compilation with _FORTIFY_SOURCE.
Fixes: df23ab95f3d7 ("libcamera: process: fix compilation on Chromium OS")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
M2M devices using MPLANE API will set the V4L2_CAP_VIDEO_M2M_MPLANE
capability flag.
Ensure that this is matched when checking for Multiplanar capabilities.
Fixes: 4f7625cca7ec ("libcamera: v4l2_videodevice: Support M2M devices")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The CameraDevice class has a mechanism to cache static metadata, but
doesn't use it. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
The CameraHalManager starts the libcamera CameraManager and creates
CameraProxy instances for each camera in the system. Clean up those
resources when the CameraHalManager terminates.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager::close() method isn't used, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager starts a thread that is never stopped. This leads
to the thread being destroyed while running, which causes a crash. Fix
this by stopping the thread and waiting for it to finish in the
destructor of the CameraHalManager.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraProxy is constructed with a Camera instance passed through a
shared pointer. It forwards it to the CameraDevice constructor, which
takes a reference used for the sole purpose of making an internal copy
of the shared pointer. Both constructors can thus take a const reference
instead of a value or a mutable reference. This optimises the
constructors slightly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Pass the CameraManager instance from the main() function to the
MainWindow class instead of accessing it through
CameraManager::instance(). This prepares for the removal of the
CameraManager::instance() method.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The camera manager is stopped both in the destructor of the MainWindow
class and in the main() function. This double stop isn't needed, remove
the former and keep the latter as the manager is started in the main()
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Get the event dispatcher from the current thread instead of the camera
manager. This prepares for the removal of CameraManager::instance().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The device enumerator logs an error message when a media device is
removed while still in use. Add the device name to the message to help
debugging.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Replace the manual implementation of asynchronous method invocation
through a custom message with Object::invokeMethod(). This simplifies
the thread RPC implementation.
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Threads contain message queues and dispatch queued messages in their
event loop, in Thread::exec(). This mechanism prevents the main thread
from dispatching messages as it doesn't run Thread::exec().
Fix this by moving message dispatching from Thread::exec() to
EventDispatcher::processEvents().
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>
|
|
When moving an object to a different thread, messages posted for the
object are moved to the message queue of the new thread. Wake up the new
thread to ensure it processes the moved messages.
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>
|
