> I have made an attempt to integrate the two interfaces in a single
> layer.
Cool.
> Alan: A while ago, you said something like this was required to get
> v4l2 into the kernel. Could you please have a look, and see if it was
> what you were thinking of - you should be able to replace videodev.c and
> videodev.h with these, without affecting the v4l1 drivers at all, but
> still be able to load v4l2 drivers.
Looks like you started with the 2.2.x videodev.c version, some stuff
which was added in 2.3/4.x is'nt there (very quick scan of the sources).
Before v4l2 can go in some minor issues should be fixed. Once
v4l2 is in the kernel (IMHO 2.5.x stuff, so we have some time...)
the API can't be changed easily, so this should be sorted first.
These come in mind:
* dma-to-userspace. For v4l1 backward compatibility the drivers
will have to support both kernel and userland buffers anyway, so
I'd extend the v4l2 interface to allow both. Adding a flag
to v4l2_buffer.flags to indicate dma-to-userspace and a
void* to v4l2_buffer for the actual pointer should work I think.
The application will still have to call VIDIOC_QUERYBUF to register
each of the userland buffers to allow the driver to lock down the
buffers between streamon and streamoff.
* multiple opens. I'd like to remove the open limitations (the no-io
opens currently in the API spec). IMHO this is just a documentation
and API spec issue.
It should be clear which ioctls will aquire + lock down ressources
(and may fail with -EBUSY if someone else uses the device) and
which ones free ressources. For capture this should be the
STREAMON/STREAMOFF ioctls I think, for overlay PREVIEW(0/1) should
do the trick.
Allowing multiple opens in the API does'nt mean that all drivers must
support it. I think this should be up to the driver. IMHO it should
be allowed for drivers to support single opens only like todays v4l1
drivers do.
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 /.
