Lines Matching +full:no +full:- +full:big +full:- +full:frame +full:- +full:no
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
71 frame buffer parameters, namely the address and size of the frame buffer
78 superuser can change the frame buffer address and size. Users are not
84 card. In this case the frame buffer is not modified by the video device,
85 and the frame buffer address and pixel format are not needed by the
92 1. Chroma-keying displays the overlaid image only where pixels in the
99 3. A list of clipping rectangles can be specified. In these regions *no*
109 prohibits different image and frame buffer formats, the format requested
159 ------------------
163 the frame buffer defined with
165 frame buffer width and height, the ``x`` and ``y`` coordinates can
166 be negative, and it can lie completely outside the frame buffer. The
178 When chroma-keying has been negotiated with
184 :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR32>` the value should
185 be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.
188 When chroma-keying has *not* been negotiated and
194 relative to the top, left corner of the frame buffer. However
195 clipping rectangles must not extend the frame buffer width and
198 x-y or y-x bands, or the order of rectangles, is not defined. When
208 supported but no clipping is desired this field must be set to zero.
211 When chroma-keying has *not* been negotiated and
221 .. code-block:: c
229 undefined. When a bit mask is supported but no clipping is desired this
233 both, or despite negotiating chroma-keying, the results are undefined.
243 :ref:`framebuffer-flags`).
256 -----------------------
260 corner of the frame buffer. Only window pixels *outside* all
272 ----------------
292 To start or stop the frame buffer overlay applications call the
296 In the opinion of the designers of this API, no driver writer taking
304 Hence as a complexity trade-off drivers *must* support two file
311 When the image is written into frame buffer memory it will be
319 BoxRec { short x1, y1, x2, y2; }`` with ``width = x2 - x1`` and
320 ``height = y2 - y1``, so one cannot pass X11 clip lists directly.