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
62 :ref:`streaming parameter <streaming-par>` ioctls as needed. The
72 frame buffer parameters, namely the address and size of the frame buffer
79 superuser can change the frame buffer address and size. Users are not
85 card. In this case the frame buffer is not modified by the video device,
86 and the frame buffer address and pixel format are not needed by the
93 1. Chroma-keying displays the overlaid image only where pixels in the
102    A list of clipping rectangles can be specified. In these regions *no*
112 prohibits different image and frame buffer formats, the format requested
162 ------------------
166     the frame buffer defined with
168     frame buffer width and height, the ``x`` and ``y`` coordinates can
169     be negative, and it can lie completely outside the frame buffer. The
181     When chroma-keying has been negotiated with
187     :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR32>` the value should
188     be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.
192     When chroma-keying has *not* been negotiated and
198     relative to the top, left corner of the frame buffer. However
199     clipping rectangles must not extend the frame buffer width and
202     x-y or y-x bands, or the order of rectangles, is not defined. When
213     supported but no clipping is desired this field must be set to zero.
217     When chroma-keying has *not* been negotiated and
227 .. code-block:: c
235 undefined. When a bit mask is supported but no clipping is desired this
239 both, or despite negotiating chroma-keying, the results are undefined.
249     :ref:`framebuffer-flags`).
262 -----------------------
266     corner of the frame buffer. Only window pixels *outside* all
278 ----------------
298 To start or stop the frame buffer overlay applications call the
302    In the opinion of the designers of this API, no driver writer taking
310    Hence as a complexity trade-off drivers *must* support two file
317    When the image is written into frame buffer memory it will be
325    BoxRec { short x1, y1, x2, y2; }`` with ``width = x2 - x1`` and
326    ``height = y2 - y1``, so one cannot pass X11 clip lists directly.