Lines Matching full:each

60       A tuple of numbers, representing a color. Each element in the tuple is a
94 Each buffer must have an underlying format. This format describes the color
95 values provided for each pixel. Although each subsystem has its own format
101 Each ``DRM_FORMAT_*`` token describes the translation between a pixel
104 whether they are RGB or YUV, integer or floating-point, the size of each channel
108 For example, ``DRM_FORMAT_ARGB8888`` describes a format in which each pixel has
118 sample is stored for each 2x2 pixel grouping).
122 modifier is ``DRM_FORMAT_MOD_LINEAR``, describing a scheme in which each plane
149 Each pixel buffer must be accompanied by logical pixel dimensions. This refers
160 Each plane must therefore be described with an ``offset`` in bytes, which will be
168 Each plane must also have a ``stride`` in bytes, expressing the offset in memory
180 described as having a height of 1080, with the memory allocation for each buffer
189 ``IN_FORMATS`` property on each DRM plane, listing the supported DRM formats, and
190 the modifiers supported for each format. In userspace, this is supported through
195 Each of these interfaces allows users to query a set of supported
237 Each allocation request must take, at a minimum: the pixel format, a list of
238 acceptable modifiers, and the buffer's width and height. Each API may extend
268 Each memory buffer is referred to by a buffer handle, which may be unique or
272 memory. For this reason, each import and allocation API must provide a separate
273 handle for each plane.
275 Each kernel subsystem has its own types and interfaces for buffer management.
292 through Vulkan, or a KMS framebuffer object; each of these import operations
385 dimensions, and at least offset and stride for each memory plane.