[libcamera-devel] Problems opening/closing camera in different processes

[Dave Stevenson]

Hi David

On Mon, 7 Nov 2022 at 12:26, David Plowman via libcamera-devel
<libcamera-devel at lists.libcamera.org> wrote:
>
> Hi everyone
>
> Recently I've been working with multiple cameras and trying to make it
> possible to close them in one process and open them in another
> (without terminating the first process altogether). I'm still left
> with one problem and would like to get some suggestions as to how we
> should solve it.
>
> To illustrate the problem:
>
> Case 1 (works):
>
> In process 1, acquire the camera and then release it (but do not
> terminate the process).
>
> Process 2 can now acquire the camera and start it successfully. Hurray!
>
> Case 2 (broken):
>
> In process 1, acquire the camera, start it, then stop it and release
> it (again, do not terminate the process).
>
> Process 2 can acquire the camera but when you try to start it, it fails.  :(
>
> The reason is that process 1 still holds file descriptors for all the
> devices in question (which is fair enough) but crucially it still has
> DMABUFs allocated, and this stops anyone else from doing so.

It shouldn't.
https://github.com/torvalds/linux/commit/d644cca50f366cd109845ae92e37c09ed79adf81
should mean that the buffers get orphaned, which frees up the queue.

The Pi pipeline handler is relying on this behaviour -  it sets the
format, calls REQBUF(n), exports all the buffer, calls REQBUF(0) to
release them from videobuf2, and then passes them back in using dmabuf
import.

Which V4L2 device is it that still has a busy queue?
There is the issue of not having enough memory to allocate a second
load of buffers.

  Dave

> Currently the CameraData (RPiCameraData in our case) gets no
> notification that the camera has been released - perhaps it should?
> The PipelineHandler could simply tell the CameraData that it's being
> released, and that would give us a place to free those buffers.
>
> Thoughts?
>
> Thanks!
> David