> > select() works for streaming mmap(), so you don't need a non-blocking
> > read() for that.
>
> Bear in mind that simpler drivers don't support mmap, and for those
> non-blocking read is going to be the only way to integrate V4L IO in a
> standard Unix select loop.
Implementing mmap() support isn't much harder than non-blocking read()
for a device driver. Many of the issues which come into play when when
implementing streaming mmap() are problems for a non-blocking read() too.
> It's be nice if bttv also supported this to allow
> for V4L applications that are not driver specific. Of course it's true that
> bttv considered in isolation doesn't need select() support for both mmap and
> read (or support for read at all, for that matter!).
bttv 0.8.x does read(). No non-blocking support throuth, as the current
implementation does dma-to-userspace for read().
> > I don't see the point in using mmap() and read() based capture at the
> > same time. So why require drivers to deal with that special case?
>
> I can think of a few scenarios where it might be useful, but more generally I
> see it as a case where the API shouldn't be trying to second guess what the
> application writer or user is going to want to do. The API/driver should make
> life easy for the user, not vice versa.
There is no point in making a driver more complex without a real need.
You can implement lots of fancy stuff, but why do that if nobody will
ever use that?
> Just as a cute example, something I'd been considering in the past was to add
> support to bttv for the Bt848 "zoom/region-of-interest" feature, and then use
> a low resolution read, concurrent with mmap, to provide a porthole viewer
> window that would let you move this region around... imagine watching MTV and
> being able to zoom in on Christina Aguilera - good application of technology!
The v4l2 API doesn't allow to do that anyway. You can't use different
settings for read/mmap capture.
> > Also streaming capture guaranties that the application can get full
> > rate, allowing any other capture requests inbetween would break that.
>
> Not exactly... the API only implies that a V4LMCAPTURE at a given point in
Sorry, I talking about v4l2 here (see $subject).
> It's been a while since I read the Bt848 datasheet, but might it even be
> possible to program the DMA engine to copy a given frame to dual destinations?
No. The bt848 has no onboard memory, it just has a FIFO which dumps the
incoming data to the PCI bus. It can't write the same data item twice.
Gerd
--
Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Au�enstelle Berlin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
