> I've thought about what you said, and the general problem is that there > is no concept of a stream halt except by explicit STREAMOFF command from > the program. V4L2 needs to handle the case where a stream has to be > halted because of an external event or change-of-state on the hardware. Why? I don't see a need for that. What "external events"? And why it is allowed to change the state if the hardware while it is busy? > Your example is good, but any stream could be interrupted, and it may > not be possible to restart the stream. For example, a hot-pluggable > device that gets unplugged. Ok, valid point. What does the usb webcam driver (ov511?) in case someone unplugs the device while it is in use? -ENODEV? > If the driver internally halts a stream, then VIDIOC_DQBUF will return > -ERESTART. If the app gets -ERESTART then the app must do a > VIDIOC_STREAMOFF (to clear the driver state). No. Reusing -ERESTART for this is a _very_ bad idea. It means something else. > With that, it is possible to make things like changing input or changing > the norm (NTSC/PAL) work. Why we should allow such changes while the device is in use? Gerd -- Get back there in front of the computer NOW. Christmas can wait. -- Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel
