On Mon, Aug 14, 2017 at 04:22:51PM -0700, Jason Ekstrand wrote:
> Cc: Daniel Stone <daniels@xxxxxxxxxxxxx>
pls read libdrm.git/include/drm/README.
-Daniel
> ---
> include/drm/drm_fourcc.h | 31 ++++++++++++++++++++++++++++++
> include/drm/drm_mode.h | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 81 insertions(+)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 7586c46..3ad838d 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -185,6 +185,8 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> /* add more to the end as needed */
>
> +#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
> +
> #define fourcc_mod_code(vendor, val) \
> ((((__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL))
>
> @@ -197,6 +199,15 @@ extern "C" {
> */
>
> /*
> + * Invalid Modifier
> + *
> + * This modifier can be used as a sentinel to terminate the format modifiers
> + * list, or to initialize a variable with an invalid modifier. It might also be
> + * used to report an error back to userspace for certain APIs.
> + */
> +#define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
> +
> +/*
> * Linear Layout
> *
> * Just plain linear layout. Note that this is different from no specifying any
> @@ -253,6 +264,26 @@ extern "C" {
> #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>
> /*
> + * Intel color control surface (CCS) for render compression
> + *
> + * The framebuffer format must be one of the 8:8:8:8 RGB formats.
> + * The main surface will be plane index 0 and must be Y/Yf-tiled,
> + * the CCS will be plane index 1.
> + *
> + * Each CCS tile matches a 1024x512 pixel area of the main surface.
> + * To match certain aspects of the 3D hardware the CCS is
> + * considered to be made up of normal 128Bx32 Y tiles, Thus
> + * the CCS pitch must be specified in multiples of 128 bytes.
> + *
> + * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
> + * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
> + * But that fact is not relevant unless the memory is accessed
> + * directly.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> +#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
> +
> +/*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> *
> * Macroblocks are laid in a Z-shape, and each pixel data is following the
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 70571af..0807797 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -657,6 +657,56 @@ struct drm_mode_atomic {
> __u64 user_data;
> };
>
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> + /* Version of this blob format */
> + __u32 version;
> +
> + /* Flags */
> + __u32 flags;
> +
> + /* Number of fourcc formats supported */
> + __u32 count_formats;
> +
> + /* Where in this blob the formats exist (in bytes) */
> + __u32 formats_offset;
> +
> + /* Number of drm_format_modifiers */
> + __u32 count_modifiers;
> +
> + /* Where in this blob the modifiers exist (in bytes) */
> + __u32 modifiers_offset;
> +
> + /* u32 formats[] */
> + /* struct drm_format_modifier modifiers[] */
> +};
> +
> +struct drm_format_modifier {
> + /* Bitmask of formats in get_plane format list this info applies to. The
> + * offset allows a sliding window of which 64 formats (bits).
> + *
> + * Some examples:
> + * In today's world with < 65 formats, and formats 0, and 2 are
> + * supported
> + * 0x0000000000000005
> + * ^-offset = 0, formats = 5
> + *
> + * If the number formats grew to 128, and formats 98-102 are
> + * supported with the modifier:
> + *
> + * 0x0000003c00000000 0000000000000000
> + * ^
> + * |__offset = 64, formats = 0x3c00000000
> + *
> + */
> + __u64 formats;
> + __u32 offset;
> + __u32 pad;
> +
> + /* The modifier that applies to the >get_plane format list bitmask. */
> + __u64 modifier;
> +};
> +
> /**
> * Create a new 'blob' data property, copying length bytes from data pointer,
> * and returning new blob ID.
> --
> 2.5.0.400.gff86faf
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
