| Age | Commit message (Collapse) | Author |
|---|
|
Add the plumbing to the pipeline handler to interact with an IPA module.
This change makes the usage of an IPA module mandatory for the rkisp1
pipeline.
The RkISP1 pipeline handler makes use of a timeline component to
schedule actions. This might be useful for other pipeline handlers going
forward so keep the generic timeline implementation separate to make it
easy to break out.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an IPA which controls the exposure time and analog gain for a sensor
connected to the rkisp1 pipeline. The IPA supports turning AE on and off
and informing the camera of the status of the AE control loop.
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>
|
|
The IPA interface needs to support interactions with the pipeline; add
interfaces to control the sensor and handling of request ISP parameters
and statistics.
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>
|
|
A new ControlList container is needed to hold metadata coming out of
the IPA. The list of supported controls in this list is expected to
grow, so for now do not add a validator for the list.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a control to report lock status of the Auto Exposure algorithm. The
idea is that if an AE algorithm is running the control shall be added to
the metadata control list.
If the AE algorithm is locked the value shall be set to true, if it's
converging it shall be set to false. If the AE algorithm is not running
the control shall not be present in the metadata control list.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a control to enable/disable Auto Exposure.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Align the wording of the documentation for the AwbEnable control with
review comments for similar controls.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The IPA acts on a camera and not on a pipeline which can expose more
then one camera. Move the IPA reference to the CameraData.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add support to the dummy VIMC IPA for tracing operation by using a FIFO
channel that will be used by the IPA Interface test to verify
communications with the IPA.
At the moment only add support for the init() operation as it's the only
defined one.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Open source IPA implementations can benefit from usage of libcamera
internal APIs. Allow this by compiling against the internal headers and
linking against libcamera.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The DummyIPA is actually a test IPA module for the virtual media
controller driver VIMC. Rename it accordingly to its usage.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
Starting or stopping a timer from a different thread than the one it
belongs to is inherently racy. Disallow it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The Timer API allows restarting a timer before expiration. This isn't
correctly implemented, fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
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>
|
|
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>
|
|
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>
|
|
Add a new CameraControlValidator class that implements the
ControlValidator interface for a Camera object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The new abstract ControlValidator class defines an interface that will
be used by the ControlList class to validate controls. This will allow
controls to the validated against different object types, such as Camera
and V4L2Device.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the ControlRange class to express the range of a V4L2 control,
replacing the open-coded minimum and maximum fields in the
V4L2ControlInfo class.
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>
|
|
Use the ControlValue class to replace the manually crafted data storage
in V4L2Control. This will help sharing code when more data types will be
supported.
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Add debug message to report which IPA modules have been loaded and in
which order.
The loading order is particularly relevant for the test VIMC IPA, as the
same IPA is compiled with an open source license tag and a proprietary
one and they both match() against the VIMC pipeline handler. Being
informed about their loading order is helpful to understand which one of
the two is actually in use.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
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>
|
|
Sort IPA modules by name when enumerating modules in a directory in
order to guarantee a stable ordering. This eases debugging by making
issues more reproducible.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Fix a typo in the CameraManager documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The timer signal was never emitted in QtEventDispatcher::timerEvent(),
this results in timers not working as designed running under the Qt
event loop. Fix this by emitting the signal on timeout.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Stopping the timer will reset the Timer::deadline_ field to 0 fixing
potential bugs and call QtEventDispatcher::unregisterTimer() which will
take care of the cleanup.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
