Lines Matching full:buffer

9 support for sharing pixel-buffer allocations between processes, devices, and
40     memory buffer:
94 Each buffer must have an underlying format. This format describes the color
121 samples, and the actual memory storage for the buffer. The most straightforward
149 Each pixel buffer must be accompanied by logical pixel dimensions. This refers
152 ``DRM_FORMAT_NV12`` buffer has a luma plane containing 1920x1080 samples for the Y
153 component, and 960x540 samples for the U and V components, the overall buffer is
156 The in-memory storage of a buffer is not guaranteed to begin immediately at the
163 buffer; for example, ``DRM_FORMAT_NV12`` may be stored in a single memory buffer
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
169 between two contiguous row. For example, a ``DRM_FORMAT_MOD_LINEAR`` buffer
171 order to allow for aligned access patterns. In this case, the buffer will still
179 effective height of 1088 pixels. In this case, the buffer continues to be
180 described as having a height of 1080, with the memory allocation for each buffer
232 acceptable modifiers, it must allocate the buffer. As there is no universal
233 buffer-allocation interface available at either kernel or userspace level, the
238 acceptable modifiers, and the buffer's width and height. Each API may extend
242 The component which allocates the buffer will make an arbitrary choice of what
247 These properties of the memory buffer are not visible to userspace, however the
251 modifier selected for the buffer, as well as the per-plane offset and stride.
264 To use a buffer within a different context, device, or subsystem, the user
268 Each memory buffer is referred to by a buffer handle, which may be unique or
269 duplicated within an image. For example, a ``DRM_FORMAT_NV12`` buffer may have
270 the luma and chroma buffers combined into a single memory buffer by use of the
275 Each kernel subsystem has its own types and interfaces for buffer management.
276 DRM uses GEM buffer objects (BOs), V4L2 has its own references, etc. These types
280 buffers. Subsystem-specific operations are used to export native buffer handles
282 native buffer handle. dma-buf file descriptors can be transferred between
286 ``DRM_FORMAT_NV12`` buffer. This will result in two memory planes (luma and
294 native buffer handles.
349     ``DRM_FORMAT_MOD_INVALID`` as the modifier of the allocated buffer to declare
354   - when importing a buffer, the user may supply ``DRM_FORMAT_MOD_INVALID`` as the
355     buffer modifier (or not supply a modifier) to indicate that the modifier is
356     unknown for whatever reason; this is only acceptable when the buffer has
359 It follows from this that for any single buffer, the complete chain of operations
361 explicit. For example, if a user wishes to allocate a buffer for use between
363 user **must not** allocate the buffer with explicit modifiers and attempt to
364 import the buffer into the media API with no modifier, but either perform the
365 allocation using implicit modifiers, or allocate the buffer for media use
369 to explicit modifiers. For example, if the buffer is allocated with
378 interpretation of buffer content, as implicit modifier operation may still be