> > 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 <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
