media/v4l/dev-overlay.rst

1 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
11 Video overlay devices have the ability to genlock (TV-)video into the
12 (VGA-)video signal of a graphics card, or to store captured images
30 frame rate of the video standard is not guaranteed. Frames may be
58 :ref:`streaming parameter <streaming-par>` ioctls as needed. The
67 frame buffer parameters, namely the address and size of the frame buffer
74 superuser can change the frame buffer address and size. Users are not
80 card. In this case the frame buffer is not modified by the video device,
81 and the frame buffer address and pixel format are not needed by the
88 1. Chroma-keying displays the overlaid image only where pixels in the
95 3. A list of clipping rectangles can be specified. In these regions *no*
105 prohibits different image and frame buffer formats, the format requested
155 ------------------
159     the frame buffer defined with
161     frame buffer width and height, the ``x`` and ``y`` coordinates can
162     be negative, and it can lie completely outside the frame buffer. The
174     When chroma-keying has been negotiated with
180     :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR32>` the value should
181     be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.
184     When chroma-keying has *not* been negotiated and
190     relative to the top, left corner of the frame buffer. However
191     clipping rectangles must not extend the frame buffer width and
194     x-y or y-x bands, or the order of rectangles, is not defined. When
204     supported but no clipping is desired this field must be set to zero.
207     When chroma-keying has *not* been negotiated and
217 .. code-block:: c
225 undefined. When a bit mask is supported but no clipping is desired this
229 both, or despite negotiating chroma-keying, the results are undefined.
239     :ref:`framebuffer-flags`).
252 -----------------------
256     corner of the frame buffer. Only window pixels *outside* all
268 ----------------
288 To start or stop the frame buffer overlay applications call the
297    In the opinion of the designers of this API, no driver writer taking
305    Hence as a complexity trade-off drivers *must* support two file
312    When the image is written into frame buffer memory it will be
320    BoxRec { short x1, y1, x2, y2; }`` with ``width = x2 - x1`` and
321    ``height = y2 - y1``, so one cannot pass X11 clip lists directly.