doc_rst: rename the media Sphinx suff to Documentation/media
[cascardo/linux.git] / Documentation / media / uapi / v4l / dev-osd.rst
1 .. -*- coding: utf-8; mode: rst -*-
2
3 .. _osd:
4
5 ******************************
6 Video Output Overlay Interface
7 ******************************
8
9 **Also known as On-Screen Display (OSD)**
10
11 Some video output devices can overlay a framebuffer image onto the
12 outgoing video signal. Applications can set up such an overlay using
13 this interface, which borrows structures and ioctls of the
14 :ref:`Video Overlay <overlay>` interface.
15
16 The OSD function is accessible through the same character special file
17 as the :ref:`Video Output <capture>` function. Note the default
18 function of such a ``/dev/video`` device is video capturing or output.
19 The OSD function is only available after calling the
20 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
21
22
23 Querying Capabilities
24 =====================
25
26 Devices supporting the *Video Output Overlay* interface set the
27 ``V4L2_CAP_VIDEO_OUTPUT_OVERLAY`` flag in the ``capabilities`` field of
28 struct :ref:`v4l2_capability <v4l2-capability>` returned by the
29 :ref:`VIDIOC_QUERYCAP` ioctl.
30
31
32 Framebuffer
33 ===========
34
35 Contrary to the *Video Overlay* interface the framebuffer is normally
36 implemented on the TV card and not the graphics card. On Linux it is
37 accessible as a framebuffer device (``/dev/fbN``). Given a V4L2 device,
38 applications can find the corresponding framebuffer device by calling
39 the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` ioctl. It returns, amongst
40 other information, the physical address of the framebuffer in the
41 ``base`` field of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`.
42 The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same
43 address in the ``smem_start`` field of struct
44 :c:type:`struct fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``
45 ioctl and struct :c:type:`struct fb_fix_screeninfo` are defined in
46 the ``linux/fb.h`` header file.
47
48 The width and height of the framebuffer depends on the current video
49 standard. A V4L2 driver may reject attempts to change the video standard
50 (or any other ioctl which would imply a framebuffer size change) with an
51 ``EBUSY`` error code until all applications closed the framebuffer device.
52
53
54 .. code-block:: c
55     :caption: Example 4.1. Finding a framebuffer device for OSD
56
57     #include <linux/fb.h>
58
59     struct v4l2_framebuffer fbuf;
60     unsigned int i;
61     int fb_fd;
62
63     if (-1 == ioctl(fd, VIDIOC_G_FBUF, &fbuf)) {
64         perror("VIDIOC_G_FBUF");
65         exit(EXIT_FAILURE);
66     }
67
68     for (i = 0; i < 30; i++) {
69         char dev_name[16];
70         struct fb_fix_screeninfo si;
71
72         snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i);
73
74         fb_fd = open(dev_name, O_RDWR);
75         if (-1 == fb_fd) {
76             switch (errno) {
77             case ENOENT: /* no such file */
78             case ENXIO:  /* no driver */
79                 continue;
80
81             default:
82                 perror("open");
83                 exit(EXIT_FAILURE);
84             }
85         }
86
87         if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &si)) {
88             if (si.smem_start == (unsigned long)fbuf.base)
89                 break;
90         } else {
91             /* Apparently not a framebuffer device. */
92         }
93
94         close(fb_fd);
95         fb_fd = -1;
96     }
97
98     /* fb_fd is the file descriptor of the framebuffer device
99        for the video output overlay, or -1 if no device was found. */
100
101
102 Overlay Window and Scaling
103 ==========================
104
105 The overlay is controlled by source and target rectangles. The source
106 rectangle selects a subsection of the framebuffer image to be overlaid,
107 the target rectangle an area in the outgoing video signal where the
108 image will appear. Drivers may or may not support scaling, and arbitrary
109 sizes and positions of these rectangles. Further drivers may support any
110 (or none) of the clipping/blending methods defined for the
111 :ref:`Video Overlay <overlay>` interface.
112
113 A struct :ref:`v4l2_window <v4l2-window>` defines the size of the
114 source rectangle, its position in the framebuffer and the
115 clipping/blending method to be used for the overlay. To get the current
116 parameters applications set the ``type`` field of a struct
117 :ref:`v4l2_format <v4l2-format>` to
118 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY`` and call the
119 :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
120 :ref:`struct v4l2_window <v4l2-window>` substructure named ``win``. It is not
121 possible to retrieve a previously programmed clipping list or bitmap.
122
123 To program the source rectangle applications set the ``type`` field of a
124 struct :ref:`v4l2_format <v4l2-format>` to
125 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY``, initialize the ``win``
126 substructure and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
127 The driver adjusts the parameters against hardware limits and returns
128 the actual parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does. Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`,
129 the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
130 about driver capabilities without actually changing driver state. Unlike
131 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` this also works after the overlay has been enabled.
132
133 A struct :ref:`v4l2_crop <v4l2-crop>` defines the size and position
134 of the target rectangle. The scaling factor of the overlay is implied by
135 the width and height given in struct :ref:`v4l2_window <v4l2-window>`
136 and struct :ref:`v4l2_crop <v4l2-crop>`. The cropping API applies to
137 *Video Output* and *Video Output Overlay* devices in the same way as to
138 *Video Capture* and *Video Overlay* devices, merely reversing the
139 direction of the data flow. For more information see :ref:`crop`.
140
141
142 Enabling Overlay
143 ================
144
145 There is no V4L2 ioctl to enable or disable the overlay, however the
146 framebuffer interface of the driver may support the ``FBIOBLANK`` ioctl.