On Fri, 25 Feb 2011, Sakari Ailus wrote: > On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote: > > Hi Sakari > > Hi Guennadi, > > > On Fri, 25 Feb 2011, Sakari Ailus wrote: > > > I agree with that. Flash synchronisation is just one of the many parameters > > > that would benefit from frame level synchronisation. Exposure time, gain > > > etc. are also such. The sensors provide varying level of hardware support > > > for all these. > > > > Well, that's true, but... From what I've seen so far, many sensors > > synchronise such sensitive configuration changes with their frame readout > > automatically, i.e., you configure some new parameter in a sensor > > register, but it will only become valid with the next frame. On other > > sensors you can issue a "hold" command, perform any needed changed, then > > issue a "commit" and all your changes will be applied atomically. > > At that level it's automatic, but what I meant is synchronising the > application of the settings to the exposure start of a given frame. This is > very similar to flash synchronisation. Right... But I don't think we can do more, than what the sensor supports about this, can we? Only stop the sensor, apply parameters, start the sensor... > > Also, we already _can_ configure gain, exposure and many other parameters, > > but we have no way to use sensor snapshot and flash-synchronisation > > capabilities. > > There is a way to configure them but the interface doesn't allow to specify > when they should take effect. ??? There are V4L ioctl()s to control the flash?... > FCam type applications requires this sort of functionality. > > <URL:http://fcam.garage.maemo.org/> > > > What we could also do, we could add an optional callback to subdev (core?) > > operations, which, if activated, the host would call on each frame > > completion. > > It's not quite that simple. The exposure of the next frame has started long > time before that. This requires much more thought probably --- in the case > of lack of hardware support, when the parameters need to be actually given > to the sensor depend somewhat on sensors, I suppose. Yes, that's right. I seem to remember, there was a case, for which such a callback would have been useful... Don't remember what that was though. > > > Flash and indicator power setting can be included to the list of controls > > > above. > > > > As I replied to Laurent, not sure we need to control the power indicator > > from V4L2, unless there are sensors, that have support for that. > > Um, flash controllers, that is. Yes, there are; the ADP1653, which is just > one example. No, not flash controllers, just an indicator, that a capture is running (normally a small red LED). > > > The power management of the camera is > > > preferrably optimised for speed so that the camera related devices need not > > > to be power cycled when using it. If the flash interface is available on a > > > subdev separately the flash can also be easily powered separately without > > > making this a special case --- the rest of the camera related devices (ISP, > > > lens and sensor) should stay powered off. > > > > > > > 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. > > > > What we would probably miss is a way to issue a STREAMON with a number of > > > > frames to capture. A new ioctl is probably needed there. Maybe that would be > > > > an opportunity to create a new stream-control ioctl that could replace > > > > STREAMON and STREAMOFF in the long term (we could extend the subdev s_stream > > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl in > > > > video_ioctl2 internally). > > > > > > How would this be different from queueing n frames (in total; count > > > dequeueing, too) and issuing streamon? --- Except that when the last frame > > > is processed the pipeline could be stopped already before issuing STREAMOFF. > > > That does indeed have some benefits. Something else? > > > > Well, you usually see in your host driver, that the videobuffer queue is > > empty (no more free buffers are available), so, you stop streaming > > immediately too. > > That's right. Disabling streaming does save some power but even more is > saved when switching the devices off completely. This is important in > embedded systems that are often battery powered. > > The hardware could be switched off when no streaming takes place. However, > this introduces extra delays to power-up at times they are unwanted --- for > example, when switching from viewfinder to still capture. > > The alternative to this is to add a timer to the driver: power off if no > streaming has taken place for n seconds, for example. I would consider this > much inferior to just providing a simple subdev for the flash chip and not > involve the ISP at all. There's an .s_power() method already in subdev core-ops. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
