In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier describes a generic pixel re-ordering which can be applicable to multiple vendors.
Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be used to describe this layout in a vendor-neutral way, and add a comment about the expected usage of such "generic" modifiers.
Signed-off-by: Brian Starkey brian.starkey@arm.com ---
This is based off a suggestion from Daniel here: https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.loca...
If there are future cases where a "generic" modifier is identified before merging with a specific vendor code, perhaps we could use `fourcc_mod_code(NONE, n)` or add a DRM_FORMAT_MOD_VENDOR_GENERIC.
However, I also think we shouldn't try and "guess" what might be generic up-front and end up polluting the generic namespace. It seems fine to just alias vendor-specific definitions unless it's very clear-cut.
I typed a version which was s/GENERIC/COMMON/, other suggestions welcome.
Cheers, -Brian
include/uapi/drm/drm_fourcc.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 299f9ac4840b..ef78dc9c3fb0 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -345,8 +345,27 @@ extern "C" { * When adding a new token please document the layout with a code comment, * similar to the fourcc codes above. drm_fourcc.h is considered the * authoritative source for all of these. + * + * Generic modifier names: + * + * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names + * for layouts which are common across multiple vendors. To preserve + * compatibility, in cases where a vendor-specific definition already exists and + * a generic name for it is desired, the common name is a purely symbolic alias + * and must use the same numerical value as the original definition. + * + * Note that generic names should only be used for modifiers which describe + * generic layouts (such as pixel re-ordering), which may have + * independently-developed support across multiple vendors. + * + * Generic names should not be used for cases where multiple hardware vendors + * have implementations of the same standardised compression scheme (such as + * AFBC). In those cases, all implementations should use the same format + * modifier(s), reflecting the vendor of the standard. */
+#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE + /* * Invalid Modifier *