drm: Add generic colorkey plane properties
Subsystems (5)
v3 cover drm: Add generic colorkey plane properties
Hello,
In this version I've reduced color keying modes and properties to a bare minimum because considering several modes and properties at once might take quite a lot of effort due to a variety of HW capabilities. This allows us to start easy with the generic colorkey properties support.
For the starter let's implement probably the most common (and simple) color keying mode - the "green screen" (or "chroma key") mode. More advanced modes and features could be implemented later on by as needed basis.
Following Ville's Syrjälä review comments to v2, the color key value is now given in ARGB16161616 format. Drivers have to convert this 16bpc format into internal color key value representation themselves. This works well for cases where conversion is done to a non-planar integer formats, but I'm not sure how drivers are supposed to cope with cases where conversion involves churning with fixed point math / floating point representation. Comments are welcome.
v2: https://lists.freedesktop.org/archives/dri-devel/2018-May/178408.html
v1: https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html
Dmitry Osipenko (1):
drm/tegra: plane: Implement generic colorkey property for older
Tegra's
Laurent Pinchart (1):
drm: Add generic colorkey properties for DRM planes
drivers/gpu/drm/drm_atomic.c | 12 ++++ drivers/gpu/drm/drm_blend.c | 99 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/tegra/dc.c | 25 +++++++++ drivers/gpu/drm/tegra/dc.h | 7 +++ drivers/gpu/drm/tegra/plane.c | 102 ++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 53 ++++++++++++++++++ 7 files changed, 301 insertions(+)
Signature · 1 line
2.17.0
RFC PATCH v3 1/2 drm: Add generic colorkey properties for DRM planes
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)
drivers/gpu/drm/drm_atomic.c +12 -0
@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {
@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {
drivers/gpu/drm/drm_blend.c +99 -0
108 lines not on this page · raw message
include/drm/drm_blend.h +3 -0
@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif
include/drm/drm_plane.h +53 -0
83 lines not on this page · raw message
Signature · 1 line
2.17.0
Maarten Lankhorst
maintainerRe: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 198 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
Signed-off-by Laurent Pinchart <[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +12
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +99
-0@@ -107,6 +107,11 @@* planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * +* colorkey: +* Color keying is set up with drm_plane_create_colorkey_properties(). +* It adds support for replacing a range of colors with a transparent +* color in the plane. +* * Note that all the property extensions described here apply either to the * plane or the CRTC (e.g. for the background color, which currently is not * exposed and assumed to be black). @@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,return 0 ; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to +* the plane to enable color keying control for blending operations. +* +* Color keying is controlled by these properties: +* +* colorkey.mode: +* The mode is an enumerated property that controls how color keying +* operates. +* +* colorkey.min, colorkey.max: +* These two properties specify the colors that are treated as the color +* key. Pixel whose value is in the [min, max] range is the color key +* matching pixel. The minimum and maximum values are expressed as a +* 64-bit integer in ARGB16161616 format, where A is the alpha value and +* R, G and B correspond to the color components. Drivers shall convert +* ARGB16161616 value into appropriate format within planes atomic check. +* +* When a single color key is desired instead of a range, userspace shall +* set the min and max properties to the same value. +* +* Drivers return an error from their plane atomic check if range can't be +* handled. +* +* Returns: +* Zero on success, negative errno on failure. +*/ +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list modes_list[DRM_PLANE_COLORKEY_MODES_NUM ]; +struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes */ +for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i; + modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop =drm_property_create_enum (plane->dev,0 ,"colorkey.mode" , + modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop =drm_property_create_range (plane->dev,0 ,"colorkey.min" , +0 ,U64_MAX ); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop =drm_property_create_range (plane->dev,0 ,"colorkey.max" , +0 ,U64_MAX ); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +3
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +11
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration +*/ +enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode. +*/ +DRM_PLANE_COLORKEY_MODE_DISABLED , +
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 10 lines
include/drm/drm_plane.h +10
-0+/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +* +* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key range +* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,
Could we add background clip as well?
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.
Quoted 9 lines
include/drm/drm_plane.h +9
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/**
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 10 lines
include/drm/drm_plane.h +10
-0+* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format) +*/ +struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};
Could we have some macros to extract the components for min/max? A, R, G, B.
~Maarten
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 204 lines · Maarten Lankhorst
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 201 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
Signed-off-by Laurent Pinchart <[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +12
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +99
-0@@ -107,6 +107,11 @@* planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * +* colorkey: +* Color keying is set up with drm_plane_create_colorkey_properties(). +* It adds support for replacing a range of colors with a transparent +* color in the plane. +* * Note that all the property extensions described here apply either to the * plane or the CRTC (e.g. for the background color, which currently is not * exposed and assumed to be black). @@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,return 0 ; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to +* the plane to enable color keying control for blending operations. +* +* Color keying is controlled by these properties: +* +* colorkey.mode: +* The mode is an enumerated property that controls how color keying +* operates. +* +* colorkey.min, colorkey.max: +* These two properties specify the colors that are treated as the color +* key. Pixel whose value is in the [min, max] range is the color key +* matching pixel. The minimum and maximum values are expressed as a +* 64-bit integer in ARGB16161616 format, where A is the alpha value and +* R, G and B correspond to the color components. Drivers shall convert +* ARGB16161616 value into appropriate format within planes atomic check. +* +* When a single color key is desired instead of a range, userspace shall +* set the min and max properties to the same value. +* +* Drivers return an error from their plane atomic check if range can't be +* handled. +* +* Returns: +* Zero on success, negative errno on failure. +*/ +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list modes_list[DRM_PLANE_COLORKEY_MODES_NUM ]; +struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes */ +for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i; + modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop =drm_property_create_enum (plane->dev,0 ,"colorkey.mode" , + modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop =drm_property_create_range (plane->dev,0 ,"colorkey.min" , +0 ,U64_MAX ); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop =drm_property_create_range (plane->dev,0 ,"colorkey.max" , +0 ,U64_MAX ); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +3
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +14
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration +*/ +enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode. +*/ +DRM_PLANE_COLORKEY_MODE_DISABLED , + +/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +*
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 7 lines
include/drm/drm_plane.h +7
-0+* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key range +* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,Could we add background clip as well?
Also could we just name them "src" and "dst" (or some variation of those). I'm betting no one has any kind of idea what these proposed names mean without looking up the docs, whereas pretty much everyone knows immediately what src/dst colorkeying means.
Quoted 15 lines
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.
Quoted 13 lines
include/drm/drm_plane.h +13
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/** +* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format)
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 6 lines
include/drm/drm_plane.h +6
-0+*/ +struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};Could we have some macros to extract the components for min/max? A, R, G, B.
And where did we lose the value+mask?
Signature · 6 lines
Ville Syrjälä Intel _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 205 lines · Ville Syrjälä
Quoted 204 lines · Maarten Lankhorst
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 201 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
Signed-off-by Laurent Pinchart <[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +12
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +99
-0@@ -107,6 +107,11 @@* planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * +* colorkey: +* Color keying is set up with drm_plane_create_colorkey_properties(). +* It adds support for replacing a range of colors with a transparent +* color in the plane. +* * Note that all the property extensions described here apply either to the * plane or the CRTC (e.g. for the background color, which currently is not * exposed and assumed to be black). @@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,return 0 ; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to +* the plane to enable color keying control for blending operations. +* +* Color keying is controlled by these properties: +* +* colorkey.mode: +* The mode is an enumerated property that controls how color keying +* operates. +* +* colorkey.min, colorkey.max: +* These two properties specify the colors that are treated as the color +* key. Pixel whose value is in the [min, max] range is the color key +* matching pixel. The minimum and maximum values are expressed as a +* 64-bit integer in ARGB16161616 format, where A is the alpha value and +* R, G and B correspond to the color components. Drivers shall convert +* ARGB16161616 value into appropriate format within planes atomic check. +* +* When a single color key is desired instead of a range, userspace shall +* set the min and max properties to the same value. +* +* Drivers return an error from their plane atomic check if range can't be +* handled. +* +* Returns: +* Zero on success, negative errno on failure. +*/ +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list modes_list[DRM_PLANE_COLORKEY_MODES_NUM ]; +struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes */ +for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i; + modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop =drm_property_create_enum (plane->dev,0 ,"colorkey.mode" , + modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop =drm_property_create_range (plane->dev,0 ,"colorkey.min" , +0 ,U64_MAX ); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop =drm_property_create_range (plane->dev,0 ,"colorkey.max" , +0 ,U64_MAX ); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +3
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +14
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration +*/ +enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode. +*/ +DRM_PLANE_COLORKEY_MODE_DISABLED , + +/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +*
Quoted 9 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 7 lines
include/drm/drm_plane.h +7
-0+* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key range +* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,Could we add background clip as well?
Sure, but I think adding a new mode should be a distinct change made on top of the initial series.
Quoted 5 lines
Also could we just name them "src" and "dst" (or some variation of those). I'm betting no one has any kind of idea what these proposed names mean without looking up the docs, whereas pretty much everyone knows immediately what src/dst colorkeying means.
Okay, I'll rename the mode to DRM_PLANE_COLORKEY_MODE_SRC in the next revision.
Quoted 15 lines
Quoted 15 lines
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.
Quoted 13 lines
include/drm/drm_plane.h +13
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/** +* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format)
Quoted 9 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 6 lines
include/drm/drm_plane.h +6
-0+*/ +struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};Could we have some macros to extract the components for min/max? A, R, G, B.
I'll add the macros in the next revision.
Quoted 2 lines
And where did we lose the value+mask?
There is no use for the mask on Tegra. I'd prefer to keep initial patches simple and minimal, other modes and additional properties could be added in the further patches on by as-needed basis. Mask could be added later with the default value of 0xffffffffffffffff. Does it sound good for you?
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 254 lines · Dmitry Osipenko
Quoted 205 lines · Ville Syrjälä
Quoted 204 lines · Maarten Lankhorst
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 201 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
Signed-off-by Laurent Pinchart <[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +12
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +99
-0@@ -107,6 +107,11 @@* planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * +* colorkey: +* Color keying is set up with drm_plane_create_colorkey_properties(). +* It adds support for replacing a range of colors with a transparent +* color in the plane. +* * Note that all the property extensions described here apply either to the * plane or the CRTC (e.g. for the background color, which currently is not * exposed and assumed to be black). @@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,return 0 ; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to +* the plane to enable color keying control for blending operations. +* +* Color keying is controlled by these properties: +* +* colorkey.mode: +* The mode is an enumerated property that controls how color keying +* operates. +* +* colorkey.min, colorkey.max: +* These two properties specify the colors that are treated as the color +* key. Pixel whose value is in the [min, max] range is the color key +* matching pixel. The minimum and maximum values are expressed as a +* 64-bit integer in ARGB16161616 format, where A is the alpha value and +* R, G and B correspond to the color components. Drivers shall convert +* ARGB16161616 value into appropriate format within planes atomic check. +* +* When a single color key is desired instead of a range, userspace shall +* set the min and max properties to the same value. +* +* Drivers return an error from their plane atomic check if range can't be +* handled. +* +* Returns: +* Zero on success, negative errno on failure. +*/ +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list modes_list[DRM_PLANE_COLORKEY_MODES_NUM ]; +struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes */ +for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i; + modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop =drm_property_create_enum (plane->dev,0 ,"colorkey.mode" , + modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop =drm_property_create_range (plane->dev,0 ,"colorkey.min" , +0 ,U64_MAX ); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop =drm_property_create_range (plane->dev,0 ,"colorkey.max" , +0 ,U64_MAX ); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +3
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +14
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration +*/ +enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode. +*/ +DRM_PLANE_COLORKEY_MODE_DISABLED , + +/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +* Quoted 9 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 7 lines
include/drm/drm_plane.h +7
-0+* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key range +* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,Could we add background clip as well?
Sure, but I think adding a new mode should be a distinct change made on top of the initial series.
Quoted 5 lines
Also could we just name them "src" and "dst" (or some variation of those). I'm betting no one has any kind of idea what these proposed names mean without looking up the docs, whereas pretty much everyone knows immediately what src/dst colorkeying means.
Okay, I'll rename the mode to
DRM_PLANE_COLORKEY_MODE_SRCin the next revision.Quoted 15 lines
Quoted 15 lines
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.
Quoted 13 lines
include/drm/drm_plane.h +13
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/** +* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format) Quoted 9 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 6 lines
include/drm/drm_plane.h +6
-0+*/ +struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};Could we have some macros to extract the components for min/max? A, R, G, B.
I'll add the macros in the next revision.
Quoted 7 lines
Quoted 2 lines
And where did we lose the value+mask?
There is no use for the mask on Tegra. I'd prefer to keep initial patches simple and minimal, other modes and additional properties could be added in the further patches on by as-needed basis. Mask could be added later with the default value of
0xffffffffffffffff. Does it sound good for you?
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
And maybe we should have the mask always? IIRC Intel hw generally has a one bit enable/disable "mask" per channel in the min+max mode (I think there's one exception where it has only a 1 bit mask in the value+mask mode as well). So we could accept 0 and 0xffff mask values in this case and reject everything else. The alternative might be to enable the keying for the channel if 'min <= max' and disable it if 'min > max'. But not sure if that's slightly too magicy.
Signature · 6 lines
Ville Syrjälä Intel _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Maarten Lankhorst
maintainerRe: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Op 06-07-18 om 16:10 schreef Ville Syrjälä:
Quoted 262 lines · Dmitry Osipenko
Quoted 246 lines · Ville Syrjälä
Quoted 205 lines · Maarten Lankhorst
Quoted 204 lines
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 201 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane properties related to the color keying, providing initial color keying support.
Signed-off-by Laurent Pinchart <[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>--- drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +12
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +99
-0@@ -107,6 +107,11 @@* planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * +* colorkey: +* Color keying is set up with drm_plane_create_colorkey_properties(). +* It adds support for replacing a range of colors with a transparent +* color in the plane. +* * Note that all the property extensions described here apply either to the * plane or the CRTC (e.g. for the background color, which currently is not * exposed and assumed to be black). @@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,return 0 ; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to +* the plane to enable color keying control for blending operations. +* +* Color keying is controlled by these properties: +* +* colorkey.mode: +* The mode is an enumerated property that controls how color keying +* operates. +* +* colorkey.min, colorkey.max: +* These two properties specify the colors that are treated as the color +* key. Pixel whose value is in the [min, max] range is the color key +* matching pixel. The minimum and maximum values are expressed as a +* 64-bit integer in ARGB16161616 format, where A is the alpha value and +* R, G and B correspond to the color components. Drivers shall convert +* ARGB16161616 value into appropriate format within planes atomic check. +* +* When a single color key is desired instead of a range, userspace shall +* set the min and max properties to the same value. +* +* Drivers return an error from their plane atomic check if range can't be +* handled. +* +* Returns: +* Zero on success, negative errno on failure. +*/ +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list modes_list[DRM_PLANE_COLORKEY_MODES_NUM ]; +struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes */ +for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i; + modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop =drm_property_create_enum (plane->dev,0 ,"colorkey.mode" , + modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop =drm_property_create_range (plane->dev,0 ,"colorkey.min" , +0 ,U64_MAX ); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop =drm_property_create_range (plane->dev,0 ,"colorkey.max" , +0 ,U64_MAX ); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +3
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +14
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration +*/ +enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode. +*/ +DRM_PLANE_COLORKEY_MODE_DISABLED , + +/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +* Quoted 8 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 7 lines
include/drm/drm_plane.h +7
-0+* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key range +* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,Could we add background clip as well?
Sure, but I think adding a new mode should be a distinct change made on top of the initial series.
Quoted 5 lines
Also could we just name them "src" and "dst" (or some variation of those). I'm betting no one has any kind of idea what these proposed names mean without looking up the docs, whereas pretty much everyone knows immediately what src/dst colorkeying means.
Okay, I'll rename the mode to
DRM_PLANE_COLORKEY_MODE_SRCin the next revision.Quoted 14 lines
Quoted 14 lines
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.
Quoted 13 lines
include/drm/drm_plane.h +13
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/** +* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format) Quoted 8 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 6 lines
include/drm/drm_plane.h +6
-0+*/ +struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};Could we have some macros to extract the components for min/max? A, R, G, B.
Quoted 8 lines
I'll add the macros in the next revision.
Quoted 2 lines
And where did we lose the value+mask?
There is no use for the mask on Tegra. I'd prefer to keep initial patches simple and minimal, other modes and additional properties could be added in the further patches on by as-needed basis. Mask could be added later with the default value of
0xffffffffffffffff. Does it sound good for you?IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
Quoted 2 lines
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
Sounds sane.
Quoted 7 lines
And maybe we should have the mask always? IIRC Intel hw generally has a one bit enable/disable "mask" per channel in the min+max mode (I think there's one exception where it has only a 1 bit mask in the value+mask mode as well). So we could accept 0 and
0xffffmask values in this case and reject everything else. The alternative might be to enable the keying for the channel if 'min <= max' and disable it if 'min > max'. But not sure if that's slightly too magicy.
Yeah, either a single value or 0/0xffff (don't care about this component) sounds like it could work.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
In reply to Ville SyrjäläQuoted 92 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
Quoted 91 lines · Dmitry Osipenko
Quoted 90 lines · Ville Syrjälä
Quoted 89 lines · Maarten Lankhorst
Hey,
Op 04-06-18 om 00:00 schreef Dmitry Osipenko:
Quoted 86 lines
From: Laurent Pinchart <[email protected]>
Color keying is the action of replacing pixels matching a given color (or range of colors) with transparent pixels in an overlay when performing blitting. Depending on the hardware capabilities, the matching pixel can either become fully transparent or gain adjustment of the pixels component values.
Color keying is found in a large number of devices whose capabilities often differ, but they still have enough common features in range to standardize color key properties. This commit adds three generic DRM plane
properties related to the color keying, providing initial color keying support.Signed-off-by: Laurent Pinchart
<[email protected]>Signed-off-by Dmitry Osipenko <[email protected]>---
drivers/gpu/drm/drm_atomic.c | 12 +++++ drivers/gpu/drm/drm_blend.c | 99 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 3 ++ include/drm/drm_plane.h | 53 +++++++++++++++++++ 4 files changed, 167 insertions(+)drivers/gpu/drm/drm_atomic.c +0
-0@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct
drm_plane*plane,> >>>drivers/gpu/drm/drm_atomic.c +12
-0state->rotation = val; }else if (property == plane->zpos_property) { state->zpos = val; + }else if (property == plane->colorkey.mode_property) { + state->colorkey.mode = val; + }else if (property == plane->colorkey.min_property) { + state->colorkey.min = val; + }else if (property == plane->colorkey.max_property) { + state->colorkey.max = val; }else if (property == plane->color_encoding_property) { state->color_encoding = val; }else if (property == plane->color_range_property) {@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; }else if (property == plane->zpos_property) { *val = state->zpos; + }else if (property == plane->colorkey.mode_property) { + *val = state->colorkey.mode; + }else if (property == plane->colorkey.min_property) { + *val = state->colorkey.min; + }else if (property == plane->colorkey.max_property) { + *val = state->colorkey.max; }else if (property == plane->color_encoding_property) { *val = state->color_encoding; }else if (property == plane->color_range_property) {drivers/gpu/drm/drm_blend.c +0
-0@@ -107,6 +107,11 @@ * planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. *
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/gpu/drm/drm_blend.c +2
-0+* colorkey: +* Color keying is set up with
drm_plane_create_colorkey_properties().
+ * It adds support for replacing a range of colors with a
transparent
Quoted 33 lines
Quoted 33 lines
Quoted 33 lines
Quoted 33 lines
Quoted 33 lines
+ * color in the plane.
+ ** Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).drivers/gpu/drm/drm_blend.c +12
-0@@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev, return 0; }EXPORT_SYMBOL (drm_atomic_normalize_zpos); + +static const char *const plane_colorkey_mode_name[] = { + [DRM_PLANE_COLORKEY_MODE_DISABLED ] ="disabled" , + [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ] ="foreground-clip" , +}; + +/** +* drm_plane_create_colorkey_properties - create colorkey properties +* @plane: drm plane +* @supported_modes: bitmask of supported color keying modes +* +* This function creates the generic color keying properties and attach them to + * the plane to enable color keying control for blending operations. + *
+ * Color keying is controlled by these properties:
+ *
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
+ * colorkey.mode:
+ * The mode is an enumerated property that controls how color keying
+ * operates.
+ *
+ * colorkey.min, colorkey.max:
+ * These two properties specify the colors that are treated as the
color
+ * key. Pixel whose value is in the [min, max] range is the color
key
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
+ * matching pixel. The minimum and maximum values are expressed as a
+ * 64-bit integer in ARGB16161616 format, where A is the alpha value
and
+ * R, G and B correspond to the color components. Drivers shall
convert
+ * ARGB16161616 value into appropriate format within planes atomic
check.
+ *
+ * When a single color key is desired instead of a range, userspace
shall
+ * set the min and max properties to the same value.
+ *
+ * Drivers return an error from their plane atomic check if range
can't be
+ * handled.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/drm_blend.c int drm_atomic_normalize_zpos(struct drm_device *dev,
Quoted 8 lines
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */drivers/gpu/drm/drm_blend.c +4
-0+int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes) +{ +struct drm_prop_enum_list
modes_list[DRM_PLANE_COLORKEY_MODES_NUM];
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/gpu/drm/drm_blend.c int drm_atomic_normalize_zpos(struct drm_device *dev,
Quoted 7 lines
drivers/gpu/drm/drm_blend.c +7
-0+struct drm_property *mode_prop; +struct drm_property *min_prop; +struct drm_property *max_prop; +unsigned int modes_num =0 ; +unsigned int i; + +/* modes are driver-specific, build the list of supported modes
*/
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/gpu/drm/drm_blend.c +6
-0+for (i =0 ; i <DRM_PLANE_COLORKEY_MODES_NUM ; i++) { +if (!(supported_modes &BIT (i))) +continue ; + + modes_list[modes_num].name = plane_colorkey_mode_name[i]; + modes_list[modes_num].type = i;
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/drm_blend.c int drm_atomic_normalize_zpos(struct drm_device *dev,
Quoted 8 lines
drivers/gpu/drm/drm_blend.c +8
-0+ modes_num++; + } + +/* at least one mode should be supported */ +if (!modes_num) +return -EINVAL ; + + mode_prop = drm_property_create_enum(plane->dev, 0,
"colorkey.mode",
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
drivers/gpu/drm/drm_blend.c int drm_atomic_normalize_zpos(struct drm_device *dev,
Quoted 5 lines
drivers/gpu/drm/drm_blend.c +5
-0+ modes_list, modes_num); +if (!mode_prop) +return -ENOMEM ; + + min_prop = drm_property_create_range(plane->dev, 0,
"colorkey.min",
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
drivers/gpu/drm/drm_blend.c int drm_atomic_normalize_zpos(struct drm_device *dev,
Quoted 5 lines
drivers/gpu/drm/drm_blend.c +5
-0+ 0, U64_MAX); +if (!min_prop) + goto err_destroy_mode_prop; + + max_prop = drm_property_create_range(plane->dev, 0,
"colorkey.max",
Quoted 58 lines
Quoted 58 lines
Quoted 58 lines
Quoted 58 lines
Quoted 58 lines
drivers/gpu/drm/drm_blend.c +22
-0+ 0, U64_MAX); +if (!max_prop) + goto err_destroy_min_prop; + +drm_object_attach_property (&plane->base, mode_prop,0 ); +drm_object_attach_property (&plane->base, min_prop,0 ); +drm_object_attach_property (&plane->base, max_prop,0 ); + + plane->colorkey.mode_property = mode_prop; + plane->colorkey.min_property = min_prop; + plane->colorkey.max_property = max_prop; + +return 0 ; + +err_destroy_min_prop: +drm_property_destroy (plane->dev, min_prop); +err_destroy_mode_prop: +drm_property_destroy (plane->dev, mode_prop); + +return -ENOMEM ; +} +EXPORT_SYMBOL (drm_plane_create_colorkey_properties);include/drm/drm_blend.h +0
-0@@ -52,4 +52,7 @@ int drm_plane_create_zpos_immutable_property(struct
drm_plane*plane,> >>>include/drm/drm_blend.h +3
-0unsigned int zpos);int drm_atomic_normalize_zpos (struct drm_device *dev,struct drm_atomic_state *state); + +int drm_plane_create_colorkey_properties (struct drm_plane *plane, +u32 supported_modes);#endif include/drm/drm_plane.h +2
-0@@ -32,6 +32,48 @@ struct drm_crtc;struct drm_printer ;struct drm_modeset_acquire_ctx ; +/** +* enum drm_plane_colorkey_mode - uapi plane colorkey mode enumeration
+ */include/drm/drm_plane.h +5
-0+enum drm_plane_colorkey_mode { +/** +* @DRM_PLANE_COLORKEY_MODE_DISABLED: +* +* No color matching performed in this mode.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc;
Quoted 8 lines
include/drm/drm_plane.h +8
-0+*/ + DRM_PLANE_COLORKEY_MODE_DISABLED, + +/** +* @DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP: +* +* This mode is also known as a "green screen". Plane pixels are +* transparent in areas where pixels match a given color key
range
Quoted 59 lines
Quoted 43 lines
Quoted 7 lines
Quoted 7 lines
include/drm/drm_plane.h struct drm_crtc; · line 55
Quoted 5 lines
include/drm/drm_plane.h +5
-0+* and there is a bottom (background) plane, in other cases plane +* pixels are unaffected. +* +*/ + DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP,Could we add background clip as well?
Sure, but I think adding a new mode should be a distinct change made on top of the initial series.
Quoted 4 lines
Also could we just name them "src" and "dst" (or some variation of those). I'm betting no one has any kind of idea what these proposed names mean without looking up the docs, whereas pretty much everyone knows immediately what src/dst colorkeying means.
Okay, I'll rename the mode to
DRM_PLANE_COLORKEY_MODE_SRCin the next revision.>Quoted 16 lines
Quoted 16 lines
Would be nice if we could map i915's legacy ioctl handler to the new color key mode.> >>
Quoted 14 lines
include/drm/drm_plane.h +14
-0+/** +* @DRM_PLANE_COLORKEY_MODES_NUM: +* +* Total number of color keying modes. +*/ + DRM_PLANE_COLORKEY_MODES_NUM, +}; + +/** +* struct drm_plane_colorkey_state - plane color keying state +* @colorkey.mode: color keying mode +* @colorkey.min: color key range minimum (in ARGB16161616 format) +* @colorkey.max: color key range maximum (in ARGB16161616 format) +*/ Quoted 8 lines
Quoted 8 lines
include/drm/drm_plane.h struct drm_crtc; · line 75
Quoted 5 lines
include/drm/drm_plane.h +5
-0+struct drm_plane_colorkey_state { +enum drm_plane_colorkey_mode mode; +u64 min; +u64 max; +};Could we have some macros to extract the components for min/max? A, R, G, B.
Quoted 8 lines
I'll add the macros in the next revision.
Quoted 1 line
And where did we lose the value+mask?
There is no use for the mask on Tegra. I'd prefer to keep initial patches simple and minimal, other modes and additional properties could be added in the further patches on by as-needed basis. Mask could be added later with the default value of
0xffffffffffffffff. Does it sound good for you?IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
Quoted 3 lines
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
You should pick both and reject unsupported property values based on the planes framebuffer format. So it will be possible to set unsupported values while plane is disabled because it doesn't have an associated framebuffer and then atomic check will fail to enable plane if property values are invalid for the given format.
Quoted 5 lines
And maybe we should have the mask always? IIRC Intel hw generally has a one bit enable/disable "mask" per channel in the min+max mode (I think there's one exception where it has only a 1 bit mask in the value+mask mode as well). So we could accept 0 and
0xffffmask values in this case and reject everything else.
Sounds good to me. Actually there is a place for the mask on Tegra, older generation doesn't support matching of the alpha channel and the alpha channel matching is simply ignored, so colorkeying could be support for the framebuffer formats that have an alpha channel if the alpha channel matching is disabled by the mask value.
Quoted 3 lines
The alternative might be to enable the
keying for the channel if 'min <= max' and disable it if 'min > max'. But not sure if that's slightly too magicy.
The mask property should suit well your case, I don't think there is any need for the magic.
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 12 lines · Dmitry Osipenko
Quoted 10 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
Quoted 5 lines
You should pick both and reject unsupported property values based on the planes framebuffer format. So it will be possible to set unsupported values while plane is disabled because it doesn't have an associated framebuffer and then atomic check will fail to enable plane if property values are invalid for the given format.
The colorkey which is attached to a plane 'A' is not applied to plane 'A', so the format of plane 'A' is not relevant. The colorkey is applied to some other plane which will be below this plane in terms of the plane blending operation.
What if you have several planes below plane 'A' with differing framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane - do you decide to limit the colorkey to 8bits per channel, or to ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't know the details of the colorkey implementation, which could be one of:
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey lower plane data -> match ARGB8888 reduced to plane compatible colorkey
which will give different results depending on the format of the lower plane data.
Signature · 3 lines
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 33 lines · Russell King - ARM Linux
Quoted 12 lines · Dmitry Osipenko
Quoted 10 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
Quoted 5 lines
You should pick both and reject unsupported property values based on the planes framebuffer format. So it will be possible to set unsupported values while plane is disabled because it doesn't have an associated framebuffer and then atomic check will fail to enable plane if property values are invalid for the given format.
The colorkey which is attached to a plane 'A' is not applied to plane 'A', so the format of plane 'A' is not relevant. The colorkey is applied to some other plane which will be below this plane in terms of the plane blending operation.
What if you have several planes below plane 'A' with differing framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane - do you decide to limit the colorkey to 8bits per channel, or to ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't know the details of the colorkey implementation, which could be one of:
Quoted 5 lines
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey lower plane data -> match ARGB8888 reduced to plane compatible colorkey
which will give different results depending on the format of the lower plane data.
Yeah. This is one of the other issues I highlighted previously. On some Intel hw you enable the dst colorkey on the lower plane where you paint the colorkey, on others you enable it on the plane above that gets shown/hidden based on the key match on the lower plane. I think on most of our hardware dst keying only ever happens between two planes, even if more planes are enabled on the crtc. But there is at least one exception where you can have two overlay planes that get keyed against the same primary plane.
I was questioning which one is the better model for the uapi. Either way you still have the uncertainty of which planes actually participate in the keying process. One way around that would be to expose some kind of plane mask which would indicate the set of planes taking part in the keying process. I think for that to work we would have to move to a model where you enable the dst key on the lower plane where you paint the color key, otherwise having multiple bits set in the mask wouldn't make sense. That would perhaps also make it more clear what the format of the color key will be.
So as an example that exception Intel hw case would have:
overlay 2: key_mode={src,none}
overlay 1: key_mode={src,none}
primary: key_mode={dst,none}, dst_key_plane_mask=0x6
to indicate that both overlay planes participate in the keying process.
Whereas most other Intel hw would have:
overlay 2: key_mode={src,none}
overlay 1: key_mode={src,none}
primary: key_mode={dst,none}, dst_key_plane_mask=0x2
to indicate that only the overlay immediately above the primary will participate.
Signature · 6 lines
Ville Syrjälä Intel _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
In reply to Russell King - ARM LinuxQuoted 33 lines · On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote:
Quoted 11 lines · Dmitry Osipenko
Quoted 9 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
Quoted 6 lines
You should pick both and reject unsupported property values based on the planes framebuffer format. So it will be possible to set unsupported values
while plane is disabled because it doesn't have an associated framebuffer and then atomic check will fail to enable plane if property values are invalid for the given format.The colorkey which is attached to a plane 'A' is not applied to plane 'A', so the format of plane 'A' is not relevant. The colorkey is applied to some other plane which will be below this plane in terms of the plane blending operation.
What if you have several planes below plane 'A' with differing framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane - do you decide to limit the colorkey to 8bits per channel, or to ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't know the details of the colorkey implementation, which could be one of:
Quoted 5 lines
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey lower plane data -> match ARGB8888 reduced to plane compatible colorkey
which will give different results depending on the format of the lower plane data.
All unsupportable cases should be rejected in the atomic check. If your HW can't handle the case where multiple bottom planes have a different format, then in the planes atomic check you'll have to walk up all the bottom planes and verify their formats.
I'm not sure whether it's worth to check the planes intersection and fail only if top plane intersects with multiple bottom planes having different formats. Perhaps that could be a driver-specific implementation detail, userspace should take into account that atomic commit may fail on changing planes position.
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 37 lines · Dmitry Osipenko
Quoted 36 lines · On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote:
Quoted 11 lines · Dmitry Osipenko
Quoted 9 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something. Although for Intel hw I think the general rule is that min+max for YUV, value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.
I guess one alternative would be to have min+max only, and the driver would reject 'min != max' if it only uses a single value?
Quoted 6 lines
You should pick both and reject unsupported property values based on the planes framebuffer format. So it will be possible to set unsupported values
while plane is disabled because it doesn't have an associated framebuffer and then atomic check will fail to enable plane if property values are invalid for the given format.The colorkey which is attached to a plane 'A' is not applied to plane 'A', so the format of plane 'A' is not relevant. The colorkey is applied to some other plane which will be below this plane in terms of the plane blending operation.
What if you have several planes below plane 'A' with differing framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane - do you decide to limit the colorkey to 8bits per channel, or to ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't know the details of the colorkey implementation, which could be one of:
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey lower plane data -> match ARGB8888 reduced to plane compatible colorkey
Quoted 7 lines
Quoted 2 lines
which will give different results depending on the format of the lower plane data.
All unsupportable cases should be rejected in the atomic check. If your HW can't handle the case where multiple bottom planes have a different format, then in the planes atomic check you'll have to walk up all the bottom planes and verify their formats.
That is *not* what I'm trying to point out.
You are claiming that we should check the validity of the colorkey format in relation to the lower planes, and it sounds like you're suggesting it in generic code. I'm trying to get you to think a bit more about what you're suggesting by considering a theoretical (or maybe not so theoretical) case.
We do have hardware out there which can have multiple planes that are merged together - I seem to remember that Tegra? hardware has that ability, but it isn't implemented in the driver yet.
So, I'm asking how you forsee the validity check working in the presence of different formats for multiple lower planes.
I'm not talking about whether the hardware supports it or not - I'm assuming that the hardware _does_ support multiple lower planes with differing formats.
Quoted 1 line
From what I understand, to take the simple case of one lower plane,
you are proposing:
- if the lower plane is ARGB1555, then specifying a colorkey with an alpha of anything except 0 or 0xffff would be invalid and should be rejected.
- if a lower plane is ARGB8888, then specifying a colorkey which is anything except 0...0xffff in 0x101 (65535 / 255) steps would be invalid and should be rejected.
Now consider the case I mentioned above. What if there are two lower planes, one with ARGB1555 and the other with ARGB8888. Does this mean that (eg) the alpha colorkey component should be rejected if:
- the alpha in the colorkey is not 0 or 0xffff, or
- it's anything except 0...0xffff in 0x101 steps?
My assertion is that this is only a decision that can be made by the driver and not by generic code, because it is hardware dependent.
I am _not_ disagreeing with the general principle of validating that the requested state is possible with the hardware.
Signature · 3 lines
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up
Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Quoted 61 lines · On Friday, 6 July 2018 20:01:36 MSK Russell King - ARM Linux wrote:
Quoted 43 lines · Dmitry Osipenko
Quoted 42 lines · On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote:
Quoted 14 lines · Dmitry Osipenko
Quoted 9 lines · On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
IIRC my earlier idea was to have different colorkey modes for the min+max and value+mask modes. That way userspace might actually have some chance of figuring out which bits of state actually do something.
Although for Intel hw I think the general rule is that min+max for YUV,
value+mask for RGB, so it's still not 100% clear what to pick if the plane supports both.Quoted 3 lines
I guess one alternative would be to have min+max only, and the driver
would reject 'min != max' if it only uses a single value?Quoted 8 lines
You should pick both and reject unsupported property values based on the
planes framebuffer format. So it will be possible to set unsupported values
while plane is disabled because it doesn't have an associated framebuffer
and then atomic check will fail to enable plane if property values are invalid for the given format.The colorkey which is attached to a plane 'A' is not applied to plane 'A', so the format of plane 'A' is not relevant. The colorkey is applied to some other plane which will be below this plane in terms of the plane blending operation.
What if you have several planes below plane 'A' with differing framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane - do you decide to limit the colorkey to 8bits per channel, or to ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't know the details of the colorkey implementation, which could be one
of:
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey lower plane data -> match ARGB8888 reduced to plane compatible colorkeyQuoted 8 lines
Quoted 2 lines
which will give different results depending on the format of the lower plane data.
All unsupportable cases should be rejected in the atomic check. If your HW can't handle the case where multiple bottom planes have a different format,
then in the planes atomic check you'll have to walk up all the bottom planes and verify their formats.That is *not* what I'm trying to point out.
You are claiming that we should check the validity of the colorkey format in relation to the lower planes, and it sounds like you're suggesting it in generic code. I'm trying to get you to think a bit more about what you're suggesting by considering a theoretical (or maybe not so theoretical) case.
Quoted 4 lines
We do have hardware out there which can have multiple planes that are merged together - I seem to remember that Tegra? hardware has that ability, but it isn't implemented in the driver yet.
I'm not sure what you're meaning by planes "merging", could you please elaborate?
Quoted 22 lines
So, I'm asking how you forsee the validity check working in the presence of different formats for multiple lower planes.
I'm not talking about whether the hardware supports it or not - I'm assuming that the hardware _does_ support multiple lower planes with differing formats.
From what I understand, to take the simple case of one lower plane, you are proposing:
- if the lower plane is ARGB1555, then specifying a colorkey with an alpha of anything except 0 or
0xffffwould be invalid and should be rejected.- if a lower plane is ARGB8888, then specifying a colorkey which is anything except 0...0xffff in
0x101(65535 / 255) steps would be invalid and should be rejected.Now consider the case I mentioned above. What if there are two lower planes, one with ARGB1555 and the other with ARGB8888. Does this mean that (eg) the alpha colorkey component should be rejected if:
Quoted 6 lines
- the alpha in the colorkey is not 0 or
0xffff, or
- it's anything except 0...0xffff in0x101steps?My assertion is that this is only a decision that can be made by the driver and not by generic code, because it is hardware dependent.
Definitely the conversion rule must be defined explicitly, otherwise colorkey property values can't be considered generic. Thank you for pointing at it. I think rounding to a closest value should be the generic conversion rule.
I'll document the conversion rule in the next revision. Please let me know if you see any problems with the rounding to a closest value.
The final decision will be made by the driver, but driver and userspace will have to take into account the defined generic conversion rule.
Quoted 2 lines
I am _not_ disagreeing with the general principle of validating that the requested state is possible with the hardware.
Thank you for the clarification.
RFC PATCH v3 2/2 drm/tegra: plane: Implement generic colorkey property for older Tegra's
In reply to Dmitry OsipenkoFor the starter a minimal color keying support is implemented, which is enough to provide userspace like Opentegra Xorg driver with ability to support color keying by the XVideo extension.
--- drivers/gpu/drm/tegra/dc.c | 25 +++++++++ drivers/gpu/drm/tegra/dc.h | 7 +++ drivers/gpu/drm/tegra/plane.c | 102 ++++++++++++++++++++++++++++++++++ 3 files changed, 134 insertions(+)
drivers/gpu/drm/tegra/dc.c +25 -0
@@ -162,6 +162,7 @@ static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)u32 foreground =BLEND_WEIGHT1 (255 ) |BLEND_WEIGHT0 (255 ) |BLEND_COLOR_KEY_NONE ;u32 blendnokey =BLEND_WEIGHT1 (255 ) |BLEND_WEIGHT0 (255 ); +enum drm_plane_colorkey_mode mode;struct tegra_plane_state *state;u32 blending[2 ];unsigned int i;
@@ -171,7 +172,15 @@ static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)tegra_plane_writel (plane, foreground,DC_WIN_BLEND_1WIN ); state =to_tegra_plane_state (plane->base.state); + mode = plane->base.state->colorkey.mode; +/* setup color keying */ +if (mode ==DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP ) { +/* color key matched areas are transparent */ + foreground = background[0 ] |BLEND_COLOR_KEY_0 ; + } + +/* setup alpha blending */ if (state->opaque) {/* * Since custom fix-weight blending isn't utilized and weight
@@ -792,6 +801,11 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,dev_err (dc->dev,"failed to create rotation property: %d\n" , err); +if (dc->soc->has_legacy_blending) +drm_plane_create_colorkey_properties (&plane->base, +BIT (DRM_PLANE_COLORKEY_MODE_DISABLED ) | +BIT (DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP )); +return &plane->base; }
@@ -1077,6 +1091,11 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,dev_err (dc->dev,"failed to create rotation property: %d\n" , err); +if (dc->soc->has_legacy_blending) +drm_plane_create_colorkey_properties (&plane->base, +BIT (DRM_PLANE_COLORKEY_MODE_DISABLED ) | +BIT (DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP )); +return &plane->base; }
@@ -1187,6 +1206,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc) copy->pclk = state->pclk; copy->div = state->div; copy->planes = state->planes; + copy->ckey = state->ckey;return ©->base; }
@@ -1917,6 +1937,11 @@ static void tegra_crtc_atomic_flush(struct drm_crtc *crtc,struct tegra_dc *dc =to_tegra_dc (crtc);u32 value; +if (dc->soc->has_legacy_blending) { +tegra_dc_writel (dc, state->ckey.min,DC_DISP_COLOR_KEY0_LOWER ); +tegra_dc_writel (dc, state->ckey.max,DC_DISP_COLOR_KEY0_UPPER ); + } + value = state->planes <<8 |GENERAL_UPDATE ;tegra_dc_writel (dc, value,DC_CMD_STATE_CONTROL ); value =tegra_dc_readl (dc,DC_CMD_STATE_CONTROL );
drivers/gpu/drm/tegra/dc.h +7 -0
@@ -18,6 +18,11 @@struct tegra_output ; +struct tegra_dc_color_key_state { +u32 min; +u32 max; +}; +struct tegra_dc_state {struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {unsigned int div;u32 planes; + +struct tegra_dc_color_key_state ckey; };static inline struct tegra_dc_state *to_dc_state (struct drm_crtc_state *state)
drivers/gpu/drm/tegra/plane.c +102 -0
113 lines not on this page · raw message
Signature · 1 line
2.17.0