No subject

passing a framebuffer between two V4L2 devices and between a V4L2 device
and GPU. The V4L2 device can either be an input or an output one.
The original idea were to add yet-another-mmap-mode at the VIDIOC streaming
ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed
there, this would leed into sync issues on a shared buffer, causing flip
effects. Also, as the API is generic, it can be used also on generic computers,
like desktops, notebooks and tablets (even on arm-based designs), and it
may end to be actually implemented as a PCI2PCI transfer.

So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers. We probably need
something that it will be an enhanced version of the VIDIOC_FBUF/VIDIOC_OVERLAY
ioctls. Unfortunately, we can't just add more stuff there, as there's no
reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's.

It seems to me that the proper way to develop such API is to start working
with Xorg V4L driver, changing it to work with KMS and with the new API
(probably porting some parts of the Xorg driver to kernelspace).

One of the problems with a shared framebuffer is that an overlayed V4L stream
may, at the worse case, be sent to up to 4 different GPU's and/or displays.

Imagine a scenario like:

	===================+===================
	|                  |                  |
	|      D1     +----|---+     D2       |
	|             | V4L|   |              |
	+-------------|----+---|--------------|
	|             |    |   |              |
	|      D3     +----+---+     D4       |
	|                  |                  |
	=======================================


Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer is
partially shared between them (the above is an example of a V4L input, although
the reverse scenario of having one frame buffer divided into 4 V4L outputs
also seems to be possible).

As the same image may be divided into 4 monitors, the buffer filling should be
synced with all of them, in order to avoid flipping effects. Also, the shared
buffer can't be re-used until all displays finish reading. From what I understood 
from the discussions with DRI people, the display API's currently has similar issues
of needing to wait for a buffer to be completely used before allowing it to be
re-used. According to them, this were solved there by dynamically allocating buffers. 
We may need to do something similar to that also at V4L.

Btw, the need of managing buffers is currently being covered by the proposal
for new ioctl()s to support multi-sized video-buffers [1].

[1] http://www.spinics.net/lists/linux-media/msg30869.html

It makes sense to me to discuss such proposal together with the above discussions, 
in order to keep the API consistent.

On my understanding, the SoC people that are driving those changes will
be working on providing the API proposals for it. They should also be
providing the needed patches, open source drivers and userspace application(s) 
that allows testing and validating the GPU <==> V4L transfers using the newly API.

Thanks,
Mauro