Re: [RFC] snapshot mode, flash capabilities and control

[Sakari Ailus <sakari.ailus@iki.fi>]

Hi,

Guennadi Liakhovetski wrote:
> On Fri, 25 Feb 2011, Sakari Ailus wrote:
>
>> Hi Guennadi,
>>
>> Guennadi Liakhovetski wrote:
>>> In principle - yes, and yes, I do realise, that the couple of controls,
>>> that I've proposed only cover a very minor subset of the whole flash
>>> function palette. The purposes of my RFC were:
>>
>> Why would there be a different interface for controlling the flash in
>> simple cases and more complex cases?
>
> Sorry, not sure what you mean. Do you mean different APIs when the flash
> is controlled directly by the sensor and by an external controller? No, of
> course we need one API, but you either issue those ioctl()s to the sensor
> (sub)device, or to the dedicated flash (sub)device. If you mean my "minor
> subset" above, then I was trying to say, that this is a basis, that has to
> be extended, but not, that we will develop a new API for more complicated
> cases.

I think I misunderstood you originally, sorry. I should have properly 
read the RFC. :-)

Your proposal of the flash mode is good, but what about software strobe 
(a little more on that below)?

Also, what about making this a V4L2 control instead? The ADP1653 driver 
that Laurent referred to implements flash control using V4L2 controls only.

A version of the driver is here:

<URL:http://gitorious.org/omap3camera/mainline/commit/a41027c857dfcbc268cf8d1c7c7d0ab8b6abac92>

It's not yet in mainline --- one reason for this is the lack of time to 
discuss a proper API for the flash. :-)

...

>>>> This doesn't solve the flash/capture synchronization problem though. I don't
>>>> think we need a dedicated snapshot capture mode at the V4L2 level. A way to
>>>> configure the sensor to react on an external trigger provided by the flash
>>>> controller is needed, and that could be a control on the flash sub-device.
>>>
>>> Well... Sensors call this a "snapshot mode." I don't care that much how we
>>> _call_ it, but I do think, that we should be able to use it.
>>
>> Some sensors and webcams might have that, but newer camera solutions
>> tend to contain a raw bayer sensor and and ISP. There is no concept of
>> snapsnot mode in these sensors.
>
> Hm, I am not sure I understand, why sensors with DSPs in them should have
> no notion of a snapshot mode. Do they have no strobe / trigger pins? And
> no built in possibility to synchronize with a flash?

I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a 
flash strobe pin while some doesn't (such as the N900).

Still, even if the strobe pin is missing it should be possible to allow 
strobing the flash by using software strobe (usually an I2C message).

I agree using a hardware strobe is much much better if it's available.

>>> Hm, don't think only the "flash subdevice" has to know about this. First,
>>> you have to switch the sensor into that mode. Second, it might be either
>>> external trigger from the flash controller, or a programmed trigger and a
>>> flash strobe from the sensor to the flash (controller). Third, well, not
>>> quite sure, but doesn't the host have to know about the snapshot mode?
>>
>> I do not favour adding use case type of functionality to interfaces that
>> do not necessarily need it. Would the concept of a snapshot be
>> parametrisable on V4L2 level?
>
> I am open to this. I don't have a good idea of whether camera hosts have
> to know about the snapshot mode or not. It's open for discussion.

What functionality would the snapshot mode provide? Flash 
synchronisation? Something else?

I have to admit I don't know of any hardware which would recognise a 
concept of "snapshot". Do you have a smart sensor which does this, for 
example? The only hardware support for the flash use I know of is the 
flash strobe signal.

Flash synchronisation is indeed an issue, and how to tell that a given 
frame has been exposed with flash. The use of flash is just one of the 
parameters which would be nice to connect to frames, though.

Regards,

-- 
Sakari Ailus
sakari.ailus@iki.fi