Hello Gerd,
> 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>
Ok, this would fix some stuff.
> > 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:
[...]
Ok, good suggestion. In my eyes this should be incorporated into
v4l2. Bill, what do you think?
But I don�t understand why there should be another API that is
like "mostly v4l but with some improvements from v4l2".
At the moment, v4l2 is gaining pace as there is Justin's working
bttv-v4l2-driver (...and I will release an alpha-version of
my saa7146-driver on tuesday), Bills Winnov-Driver plus an
excellent set of documentation and a driver-writers-guide.
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.
I don�t want to hurt Alans feelings, but I think he has
enough things to do besides specifing a new api and
writing (sorry Bill!) "boring" documentation.
Additionally, it would take again some time to get a
working bttv-driver.
> Gerd
CU,
Michael.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
