> I cannot understand why on the one side changing the exsting (and in my
> eyes obsolete) v4l-api is suggested which would definetely break
> existing driver- as well as user-code, when on the other side
> there is an existing and very-well designed api that already
> features most things people are always asking for: v4l2.
Was discussed some time ago here. Alan plans to build a new v4l spec
(see msg id <[EMAIL PROTECTED]>) which
basically steels some ideas from different places and adds them:
<quote>
- Original V4L interfaces
- V4L2/Buz multiple buffer posting (non mmap)
- V4L2 format descriptions/table
- V4L2 style enumerate supported formats
- Buz codec setup/control - done in a style like the Stradis if possible
- Stradis V4L extensions for remote input/media control
</quote>
> v4l2 fixed all problems and inconsistencies in comparision to v4l
> I had, when developing drivers for both apis:
>
> Here is a short list:
>
> 1) v4l2 uses queues to for the capture buffers.
Should get fixed, see above.
> 2) One problem that Gerd states in his programming-faq within `xawtv':
>
> > One problem is that the TV norm (PAL/NTSC/...) is in struct
> > video_tuner, not struct video_channel. That's bad if you have a board
> > without tuner at all and a PAL video recorder connected to Composite1
> > and a NTSC Camera to Composite2...
Hmm, I can't see this on alans todo list :-/
> 3) Another big thing is the inconsistency within different capture
> formats. For example: in v4l the byte-order for, say, YUV422 is
> v4l2 clearly separates these two capture formats.
It also fixes some RGB byte order issues (except for RGB555/RGR565 where
no big endian version exists yet).
> My suggestion would be: bring in v4l2 into the kernel with a
> new major number as well as the existing v4l2-drivers.
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: The application can ask for capture
buffers with VIDIOC_REQBUFS. If this was successfull, the application
can use these unlimited until they are freed by the application (either
munmap() or some ioctl if we get rid off the mmaped buffers by using
kiobufs). If the driver can't satisfy what the app asks for because
someone else uses the card, VIDIOC_REQBUFS comes back with -EBUSY.
This will allow multiple applications to do single frame captures if
all involved applications play nicely. Recording video would still
lock out others (at least with bttv).
It will also provide a clean way to support hardware which can handle
multiple video streams in parallel like the one mentioned by Jeff Garzik
in <[EMAIL PROTECTED]> + followups. This one can handle
video up to a certain DMA bandwith, multiple streams from multiple input
sources are supported.
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.
