> > The v4l2 interface isn't perfect either. IMHO the multiple open spec
> > has some problems too, because you have to specify at open() time if
> > you want to capture with that file handle or not, and only one handle
> > is allowed to ask for capture. I'd like to see this limit removed.
> >
> > It should be handled this way:
> [...]
>
> Ok, good suggestion. In my eyes this should be incorporated into
> v4l2. Bill, what do you think?
Another point: With 2.4.x and kiobufs we can do DMA to userspace now.
I've had a look at the code this weekend, I have it working (quick+dirty
hack) with bttv.
The v4l2 capture interface should use kiobufs instead of let the
applications mmap() kernel-space capture buffers. Unfortunaly drivers
will have to support both kiobufs and mmap to maintain v4l1 backward
compatibility.
> But I don�t understand why there should be another API that is
> like "mostly v4l but with some improvements from v4l2".
Ask Alan. I'd be happy with v4l2 as long as it is backward
compatible. From scanning over v4l2 videodev.[ch] it looks like it
is for the userland API, but not in-kernel (i.e. if you drop in the
v4l2 videodev.[ch] files it will break existing v4l1 drivers).
It is important that v4l1 and v4l2 drivers can coexist because
there are already alot of existing v4l1 drivers.
> For the "new" api, all these things should be available, too.
> Especially of course, the detailed documentation, to make
> things clear to both driver-writers and user-application
> writers.
Big plus for v4l2.
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
