Hi,

From the today's V4L presentation, there were two missing topics that may be

useful to include for our discussions: a) V4L overlay mode; b) dvb.

So, I'm bringing those two topics for discussions. If needed, I can do some presentation about them, but it seemed better to start the discussion via ML, in order to know more about the interests over those two subject.

a) V4L overlay mode ================

The V4L Overlay mode were used a lot during kernel 2.2 and 2.4 days, were most hardware were not capable enough to do real-time processing of video streams. It is supported by xawtv and a Xorg v4l driver, and uses XV overlay extensions to display video. It is simple to setup and it requires no CPU usage for it, as the video framebuffer is passed directly to the video hardware, that programs DMA to write directly into the fb memory.

The main structures used on overlay mode (from kerrnel include/linux/videodev2.h) are:

struct v4l2_pix_format { __u32 width; __u32 height; __u32 pixelformat; enum v4l2_field field; __u32 bytesperline; /* for padding, zero if unused */ __u32 sizeimage; enum v4l2_colorspace colorspace; __u32 priv; /* private data, depends on pixelformat */ };

struct v4l2_framebuffer { __u32 capability; __u32 flags; /* FIXME: in theory we should pass something like PCI device + memory * region + offset instead of some physical address */ void *base; struct v4l2_pix_format fmt; }; /* Flags for the 'capability' field. Read only */ #define V4L2_FBUF_CAP_EXTERNOVERLAY 0x0001 #define V4L2_FBUF_CAP_CHROMAKEY 0x0002 #define V4L2_FBUF_CAP_LIST_CLIPPING 0x0004 #define V4L2_FBUF_CAP_BITMAP_CLIPPING 0x0008 #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 #define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 /* Flags for the 'flags' field. */ #define V4L2_FBUF_FLAG_PRIMARY 0x0001 #define V4L2_FBUF_FLAG_OVERLAY 0x0002 #define V4L2_FBUF_FLAG_CHROMAKEY 0x0004 #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 #define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040

Using it is as simple as selecting a format that the video display framebuffer supports, and send a couple of ioctls to the video adapter.

This is what the Xorg v4l driver (v4l.c) does (simplified, to ease comprehension):

struct v4l2_framebuffer yuv_fbuf; int on = 1; if (-1 == ioctl(V4L_FD, VIDIOC_G_FBUF, &yuv_fbuf)) return;

/* Sets the Framebuf data: width, heigth, bpp, format, base and display position */ yuv_fbuf.fmt.width = surface->width; yuv_fbuf.fmt.height = surface->height; yuv_fbuf.fmt.bytesperline = surface->pitches[0]; yuv_fbuf.fmt.pixelformat = V4L2_PIX_FMT_YUYV; yuv_fbuf.base = (char *)(memPhysBase + surface->offsets[0]); memset(&yuv_win, 0, sizeof(yuv_win)); yuv_win.w.left = 0; yuv_win.w.top = 0; yuv_win.w.width = surface->width; yuv_win.w.height = surface->height; if (-1 == ioctl(V4L_FD, VIDIOC_S_FBUF, yuv_fbuf)) return;

/* Sets mem transfer type to overlay mode */ memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_OVERLAY; if (-1 == ioctl(V4L_FD, VIDIOC_S_FMT, &fmt)) return;

/* Enables overlay mode. Data are transfered directly from video capture device into display framebuffer */ memcpy(&fmt.fmt.win, &pPPriv->yuv_win, sizeof(pPPriv->yuv_win)); if (-1 == ioctl(V4L_FD, VIDIOC_OVERLAY, &on)) return;

The main issue with the overlay mode, as discussed on the first day, is that the framebuffer pointer is a physical address. The original idea, on v4l2, were to use some framebuffer ID.

That's said, it wouldn't be hard to add a new flag at v4l2_framebuffer.flags, saying meant to say that it should use a GEM ID. I had some discussions with David Arlie about that when I've submitted the v4l driver fixes due to the removal of the V4L1 old API. I'm planning to submit something like that in the future, when I have some spare time for doing it. Eventually, if Linaro is interested, it could be an interesting project, as it may solve some of the current needs.

It is probably simpler to do that than to add another mode to the V4L MMAP stuff.

b) DVB ===

Several new ARM devices are now shipped with Digital TV integrated on that. On my Country, we have several mobile phones, tablets and GPS devices with DTV receptors inside. Modern TV sets and set-top-boxes already use Linux with DVB support inside. GoogleTV will for sure need DTV support, as well as similar products.

Even being used everywhere, currently, no big vendor tried to send us patches to improve their DVB support, but I suspect that this should happen soon. This is just an educated guess. It would be nice to have some feedback about that from the vendors.

The DVB API is completely different from the V4L one, and there are two different types of DVB devices: - Full-featured DVB devices, with MPEG-TS, audio and video codec inside it; - "simple" devices that just provide a read() interface to get an MPEG-TS stream.

As modern ARM SoC devices can have a codec DSP processor, it makes sense for them to use the full-featured API, providing just audio and video via the DVB API (yes, DVB has a different way to control and export audio/video than V4L/alsa).

The question here is: is there any demand for it right now? If so, what are the requirements? Are the memory management requirements identical to the current ones?

Thanks, Mauro