/*
* Copyright 2011 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
#include "drm.h"
#if defined(__cplusplus)
extern "C" {
#endif
/**
* DOC: overview
*
* In the DRM subsystem, framebuffer pixel formats are described using the
* fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the
* fourcc code, a Format Modifier may optionally be provided, in order to
* further describe the buffer's format - for example tiling or compression.
*
* Format Modifiers
* ----------------
*
* Format modifiers are used in conjunction with a fourcc code, forming a
* unique fourcc:modifier pair. This format:modifier pair must fully define the
* format and data layout of the buffer, and should be the only way to describe
* that particular buffer.
*
* Having multiple fourcc:modifier pairs which describe the same layout should
* be avoided, as such aliases run the risk of different drivers exposing
* different names for the same data format, forcing userspace to understand
* that they are aliases.
*
* Format modifiers may change any property of the buffer, including the number
* of planes and/or the required allocation size. Format modifiers are
* vendor-namespaced, and as such the relationship between a fourcc code and a
* modifier is specific to the modifer being used. For example, some modifiers
* may preserve meaning - such as number of planes - from the fourcc code,
* whereas others may not.
*
* Modifiers must uniquely encode buffer layout. In other words, a buffer must
* match only a single modifier. A modifier must not be a subset of layouts of
* another modifier. For instance, it's incorrect to encode pitch alignment 