[libcamera-devel] Advice on how to wait for camera framework to start

[Eric Curtin]

On Thu, 23 Jun 2022 at 17:48, Kieran Bingham
<kieran.bingham at ideasonboard.com> wrote:
>
> Quoting Eric Curtin via libcamera-devel (2022-06-21 16:32:18)
> > Hi guys,
> >
> > I'm looking for a way on boot to wait until the camera framework has
> > started in a machine and at that point start the camera as quickly as
> > possible. At present if you start the camera before the camera stack is up
> > kernel-side at present you get:
> >
> > "No valid sysfs media device directory"
> >
> > unless you have compiled with libudev, then you fail in a similar location
> > in the udev version.
> >
> > Without being an expert in systemd, udev etc. Are there any useful ways to
> > detect when the camera is up kernel side and at that point start as quickly
> > as possible? Without repeatedly checking for existence of the directory?
>
> I think systemd can do waiting on devices - but that sounds hard to do
> generically - because it's platform specific with what to wait on.

I actually used to do it the systemd udev way, but it's too slow,
because only then you are executing the binary. It's faster to have
the binary loaded with all the dynamic linking and other
initialization done, etc.

I did wait for /dev/media*, then I found /dev/video0 is probably
better, so I changed it to that? I think at least for a v4l2 device
you need both and it appears /dev/video* appears after /dev/media*.

Thanks for the ideas.

What I did is basically what's in:

CamApp::init()

down to the first:

#endif

https://github.com/ericcurtin/twincam/blob/main/src/twincam.cpp

My code is probably very v4l2 specific and I will eventually do the
udev part in an event driven fashion most likely.

>
> I think certainly waiting on the /dev/media0 device is a minimum, but
> the camera manager won't handle the cameras until they are all
> available. I think udev is already event driven - so it might be able to
> probe the cameras when the components are fully available - but this
> would be taking the path of building a camera 'server' daemon, or making
> even fixed cameras appear as if they were 'hotplugged'.
>
> I know in the android layer, they don't like that to happen - they wait
> for an expected number of cameras to be available or they restart the
> server to wait and try again...
>
> Not a solution or an answer I'm afraid, but this is definitely an
> interesting discussion point!
> --
> Kieran
>