> 1) backward-compatibility layer in v4l2
>
> I still don´t see the need of a v4l-backward
> compatibility layer in v4l2.
For drivers available with v4l it is mandatory
to keep compatibility. For others it is nice
to have.
> I have written both v4l and v4l2-drivers for
> my saa7146-based hardware. Although I tried
> to make my v4l-driver as 'bttv' as possible,
> it never worked with all applications, because
> the apps used some implicit "features" of 'bttv'.
They are broken then. xawtv had plenty of such
bugs too (maybe still has some).
> With this, Justin's approach using a "videodevX" would
> not be needed any more.
What is bad with this?
> You could load both "videodev.o"
> and "videodev2.o" and use your old radio-drivers for
> v4l and the new v4l2-driver for you video-hardware
> for example.
So you can with "videodevX.o".
> Nobody has said: well, you have to add a compatibilty layer
> to ext2, so it can work with old ext-partitions as well.
> It was an complete overhaul, too.
It's a different story. Your filesystem is either ext or ext2,
period. The v4l2 driver has to handle both v4l1 and v4l2
interfaces *at the same time* to be able to support both old
and new applications.
> 3) kiobufs
>
> But there were some questions, that have not been answered
> in this mailing list yet:
> What happens if the app releases the memory, although the
> driver is still doing DMA to it?
I'd expect kiobufs increase the reference counter for the page
while it is locked down so it will not be released until DMA
is done even if the application does. But I hav'nt checked the
kernel source yet.
> What about memory in regions
> that cannot be addressed via DMA?
return -EINVAL on QUERYBUF?
> Have these things been solved?
IMHO they have nothing to do with the API design.
> 4) multiple opens
>
> To support multiple capturing opens is a good thing, when the hardware
> can really deliver independent data from different sources.
>
> For a simple tv-card, multiple capturing opens are a mess. The
> discussion always states that the format of the capture should
> be maintained with every open. But what about the other
> parameters available?
Most of them need to be per-open too. Looks like I should go throuth
the API and write it down...
> I don't think that multiple capturing opens are worth the
> effort.
You don't _have_ to support multiple opens in the driver.
> Why mess with multiple capturing opens that stay open for
> a long while?
Having overlay (i.e. watch TV / check camera with xawtv) and
capture work in parallel is useful. I expect this will be
used more frequently than having two applications do capture
in parallel (at least with the common TV cards which can
capture from a single input source only).
> If multiple capturing opens should be supported, this should
> be done using a userspace-library anyway. There is no need
> to add the complexity to every other driver out there --
> some simple hooks + userspace library are much better.
(1) Supporting multiple opens is not mandatory.
(2) If a driver decides to support multiple opens it has to
keep multiple contexts anyway. I can't see how switching
them with "simple hooks" rather than with multiple
filehandles makes it easier for the driver.
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 /.
