On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: <snip> > > > 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. This probably assumes that the host driver knows that this is a special queue? Because in general drivers will simply keep capturing in the last buffer and not release it to userspace until a new buffer is queued. That said, it wouldn't be hard to add some flag somewhere that puts a queue in a 'stop streaming on last buffer capture' mode. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
