| /Documentation/gpu/ |
| D | afbc.rst | 87 Within each plane, the component ordering also follows the fourcc
94 * Plane 0:
102 * Plane 0:
106 * Plane 1:
127 - Plane 0: 4 components
135 - Plane 0: 4 components
143 - Plane 0: 3 components
150 - Plane 0: 3 components
157 - Plane 0: 4 components
164 - 8-bit per component YCbCr 444, single plane
[all …]
|
| D | kms-properties.csv | 61 ,Overlay,"""colorkey""",RANGE,"Min=0, Max=0xffffff",Plane,TBD
62 ,,"""colorkey_min""",RANGE,"Min=0, Max=0xffffff",Plane,TBD
63 ,,"""colorkey_max""",RANGE,"Min=0, Max=0xffffff",Plane,TBD
64 ,,"""colorkey_val""",RANGE,"Min=0, Max=0xffffff",Plane,TBD
65 ,,"""colorkey_alpha""",RANGE,"Min=0, Max=0xffffff",Plane,TBD
66 …mponent"" , ""V component"", ""RGB"", “R component"", ""G component"", ""B component"" }",Plane,TBD
67 ,,"""brightness""",RANGE,"Min=0, Max=256 + 255",Plane,TBD
68 ,,"""contrast""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
69 ,,"""saturation""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
73 nouveau,NV10 Overlay,"""colorkey""",RANGE,"Min=0, Max=0x01ffffff",Plane,TBD
[all …]
|
| D | vkms.rst | 116 Add Plane Features
119 There's lots of plane features we could add support for:
128 - Async updates (currently only possible on cursor plane using the legacy
181 - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
194 This needs a bunch of features (plane compositing, multiple outputs, ...)
|
| D | komeda-kms.rst | 296 by KMS-plane/wb_conn/crtc respectively.
354 crtc/plane/connector. One KMS-obj cannot represent only one single component,
359 And a KMS-Plane may require multiple komeda resources: layer/scaler/compiz.
363 - Plane: `Layer(input) pipeline`_
367 So, for komeda, we treat KMS crtc/plane/connector as users of pipeline and
372 How to map plane to Layer(input) pipeline
379 The easiest way is binding a plane to a fixed Layer pipeline, but consider the
398 So for komeda, the KMS-plane doesn't represent a fixed komeda layer pipeline,
400 Layers to fit the requirement of one KMS-plane.
|
| D | drm-kms.rst | 60 :c:type:`struct drm_plane <drm_plane>`, see `Plane Abstraction`_ for more
63 for blending. The precise blending step is explained in more detail in `Plane
252 doesn't always allow it, but where possible plane updates on different CRTCs
371 Plane Abstraction
377 Plane Functions Reference
386 Plane Composition Functions Reference
392 Plane Damage Tracking Functions Reference
401 Plane Panic Feature
407 Plane Panic Functions Reference
559 Standard Plane Properties
[all …]
|
| /Documentation/gpu/amdgpu/display/ |
| D | mpo-overview.rst | 17 * Plane independent page flips - No need to be tied to global compositor
31 * ``DRM_PLANE_TYPE_PRIMARY``: Primary planes represent a "main" plane for a
34 * ``DRM_PLANE_TYPE_CURSOR``: Cursor planes represent a "cursor" plane for a
45 * 1 Overlay plane (shared among CRTCs).
53 configuration for optimal single display output (e.g., 2 pipes per plane).
56 display - will see 4 pipes in use, 2 per plane.
58 At least 1 pipe must be used per plane (primary and overlay), so for this
65 Plane Restrictions
78 Not every property is available on every plane:
94 plane as it is being treated as part of the plane. Another consequence of that
[all …]
|
| D | display-manager.rst | 60 pre-blending but DRM/KMS has not per-plane color correction properties.
90 Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` used to
91 describes how pixels from a foreground plane (fg) are composited with the
92 background plane (bg). Here, we present main concepts of DRM blend mode to help
94 this DRM property and the alpha blending equations in :ref:`DRM Plane
97 Basically, a blend mode sets the alpha blending equation for plane
105 - *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see
106 more in :ref:`DRM Plane Composition Properties <plane_composition_properties>`.
112 the alpha channel value of each pixel in a plane is ignored and only the plane
115 DRM has three blend mode to define the blend formula in the plane composition:
[all …]
|
| D | dc-debug.rst | 27 You need to reload your GUI to see the visual confirmation. When the plane
29 the bottom of each hardware plane being drawn on the screen.
32 * The height of the bar indicates the index of the plane
34 covering the same plane
37 plane, and the desktop is drawn in another plane. The video plane should
45 * Multiple plane **may** be briefly disabled during window transitions or
|
| D | dc-glossary.rst | 174 Multiple pipes and plane combine
177 Multi Plane Overlay
195 Output Plane Processor
|
| /Documentation/userspace-api/media/v4l/ |
| D | vidioc-expbuf.rst | 48 one. For the multi-planar API, applications set the ``plane`` field to
49 the index of the plane to be exported. Valid planes range from zero to
51 the single-planar API, applications must set ``plane`` to zero.
55 case of multi-planar API, every plane is exported separately using
100 expbuf.plane = i;
136 - ``plane``
137 - Index of the plane to be exported when using the multi-planar API.
162 ``flags`` or ``type`` or ``index`` or ``plane`` fields are invalid.
|
| D | pixfmt-uv8.rst | 10 UV plane interleaved
16 In this format there is no Y plane, Only CbCr plane. ie (UV interleaved)
|
| D | pixfmt-reserved.rst | 203 - Two-planar format used by Samsung S5C73MX cameras. The first plane
210 The first plane can start either with JPEG or UYVY data chunk. The
215 The second plane, at an offset of 4084 bytes, contains a 4-byte
216 offset to the pointer array in the first plane. This offset is
218 All numbers in the second plane are also in big endian order.
219 Remaining data in the second plane is undefined. The information
220 in the second plane allows to easily find location of the pointer
225 initially set a data pointer to the start of first plane and then
|
| D | pixfmt-m420.rst | 10 YUV 4:2:0. Hybrid plane line-interleaved layout.
20 The luma plane has one byte per pixel. The chroma plane contains
|
| D | pixfmt-yuv-planar.rst | 12 - Semi-planar formats use two planes. The first plane is the luma plane and
13 stores the Y components. The second plane is the chroma plane and stores the
19 Within a plane, components are stored in pixel order, which may be linear or
21 the chroma planes may be constrained by the line stride of the luma plane.
35 use two planes, and store the luma components in the first plane and the chroma
36 components in the second plane. The Cb and Cr components are interleaved in the
37 chroma plane, with Cb and Cr always stored in pairs. The chroma order is
208 .. [1] Order of chroma samples in the second plane
228 Semi-planar YUV 4:2:0 formats. The chroma plane is subsampled by 2 in each
230 of bytes as luma lines, and the chroma plane contains half the number of lines
[all …]
|
| D | depth-formats.rst | 9 Depth data provides distance to points, mapped onto the image plane
|
| D | pixfmt-inzi.rst | 22 The first plane - Infrared data - is stored according to
29 The second plane provides 16-bit per-pixel Depth data arranged in
|
| D | dmabuf.rst | 61 The buffer (plane) file descriptor is passed on the fly with the
63 buffers, every plane can be associated with a different DMABUF
67 Example: Queueing DMABUF using single plane API
90 Example 3.6. Queueing DMABUF using multi plane API
|
| D | planar-apis.rst | 12 per "plane". A plane is a sub-buffer of the current frame. For examples
|
| /Documentation/userspace-api/ |
| D | dma-buf-alloc-exchange.rst | 45 plane:
116 and chroma YUV samples are stored in separate planes, where the chroma plane is
122 modifier is ``DRM_FORMAT_MOD_LINEAR``, describing a scheme in which each plane
131 a plane stores pixels (0,0) to (3,3) inclusive, and the second tile in a plane
135 example, the ``I915_FORMAT_MOD_Y_TILED_CCS`` modifier adds a second plane to RGB
152 ``DRM_FORMAT_NV12`` buffer has a luma plane containing 1920x1080 samples for the Y
160 Each plane must therefore be described with an ``offset`` in bytes, which will be
164 where the luma plane's storage begins immediately at the start of the buffer
165 with an offset of 0, and the chroma plane's storage follows within the same buffer
166 beginning from the byte offset for that plane.
[all …]
|
| /Documentation/devicetree/bindings/display/ti/ |
| D | ti,am65x-dss.yaml | 19 format. The first plane is full video plane with all features and the
20 second is a "lite plane" without scaling support.
34 - description: VIDL1 light video plane
35 - description: VID video plane
|
| D | ti,j721e-dss.yaml | 30 - description: VIDL1 light video plane 1
31 - description: VIDL2 light video plane 2
32 - description: VID1 video plane 1
33 - description: VID1 video plane 2
|
| D | ti,k2g-dss.yaml | 16 SubSystem. It has only one output port and video plane. The
27 - description: VID1 video plane 1
|
| /Documentation/networking/ |
| D | gtp.rst | 23 phone will use the control plane to signal for the establishment of
58 It *only* implements the so-called 'user plane', carrying the User-IP
59 payload, called GTP-U. It does not implement the 'control plane',
71 data plane is accelerated inside the kernel.
73 Don't be confused by terminology: The GTP User Plane goes through
74 kernel accelerated path, while the GTP Control Plane goes to
115 responsibility of the control plane implementation in userspace to
187 User plane entities in a way that allows multiplexing of different
238 The Access Point Name is purely a control plane (GTP-C) concept.
|
| /Documentation/userspace-api/media/drivers/ |
| D | cx2341x-uapi.rst | 18 The Y plane is divided into blocks of 16x16 pixels from left to right
26 The UV plane is divided into blocks of 16x8 UV values going from left
63 // descramble Y plane
65 // The Y plane is divided into blocks of 16x16 pixels
81 // descramble U/V plane
84 // Again, the UV plane is divided into blocks of 16x16 UV values.
|
| /Documentation/devicetree/bindings/iio/ |
| D | mount-matrix.txt | 60 is projected onto the (x,y) plane of the display panel.
96 ground plane and positive towards magnetic North, (x) is in the ground plane,
98 perpendicular to the ground plane and positive upwards.
130 velocity is defined as orthogonal to the plane of rotation, so if you put the
|