Gerd Knorr wrote: > > The non-blocking open/read is useful because it allows you to integrate > > V4L read() based IO with other non-V4L IO in a single select() based > > loop/thread. > > 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. 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!). > > > No. The API spec is pretty clear here: You can't stream and read() at > > > the same time. > > > > Hmmm... I wasn't aware of that. I don't see the point of restricting it. > > 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. 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! > 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 time will receive the next available frame. If the application or user (maybe with a background web cam, or whatever) wants to do mixed read and streaming than obviously some caveats may apply. 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? Ben