Re: [RFC] Video events, version 2.2

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

Eino-Ville Talvala wrote:
> I think we have a use case for events that would require correlating 
> with frames, although I agree that the buffer index would be far simpler 
> to match with than a timestamp.  The specific feature is letting the 
> application know exactly what sensor settings were used with a given 
> frame, which is essential for our slowly-developing computational camera 
> API, which will be changing sensor parameters on nearly every frame 
> boundary.
> 
> I think one event is probably sufficient to encode the relevant register 
> values of our sensor.  Would you expect there to be any issue with 
> having an event happen per frame?

I do expect several events per frame from the AEWB, AF and histogram 
statistics and no problems. :-)

But if I understand correctly, the registers are some kind of metadata 
associated to the frame? That perhaps includes exposure time, gain etc. 
The events interface would be good for this if the metadata fits to a 
single v4l2_event structure. A new ioctl could be an alternative, 
perhaps it could be a private ioctl first.

This is more or less comparable to the H3A statistics IMO. So the user 
space gets an event and can query the H3A data.

Associating events to a single frame is slightly troublesome since a 
succesful frame reception is only certain when it already has happened. 
There could be a metadata event and after that a receive buffer overflow 
that spoils the frame. In that case the field_count could be just 
incremented without dequeueing any buffers, though.

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