Michael H. Schimek wrote:
> Gerd Knorr wrote:
> >
> > > Yup. And being able to use each of them would be a good thing, imho.
> > > Your point that you could do within alternate buffers is valid, it's
> > > just a personal preference of me to keep the fields sequential.
> >
> > Have V4L2_FIELD_SEQ_TB + V4L2_FIELD_SEQ_BT now, ok?
>
> I think that's a bad idea. See again, Ronald Bultje confirmed (if I
> understood correctly) he wants the _older_ field first, not top or
> bottom.
I understood it exactly the other way around: first field is always
the temporal first. Ronald?
> > I've also dropped min/maxsize from v4l2_capabilities.
>
> Fine. But something else, in the last version of your videodev.h it
> seems you dropped all capab flags. A brief summary:
>
> * TUNER is redundant because an app can just enumerate inputs to learn
> the hw can tune, and more (how many tuners, name, supported video
> standards, audio decoding, frequency range etc).
A TUNER bit is still present, IMHO a _simple_ check to see whenever some
tuner is present or not is useful.
> * PREVIEW (OVERLAY) - You said it's useful, what changed your mind?
It is still there, named "V4L2_CAP_VIDEO_OVERLAY" now.
> * READ/WRITE/STREAMING - Actually I thought this was never in question
> (unlike optional ioctls just returning -EINVAL). I always liked to
> enable the appropriate i/o routines without much ado. What's the
> alternative?
read/write/streaming not being optional (but mandatory like select
support)?
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
