[libcamera-devel] checking camera state for shutdown

[Christian Rauch]

Hi Kieran,

Am 22.09.22 um 10:35 schrieb Kieran Bingham:
> Quoting Christian Rauch via libcamera-devel (2022-09-21 23:01:47)
>> Hi,
>>
>> I am trying to shut down the camera and camera manager properly, but I
>> am getting messages such as "Camera in Stopping state trying
>> queueRequest() requiring state Running" and "Removing media device
>> /dev/media1 while still in use".
>>
>> The general approach I am using is to
>> 1. disconnect callbacks:
>>      camera->requestCompleted.disconnect();
>> 2. stop camera:
>>     camera->stop();
>>     camera->release();
>> 3. stop camera manager:
>>     camera_manager.stop();
>>
>> But the messages above tell me that my callbacks, which re-queue the
>> requests, are not finished before I call stop, and the camera has not
>> been stopped when I stop the camera manager. I can work around this by a
>> "sleep(1)" after the disconnect, but this is not nice.
>
> Hrm... I think we normally disconnect after stopping the camera.
> Though that should still work I would expect, but ...

I think the callback has to be disconnected before stopping the camera.
Otherwise, the callback might still process buffers etc. while the
camera is stopped.
I assume this is happening here: The signal gets disconnected and the
camera is stopped immediately afterwards. But since the (now
disconnected) callback is still running from the previous "emit", it
will try to re-queue the request, which will fail since the camera has
already been stopped.

Since there is no way to tell that the camera has stopped, it is not
possible to prevent these invalid operations inside the callback.

In any case, there should be a way to either:
A) wait for all callbacks to be finished (like a thread join), or
B) tell if the camera stopped (or generally the camera's state).

>
>> Since the camera state is only accessible via internal/private API, how
>> is a user supposed to control the ordered shutdown of cameras etc.? Do
>> we need public API that lets a user check the camera state? Or should
>> the disconnect, stop and release calls make sure that the objects reach
>> these states before returning?
>
> Calling camera->stop() should indeed already block until the camera is
> stopped.
>
> At first I thought the lack of a requestCompleted handler might mean
> libcamera is still holding on to the requests and hasn't been able to
> get them back to the application - but I think they would just leak, and
> be lost. That could be the problem.
>
>
>> Best,
>> Christian
>>