> 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
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
