I've been working on control events and while doing that I encountered a V4L2 API problem. Currently calling select() without REQBUFS having been called first will assume that you want to read (or write for output devices) and it will start the DMA accordingly if supported by the driver. This is very nice for applications that want to use read (usually for MPEG encoders), since they don't need to do an intial read() to kickstart the DMA. It is also pretty much what you expect to happen. Unfortunately, this clashes with applications that just select on exceptions (like a control panel type application that just wants to get events when controls change value). Now a select() on an exception will cause the driver to start the DMA. Obviously not what you want. Ideally the driver's poll() implementation should check whether the user wanted to wait for input, output or exceptions. Unfortunately, that information is not in general passed to the driver (see the code in fs/select.c). I am not certain what to do. One option is that poll no longer can kick off a DMA action. Instead apps need to call read() or write() at least once. In that case a read/write count of 0 should be allowed: that way you can start the DMA without actually needing to read or write data. So apps can do a read(fd, buf, 0), then use poll afterwards to wait for data to arrive. I'm not sure whether this is OK or not. Another alternative would be to try and change the poll() op so that this information is actually passed to the driver. That's a rather painful alternative, though. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
