[libcamera-devel] [PATCH v3 6/6] android: hal: Add Camera3 HAL

[Laurent Pinchart]

Hi Jacopo,

On Mon, Aug 12, 2019 at 11:21:02AM +0200, Jacopo Mondi wrote:
> Hi Laurent, one additiona note
> 
> On Sat, Aug 10, 2019 at 07:51:51PM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> 
> [snip]
> 
> > > +int CameraProxy::processCaptureRequest(camera3_capture_request_t *request)
> > > +{
> > > +	ThreadRpc rpcRequest;
> > > +	rpcRequest.tag = ThreadRpc::ProcessCaptureRequest;
> > > +	rpcRequest.request = request;
> > > +
> > > +	threadRpcCall(rpcRequest);
> > > +
> > > +	return 0;
> > > +}
> >
> > Repeating my question for the previous version, does this method need to
> > be synchronous ? We can keep it as-is for now, but I wonder if it
> > wouldn't make sense to later move (part of) the validation code here and
> > make the call asynchronous.
> 
> Quoting the camera3.h header description of the expected operation
> sequence:
> 
>  * 7. The framework constructs and sends the first capture request to the HAL,
>  *    with settings based on one of the sets of default settings, and with at
>  *    least one output stream, which has been registered earlier by the
>  *    framework. This is sent to the HAL with
>  *    camera3_device_t->ops->process_capture_request(). The HAL must block the
>  *    return of this call until it is ready for the next request to be sent.
> 
> The last statement makes me wonder if making the method asynchronous
> would not then require serializin the requests on our side, as if we
> return earlier, there might be a chance (no idea how large the
> windonw could be) we receive a new capture request while the previous
> one still has to be handled.
> 
> Consider this, I'm not sure it's a good idea to make this call
> asynchronous.

As the calls are queued and processed in order in our HAL implementation
I think we could still make it asynchronous, but it may not be worth it
indeed. Let's just keep it in mind for now.

-- 
Regards,

Laurent Pinchart