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@xxxxxxxxxxxxxxxxxxxxxxxxxx -- 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
