Hello, On October 06, 2009 12:31 AM Karicheri, Muralidharan wrote: > Are we constrained to use the QBUF/DQBUF/STREAMON/STREAMOFF model for this specific device (memory to > memory)? What about adding new IOCTLs that can be used for this specific device type that possibly can > simplify the implementation? Don't forget about the simplest V4L2 io model based on read() and write() calls. This io model fits very well into transaction/conversion like device. There is an issue with blocking calls, as the applications would need to use threads in order to do simple image conversion, but this can be easily avoided with non-blocking io and poll(). > As we have seen in the discussion, this is not a streaming device, rather > a transaction/conversion device which operate on a given frame to get a desired output frame. Each > transaction may have it's own set of configuration context which will be applied to the hardware > before starting the operation. This is unlike a streaming device, where most of the configuration is > done prior to starting the streaming. >From the application point of view an instance of such a device still is a streaming device. The application should not even know if any other apps are using the device or not (well, it may only notice the lower throughput or higher device latency, but this cannot be avoided). Application can queue input and output buffers, stream on and wait for the result. > The changes done during streaming are controls like brightness, > contrast, gain etc. The frames received by application are either synchronized to an input source > timing or application output frame based on a display timing. Also a single IO instance is usually > maintained at the driver where as in the case of memory to memory device, hardware needs to switch > contexts between operations. So we might need a different approach than capture/output device. All this is internal to the device driver, which can hide it from the application. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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
