Searched full:planes (Results 1 – 25 of 48) sorted by relevance
12
| /Documentation/ABI/testing/ |
| D | sysfs-devices-platform-sh_mobile_lcdc_fb | 6 to overlay planes.
17 to overlay planes.
30 to overlay planes.
40 to overlay planes.
|
| /Documentation/devicetree/bindings/display/ |
| D | amlogic,meson-vpu.yaml | 35 It can handle 2 OSD Planes and 2 Video Planes.
41 various planes into a single pixel stream.
42 There is a special "pre-blending" used by the video planes with a dedicated
43 scaler and a "post-blending" to merge with the OSD Planes.
44 The OSD planes also have a dedicated scaler for one of the OSD.
|
| /Documentation/media/uapi/v4l/ |
| D | dmabuf.rst | 37 DRM). Buffers (planes) are allocated by a driver on behalf of an
105 struct v4l2_plane planes[VIDEO_MAX_PLANES];
112 buf.m.planes = planes;
115 memset(&planes, 0, sizeof planes);
118 buf.m.planes[i].m.fd = dmafd[i];
|
| D | mmap.rst | 56 be equal to number of buffers times number of planes in each buffer. The
139 /* Our current format uses 3 planes per buffer */
175 struct v4l2_plane planes[FMT_NUM_PLANES];
182 * of planes array. */
184 buffer.m.planes = planes;
193 buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */
195 buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length,
198 fd, buffer.m.planes[j].m.offset);
202 the buffers and planes mapped so far. */
|
| D | pixfmt-v4l2-mplane.rst | 15 and layout for each of the planes in a multi-planar format. The
17 information common to all planes (such as image width and height) and an
19 describing all planes of that format.
98 - Number of planes (i.e. separate memory buffers) for this format
|
| D | pixfmt-nv16m.rst | 18 Variation of ``V4L2_PIX_FMT_NV16`` and ``V4L2_PIX_FMT_NV61`` with planes
26 three components are separated into two sub-images or planes.
28 two planes are non-contiguous in memory, i.e. the chroma plane does not
|
| D | pixfmt-yuv420m.rst | 20 planes non contiguous in memory.
27 components are separated into three sub-images or planes.
40 If the Y plane has pad bytes after each row, then the Cb and Cr planes
|
| D | pixfmt-nv12m.rst | 21 Variation of ``V4L2_PIX_FMT_NV12`` and ``V4L2_PIX_FMT_NV21`` with planes
29 three components are separated into two sub-images or planes.
31 two planes are non-contiguous in memory, i.e. the chroma plane do not
|
| D | pixfmt-nv12mt.rst | 17 has two planes - one for luminance and one for chrominance. Chroma
28 two sub-images or planes. The Y plane has one byte per pixel and pixels
|
| D | vidioc-querybuf.rst | 55 using the :ref:`multi-planar API <planar-apis>`, the ``m.planes``
68 fields ``m.mem_offset`` and ``length`` in the ``m.planes`` array
|
| D | pixfmt-yuv411p.rst | 26 components are separated into three sub-images or planes. The Y plane is
34 If the Y plane has pad bytes after each row, then the Cr and Cb planes
|
| D | pixfmt-yuv410.rst | 27 components are separated into three sub-images or planes. The Y plane is
36 If the Y plane has pad bytes after each row, then the Cr and Cb planes
|
| D | pixfmt-yuv422p.rst | 26 planes. The Y plane is first. The Y plane has one byte per pixel. The Cb
33 If the Y plane has pad bytes after each row, then the Cr and Cb planes
|
| D | planar-apis.rst | 63 describing planes is added. Arrays of this structure are passed in
64 the new ``m.planes`` field of struct
|
| D | pixfmt-v4l2.rst | 39 to a multiple of the scale factor of any smaller planes. For
84 ``width`` field for the other planes. For example the Cb and Cr
85 planes of a YUV 4:2:0 image have half as many padding bytes
|
| D | pixfmt-yuv420.rst | 27 components are separated into three sub- images or planes. The Y plane
37 If the Y plane has pad bytes after each row, then the Cr and Cb planes
|
| D | pixfmt-yuv422m.rst | 27 components are separated into three sub-images or planes.
39 If the Y plane has pad bytes after each row, then the Cb and Cr planes
|
| D | pixfmt-yuv444m.rst | 27 components are separated into three sub-images or planes.
37 If the Y plane has pad bytes after each row, then the Cb and Cr planes
|
| D | vidioc-expbuf.rst | 57 the index of the plane to be exported. Valid planes range from zero to
58 the maximal number of valid planes for the currently active format. For
|
| D | userp.rst | 25 methods. Buffers (planes) are allocated by the application itself, and
32 No buffers (planes) are allocated beforehand, consequently they are not
|
| /Documentation/gpu/ |
| D | afbc.rst | 78 Number of Planes
82 420), can be encoded into one, or multiple, AFBC planes. As with
84 of planes in order to correctly decode the buffer. The fourcc code is
85 used to determine the number of encoded planes in an AFBC buffer,
86 matching the number of planes for the linear (unmodified) format.
123 - Planes/Components
|
| D | vkms.rst | 35 - Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
49 - Real overlay planes, not just cursor.
51 - Full alpha blending on all planes.
|
| D | drm-kms.rst | 59 see `Frame Buffer Abstraction`_) feed into planes. Planes are represented by
61 details. One or more (or even no) planes feed their pixel data into a CRTC
236 Atomic provides transactional modeset (including planes) updates, but a
258 :c:type:`struct drm_plane_state <drm_plane_state>` for planes, :c:type:`struct
|
| /Documentation/fb/ |
| D | api.rst | 69 Macropixels are split across multiple planes. The number of planes is equal to
73 Planes are located contiguously in memory.
77 Macropixels are split across multiple planes. The number of planes is equal to
81 Planes are interleaved in memory. The interleave factor, defined as the
83 belonging to different planes, is stored in the fixed screen information
163 __u32 type_aux; /* Interleave for interleaved Planes */
|
| D | arkfb.rst | 38 with interleaved planes (1 byte interleave), MSB first. Both modes support
|
12