...Just occurred to me: On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote: > On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote: > > > On Mon, 28 Feb 2011, Hans Verkuil wrote: > > > > > Does anyone know which drivers stop capture if there are no buffers available? > > > I'm not aware of any. > > > > Many soc-camera hosts do that. > > > > > I think this is certainly a good initial approach. > > > > > > Can someone make a list of things needed for flash/snapshot? So don't look yet > > > at the implementation, but just start a list of functionalities that we need > > > to support. I don't think I have seen that yet. > > > > These are not the features, that we _have_ to implement, these are just > > the ones, that are related to the snapshot mode: > > > > * flash strobe (provided, we do not want to control its timing from > > generic controls, and leave that to "reasonable defaults" or to > > private controls) Wouldn't it be a good idea to also export an LED (drivers/leds/) API from our flash implementation? At least for applications like torch. Downside: the LED API itself is not advanced enough for all our uses, and exporting two interfaces to the same device is usually a bad idea. Still, conceptually it seems to be a good fit. Thanks Guennadi > > * trigger pin / command > > * external exposure > > * exposure mode (ERS, GRR,...) > > * use "trigger" or "shutter" for readout > > * number of frames to capture > > Add > > * multiple videobuffer queues > > to the list --- 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
