Hi everybody, We are nearly done implementing hardware controlled time multiplexing in V4L2. Has promised, I'm posting the results of our experience. The method used to activate/deactivate the inputs is the one described by Gerd in http://www.spinics.net/lists/vfl/msg07946.html. We had to implement the following in the driver: - A buffer can't be associated to an input, as the hardware doesn't provide a way to know which input will be next before we pass it the buffer scatter-gather list. Only the number of buffers reserved for each input is kept in the driver internal state. -Iin QBUF, if buf.flags has V4L2_BUF_FLAG_TIMEMUX (0x200), buf.reserved[0] must be set by the application as the input number that the buffer will be used for. If the input has no buffer associated with it, it will be activated. The input buffer count is incremented by one. - In DQBUF, if buf.flags has V4L2_BUF_FLAG_TIMEMUX, buf.reserved[0] is set by the driver to the input number corresponding to the buffer being dequeued. The input buffer count is decremented by one. If the count reaches 0, the input is deactivated. - In DQBUF, if the next buffer in the done list contains an image from an input that has been deactivated (this happens because of internal delays), the buffer is requeued and not passed to the user. That was quite easy to implement, and works quite well. Some more problems arose when we tried to setup capture. The hardware allows to set the brightness, contrast, hue, saturation, temporal decimation and image size independently for each input. Some parameters are easy to manage, others are not. - Brightness, contrast, hue, saturation: These parameters are set for the input currently selected by S_INPUT. This can be changed anytime are runtime. No problem here. - Temporal decimation: Same as above. Still no problem here. - Image size: The image size must be known before allocating the buffers. When the inputs have different sizes, some problems may occur. The buffers must be allocated to match the largest size, which means we have to set the size of all inputs, as they all can be enabled at runtime. An alternative would be to use the same size for all inputs, not using the hardware ability to scale each of them independently. I'm not entirely convinced about that. Comments are welcome. Laurent Pinchart
