Lines Matching full:may
25 Conceptually a two-dimensional array of pixels. The pixels may be stored
42 in bytes and at least one handle in some API. May contain one or more
51 more color channels values, e.g. R, G and B, or Y, Cb and Cr. May also
56 of a pixel or an image. The data for one pixel may be spread over several
134 Some modifiers may modify the number of planes required for an image; for
162 calculations. This may be used to combine multiple planes into a single memory
163 buffer; for example, ``DRM_FORMAT_NV12`` may be stored in a single memory buffer
170 with dimensions of 1000x1000 may have been allocated as if it were 1024x1000, in
176 Buffers may also be padded further in the y dimension, simply by allocating a
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
269 duplicated within an image. For example, a ``DRM_FORMAT_NV12`` buffer may have
271 per-plane offset parameters, or they may be completely separate allocations in
285 For example, a Wayland media player may use V4L2 to decode a video frame into a
297 import will succeed into all consumers; they may have constraints beyond those
327 should use its own logic to determine what the underlying layout may be.
338 There are four cases where this token may be used:
339 - during enumeration, an interface may return ``DRM_FORMAT_MOD_INVALID``, either
342 may be used
343 - during allocation, a user may supply ``DRM_FORMAT_MOD_INVALID``, either as the
348 - in a post-allocation query, an implementation may return
351 modifier description is not available; per the above rules, this may only be
354 - when importing a buffer, the user may supply ``DRM_FORMAT_MOD_INVALID`` as the
368 As one exception to the above, allocations may be 'upgraded' from implicit
370 ``gbm_bo_create`` (taking no modifiers), the user may then query the modifier with
378 interpretation of buffer content, as implicit modifier operation may still be