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

[Jacopo Mondi]

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.

Thanks
   j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20190812/6cdee5b5/attachment.sig>