Gerd Knorr wrote:
...snip...
> 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).
Yeah, I know - I just don't have the resources at the moment to keep
full 2.2 and 2.4 kernel trees. I will only do 2.4 when it is officially
released.
> 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.
That is just what those reserved[] fields are for at the end of
v4l2_buffer. One of those can be used, and an extra flag field
implemented. Thanks to Bill Dirks, it seems v4l2 is very extensible...
(And thanks to luck/good planning DMA to userspace will work very well
with the current API!)
> * 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.
I would also like to have opens simply lock down the resources they
require.
> 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.
This goes with the point above...
> 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.
This is allowed in the API as is currently specced.
An extra that I was think of was to take out the v4l1 backward
compatibility from v4l2, and make a separate module, a pseudo driver
which can plug in on a different minor, and provide a v4l1 interface to
another driver, and a similar module to provide a v4l2 interface to a
v4l1 driver. This way the interfaces could also be done at driver level
(ie a driver registers both a v4l1 and a v4l2 interface), to provide
optimal performance on both interfaces.
Any thoughts?
-justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
