Hello Gerd,
> Another point: With 2.4.x and kiobufs we can do DMA to userspace now.
> I've had a look at the code this weekend,
> I have it working (quick+dirty hack) with bttv.
Please notify us if you have some alpha-code available on the net,
so we can see how you did it.
> The v4l2 capture interface should use kiobufs instead of let the
> applications mmap() kernel-space capture buffers. Unfortunaly drivers
> will have to support both kiobufs and mmap to maintain v4l1 backward
> compatibility.
With my suggestion (bringing v4l2 parallel to v4l into the kernel)
no backward compatibility is necessary in my eyes.
When the 'kiobuf'-stuff is part of the stable kernel,
the "new" v4l2 could be brought into the kernel using all
the new techniques.
But perhaps we should not overreact on the 'kiobuf'-stuff.
Although it is a very good idea and gets rid of many problems,
it is still very young and there is not much documentation
and examples, especially for user-space-applications that
use it.
And: v4l2 is out there for more than two years and has already
been voted to be better than v4l in direct comparision. And
although the whole video for linux is growing fast at the moment,
there is still no real improvement visible to me. All are still
using v4l.
Plus, Alan states that there are still some things missing with
'kiobufs' needed to provide the things you have been talking about.
I cannot comment on this because I know too little about the stuff,
but perhaps we should stick to the things we have at the moment.
(This does not mean that I don't want any improvements...)
> > But I don�t understand why there should be another API that is
> > like "mostly v4l but with some improvements from v4l2".
>
> Ask Alan.
What do you think Alan?
> It is important that v4l1 and v4l2 drivers can coexist because
> there are already alot of existing v4l1 drivers.
Again, with bringing v4l2 in addition to v4l into the kernel,
not every driver has be ready immediately. All drivers can
be added one after another.
Many "old" drivers, e.g. drivers for the various radio-cards
out there, can be ported easily, since they don�t need any
fancy irq or dma handling.
> Gerd
As you can see, I am still not convinced that v4l2 should
be backward compatible or should exploit all new additions
from the upcoming 2.4.x-kernel.
Sorry, but v4l is simply too broken for non-bt8x8-hardware
and we should switch quickly to something that is more
generic.
CU,
Michael.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.