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

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

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?

As far as I see it, the way the flash is accessed should be the same in
both cases --- if more complex functionality is required that would be
implemented in using additional ways (controls, for example).

The drivers should use sane defaults for controls like power and length.
I assume things like mode (strobe/continuous) is fairly standard
functionality.

> 1. get things started in the snapshot / flash direction;)
> 2. get access to dedicated snapshot / flash registers, present on many 
> sensors and SoCs
> 3. get at least the very basic snapshot / flash functions, common to most 
> hardware implementations, but trying to make it future-proof for further 
> extensions
> 4. get a basis for a future detailed discussion
> 
>> Let's also not forget that, in addition to the flash LEDs itself, devices 
>> often feature an indicator LED (a small low-power red LED used to indicate 
>> that video capture is ongoing).
> 
> Well, this one doesn't seem too special to me? Wouldn't it suffice to just 
> toggle it from user-space on streamon / streamoff?

And what if you want to use the led unconnected to the streaming state? :-)

>> 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, 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?

Otherwise we may end adding interfaces for use case specific things. The
use cases vary a lot more than the individual features that are required
to implement them, suggesting it's relatively easy to add redundant
functionality to the API.

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com