[Q] Asynchronous controls vs. events

[Q] Asynchronous controls vs. events

[Guennadi Liakhovetski]

Hi,

I need to add asynchronous control support to the UVC driver. Some UVC 
cameras support some controls in asynchronous mode. For those controls a 
USB status is returned to the host, but the control will only be 
completed, when an Interrupt packet is sent by the device. I can see two 
ways to support this:

(1) synchronously: the driver waits in S_CTRL until the interrupt packet 
arrives

(2) asynchronously: the driver returns immediately and sends an event 
after the Interrupt packet is received.

Question: which method would be preferred, if (2) - what error code should 
the driver use to indicate, that the result of the control isn't known 
yet? Or should success be returned, since a success anyway doesn't 
guarantee that the specified value has already taken effect.

Thanks
Guennadi

Re: [Q] Asynchronous controls vs. events

[Sakari Ailus]

Hi Guennadi,

On Tue, May 17, 2016 at 04:51:07PM +0200, Guennadi Liakhovetski wrote:
> Hi,
> 
> I need to add asynchronous control support to the UVC driver. Some UVC 
> cameras support some controls in asynchronous mode. For those controls a 
> USB status is returned to the host, but the control will only be 
> completed, when an Interrupt packet is sent by the device. I can see two 
> ways to support this:
> 
> (1) synchronously: the driver waits in S_CTRL until the interrupt packet 
> arrives
> 
> (2) asynchronously: the driver returns immediately and sends an event 
> after the Interrupt packet is received.
> 
> Question: which method would be preferred, if (2) - what error code should 
> the driver use to indicate, that the result of the control isn't known 
> yet? Or should success be returned, since a success anyway doesn't 
> guarantee that the specified value has already taken effect.

I'd go with the second option and return success.

The reasoning is that making the operation synchronous requires the user to
wait inconveniently long time. Setting several controls would require at
least as many frames as there are controls. For sensors, the controls will
take effect only later on in any case, often a few frames later depending on
the sensor and what's being changed.

Probably in that case the driver has a reasonable chance of being
successful; the driver can validate the value of the control, can't it, and
if the link went down, there would be other issues as well.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk