[libcamera-devel] Support for hotplugging UVC devices

Laurent Pinchart laurent.pinchart at ideasonboard.com
Fri Apr 17 16:39:23 CEST 2020


Hi Umang,

On Fri, Apr 17, 2020 at 12:28:04PM +0000, Umang Jain wrote:
> Hi all,
> 
> I have doing some researching regarding hot-plugging UVC devices. The
> goal is to have CameraManager emit a "camera-added" hotplug signal so
> that applications like QCam, can detect the newly hotplugged camera
> and be able to start streaming.  I have discussed this with Kieran
> briefly and we both agree this is something worth pursuing.
> 
> As far as I read the implementation,
> DeviceEnumeratorUdev::udevNotify() can detect new UVC devices being
> plugged in and add the the list of media devices in the
> DeviceEnumerator.
> 
> But right now, there is nothing done when a new device is being
> plugged-in, so that it can be brought into use. Below is what I think
> is a very crude version of the code flow is:
> 
> 1) Emit a signal for DeviceEnumerator::addDevice() that CameraManager
> can connect to.
> 
> 2) Upon receiving the signal, the CameraManager queries the
> PipelineHandler to see if it has a supported pipeline. Initially, this
> is being done via PipelineHandler::match() but match() takes a entire
> DeviceEnumerator as argument and is meant to run in a loop(in
> ::init()).  We need something similar to  match() which can validate
> the pipeline-handling-support but for a specific MediaDevice
> instance(s?).

There are two classes involved here, PipelineHandler and
PipelineHandlerFactory. For every subclass of PipelineHandler, we have a
corresponding PipelineHandlerFactory subclass. The job of the factory is
to create an instance of the corresponding PipelineHandler subclass.
There's one instance of each PipelineHandlerFactory subclass registered
in the static list of factories, regardless of how many instances of the
corresponding hardware exist. One instance of the corresponding
PipelineHandler subclass is then created for each device in the system.
The current implementation requires creating a PipelineHandler instance
to see if it matches devices in the system (with match()), so lots of
instances are created an immediately deleted because no match is found.
We will likely rework this in the future, but for now hotplug can use
the same mechanism, looping over all factories, creating pipeline
handler instances, matching them with devices, and deleting them if they
don't match.

> 3) After the Pipeline Handler can validate the support for a
> MediaDevice, it can go ahead and create/register the Camera via
> PipelineHandler::registerCamera() with the CameraManager.

That's right. From a pipeline handler point of view, there should be no
difference whether this step is executed when the camera manager is
started, or later when a device is plugged in.

> 4) The signal-handler in 2), proceeds to emit a
> CameraManager::camera-added signal for applications to connect to.

I think that signal should be emitted when the camera is registered with
the camera manager, not by the hotplug handler from 2).

We also need to consider thread-safety, and make sure the application
will not race with hot-plug. Hot-unplug also needs to be considered from
the point of view of race conditions.

> This is what I have researched till now. Of course, this is right now
> being targeted towards UVC devices but I am sure folks here, will have
> some generalistic point of view to support hotplugs for various other
> media-device domains that I might not be aware of.  Your
> thoughts/comments will be helpful.
> 
> Let me know what you think!

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list