> > This is the problem with V4L read(), as I see it. The most efficient > > read() / select() implementations end up being a lot like mmap() / > > VIDIOCSYNC, which makes me want to drop support for one or the other. > > (That cannot be done without breaking a lot of apps, though). > > If/when Linux gets async IO that will be true, but until then there's no > way to queue multiple reads, No. From the driver's point of view the mmap() interface and non-blocking read()s are very close. A very simply driver will do blocking reads only. It can do everything while having the process context of the proccess cwhich captures frames using read(). For both non-blocking I/O and mmap()-based capture you have to start doing stuff asyncronly (within the IRQ handler, whatever...), and things become more complex for the driver because of that. > (although I guess we *could* break > compatability in 2.5). I'd prefeare to get the v4l2 interface right before adding it to the kernel, so we don't have to break it once it was added to the standard kernel. Gerd -- Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
