[PATCH v2] drm: Document requirements for driver-specific KMS props in new drivers
When extending support for a driver-specific KMS property to additional drivers, we should apply all the requirements for new properties and make sure the semantics are the same and documented. v2: devs of the driver which introduced property shall help and ack Signed-off-by: Sebastian Wick Acked-by: Maxime Ripard Acked-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 13d3627d8bc0..b98b98359c90 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -496,6 +496,13 @@ addition to the one mentioned above: * An IGT test must be submitted where reasonable. +For historical reasons, non-standard, driver-specific properties exist. If a KMS +driver wants to add support for one of those properties, the requirements for +new properties apply where possible. Additionally, the documented behavior must +match the de facto semantics of the existing property to ensure compatibility. +Developers of the driver that first added the property should help with those +tasks and must ACK the documented behavior if possible. + Property Types and Blob Property Support -- 2.44.0
Re: [PATCH v2] drm/drm_connector: Document Colorspace property variants
On Thu, Mar 07, 2024 at 10:29:22AM +0200, Pekka Paalanen wrote: > On Wed, 6 Mar 2024 17:42:09 +0100 > Sebastian Wick wrote: > > > On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote: > > > On Tue, 5 Mar 2024 14:51:49 +0100 > > > Sebastian Wick wrote: > > > > > > > The initial idea of the Colorspace prop was that this maps 1:1 to > > > > InfoFrames/SDP but KMS does not give user space enough information nor > > > > control over the output format to figure out which variants can be used > > > > for a given KMS commit. At the same time, properties like Broadcast RGB > > > > expect full range quantization range being produced by user space from > > > > the CRTC and drivers to convert to the range expected by the sink for > > > > the chosen output format, mode, InfoFrames, etc. > > > > > > > > This change documents the reality of the Colorspace property. The > > > > Default variant unfortunately is very much driver specific and not > > > > reflected by the EDID. The BT2020 variants are in active use by generic > > > > compositors which have expectations from the driver about the > > > > conversions it has to do when selecting certain output formats. > > > > > > > > Everything else is also marked as undefined. Coming up with valid > > > > behavior that makes it usable from user space and consistent with other > > > > KMS properties for those variants is left as an exercise for whoever > > > > wants to use them. > > > > > > > > v2: > > > > * Talk about "pixel operation properties" that user space configures > > > > * Mention that user space is responsible for checking the EDID for sink > > > >support > > > > * Make it clear that drivers can choose between RGB and YCbCr on their > > > >own > > > > > > > > Signed-off-by: Sebastian Wick > > > > --- > > > > drivers/gpu/drm/drm_connector.c | 79 + > > > > include/drm/drm_connector.h | 8 > > > > 2 files changed, 61 insertions(+), 26 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > > > b/drivers/gpu/drm/drm_connector.c > > > > index b0516505f7ae..65cdcc7d22db 100644 > > > > --- a/drivers/gpu/drm/drm_connector.c > > > > +++ b/drivers/gpu/drm/drm_connector.c > > > > @@ -2147,24 +2147,67 @@ > > > > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > > > * DOC: standard connector properties > > > > * > > > > * Colorspace: > > > > - * This property helps select a suitable colorspace based on the > > > > sink > > > > - * capability. Modern sink devices support wider gamut like BT2020. > > > > - * This helps switch to BT2020 mode if the BT2020 encoded video > > > > stream > > > > - * is being played by the user, same for any other colorspace. > > > > Thereby > > > > - * giving a good visual experience to users. > > > > - * > > > > - * The expectation from userspace is that it should parse the EDID > > > > - * and get supported colorspaces. Use this property and switch to > > > > the > > > > - * one supported. Sink supported colorspaces should be retrieved by > > > > - * userspace from EDID and driver will not explicitly expose them. > > > > - * > > > > - * Basically the expectation from userspace is: > > > > - * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > > > - *colorspace > > > > - * - Set this new property to let the sink know what it > > > > - *converted the CRTC output to. > > > > - * - This property is just to inform sink what colorspace > > > > - *source is trying to drive. > > > > + * This property is used to inform the driver about the color > > > > encoding > > > > + * user space configured the pixel operation properties to produce. > > > > + * The variants set the colorimetry, transfer characteristics, and > > > > which > > > > + * YCbCr conversion should be used when necessary. > > > > + * The transfer characteristics from HDR_OUTPUT_METADATA takes > > > > precedence > > > > + * over this property. > >
[PATCH v2] drm: Document requirements for driver-specific KMS props in new drivers
When extending support for a driver-specific KMS property to additional drivers, we should apply all the requirements for new properties and make sure the semantics are the same and documented. v2: devs of the driver which introduced property shall help and ack Signed-off-by: Sebastian Wick --- Documentation/gpu/drm-kms.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 13d3627d8bc0..b98b98359c90 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -496,6 +496,13 @@ addition to the one mentioned above: * An IGT test must be submitted where reasonable. +For historical reasons, non-standard, driver-specific properties exist. If a KMS +driver wants to add support for one of those properties, the requirements for +new properties apply where possible. Additionally, the documented behavior must +match the de facto semantics of the existing property to ensure compatibility. +Developers of the driver that first added the property should help with those +tasks and must ACK the documented behavior if possible. + Property Types and Blob Property Support -- 2.44.0
Re: [PATCH] drm: Document requirements for driver-specific KMS props in new drivers
On Wed, Mar 06, 2024 at 03:14:15PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 29, 2024 at 09:28:31PM +0100, Sebastian Wick wrote: > > When extending support for a driver-specific KMS property to additional > > drivers, we should apply all the requirements for new properties and > > make sure the semantics are the same and documented. > > > > Signed-off-by: Sebastian Wick > > --- > > Documentation/gpu/drm-kms.rst | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index 13d3627d8bc0..afa10a28035f 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -496,6 +496,11 @@ addition to the one mentioned above: > > > > * An IGT test must be submitted where reasonable. > > > > +For historical reasons, non-standard, driver-specific properties exist. If > > a KMS > > +driver wants to add support for one of those properties, the requirements > > for > > +new properties apply where possible. Additionally, the documented behavior > > must > > +match the de facto semantics of the existing property to ensure > > compatibility. > > + > > I'm conflicted about this one, really. > > On one hand, yeah, it's definitely reasonable and something we would > want on the long run. > > But on the other hand, a driver getting its technical debt worked on for > free by anyone but its developpers doesn't seem fair to me. Most of the work would have to be done for a new property as well. The only additional work is then documenting the de-facto semantics and moving the existing driver-specific code to the core. Would it help if we spell out that the developers of the driver-specific property shall help with both tasks? > Also, I assume this is in reaction to the discussion we had on the > Broadcast RGB property. We used in vc4 precisely because there was some > userspace code to deal with it and we could just reuse it, and it was > documented. So the requirements were met already. It was not in drm core and the behavior was not documented properly at least. Either way, with Broadcast RGB we were already in a bad situation because it was implemented by 2 drivers independently. This is what I want to avoid in the first place. The cleanup afterwards (thank you!) just exposed the problem. > Maxime
Re: [PATCH v2] drm/drm_connector: Document Colorspace property variants
On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote: > On Tue, 5 Mar 2024 14:51:49 +0100 > Sebastian Wick wrote: > > > The initial idea of the Colorspace prop was that this maps 1:1 to > > InfoFrames/SDP but KMS does not give user space enough information nor > > control over the output format to figure out which variants can be used > > for a given KMS commit. At the same time, properties like Broadcast RGB > > expect full range quantization range being produced by user space from > > the CRTC and drivers to convert to the range expected by the sink for > > the chosen output format, mode, InfoFrames, etc. > > > > This change documents the reality of the Colorspace property. The > > Default variant unfortunately is very much driver specific and not > > reflected by the EDID. The BT2020 variants are in active use by generic > > compositors which have expectations from the driver about the > > conversions it has to do when selecting certain output formats. > > > > Everything else is also marked as undefined. Coming up with valid > > behavior that makes it usable from user space and consistent with other > > KMS properties for those variants is left as an exercise for whoever > > wants to use them. > > > > v2: > > * Talk about "pixel operation properties" that user space configures > > * Mention that user space is responsible for checking the EDID for sink > >support > > * Make it clear that drivers can choose between RGB and YCbCr on their > >own > > > > Signed-off-by: Sebastian Wick > > --- > > drivers/gpu/drm/drm_connector.c | 79 + > > include/drm/drm_connector.h | 8 > > 2 files changed, 61 insertions(+), 26 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > b/drivers/gpu/drm/drm_connector.c > > index b0516505f7ae..65cdcc7d22db 100644 > > --- a/drivers/gpu/drm/drm_connector.c > > +++ b/drivers/gpu/drm/drm_connector.c > > @@ -2147,24 +2147,67 @@ > > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > * DOC: standard connector properties > > * > > * Colorspace: > > - * This property helps select a suitable colorspace based on the sink > > - * capability. Modern sink devices support wider gamut like BT2020. > > - * This helps switch to BT2020 mode if the BT2020 encoded video stream > > - * is being played by the user, same for any other colorspace. Thereby > > - * giving a good visual experience to users. > > - * > > - * The expectation from userspace is that it should parse the EDID > > - * and get supported colorspaces. Use this property and switch to the > > - * one supported. Sink supported colorspaces should be retrieved by > > - * userspace from EDID and driver will not explicitly expose them. > > - * > > - * Basically the expectation from userspace is: > > - * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > - *colorspace > > - * - Set this new property to let the sink know what it > > - *converted the CRTC output to. > > - * - This property is just to inform sink what colorspace > > - *source is trying to drive. > > + * This property is used to inform the driver about the color encoding > > + * user space configured the pixel operation properties to produce. > > + * The variants set the colorimetry, transfer characteristics, and which > > + * YCbCr conversion should be used when necessary. > > + * The transfer characteristics from HDR_OUTPUT_METADATA takes precedence > > + * over this property. > > + * User space always configures the pixel operation properties to produce > > + * full quantization range data (see the Broadcast RGB property). > > + * > > + * Drivers inform the sink about what colorimetry, transfer > > + * characteristics, YCbCr conversion, and quantization range to expect > > + * (this can depend on the output mode, output format and other > > + * properties). Drivers also convert the user space provided data to what > > + * the sink expects. > > Hi Sebastian, > > should it be more explicit that drivers are allowed to do only > RGB->YCbCr and quantization range conversions, but not TF nor gamut > conversions? > > That is, if the driver cannot pick the TF implied by "Colorspace" > property for the sink, then it cannot pick another TF for the sink and > silently convert. It think this should apply to all options including > the undefined ones. Or is that too much to guess? That's a rea
[PATCH v2] drm/drm_connector: Document Colorspace property variants
The initial idea of the Colorspace prop was that this maps 1:1 to InfoFrames/SDP but KMS does not give user space enough information nor control over the output format to figure out which variants can be used for a given KMS commit. At the same time, properties like Broadcast RGB expect full range quantization range being produced by user space from the CRTC and drivers to convert to the range expected by the sink for the chosen output format, mode, InfoFrames, etc. This change documents the reality of the Colorspace property. The Default variant unfortunately is very much driver specific and not reflected by the EDID. The BT2020 variants are in active use by generic compositors which have expectations from the driver about the conversions it has to do when selecting certain output formats. Everything else is also marked as undefined. Coming up with valid behavior that makes it usable from user space and consistent with other KMS properties for those variants is left as an exercise for whoever wants to use them. v2: * Talk about "pixel operation properties" that user space configures * Mention that user space is responsible for checking the EDID for sink support * Make it clear that drivers can choose between RGB and YCbCr on their own Signed-off-by: Sebastian Wick --- drivers/gpu/drm/drm_connector.c | 79 + include/drm/drm_connector.h | 8 2 files changed, 61 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b0516505f7ae..65cdcc7d22db 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -2147,24 +2147,67 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); * DOC: standard connector properties * * Colorspace: - * This property helps select a suitable colorspace based on the sink - * capability. Modern sink devices support wider gamut like BT2020. - * This helps switch to BT2020 mode if the BT2020 encoded video stream - * is being played by the user, same for any other colorspace. Thereby - * giving a good visual experience to users. - * - * The expectation from userspace is that it should parse the EDID - * and get supported colorspaces. Use this property and switch to the - * one supported. Sink supported colorspaces should be retrieved by - * userspace from EDID and driver will not explicitly expose them. - * - * Basically the expectation from userspace is: - * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink - *colorspace - * - Set this new property to let the sink know what it - *converted the CRTC output to. - * - This property is just to inform sink what colorspace - *source is trying to drive. + * This property is used to inform the driver about the color encoding + * user space configured the pixel operation properties to produce. + * The variants set the colorimetry, transfer characteristics, and which + * YCbCr conversion should be used when necessary. + * The transfer characteristics from HDR_OUTPUT_METADATA takes precedence + * over this property. + * User space always configures the pixel operation properties to produce + * full quantization range data (see the Broadcast RGB property). + * + * Drivers inform the sink about what colorimetry, transfer + * characteristics, YCbCr conversion, and quantization range to expect + * (this can depend on the output mode, output format and other + * properties). Drivers also convert the user space provided data to what + * the sink expects. + * + * User space has to check if the sink supports all of the possible + * colorimetries that the driver is allowed to pick by parsing the EDID. + * + * For historical reasons this property exposes a number of variants which + * result in undefined behavior. + * + * Default: + * The behavior is driver-specific. + * BT2020_RGB: + * BT2020_YCC: + * User space configures the pixel operation properties to produce + * RGB content with Rec. ITU-R BT.2020 colorimetry, Rec. + * ITU-R BT.2020 (Table 4, RGB) transfer characteristics and full + * quantization range. + * User space can use the HDR_OUTPUT_METADATA property to set the + * transfer characteristics to PQ (Rec. ITU-R BT.2100 Table 4) or + * HLG (Rec. ITU-R BT.2100 Table 5) in which case, user space + * configures pixel operation properties to produce content with + * the respective transfer characteristics. + * User space has to make sure the sink supports Rec. + * ITU-R BT.2020 R'G'B' and Rec. ITU-R BT.2020 Y'C'BC'R + * colorimetry. + * Drivers can configure the sink to use an RGB format, tell the + * sink to expect Rec. ITU-R BT.2020 R'G'B' c
[PATCH] drm/drm_connector: Document Colorspace property variants
The initial idea of the Colorspace prop was that this maps 1:1 to InfoFrames/SDP but KMS does not give user space enough information nor control over the output format to figure out which variants can be used for a given KMS commit. At the same time, properties like Broadcast RGB expect full range quantization range being produced by user space from the CRTC and drivers to convert to the range expected by the sink for the chosen output format, mode, InfoFrames, etc. This change documents the reality of the Colorspace property. The Default variant unfortunately is very much driver specific and not reflected by the EDID. The BT2020 variants are in active use by generic compositors which have expectations from the driver about the conversions it has to do when selecting certain output formats. Everything else is also marked as undefined. Coming up with valid behavior that makes it usable from user space and consistent with other KMS properties for those variants is left as an exercise for whoever wants to use them. Signed-off-by: Sebastian Wick --- drivers/gpu/drm/drm_connector.c | 67 - include/drm/drm_connector.h | 8 2 files changed, 49 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b0516505f7ae..1c4ce7f90a76 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -2147,24 +2147,55 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); * DOC: standard connector properties * * Colorspace: - * This property helps select a suitable colorspace based on the sink - * capability. Modern sink devices support wider gamut like BT2020. - * This helps switch to BT2020 mode if the BT2020 encoded video stream - * is being played by the user, same for any other colorspace. Thereby - * giving a good visual experience to users. - * - * The expectation from userspace is that it should parse the EDID - * and get supported colorspaces. Use this property and switch to the - * one supported. Sink supported colorspaces should be retrieved by - * userspace from EDID and driver will not explicitly expose them. - * - * Basically the expectation from userspace is: - * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink - *colorspace - * - Set this new property to let the sink know what it - *converted the CRTC output to. - * - This property is just to inform sink what colorspace - *source is trying to drive. + * This property selects the colorimetry and transfer characteristics user + * space configured the CRTC to produce. + * The transfer characteristics might get overwritten by the + * HDR_OUTPUT_METADATA property. + * The quantization range is always full (see the Broadcast RGB property). + * + * The driver is expected to send the right metadata to the sink which can + * depend on the property value, the output mode and the output format. + * It's also responsible for converting to the output format, taking into + * account YCbCr conversion and quantization range. + * + * For historical reasons this property exposes a number of variants which + * result in undefined behavior. + * + * Default: + * The behavior is driver-specific. + * BT2020_RGB: + * BT2020_YCC: + * User space configures the state such that the CRTC produces RGB + * content with Rec. ITU-R BT.2020 colorimetry, Rec. ITU-R BT.2020 + * (Table 4, RGB) transfer characteristics and full quantization + * range. + * User space can use the HDR_OUTPUT_METADATA property to set the + * transfer characteristics to PQ (Rec. ITU-R BT.2100 Table 4) or + * HLG (Rec. ITU-R BT.2100 Table 5) in which case, user space + * configures the CRTC to produce content with the respective + * transfer characteristics. + * Drivers can configure the sink to use an RGB format, tell the + * sink to expect Rec. ITU-R BT.2020 R'G'B' colorimetry and convert + * to the appropriate quantization range. + * Drivers can configure the sink to use a YCbCr format, tell the + * sink to expect Rec. ITU-R BT.2020 Y'C'BC'R colorimetry, convert + * to YCbCr using the Rec. ITU-R BT.2020 non-constant luminance + * conversion matrix and convert to the appropriate quantization + * range. + * SMPTE_170M_YCC: + * BT709_YCC: + * XVYCC_601: + * XVYCC_709: + * SYCC_601: + * opYCC_601: + * opRGB: + * BT2020_CYCC: + * DCI-P3_RGB_D65: + * DCI-P3_RGB_Theater: + * RGB_WIDE_FIXED: + * RGB_WIDE_FLOAT: + * BT601_YCC: + * The behavior is undefined. * * Because between HDMI and DP have different colorspaces, * drm_mode_create_hdmi_colorspace_property() is used
Re: [PATCH v7 21/36] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Mar 01, 2024 at 01:12:02PM +0100, Maxime Ripard wrote: > On Fri, Mar 01, 2024 at 12:29:41PM +0100, Sebastian Wick wrote: > > On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote: > > > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote: > > > > > @@ -1708,6 +1731,39 @@ > > > > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); > > > > > /** > > > > > * DOC: HDMI connector properties > > > > > * > > > > > + * Broadcast RGB (HDMI specific) > > > > > + * Indicates the Quantization Range (Full vs Limited) used. The > > > > > color > > > > > + * processing pipeline will be adjusted to match the value of > > > > > the > > > > > + * property, and the Infoframes will be generated and sent > > > > > accordingly. > > > > > + * > > > > > + * This property is only relevant if the HDMI output format is > > > > > RGB. If > > > > > + * it's one of the YCbCr variant, it will be ignored and the > > > > > output will > > > > > + * use a limited quantization range. > > > > > > > > Uh, maybe just say that the quantization range is selected automatically > > > > in case a YCbCr output format is in use. I'm not sure every YCbCr > > > > variant requires limited and even if it does, new formats could change > > > > this. > > > > > > I documented what i915 is doing: > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdmi.c#L2143 > > > > Sure, this is one valid strategy for the automatic behavior of YCbCr. > > Drivers could also always send an InfoFrame to ensure full range where > > possible. The point here is that this property shall not affect YCbCr > > output formats! > > > > Maybe it's even better to say "driver specific" instead of "automatic". > > Honestly, I'm not sure what you want from me here. Ville and you > insisted on the previous version to document what i915 is doing and to > follow whatever the behaviour was, and that we shouldn't spend time > improving the property. Fine, I did that. > > But now, you want me to ... improve the property? The property has a clear scope: quantization range for RGB output formats. What Intel does with things that are not in scope of the property is irrelevant. This isn't improving the property either but documenting the scope of the property. Sorry if this seems arbitrary but these details are so important to get right because the interactions between all the different things is already majorly broken. > Maxime >
Re: [PATCH v7 21/36] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Mar 01, 2024 at 11:30:56AM +0100, Maxime Ripard wrote: > On Thu, Feb 29, 2024 at 08:47:26PM +0100, Sebastian Wick wrote: > > > @@ -1708,6 +1731,39 @@ > > > EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); > > > /** > > > * DOC: HDMI connector properties > > > * > > > + * Broadcast RGB (HDMI specific) > > > + * Indicates the Quantization Range (Full vs Limited) used. The > > > color > > > + * processing pipeline will be adjusted to match the value of the > > > + * property, and the Infoframes will be generated and sent > > > accordingly. > > > + * > > > + * This property is only relevant if the HDMI output format is RGB. > > > If > > > + * it's one of the YCbCr variant, it will be ignored and the output > > > will > > > + * use a limited quantization range. > > > > Uh, maybe just say that the quantization range is selected automatically > > in case a YCbCr output format is in use. I'm not sure every YCbCr > > variant requires limited and even if it does, new formats could change > > this. > > I documented what i915 is doing: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdmi.c#L2143 Sure, this is one valid strategy for the automatic behavior of YCbCr. Drivers could also always send an InfoFrame to ensure full range where possible. The point here is that this property shall not affect YCbCr output formats! Maybe it's even better to say "driver specific" instead of "automatic". > Maxime >
Re: [PATCH v7 21/36] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Mar 01, 2024 at 09:29:17AM +0100, Hans Verkuil wrote:
> On 29/02/2024 20:47, Sebastian Wick wrote:
> > On Thu, Feb 22, 2024 at 07:14:07PM +0100, Maxime Ripard wrote:
> >> The i915 driver has a property to force the RGB range of an HDMI output.
> >> The vc4 driver then implemented the same property with the same
> >> semantics. KWin has support for it, and a PR for mutter is also there to
> >> support it.
> >>
> >> Both drivers implementing the same property with the same semantics,
> >> plus the userspace having support for it, is proof enough that it's
> >> pretty much a de-facto standard now and we can provide helpers for it.
> >>
> >> Let's plumb it into the newly created HDMI connector.
> >>
> >> Reviewed-by: Dave Stevenson
> >> Signed-off-by: Maxime Ripard
> >> ---
> >> Documentation/gpu/kms-properties.csv | 1 -
> >> drivers/gpu/drm/drm_atomic.c | 2 +
> >> drivers/gpu/drm/drm_atomic_state_helper.c | 4 +-
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_connector.c | 89
> >> +++
> >> include/drm/drm_connector.h | 36 +
> >> 6 files changed, 134 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/gpu/kms-properties.csv
> >> b/Documentation/gpu/kms-properties.csv
> >> index 0f9590834829..caef14c532d4 100644
> >> --- a/Documentation/gpu/kms-properties.csv
> >> +++ b/Documentation/gpu/kms-properties.csv
> >> @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> >> Values,Object attached,De
> >> ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> >> Max=0x",Connector,property to suggest an X offset for a connector
> >> ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to
> >> suggest an Y offset for a connector
> >> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> >> }",Connector,TDB
> >> -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> >> ""Limited 16:235"" }",Connector,"When this property is set to Limited
> >> 16:235 and CTM is set, the hardware will be programmed with the result of
> >> the multiplication of CTM by the limited range matrix to ensure the pixels
> >> normally in the range 0..1.0 are remapped to the range 16/255..235/255."
> >> ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> >> }",Connector,TBD
> >> ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> >> etc.",Connector,TBD
> >> ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 26f9e525c0a0..3e57d98d8418 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -1145,6 +1145,8 @@ static void drm_atomic_connector_print_state(struct
> >> drm_printer *p,
> >>
> >>if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> >>connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> >> + drm_printf(p, "\tbroadcast_rgb=%s\n",
> >> +
> >> drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> >>drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
> >>drm_printf(p, "\toutput_format=%s\n",
> >>
> >> drm_hdmi_connector_get_output_format_name(state->hdmi.output_format));
> >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> index 9f517599f117..0e8fb653965a 100644
> >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> @@ -589,6 +589,7 @@ void __drm_atomic_helper_connector_hdmi_reset(struct
> >> drm_connector *connector,
> >>
> >>new_state->max_bpc = max_bpc;
> >>
Colorspace "Default" and the CTA-861 spec
Hey all, I was trying to document the Colorspace property variants with what the sink expects, what kind of data the CRTC should be configured to produce, and what drivers must guarantee. I tried to stick to CTA-861-I for this exercise and after more than an hour to get the "Default" variant right, I gave up and now I'm writing this mail. There are actually 4 distinct parameters that have to be known: the colorimetry (primaries and white point), the transfer characteristics, the YCbCr conversion matrix and the quantization level. Section 5.1 has two paragraphs talking about the default color space (which should imply the rest of the parameters). For IT formats, and CE formats in some situations "the RGB color space used should be the RGB color space the Sink declares in the Basic Display Parameters and Features Block of its EDID". For sinks that accept YCbCr data and InfoFrames, CE formats default to other color spaces. They do support setting InfoFrames though and thus can set Y2=Y1=Y0=0 and force the sink into accepting RGB (Table 18) and set C1=C0=0 for Colorimetry RGB. Foote a helpfully notes that this is the colorimetry declared in the EDID. Now, the first obvious issue is that none of that defines the YCbCr matrix to be used. It is entirely undefined. If drivers use an YCbCr output format, user space gets undefined behavior. The second issue is the transfer characteristics. Section 5.3 defines the transfer characteristics when a specific color space is selected. If the colorimetry is RGB then the BT.709 transfer characteristics are used (and not the gamma from the EDID) whereas the default color space as defined in 5.1 seems to point to the EDID even for gamma. That would means depending on if we have an IT mode or a CE mode with a sink that supports YCbCr and InfoFrames, the default transfer characteristics could be different. User space would have to figure all of that out to know which transfer characteristics it should use. Is the spec just wrong here? There also is the "defaultRGB" colorimetry. This one actually clearly defines that the sink shall expect data with the colorimetry and gamma from the EDID. It seems to have been added in CTA-861-I so support for it is basically non-existent. So what should we do? To me it seems almost impossible to define anything useful for the "Default" property variant, but because the "defaultRGB" colorimetry is not supported at all right now, making "Default" undefined means we can't get predictable colors on almost all displays. Cheers, Sebastian
[PATCH] drm: Document requirements for driver-specific KMS props in new drivers
When extending support for a driver-specific KMS property to additional drivers, we should apply all the requirements for new properties and make sure the semantics are the same and documented. Signed-off-by: Sebastian Wick --- Documentation/gpu/drm-kms.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 13d3627d8bc0..afa10a28035f 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -496,6 +496,11 @@ addition to the one mentioned above: * An IGT test must be submitted where reasonable. +For historical reasons, non-standard, driver-specific properties exist. If a KMS +driver wants to add support for one of those properties, the requirements for +new properties apply where possible. Additionally, the documented behavior must +match the de facto semantics of the existing property to ensure compatibility. + Property Types and Blob Property Support -- 2.43.0
Re: [PATCH v7 21/36] drm/connector: hdmi: Add Broadcast RGB property
= new_state->crtc;
> struct drm_crtc_state *crtc_state;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d4..2b415b4ed506 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -776,6 +776,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->max_requested_bpc = val;
> } else if (property == connector->privacy_screen_sw_state_property) {
> state->privacy_screen_sw_state = val;
> + } else if (property == connector->broadcast_rgb_property) {
> + state->hdmi.broadcast_rgb = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -859,6 +861,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->max_requested_bpc;
> } else if (property == connector->privacy_screen_sw_state_property) {
> *val = state->privacy_screen_sw_state;
> + } else if (property == connector->broadcast_rgb_property) {
> + *val = state->hdmi.broadcast_rgb;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 591d2d500f61..6ffe59d01698 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1212,6 +1212,29 @@ static const u32 dp_colorspaces =
> BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
> BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
>
> +static const struct drm_prop_enum_list broadcast_rgb_names[] = {
> + { DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic" },
> + { DRM_HDMI_BROADCAST_RGB_FULL, "Full" },
> + { DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" },
> +};
> +
> +/*
> + * drm_hdmi_connector_get_broadcast_rgb_name - Return a string for HDMI
> connector RGB broadcast selection
> + * @broadcast_rgb: Broadcast RGB selection to compute name of
> + *
> + * Returns: the name of the Broadcast RGB selection, or NULL if the type
> + * is not valid.
> + */
> +const char *
> +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb
> broadcast_rgb)
> +{
> + if (broadcast_rgb > DRM_HDMI_BROADCAST_RGB_LIMITED)
> + return NULL;
> +
> + return broadcast_rgb_names[broadcast_rgb].name;
> +}
> +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
> +
> static const char * const output_format_str[] = {
> [HDMI_COLORSPACE_RGB] = "RGB",
> [HDMI_COLORSPACE_YUV420]= "YUV 4:2:0",
> @@ -1708,6 +1731,39 @@
> EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
> /**
> * DOC: HDMI connector properties
> *
> + * Broadcast RGB (HDMI specific)
> + * Indicates the Quantization Range (Full vs Limited) used. The color
> + * processing pipeline will be adjusted to match the value of the
> + * property, and the Infoframes will be generated and sent accordingly.
> + *
> + * This property is only relevant if the HDMI output format is RGB. If
> + * it's one of the YCbCr variant, it will be ignored and the output will
> + * use a limited quantization range.
Uh, maybe just say that the quantization range is selected automatically
in case a YCbCr output format is in use. I'm not sure every YCbCr
variant requires limited and even if it does, new formats could change
this.
With this changed, this patch is
Reviewed-by: Sebastian Wick
> + *
> + * The CRTC attached to the connector must be configured by user-space
> to
> + * always produce full-range pixels.
> + *
> + * The value of this property can be one of the following:
> + *
> + * Automatic:
> + * The quantization range is selected automatically based on the
> + * mode according to the HDMI specifications (HDMI 1.4b -
> Section
> + * 6.6 - Video Quantization Ranges).
> + *
> + * Full:
> + * Full quantization range is forced.
> + *
> + * Limited 16:235:
> + * Limited quantization range is forced. Unlike the name
> suggests,
> + * this works for any number of bits-per-component.
> + *
> + * Property values other than Automatic can result in colors being off
> (if
> + * limited is selected but the di
Re: [PATCH v2 0/7] Add YUV formats to VKMS
On Wed, Feb 28, 2024 at 08:42:41PM -0300, Arthur Grillo wrote: > > > On 15/01/24 12:06, Sebastian Wick wrote: > > On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote: > >> This patchset aims to add support for additional buffer YUV formats. > >> More specifically, it adds support to: > >> > >> Semi-planar formats: > >> > >> - NV12 > >> - NV16 > >> - NV24 > >> - NV21 > >> - NV61 > >> - NV42 > >> > >> Planar formats: > >> > >> - YUV440 > >> - YUV422 > >> - YUV444 > >> - YVU440 > >> - YVU422 > >> - YVU444 > >> > >> These formats have more than one plane, and most have chroma > >> subsampling. These properties don't have support on VKMS, so I had to > >> work on this before. > >> > >> To ensure that the conversions from YUV to RGB are working, I wrote a > >> KUnit test. As the work from Harry on creating KUnit tests on VKMS[1] is > >> not yet merged, I took the setup part (Kconfig entry and .kunitfile) > >> from it. > >> > >> Furthermore, I couldn't find any sources with the conversion matrices, > >> so I had to work out the values myself based on the ITU papers[2][3][4]. > >> So, I'm not 100% sure if the values are accurate. I'd appreciate some > >> input if anyone has more knowledge in this area. > > > > H.273 CICP [1] has concise descriptions of the required values for most > > widely used formats and the colour python framework [2] also can be used > > to quickly get to the desired information most of the time. > > > > [1]: https://www.itu.int/rec/T-REC-H.273 > > [2]: https://www.colour-science.org/ > > I want to thank you for suggesting the python framework, it helped > immensely now that I'm changing the precision from 8-bit to 32-bit[1]. > > If I'd known about this framework while developing this patch, I > would've saved myself a few weeks of pain and suffering recreating a > part of this library XD. I'm glad this is useful for you! We also used it for our color-and-hdr project https://gitlab.freedesktop.org/pq/color-and-hdr/. > [1]: > https://lore.kernel.org/all/b23da076-0bfb-48b2-9386-383a6dec1...@riseup.net/ > > Best Regards, > ~Arthur Grillo > > > > >> Also, I used two IGT tests to check if the formats were having a correct > >> conversion (all with the --extended flag): > >> > >> - kms_plane@pixel_format > >> - kms_plane@pixel_format_source_clamping. > >> > >> The nonsubsampled formats don't have support on IGT, so I sent a patch > >> fixing this[5]. > >> > >> Currently, this patchset does not add those formats to the writeback, as > >> it would require a rewrite of how the conversions are done (similar to > >> what was done on a previous patch[6]). So, I would like to review this > >> patchset before I start the work on this other part. > >> > >> [1]: > >> https://lore.kernel.org/all/20231108163647.106853-5-harry.wentl...@amd.com/ > >> [2]: https://www.itu.int/rec/R-REC-BT.601-7-201103-I/en > >> [3]: https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en > >> [4]: https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en > >> [5]: > >> https://lists.freedesktop.org/archives/igt-dev/2024-January/066937.html > >> [6]: > >> https://lore.kernel.org/dri-devel/20230414135151.75975-2-mca...@igalia.com/ > >> > >> Signed-off-by: Arthur Grillo > >> --- > >> Changes in v2: > >> - Use EXPORT_SYMBOL_IF_KUNIT instead of including the .c test > >> file (Maxime) > >> - Link to v1: > >> https://lore.kernel.org/r/20240105-vkms-yuv-v1-0-34c4cd345...@riseup.net > >> > >> --- > >> Arthur Grillo (7): > >> drm/vkms: Use drm_frame directly > >> drm/vkms: Add support for multy-planar framebuffers > >> drm/vkms: Add range and encoding properties to pixel_read function > >> drm/vkms: Add chroma subsampling > >> drm/vkms: Add YUV support > >> drm/vkms: Drop YUV formats TODO > >> drm/vkms: Create KUnit tests for YUV conversions > >> > >> Documentation/gpu/vkms.rst| 3 +- > >> drivers/gpu/drm/vkms/Kconfig | 15 ++ > >> drivers/gpu/drm/vkms/Makefile | 1 + > >> drivers/gpu/drm/vkms/tests/.kunitconfig | 4 + > >> drivers/gpu/drm/vkms/tests/Makefile | 3 + > >> drivers/gpu/drm/vkms/tests/vkms_format_test.c | 156 > >> drivers/gpu/drm/vkms/vkms_drv.h | 6 +- > >> drivers/gpu/drm/vkms/vkms_formats.c | 247 > >> ++ > >> drivers/gpu/drm/vkms/vkms_formats.h | 9 + > >> drivers/gpu/drm/vkms/vkms_plane.c | 26 ++- > >> drivers/gpu/drm/vkms/vkms_writeback.c | 5 - > >> 11 files changed, 426 insertions(+), 49 deletions(-) > >> --- > >> base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f > >> change-id: 20231226-vkms-yuv-6f7859f32df8 > >> > >> Best regards, > >> -- > >> Arthur Grillo > >> > > >
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 27, 2024 at 09:35:22PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Add a new immutable plane property by which a plane can advertise > a handful of recommended plane sizes. This would be mostly exposed > by cursor planes as a slightly more capable replacement for > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > a one size fits all limit for the whole device. > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > size via the cursor size caps. But always using the max sized > cursor can waste a surprising amount of power, so a better > stragey is desirable. > > Most other drivers don't specify any cursor size at all, in > which case the ioctl code just claims that 64x64 is a great > choice. Whether that is actually true is debatable. > > A poll of various compositor developers informs us that > blindly probing with setcursor/atomic ioctl to determine > suitable cursor sizes is not acceptable, thus the > introduction of the new property to supplant the cursor > size caps. The compositor will now be free to select a > more optimal cursor size from the short list of options. > > Note that the reported sizes (either via the property or the > caps) make no claims about things such as plane scaling. So > these things should only really be consulted for simple > "cursor like" use cases. > > Userspace consumer in the form of mutter seems ready: > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 > > v2: Try to add some docs > v3: Specify that value 0 is reserved for future use (basic idea from Jonas) > Drop the note about typical hardware (Pekka) > v4: Update the docs to indicate the list is "in order of preference" > Add a a link to the mutter MR > > Cc: Simon Ser > Cc: Jonas Ådahl > Cc: Daniel Stone > Cc: Sameer Lattannavar > Cc: Sebastian Wick > Acked-by: Harry Wentland > Acked-by: Pekka Paalanen > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_mode_config.c | 7 + > drivers/gpu/drm/drm_plane.c | 52 +++ > include/drm/drm_mode_config.h | 5 +++ > include/drm/drm_plane.h | 4 +++ > include/uapi/drm/drm_mode.h | 11 +++ > 5 files changed, 79 insertions(+) > > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 48fd2d67f352..568972258222 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c > @@ -372,6 +372,13 @@ static int drm_mode_create_standard_properties(struct > drm_device *dev) > return -ENOMEM; > dev->mode_config.modifiers_property = prop; > > + prop = drm_property_create(dev, > +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, > +"SIZE_HINTS", 0); > + if (!prop) > + return -ENOMEM; > + dev->mode_config.size_hints_property = prop; > + > return 0; > } > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 672c655c7a8e..4135ce16e608 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -140,6 +140,25 @@ > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have > been > * various bugs in this area with inconsistencies between the capability > * flag and per-plane properties. > + * > + * SIZE_HINTS: > + * Blob property which contains the set of recommended plane size > + * which can used for simple "cursor like" use cases (eg. no scaling). > + * Using these hints frees userspace from extensive probing of > + * supported plane sizes through atomic/setcursor ioctls. > + * > + * The blob contains an array of struct drm_plane_size_hint, in > + * order of preference. For optimal usage userspace should pick > + * the first size that satisfies its own requirements. > + * > + * Drivers should only attach this property to planes that > + * support a very limited set of sizes. > + * > + * Note that property value 0 (ie. no blob) is reserved for potential > + * future use. Current userspace is expected to ignore the property > + * if the value is 0, and fall back to some other means (eg. > + * _CAP_CURSOR_WIDTH and _CAP_CURSOR_HEIGHT) to determine > + * the appropriate plane size to use. > */ > > static unsigned int drm_num_planes(struct drm_device *dev) > @@ -1729,3 +1748,36 @@ int drm_plane_create_scaling_filter_property(struct > drm_plane *plane, > return 0; > } > EXPORT_SYMBOL(drm_plane_create_scali
Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 22, 2024 at 02:58:45PM +0200, Ville Syrjälä wrote: > On Thu, Feb 22, 2024 at 11:54:04AM +0100, Maxime Ripard wrote: > > On Mon, Feb 19, 2024 at 03:01:44PM +0100, Sebastian Wick wrote: > > > On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote: > > > > On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote: > > > > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard > > > > > > > > > > > wrote: > > > > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime > > > > > > > > > > > > > Ripard wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian > > > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range > > > > > > > > > > > > > > > > > (Full vs Limited) used. > > > > > > > > > > > > > > > > > + * Infoframes will be generated > > > > > > > > > > > > > > > > > according to that value. > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > + * The value of this property can be > > > > > > > > > > > > > > > > > one of the following: > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > + * Drivers can set up this pr
Re: Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote: > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > > > wrote: > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > * > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full > > > > > > > > > > > > > > vs Limited) used. > > > > > > > > > > > > > > + * Infoframes will be generated according to > > > > > > > > > > > > > > that value. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * The value of this property can be one of > > > > > > > > > > > > > > the following: > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > > > There might be two > > > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > &g
Re: [PATCH] drm: document userspace expectations around the Colorspace connector property
On Tue, Feb 13, 2024 at 11:26:44AM +0200, Ville Syrjälä wrote: > On Mon, Feb 12, 2024 at 05:50:36PM +0100, Sebastian Wick wrote: > > On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote: > > > On Fri, 9 Feb 2024 17:53:07 +0100 > > > Xaver Hugl wrote: > > > > > > > Signed-off-by: Xaver Hugl > > > > --- > > > > drivers/gpu/drm/drm_connector.c | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > > > b/drivers/gpu/drm/drm_connector.c > > > > index b0516505f7ae..01e13984629b 100644 > > > > --- a/drivers/gpu/drm/drm_connector.c > > > > +++ b/drivers/gpu/drm/drm_connector.c > > > > @@ -2158,6 +2158,14 @@ > > > > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > > > * one supported. Sink supported colorspaces should be retrieved by > > > > * userspace from EDID and driver will not explicitly expose them. > > > > * > > > > + * As userspace can't currently know whether or not the output is > > > > using > > > > + * RGB or YCC signalling, the driver must translate properties to > > > > their > > > > + * relevant RGB or YCC counterparts, depending on the actually used > > > > + * signalling. Property values that are only valid for either YCC > > > > or RGB > > > > + * and have no equivalent for the other signalling type must not be > > > > + * exposed as supported, unless the driver can guarantee it never > > > > uses > > > > + * the signalling that doesn't match the property. > > > > + * > > > > * Basically the expectation from userspace is: > > > > * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > > > *colorspace > > > > > > While this addition is good, I have another question: > > > > > > Does "Colorspace" property choose also the RGB->YCbCr matrix that the > > > driver will use when it happens to use YCbCr signalling? > > > > > > So far we have only been talking about the primaries and white point. > > > > Uh, yeah, good point. The InfoFrames do affect both the YCbCr conversion > > and the transfer characteristics that the sink expects. Drivers should > > do the RGB to YCbCr conversion with the new matrix. I think (and very > > much hope) that drivers don't rely on the TF for any internal processing > > but if they did, they also should use the one the sink expects. > > What we need is: > - list of the property values that are still allowd (the ones that still > make sense with the changed semantics) > - mark all the other ones as deprecated > - filter/reject the deprecated values when creating the property > - document each valid enum value fully (for both RGB and YCbCr output): > * what exacly is signalled to the sink via infoframe/msa/vsc sdp > * what processing is the driver expected to perform on the actual data I'm starting to agree that this is a better idea than coming up with a number of rules. We only rely on the default colorimetry as indicated by EDID and BT.2020. Xaver, are you going to update the patch accordingly? > -- > Ville Syrjälä > Intel >
Re: [PATCH 09/28] drm: Add Color ops capability property
On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> Add capability property which a colorop can expose it's
> hardware's abilities. It's a blob property that can be
> filled with respective data structures depending on the
> colorop. The user space is expected to read this property
> and program the colorop accordingly.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> include/drm/drm_colorop.h | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9f6a3a1c8020..95f1df73209c 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> *val = state->curve_1d_type;
> } else if (property == colorop->data_property) {
> *val = (state->data) ? state->data->base.id : 0;
> + } else if (property == colorop->hw_caps_property) {
> + *val = state->hw_caps ?
> + state->hw_caps->base.id : 0;
> } else {
> return -EINVAL;
> }
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index 5b8c36538491..f417e109c40a 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -59,6 +59,12 @@ struct drm_colorop_state {
>*/
> enum drm_colorop_curve_1d_type curve_1d_type;
>
> + /**
> + * @hw_caps:
> + *
> + */
> + struct drm_property_blob *hw_caps;
> +
Is this supposed to be generic for any colorop or specifically for
DRM_COLOROP_1D_LUT?
> /**
>* @data:
>*
> @@ -167,6 +173,13 @@ struct drm_colorop {
>*/
> struct drm_property *bypass_property;
>
> + /**
> + * @hwlut_caps_property:
> + *
> + * Property to expose hardware lut capbilities.
> + */
> + struct drm_property *hw_caps_property;
> +
> /**
>* @curve_1d_type:
>*
> --
> 2.42.0
>
Re: [PATCH 08/28] drm: Add Color lut range attributes
On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> This defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe segmented lut ranges/PWL LUTs in the hardware.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Chaitanya Kumar Borah
> ---
> include/uapi/drm/drm_mode.h | 58 +
> 1 file changed, 58 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index af67f32e0087..376498715d0e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> DRM_MODE_PAGE_FLIP_ASYNC | \
> DRM_MODE_PAGE_FLIP_TARGET)
>
All of this uses DRM_MODE_LUT namespace but it seems specifically for
the drm colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the
naming.
> +/**
> + * DRM_MODE_LUT_INTERPOLATE
> + *
> + * linearly interpolate between the points
> + */
> +#define DRM_MODE_LUT_INTERPOLATE BIT(0)
> +
> +/**
> + * DRM_MODE_LUT_REUSE_LAST
> + *
> + * the last value of the previous range is the
> + * first value of the current range.
> + */
> +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> +
> +/**
> + * DRM_MODE_LUT_NON_DECREASING
> + *
> + * the curve must be non-decreasing
> + */
> +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> +
> +/**
> + * DRM_MODE_LUT_REFLECT_NEGATIVE
> + *
> + * the curve is reflected across origin for negative inputs
> + */
> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> +
> +/**
> + * DRM_MODE_LUT_SINGLE_CHANNEL
> + *
> + * the same curve (red) is used for blue and green channels as well
> + */
> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> +
> +/**
> + * struct drm_color_lut_range
> + *
> + * structure to advertise capability of a color hardware
> + * block that accepts LUT values. It can represent LUTs with
> + * varied number of entries and distributions
> + * (Multi segmented, Logarithmic etc).
> + */
> +
> +struct drm_color_lut_range {
> + /* DRM_MODE_LUT_* */
> + __u32 flags;
> + /* number of points on the curve */
> + __u16 count;
> + /* input/output bits per component */
> + __u8 input_bpc, output_bpc;
> + /* input start/end values */
> + __s32 start, end;
> + /* output min/max values */
> + __s32 min, max;
> +};
> +
> /*
> * Request a page flip on the specified crtc.
> *
> --
> 2.42.0
>
Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > > > /** > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > * > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full vs > > > > > > > > > > > > Limited) used. > > > > > > > > > > > > + * Infoframes will be generated according to that > > > > > > > > > > > > value. > > > > > > > > > > > > + * > > > > > > > > > > > > + * The value of this property can be one of the > > > > > > > > > > > > following: > > > > > > > > > > > > + * > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > + * RGB Range is selected automatically > > > > > > > > > > > > based on the mode > > > > > > > > > > > > + * according to the HDMI specifications. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Full: > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > + * Limited RGB Range is forced. Unlike > > > > > > > > > > > > the name suggests, > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > There might be two > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > > pipeline processing > > > > > > > > > > > such that a full-range input to the CRTC is converted to > > > > > > > > > > > either full- or > > > > > > > > > > > limited-range, depending on what the monitor is supposed > > > > > > > > > > > to accept. > > > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there is > > > > > > > > > > > no signalling, > > > > > > > > > > > or that the signalling matc
Re: [PATCH] drm: document userspace expectations around the Colorspace connector property
On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote: > On Fri, 9 Feb 2024 17:53:07 +0100 > Xaver Hugl wrote: > > > Signed-off-by: Xaver Hugl > > --- > > drivers/gpu/drm/drm_connector.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > b/drivers/gpu/drm/drm_connector.c > > index b0516505f7ae..01e13984629b 100644 > > --- a/drivers/gpu/drm/drm_connector.c > > +++ b/drivers/gpu/drm/drm_connector.c > > @@ -2158,6 +2158,14 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > * one supported. Sink supported colorspaces should be retrieved by > > * userspace from EDID and driver will not explicitly expose them. > > * > > + * As userspace can't currently know whether or not the output is using > > + * RGB or YCC signalling, the driver must translate properties to their > > + * relevant RGB or YCC counterparts, depending on the actually used > > + * signalling. Property values that are only valid for either YCC or > > RGB > > + * and have no equivalent for the other signalling type must not be > > + * exposed as supported, unless the driver can guarantee it never uses > > + * the signalling that doesn't match the property. > > + * > > * Basically the expectation from userspace is: > > * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > *colorspace > > While this addition is good, I have another question: > > Does "Colorspace" property choose also the RGB->YCbCr matrix that the > driver will use when it happens to use YCbCr signalling? > > So far we have only been talking about the primaries and white point. Uh, yeah, good point. The InfoFrames do affect both the YCbCr conversion and the transfer characteristics that the sink expects. Drivers should do the RGB to YCbCr conversion with the new matrix. I think (and very much hope) that drivers don't rely on the TF for any internal processing but if they did, they also should use the one the sink expects.
Re: [PATCH] drm: document userspace expectations around the Colorspace connector property
On Fri, Feb 09, 2024 at 05:53:07PM +0100, Xaver Hugl wrote: > Signed-off-by: Xaver Hugl > --- > drivers/gpu/drm/drm_connector.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b0516505f7ae..01e13984629b 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -2158,6 +2158,14 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > * one supported. Sink supported colorspaces should be retrieved by > * userspace from EDID and driver will not explicitly expose them. > * > + * As userspace can't currently know whether or not the output is using > + * RGB or YCC signalling, the driver must translate properties to their > + * relevant RGB or YCC counterparts, depending on the actually used > + * signalling. Property values that are only valid for either YCC or RGB > + * and have no equivalent for the other signalling type must not be > + * exposed as supported, unless the driver can guarantee it never uses > + * the signalling that doesn't match the property. > + * > * Basically the expectation from userspace is: > * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > *colorspace > -- > 2.43.0 > Thank you! Reviewed-by: Sebastian Wick
Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > Hi, > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > > > > > > > > /** > > > > > > > > * DOC: HDMI connector properties > > > > > > > > * > > > > > > > > + * Broadcast RGB > > > > > > > > + * Indicates the RGB Quantization Range (Full vs Limited) > > > > > > > > used. > > > > > > > > + * Infoframes will be generated according to that value. > > > > > > > > + * > > > > > > > > + * The value of this property can be one of the following: > > > > > > > > + * > > > > > > > > + * Automatic: > > > > > > > > + * RGB Range is selected automatically based on > > > > > > > > the mode > > > > > > > > + * according to the HDMI specifications. > > > > > > > > + * > > > > > > > > + * Full: > > > > > > > > + * Full RGB Range is forced. > > > > > > > > + * > > > > > > > > + * Limited 16:235: > > > > > > > > + * Limited RGB Range is forced. Unlike the name > > > > > > > > suggests, > > > > > > > > + * this works for any number of > > > > > > > > bits-per-component. > > > > > > > > + * > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > + * > > > > > > > > > > > > > > This is a good time to document this in more detail. There might > > > > > > > be two > > > > > > > different things being affected: > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color pipeline > > > > > > > processing > > > > > > > such that a full-range input to the CRTC is converted to either > > > > > > > full- or > > > > > > > limited-range, depending on what the monitor is supposed to > > > > > > > accept. > > > > > > > > > > > > > > When automatic is selected, does that mean that there is no > > > > > > > signalling, > > > > > > > or that the signalling matches what the monitor is supposed to > > > > > > > accept > > > > > > > according to the spec? Also, is this really HDMI specific? > > > > > > > > > > > > > > When full or limited is selected and the monitor doesn't support > > > > > > > the > > > > > > > signalling, what happens? > > > > > > > > > > > > Forgot to mention: user-space still has no control over RGB vs > > > > > > YCbCr on > > > > > > the cable, so is this only affecting RGB? If not, how does it affect > > > > > > YCbCr? > > > > > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it looks like > > > > > if > > > > > we're using a YCbCr format, i915 will always use a limited range while > > > > > vc4 will follow the value of the property. > > > > > > > > The property is literally called "Broadcast *RGB*". > > > > That should explain why it's only affecting RGB. > > > > > > Right. And the limited range option is called "Limited 16:235" despite > > > being usable on bpc > 8 bits. Naming errors occurs, and history happens > > > to make names inconsistent too, that's fine and not an argument in > > > itself. > >
Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Fri, Feb 02, 2024 at 04:49:04PM +0100, Maxime Ripard wrote: > Hi Sebastian, > > On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote: > > > /** > > > * DOC: HDMI connector properties > > > * > > > + * Broadcast RGB > > > + * Indicates the RGB Quantization Range (Full vs Limited) used. > > > + * Infoframes will be generated according to that value. > > > + * > > > + * The value of this property can be one of the following: > > > + * > > > + * Automatic: > > > + * RGB Range is selected automatically based on the mode > > > + * according to the HDMI specifications. > > > + * > > > + * Full: > > > + * Full RGB Range is forced. > > > + * > > > + * Limited 16:235: > > > + * Limited RGB Range is forced. Unlike the name suggests, > > > + * this works for any number of bits-per-component. > > > + * > > > + * Drivers can set up this property by calling > > > + * drm_connector_attach_broadcast_rgb_property(). > > > + * > > > > This is a good time to document this in more detail. There might be two > > different things being affected: > > > > 1. The signalling (InfoFrame/SDP/...) > > 2. The color pipeline processing > > > > All values of Broadcast RGB always affect the color pipeline processing > > such that a full-range input to the CRTC is converted to either full- or > > limited-range, depending on what the monitor is supposed to accept. > > > > When automatic is selected, does that mean that there is no signalling, > > or that the signalling matches what the monitor is supposed to accept > > according to the spec? Also, is this really HDMI specific? > > > > When full or limited is selected and the monitor doesn't support the > > signalling, what happens? > > Leaving the YCbCr vs RGB discussion aside, would this be better ? Yes, it is. Thanks. We do have to resolve the YCbCr vs RGB issue though. > * Broadcast RGB (HDMI specific) > * Indicates the Quantization Range (Full vs Limited) used. The color > * processing pipeline will be adjusted to match the value of the Ah, another thing no note here is that the CRTC as configured by user space must always produce full range pixels. > * property, and the Infoframes will be generated and sent accordingly. > * > * The value of this property can be one of the following: > * > * Automatic: > * The quantization range is selected automatically based on the > * mode according to the HDMI specifications (HDMI 1.4b - Section > * 6.6 - Video Quantization Ranges). > * > * Full: > * Full quantization range is forced. > * > * Limited 16:235: > * Limited quantization range is forced. Unlike the name > suggests, > * this works for any number of bits-per-component. > * > * Property values other than Automatic can result in colors being off > (if > * limited is selected but the display expects full), or a black screen > * (if full is selected but the display expects limited). > * > * Drivers can set up this property by calling > * drm_connector_attach_broadcast_rgb_property(). > > Thanks! > Maxime
Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace
On Wed, Jan 17, 2024 at 12:58:15PM +, Andri Yngvason wrote: > mið., 17. jan. 2024 kl. 09:21 skrifaði Pekka Paalanen : > > > > On Tue, 16 Jan 2024 14:11:43 + > > Andri Yngvason wrote: > > > > > þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick > > > : > > > > > > > > On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote: > > > [...] > > > > > şri., 16. jan. 2024 kl. 11:42 skrifaği Sebastian Wick > > > > > : > > > > > > > > > > > > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > > > > > > > From: Werner Sembach > > > > > > > > > > > > > > Add a new general drm property "force color format" which can be > > > > > > > used > > > > > > > by userspace to tell the graphics driver which color format to > > > > > > > use. > > > > > > > > > > > > I don't like the "force" in the name. This just selects the color > > > > > > format, let's just call it "color format" then. > > > > > > > > > > > > > > > > In previous revisions, this was "preferred color format" and "actual > > > > > color format", of which the latter has been dropped. I recommend > > > > > reading the discussion for previous revisions. > > > > > > > > Please don't imply that I didn't read the thread I'm answering to. > > > > FYI, I have not read this thread. > > > > pq, You did not read this summary? > https://lore.kernel.org/dri-devel/cafnqbqwjejax6b4oewpgasmud5_nxzymxufdog294ctvgbt...@mail.gmail.com/ > > You partook in the discussion on IRC. Please read it and tell me if I > misunderstood anything. > > Sebastian, I apologise. You clearly read it as you even replied to it! Thank you :) > > > > > > > > > There are arguments for adding "actual color format" later and if it > > > > > is added later, we'd end up with "color format" and "actual color > > > > > format", which might be confusing, and it is why I chose to call it > > > > > "force color format" because it clearly communicates intent and > > > > > disambiguates it from "actual color format". > > > > > > > > There is no such thing as "actual color format" in upstream though. > > > > Basing your naming on discarded ideas is not useful. The thing that sets > > > > the color space for example is called "Colorspace", not "force > > > > colorspace". > > > > > > > > > > Sure, I'm happy with calling it whatever people want. Maybe we can > > > have a vote on it? > > > > It would sound strange to say "force color format" = "auto". Just drop > > the "force" of it. > > > > If and when we need the feedback counterpart, it could be an immutable > > prop called "active color format" where "auto" is not a valid value, or > > something in the new "output properties" design Sima has been thinking > > of. > > There seems to be consensus for calling it "color format" > > > > > > > > [...] > > > > > > > @@ -1396,6 +1404,15 @@ static const u32 dp_colorspaces = > > > > > > > * drm_connector_attach_max_bpc_property() to create and > > > > > > > attach the > > > > > > > * property to the connector during initialization. > > > > > > > * > > > > > > > + * force color format: > > > > > > > + * This property is used by userspace to change the used color > > > > > > > format. When > > > > > > > + * used the driver will use the selected format if valid for > > > > > > > the hardware, > > > > > > > > > > > > All properties are always "used", they just can have different > > > > > > values. > > > > > > You probably want to talk about the auto mode here. > > > > > > > > > > Maybe we can say something like: If userspace does not set the > > > > > property or if it is explicitly set to zero, the driver will select > > > > > the appropriate color format based on other constraints. > > > > &g
Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Jan 15, 2024 at 04:25:41PM +0100, Maxime Ripard wrote:
> On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > > The i915 driver has a property to force the RGB range of an HDMI output.
> > > The vc4 driver then implemented the same property with the same
> > > semantics. KWin has support for it, and a PR for mutter is also there to
> > > support it.
> > >
> > > Both drivers implementing the same property with the same semantics,
> > > plus the userspace having support for it, is proof enough that it's
> > > pretty much a de-facto standard now and we can provide helpers for it.
> > >
> > > Let's plumb it into the newly created HDMI connector.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > Documentation/gpu/kms-properties.csv | 1 -
> > > drivers/gpu/drm/drm_atomic.c | 5 +
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 17 +
> > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > > drivers/gpu/drm/drm_connector.c| 76 +
> > > drivers/gpu/drm/tests/Makefile | 1 +
> > > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 376
> > > +
> > > drivers/gpu/drm/tests/drm_connector_test.c | 117 ++-
> > > drivers/gpu/drm/tests/drm_kunit_edid.h | 106 ++
> > > include/drm/drm_connector.h| 36 ++
> > > 10 files changed, 737 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/gpu/kms-properties.csv
> > > b/Documentation/gpu/kms-properties.csv
> > > index 0f9590834829..caef14c532d4 100644
> > > --- a/Documentation/gpu/kms-properties.csv
> > > +++ b/Documentation/gpu/kms-properties.csv
> > > @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> > > Values,Object attached,De
> > > ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > > Max=0x",Connector,property to suggest an X offset for a connector
> > > ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to
> > > suggest an Y offset for a connector
> > > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > > }",Connector,TDB
> > > -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> > > ""Limited 16:235"" }",Connector,"When this property is set to Limited
> > > 16:235 and CTM is set, the hardware will be programmed with the result of
> > > the multiplication of CTM by the limited range matrix to ensure the
> > > pixels normally in the range 0..1.0 are remapped to the range
> > > 16/255..235/255."
> > > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> > > }",Connector,TBD
> > > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B""
> > > } etc.",Connector,TBD
> > > ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index c31fc0b48c31..1465a7f09a0b 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1142,6 +1142,11 @@ static void
> > > drm_atomic_connector_print_state(struct drm_printer *p,
> > > drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
> > > drm_printf(p, "\tcolorspace=%s\n",
> > > drm_get_colorspace_name(state->colorspace));
> > >
> > > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
> > > + drm_printf(p, "\tbroadcast_rgb=%s\n",
> > > +
> > > drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> > > +
> > > if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> > > if (state->wri
Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace
On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote: > Hi Sebastian, > > þri., 16. jan. 2024 kl. 11:42 skrifaði Sebastian Wick > : > > > > On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote: > > > From: Werner Sembach > > > > > > Add a new general drm property "force color format" which can be used > > > by userspace to tell the graphics driver which color format to use. > > > > I don't like the "force" in the name. This just selects the color > > format, let's just call it "color format" then. > > > > In previous revisions, this was "preferred color format" and "actual > color format", of which the latter has been dropped. I recommend > reading the discussion for previous revisions. Please don't imply that I didn't read the thread I'm answering to. > There are arguments for adding "actual color format" later and if it > is added later, we'd end up with "color format" and "actual color > format", which might be confusing, and it is why I chose to call it > "force color format" because it clearly communicates intent and > disambiguates it from "actual color format". There is no such thing as "actual color format" in upstream though. Basing your naming on discarded ideas is not useful. The thing that sets the color space for example is called "Colorspace", not "force colorspace". > [...] > > > @@ -1396,6 +1404,15 @@ static const u32 dp_colorspaces = > > > * drm_connector_attach_max_bpc_property() to create and attach the > > > * property to the connector during initialization. > > > * > > > + * force color format: > > > + * This property is used by userspace to change the used color format. > > > When > > > + * used the driver will use the selected format if valid for the > > > hardware, > > > > All properties are always "used", they just can have different values. > > You probably want to talk about the auto mode here. > > Maybe we can say something like: If userspace does not set the > property or if it is explicitly set to zero, the driver will select > the appropriate color format based on other constraints. The property can be in any state without involvement from user space. Don't talk about setting it, talk about the state it is in: When the color format is auto, the driver will select a format. > > > > > + * sink, and current resolution and refresh rate combination. Drivers > > > to > > > > If valid? So when a value is not actually supported user space can still > > set it? What happens then? How should user space figure out if the > > driver and the sink support the format? > > The kernel does not expose this property unless it's implemented in the > driver. If the driver simply doesn't support *one format*, the enum value for that format should not be exposed, period. This isn't about the property on its own. > This was originally "preferred color format". Perhaps the > documentation should better reflect that it is now a mandatory > constraint which fails the modeset if not satisfied. That would definitely help. > > > > For the Colorspace prop, the kernel just exposes all formats it supports > > (independent of the sink) and then makes it the job of user space to > > figure out if the sink supports it. > > > > The same could be done here. Property value is exposed if the driver > > supports it in general, commits can fail if the driver can't support it > > for a specific commit because e.g. the resolution or refresh rate. User > > space must look at the EDID/DisplayID/mode to figure out the supported > > format for the sink. > > Yes, we can make it possible for userspace to discover which modes are > supported by the monitor, but there are other constraints that need to > be satisfied. This was discussed in the previous revision. I mean, yes, that's what I said. User space would then only be responsible for checking the sink capabilities and the atomic check would take into account other (non-sink) constraints. > In any case, these things can be added later and need not be a part of > this change set. No, this is the contract between the kernel and user space and has to be figured out before we can merge new uAPI. > > [...] > > Regards, > Andri >
Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace
On Mon, Jan 15, 2024 at 04:05:52PM +, Andri Yngvason wrote:
> From: Werner Sembach
>
> Add a new general drm property "force color format" which can be used
> by userspace to tell the graphics driver which color format to use.
I don't like the "force" in the name. This just selects the color
format, let's just call it "color format" then.
> Possible options are:
> - auto (default/current behaviour)
> - rgb
> - ycbcr444
> - ycbcr422 (supported by neither amdgpu or i915)
> - ycbcr420
>
> In theory the auto option should choose the best available option for the
> current setup, but because of bad internal conversion some monitors look
> better with rgb and some with ycbcr444.
>
> Also, because of bad shielded connectors and/or cables, it might be
> preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
> for a signal that is less susceptible to interference.
>
> In the future, automatic color calibration for screens might also depend on
> this option being available.
>
> Signed-off-by: Werner Sembach
> Signed-off-by: Andri Yngvason
> Tested-by: Andri Yngvason
> ---
>
> Changes in v2:
> - Renamed to "force color format" from "preferred color format"
> - Removed Reported-by pointing to invalid email address
>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 48 +
> include/drm/drm_connector.h | 16 ++
> 4 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39ef0a6addeba..1dabd164c4f09 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -707,6 +707,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->max_requested_bpc !=
> new_connector_state->max_requested_bpc)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->force_color_format !=
> + new_connector_state->force_color_format)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d49..e45949bf4615f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -776,6 +776,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->max_requested_bpc = val;
> } else if (property == connector->privacy_screen_sw_state_property) {
> state->privacy_screen_sw_state = val;
> + } else if (property == connector->force_color_format_property) {
> + state->force_color_format = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -859,6 +861,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->max_requested_bpc;
> } else if (property == connector->privacy_screen_sw_state_property) {
> *val = state->privacy_screen_sw_state;
> + } else if (property == connector->force_color_format_property) {
> + *val = state->force_color_format;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae9..e0535e58b4535 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> };
>
> +static const struct drm_prop_enum_list drm_force_color_format_enum_list[] = {
> + { 0, "auto" },
> + { DRM_COLOR_FORMAT_RGB444, "rgb" },
> + { DRM_COLOR_FORMAT_YCBCR444, "ycbcr444" },
> + { DRM_COLOR_FORMAT_YCBCR422, "ycbcr422" },
> + { DRM_COLOR_FORMAT_YCBCR420, "ycbcr420" },
> +};
> +
> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>drm_dp_subconnector_enum_list)
>
> @@ -1396,6 +1404,15 @@ static const u32 dp_colorspaces =
> * drm_connector_attach_max_bpc_property() to create and attach the
> * property to the connector during initialization.
> *
> + * force color format:
> + * This property is used by userspace to change the used color format. When
> + * used the driver will use the selected format if valid for the hardware,
All properties are always "used", they just can have different values.
Re: [PATCH v2 0/7] Add YUV formats to VKMS
On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote: > This patchset aims to add support for additional buffer YUV formats. > More specifically, it adds support to: > > Semi-planar formats: > > - NV12 > - NV16 > - NV24 > - NV21 > - NV61 > - NV42 > > Planar formats: > > - YUV440 > - YUV422 > - YUV444 > - YVU440 > - YVU422 > - YVU444 > > These formats have more than one plane, and most have chroma > subsampling. These properties don't have support on VKMS, so I had to > work on this before. > > To ensure that the conversions from YUV to RGB are working, I wrote a > KUnit test. As the work from Harry on creating KUnit tests on VKMS[1] is > not yet merged, I took the setup part (Kconfig entry and .kunitfile) > from it. > > Furthermore, I couldn't find any sources with the conversion matrices, > so I had to work out the values myself based on the ITU papers[2][3][4]. > So, I'm not 100% sure if the values are accurate. I'd appreciate some > input if anyone has more knowledge in this area. H.273 CICP [1] has concise descriptions of the required values for most widely used formats and the colour python framework [2] also can be used to quickly get to the desired information most of the time. [1]: https://www.itu.int/rec/T-REC-H.273 [2]: https://www.colour-science.org/ > Also, I used two IGT tests to check if the formats were having a correct > conversion (all with the --extended flag): > > - kms_plane@pixel_format > - kms_plane@pixel_format_source_clamping. > > The nonsubsampled formats don't have support on IGT, so I sent a patch > fixing this[5]. > > Currently, this patchset does not add those formats to the writeback, as > it would require a rewrite of how the conversions are done (similar to > what was done on a previous patch[6]). So, I would like to review this > patchset before I start the work on this other part. > > [1]: > https://lore.kernel.org/all/20231108163647.106853-5-harry.wentl...@amd.com/ > [2]: https://www.itu.int/rec/R-REC-BT.601-7-201103-I/en > [3]: https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en > [4]: https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en > [5]: https://lists.freedesktop.org/archives/igt-dev/2024-January/066937.html > [6]: > https://lore.kernel.org/dri-devel/20230414135151.75975-2-mca...@igalia.com/ > > Signed-off-by: Arthur Grillo > --- > Changes in v2: > - Use EXPORT_SYMBOL_IF_KUNIT instead of including the .c test > file (Maxime) > - Link to v1: > https://lore.kernel.org/r/20240105-vkms-yuv-v1-0-34c4cd345...@riseup.net > > --- > Arthur Grillo (7): > drm/vkms: Use drm_frame directly > drm/vkms: Add support for multy-planar framebuffers > drm/vkms: Add range and encoding properties to pixel_read function > drm/vkms: Add chroma subsampling > drm/vkms: Add YUV support > drm/vkms: Drop YUV formats TODO > drm/vkms: Create KUnit tests for YUV conversions > > Documentation/gpu/vkms.rst| 3 +- > drivers/gpu/drm/vkms/Kconfig | 15 ++ > drivers/gpu/drm/vkms/Makefile | 1 + > drivers/gpu/drm/vkms/tests/.kunitconfig | 4 + > drivers/gpu/drm/vkms/tests/Makefile | 3 + > drivers/gpu/drm/vkms/tests/vkms_format_test.c | 156 > drivers/gpu/drm/vkms/vkms_drv.h | 6 +- > drivers/gpu/drm/vkms/vkms_formats.c | 247 > ++ > drivers/gpu/drm/vkms/vkms_formats.h | 9 + > drivers/gpu/drm/vkms/vkms_plane.c | 26 ++- > drivers/gpu/drm/vkms/vkms_writeback.c | 5 - > 11 files changed, 426 insertions(+), 49 deletions(-) > --- > base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f > change-id: 20231226-vkms-yuv-6f7859f32df8 > > Best regards, > -- > Arthur Grillo >
Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace
On Thu, Jan 11, 2024 at 05:17:46PM +, Andri Yngvason wrote: > mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone : > > > > > > This thing here works entirely differently, and I think we need somewhat > > > new semantics for this: > > > > > > - I agree it should be read-only for userspace, so immutable sounds right. > > > > > > - But I also agree with Daniel Stone that this should be tied more > > > directly to the modeset state. > > > > > > So I think the better approach would be to put the output type into > > > drm_connector_state, require that drivers compute it in their > > > ->atomic_check code (which in the future would allow us to report it out > > > for TEST_ONLY commits too), and so guarantee that the value is updated > > > right after the kms ioctl returns (and not somewhen later for non-blocking > > > commits). > > > > That's exactly the point. Whether userspace gets an explicit > > notification or it has to 'know' when to read isn't much of an issue - > > just as long as it's well defined. I think the suggestion of 'do it in > > atomic_check and then it's guaranteed to be readable when the commit > > completes' is a good one. > > > > I do still have some reservations - for instance, why do we have the > > fallback to auto when userspace has explicitly requested a certain > > type? - but they may have been covered previously. > > > > We discussed this further on IRC and this is summary of that discussion: > > Sima proposed a new type of property that can be used to git feedback to > userspace after atomic ioctl. The user supplies a list of output properties > that they want to query and the kernel fills it in before returning from the > ioctl. This would help to get some information about why things failed > during TEST_ONLY. > > Emersion raised the point that you might not know how much memory is needed > beforehand for the returned properties, to which sima replied: blob > property. There was some discussion about how that makes it possible to leak > kernel memory, especially if userspace does not know about a new property > blob. Emersion pointed out that userspace should only request properties > that it understands and pq agreed. > > Emersion asked how the user should inform the kernel that it's done with the > blob, to which sima replied: DRM_IOCTL_MODE_DESTROYPROPBLOB. Sima also > mentioned using some sort of weak reference garbage collection scheme for > properties and there was some further discussion, but I'm not sure there was > any conclusion. > > I asked if it made sense to add color format capabilities to the mode info > struct, but the conclusion was that it wouldn't really be useful because we > need TEST_ONLY anyway to see if the color format setting is compatible with > other settings. > > I asked again if we should drop the "active color format" property as it > seems to be more trouble than it's worth for now. pq mentioned that there > are 2 separate use cases (in his words): > - People playing with setting UI would like to know what "auto" would result > in, but that's just nice to have > - The other use case is the flicker-free boot into known configuration He > went on to point out that the main problem with "auto" is that any modeset > could make the driver decide differently. This means that we cannot fully > rely on the previously set property. > > However, leaving out "active color property" did not put us in a worse > situation than before, so the conclusion was that we should leave it out for > now. For GUI selectors, the current TEST_ONLY should be good enough, and all > the fancy stuff discussed previously isn't needed for now. > > To summarise the summary: this means that we will drop the "active > color format" property and rename the "preferred color format" > property to "force color format" or just "color format" and failing to > satisfy that constraint will fail the modeset rather than falling back > to the "auto" behaviour. That's a good idea. Anything else won't work with the new color pipeline API anyways because user space will be responsible for setting up the color pipeline API in a way so that the monitor will receive the correctly encoded data. > Cheers, > Andri >
Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > The i915 driver has a property to force the RGB range of an HDMI output.
> > The vc4 driver then implemented the same property with the same
> > semantics. KWin has support for it, and a PR for mutter is also there to
> > support it.
> >
> > Both drivers implementing the same property with the same semantics,
> > plus the userspace having support for it, is proof enough that it's
> > pretty much a de-facto standard now and we can provide helpers for it.
> >
> > Let's plumb it into the newly created HDMI connector.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/gpu/kms-properties.csv | 1 -
> > drivers/gpu/drm/drm_atomic.c | 5 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 17 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > drivers/gpu/drm/drm_connector.c| 76 +
> > drivers/gpu/drm/tests/Makefile | 1 +
> > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 376
> > +
> > drivers/gpu/drm/tests/drm_connector_test.c | 117 ++-
> > drivers/gpu/drm/tests/drm_kunit_edid.h | 106 ++
> > include/drm/drm_connector.h| 36 ++
> > 10 files changed, 737 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/gpu/kms-properties.csv
> > b/Documentation/gpu/kms-properties.csv
> > index 0f9590834829..caef14c532d4 100644
> > --- a/Documentation/gpu/kms-properties.csv
> > +++ b/Documentation/gpu/kms-properties.csv
> > @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> > Values,Object attached,De
> > ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > Max=0x",Connector,property to suggest an X offset for a connector
> > ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to
> > suggest an Y offset for a connector
> > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > }",Connector,TDB
> > -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> > ""Limited 16:235"" }",Connector,"When this property is set to Limited
> > 16:235 and CTM is set, the hardware will be programmed with the result of
> > the multiplication of CTM by the limited range matrix to ensure the pixels
> > normally in the range 0..1.0 are remapped to the range 16/255..235/255."
> > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> > etc.",Connector,TBD
> > ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index c31fc0b48c31..1465a7f09a0b 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1142,6 +1142,11 @@ static void drm_atomic_connector_print_state(struct
> > drm_printer *p,
> > drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
> > drm_printf(p, "\tcolorspace=%s\n",
> > drm_get_colorspace_name(state->colorspace));
> >
> > + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
> > + drm_printf(p, "\tbroadcast_rgb=%s\n",
> > +
> > drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> > +
> > if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> > if (state->writeback_job && state->writeback_job->fb)
> > drm_printf(p, "\tfb=%d\n",
> > state->writeback_job->fb->base.id);
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index e69c0cc1c6da..10d98620a358 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_stat
Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
> support it.
>
> Both drivers implementing the same property with the same semantics,
> plus the userspace having support for it, is proof enough that it's
> pretty much a de-facto standard now and we can provide helpers for it.
>
> Let's plumb it into the newly created HDMI connector.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/gpu/kms-properties.csv | 1 -
> drivers/gpu/drm/drm_atomic.c | 5 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 17 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> drivers/gpu/drm/drm_connector.c| 76 +
> drivers/gpu/drm/tests/Makefile | 1 +
> .../gpu/drm/tests/drm_atomic_state_helper_test.c | 376
> +
> drivers/gpu/drm/tests/drm_connector_test.c | 117 ++-
> drivers/gpu/drm/tests/drm_kunit_edid.h | 106 ++
> include/drm/drm_connector.h| 36 ++
> 10 files changed, 737 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv
> index 0f9590834829..caef14c532d4 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> Values,Object attached,De
> ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property
> to suggest an X offset for a connector
> ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest
> an Y offset for a connector
> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> }",Connector,TDB
> -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
> set, the hardware will be programmed with the result of the multiplication of
> CTM by the limited range matrix to ensure the pixels normally in the range
> 0..1.0 are remapped to the range 16/255..235/255."
> ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> etc.",Connector,TBD
> ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c31fc0b48c31..1465a7f09a0b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1142,6 +1142,11 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
> drm_printf(p, "\tcolorspace=%s\n",
> drm_get_colorspace_name(state->colorspace));
>
> + if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
> + drm_printf(p, "\tbroadcast_rgb=%s\n",
> +
> drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> +
> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> if (state->writeback_job && state->writeback_job->fb)
> drm_printf(p, "\tfb=%d\n",
> state->writeback_job->fb->base.id);
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index e69c0cc1c6da..10d98620a358 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -583,6 +583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
> void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector
> *connector,
> struct drm_connector_state
> *new_state)
> {
> + new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
>
> @@ -650,6 +651,22 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
> int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
> struct drm_atomic_state *state)
> {
> + struct drm_connector_state *old_state =
> + drm_atomic_get_old_connector_state(state, connector);
> + struct drm_connector_state *new_state =
> + drm_atomic_get_new_connector_state(state, connector);
> +
> + if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
> + struct drm_crtc *crtc = new_state->crtc;
> + struct drm_crtc_state *crtc_state;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
>
Re: [RFC PATCH 2/2] vc4: introduce DMA-BUF heap
On Thu, Nov 09, 2023 at 06:38:20PM +, Dave Stevenson wrote: > Hi Simon > > On Thu, 9 Nov 2023 at 17:46, Simon Ser wrote: > > > > On Thursday, November 9th, 2023 at 16:42, Dave Stevenson > > wrote: > > > > > > > - What would be a good name for the heap? "vc4" is maybe a bit naive > > > > > and > > > > > not precise enough. Something with "cma"? Do we need to plan a > > > > > naming > > > > > scheme to accomodate for multiple vc4 devices? > > > > > > > > That's a general issue though that happens with pretty much all devices > > > > with a separate node for modesetting and rendering, so I don't think > > > > addressing it only for vc4 make sense, we should make it generic. > > > > > > > > So maybe something like "scanout"? > > > > > > > > One thing we need to consider too is that the Pi5 will have multiple > > > > display nodes (4(?) iirc) with different capabilities, vc4 being only > > > > one of them. This will impact that solution too. > > > > > > It does need to scale. > > > > > > Pi5 adds 4 additional DRM devices (2xDSI, 1xDPI, and 1xComposite > > > Video), and just this last week I've been running Wayfire with TinyDRM > > > drivers for SPI displays and UDL (DisplayLink) outputs as well. > > > Presumably all of those drivers need to have appropriate hooks added > > > so they each expose a dma-heap to enable scanout buffers to be > > > allocated. > > > > I'm not sure this makes sense necessarily for all of these devices. For vc4 > > and > > the 4 additional RPi 5 DRM devices, probably. For the rest, e.g. UDL, I'm > > not > > sure it makes sense to expose scanout memory allocation via DMA heaps: AFAIK > > UDL needs CPU access to the buffers, it can't "scanout", and thus directly > > rendering via v3d to a "scanout-capable" buffer doesn't make sense. There > > will > > be a copy (CPU download) either way, and allocating via v3d wouldn't make a > > difference. > > You as a developer may know that UDL is going to need CPU access, but > how does a generic userspace app know? Is it a case of falling back to > allocating via the renderer if there is no suitably named heap? If we're going with the idea of using sysfs to link a device to a heap (which I think we should), then those devices all should be linked to the system memory heap, no? > > > Can we add another function pointer to the struct drm_driver (or > > > similar) to do the allocation, and move the actual dmabuf handling > > > code into the core? > > > > Do you mean that the new logic introduced in this patch should be in DRM > > core > > to allow other drivers to more easily re-use it? Or do you mean something > > else? > > Yes, make it easy to reuse between drivers. > > > Indeed, there is nothing vc4-specific in this patch, the only requirement is > > that the driver uses drm_gem_dma_helper. So this code could be moved into > > (or > > alongside) that helper in DRM core. However, maybe it would be best to wait > > to > > have a second user for this infrastructure before we move into core. > > Upstreaming of the DSI / DPI / composite drivers for Pi5 should only > be a few months away, and they can all directly scanout. > > I expect the Rockchip platforms to also fall into the same category as > the Pi, with Mali as the 3D IP, and the VOP block as the scanout > engine. Have I missed some detail that means that they aren't a second > user for this? > > > > > > - Need to add !vc5 support. > > > > > > > > If by !vc5 you mean RPi0-3, then it's probably not needed there at all > > > > since it has a single node for both modesetting and rendering? > > > > > > That is true, but potentially vc4 could be rendering for scanout via UDL > > > or SPI. > > > Is it easier to always have the dma-heap allocator for every DRM card > > > rather than making userspace mix and match depending on whether it is > > > all in one vs split? > > > > I don't think it's realistic to try to always make DMA heaps available for > > each > > and every driver which might need it from day one. It's too big of a task. > > And > > it's an even bigger task to try to design a fully generic heap compatibility > > uAPI from day one. I'd much rather add the heaps one by one, if and when we > > figure that it makes sense, and incrementally work our way through. > > Is it really that massive a task? We have the dma heap UAPI for > handling the allocations, so what new UAPI is required? > > If it's a new function pointer in struct drm_driver, then the heap is > only created by the core if that function is defined using the driver > name. The function returns a struct dma_buf *. > Any driver using drm_gem_dma_helper can use the new helper function > that is basically your vc4_dma_heap_allocate. The "if > (WARN_ON_ONCE(!vc4->is_vc5))" could be handled by not setting the > function pointer on those platforms. > > Sorry, I feel I must be missing some critical piece of information here. > > Dave >
Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote: > > On Tue, 7 Nov 2023 11:58:26 -0500 > Harry Wentland wrote: > > > On 2023-11-07 04:55, Pekka Paalanen wrote: > > > On Mon, 6 Nov 2023 11:19:27 -0500 > > > Harry Wentland wrote: > > > > > >> On 2023-10-20 06:36, Pekka Paalanen wrote: > > >>> On Thu, 19 Oct 2023 10:56:40 -0400 > > >>> Harry Wentland wrote: > > >>> > > On 2023-10-10 12:13, Melissa Wen wrote: > > > O 09/08, Harry Wentland wrote: > > >> Signed-off-by: Harry Wentland > > >>> > > >>> ... > > >>> > > > Also, with this new plane API in place, I understand that we will > > > already need think on how to deal with the mixing between old drm > > > color > > > properties (color encoding and color range) and these new way of > > > setting > > > plane color properties. IIUC, Pekka asked a related question about it > > > when talking about CRTC automatic RGB->YUV (?) > > > > > > > We'll still need to confirm whether we'll want to deprecate these > > existing properties. If we do that we'd want a client prop. Things > > should still work without deprecating them, if drivers just pick up > > after the initial encoding and range CSC. > > > > But realistically it might be better to deprecate them and turn them > > into explicit colorops. > > >>> > > >>> The existing properties would need to be explicitly reflected in the > > >>> new pipelines anyway, otherwise there would always be doubt at which > > >>> point of a pipeline the old properties apply, and they might even > > >>> need to change positions between pipelines. > > >>> > > >>> I think it is simply easier to just hide all old color related > > >>> properties when userspace sets the client-cap to enable pipelines. The > > >>> problem is to make sure to hide all old properties on all drivers that > > >>> support the client-cap. > > >>> > > >>> As a pipeline must be complete (describe everything that happens to > > >>> pixel values), it's going to be a flag day per driver. > > >>> > > >>> Btw. the plane FB YUV->RGB conversion needs a colorop in every pipeline > > >>> as well. Maybe it's purely informative and non-configurable, keyed by > > >>> FB pixel format, but still. > > >>> > > >>> We also need a colorop to represent sample filtering, e.g. bilinear, > > >>> like I think Sebastian may have mentioned in the past. Everything > > >>> before the sample filter happens "per tap" as Joshua Ashton put it, and > > >>> everything after it happens on the sample that was computed as a > > >>> weighted average of the filter tap inputs (texels). > > >>> > > >>> There could be colorops other than sample filtering that operate on > > >>> more than one sample at a time, like blur or sharpness. There could > > >>> even be colorops that change the image size like adding padding that > > >>> the following colorop hardware requires, and then yet another colorop > > >>> that clips that padding away. For an example, see > > >>> https://lists.freedesktop.org/archives/dri-devel/2023-October/427015.html > > >>> > > >>> If that padding and its color can affect the pipeline results of the > > >>> pixels near the padding (e.g. some convolution is applied with them, > > >>> which may be the reason why padding is necessary to begin with), then > > >>> it would be best to model it. > > >>> > > >> > > >> I hear you but I'm also somewhat shying away from defining this at this > > >> point. > > > > > > Would you define them before the new UAPI is released though? > > > > > > I agree there is no need to have them in this patch series, but I think > > > we'd hit the below problems if the UAPI is released without them. > > > > > >> There are already too many things that need to happen and I will focus > > >> on the > > >> actual color blocks (LUTs, matrices) first. We'll always be able to add > > >> a new > > >> (read-only) colorop type to define scaling and tap behavior at any point > > >> and > > >> a client is free to ignore a color pipeline if it doesn't find any > > >> tap/scale > > >> info in it. > > > > > > How would userspace know to look for tap/scale info, if there is no > > > upstream definition even on paper? > > > > > > > So far OSes did not care about this. Whether that's good or bad is > > something everyone can answer for themselves. > > > > If you write a compositor and really need this you can just ignore > > color pipelines that don't have this, i.e., you'll probably want > > to wait with implementing color pipeline support until you have what > > you need from DRM/KMS. > > > > This is not to say I don't want to have support for Weston. But I'm > > wondering if we place too much importance on getting every little > > thing figured out whereas we could be making forward progress and > > address more aspects of a color pipeline in the future. There is a > > reason gamescope has made a huge difference in driving the color > > management work forward. > > > > > And the
Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Tue, Nov 07, 2023 at 11:52:11AM -0500, Harry Wentland wrote: > > > On 2023-10-26 13:30, Sebastian Wick wrote: > > On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote: > >> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT) > >> Alex Goins wrote: > >> > >>> Thank you Harry and all other contributors for your work on this. > >>> Responses > >>> inline - > >>> > >>> On Mon, 23 Oct 2023, Pekka Paalanen wrote: > >>> > >>>> On Fri, 20 Oct 2023 11:23:28 -0400 > >>>> Harry Wentland wrote: > >>>> > >>>>> On 2023-10-20 10:57, Pekka Paalanen wrote: > >>>>>> On Fri, 20 Oct 2023 16:22:56 +0200 > >>>>>> Sebastian Wick wrote: > >>>>>> > >>>>>>> Thanks for continuing to work on this! > >>>>>>> > >>>>>>> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote: > > snip > > >> > >>>>>> I think we also need a definition of "informational". > >>>>>> > >>>>>> Counter-example 1: a colorop that represents a non-configurable > >>>>> > >>>>> Not sure what's "counter" for these examples? > >>>>> > >>>>>> YUV<->RGB conversion. Maybe it determines its operation from FB pixel > >>>>>> format. It cannot be set to bypass, it cannot be configured, and it > >>>>>> will alter color values. > >>> > >>> Would it be reasonable to expose this is a 3x4 matrix with a read-only > >>> blob and > >>> no BYPASS property? I already brought up a similar idea at the XDC HDR > >>> Workshop > >>> based on the principle that read-only blobs could be used to express some > >>> static > >>> pipeline elements without the need to define a new type, but got mixed > >>> opinions. > >>> I think this demonstrates the principle further, as clients could detect > >>> this > >>> programmatically instead of having to special-case the informational > >>> element. > >> > > > > I'm all for exposing fixed color ops but I suspect that most of those > > follow some standard and in those cases instead of exposing the matrix > > values one should prefer to expose a named matrix (e.g. BT.601, BT.709, > > BT.2020). > > > > Agreed. > > > As a general rule: always expose the highest level description. Going > > from a name to exact values is trivial, going from values to a name is > > much harder. > > > >> If the blob depends on the pixel format (i.e. the driver automatically > >> chooses a different blob per pixel format), then I think we would need > >> to expose all the blobs and how they correspond to pixel formats. > >> Otherwise ok, I guess. > >> > >> However, do we want or need to make a color pipeline or colorop > >> conditional on pixel formats? For example, if you use a YUV 4:2:0 type > >> of pixel format, then you must use this pipeline and not any other. Or > >> floating-point type of pixel format. I did not anticipate this before, > >> I assumed that all color pipelines and colorops are independent of the > >> framebuffer pixel format. A specific colorop might have a property that > >> needs to agree with the framebuffer pixel format, but I didn't expect > >> further limitations. > > > > We could simply fail commits when the pipeline and pixel format don't > > work together. We'll probably need some kind of ingress no-op node > > anyway and maybe could list pixel formats there if required to make it > > easier to find a working configuration. > > > > The problem with failing commits is that user-space has no idea why it > failed. If this means that userspace falls back to SW composition for > NV12 and P010 it would avoid HW offloading in one of the most important > use-cases on AMD HW for power-saving purposes. Exposing which pixel formats work with a pipeline should be uncontroversial, and so should be an informative scaler op. Both can be added without a problem at a later time, so let's not make any of that mandatory for the first version. One step after the other. > > snip > > >>> Despite being programmable, the LUTs are updated in a manner that is less > >>> efficient as compared to e.g. the non-static "degamma" LUT. Would it be >
Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Fri, Oct 27, 2023 at 10:59:25AM +0200, Michel Dänzer wrote: > On 10/26/23 21:25, Alex Goins wrote: > > On Thu, 26 Oct 2023, Sebastian Wick wrote: > >> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote: > >>> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT) > >>> Alex Goins wrote: > >>> > >>>> Despite being programmable, the LUTs are updated in a manner that is less > >>>> efficient as compared to e.g. the non-static "degamma" LUT. Would it be > >>>> helpful > >>>> if there was some way to tag operations according to their performance, > >>>> for example so that clients can prefer a high performance one when they > >>>> intend to do an animated transition? I recall from the XDC HDR workshop > >>>> that this is also an issue with AMD's 3DLUT, where updates can be too > >>>> slow to animate. > >>> > >>> I can certainly see such information being useful, but then we need to > >>> somehow quantize the performance. > > > > Right, which wouldn't even necessarily be universal, could depend on the > > given > > host, GPU, etc. It could just be a relative performance indication, to give > > an > > order of preference. That wouldn't tell you if it can or can't be animated, > > but > > when choosing between two LUTs to animate you could prefer the higher > > performance one. > > > >>> > >>> What I was left puzzled about after the XDC workshop is that is it > >>> possible to pre-load configurations in the background (slow), and then > >>> quickly switch between them? Hardware-wise I mean. > > > > This works fine for our "fast" LUTs, you just point them to a surface in > > video > > memory and they flip to it. You could keep multiple surfaces around and flip > > between them without having to reprogram them in software. We can easily do > > that > > with enumerated curves, populating them when the driver initializes instead > > of > > waiting for the client to request them. You can even point multiple hardware > > LUTs to the same video memory surface, if they need the same curve. > > > >> > >> We could define that pipelines with a lower ID are to be preferred over > >> higher IDs. > > > > Sure, but this isn't just an issue with a pipeline as a whole, but the > > individual elements within it and how to use them in a given context. > > > >> > >> The issue is that if programming a pipeline becomes too slow to be > >> useful it probably should just not be made available to user space. > > > > It's not that programming the pipeline is overall too slow. The LUTs we have > > that are relatively slow to program are meant to be set infrequently, or > > even > > just once, to allow the scaler and tone mapping operator to operate in fixed > > point PQ space. You might still want the tone mapper, so you would choose a > > pipeline that includes them, but when it comes to e.g. animating a night > > light, > > you would want to choose a different LUT for that purpose. > > > >> > >> The prepare-commit idea for blob properties would help to make the > >> pipelines usable again, but until then it's probably a good idea to just > >> not expose those pipelines. > > > > The prepare-commit idea actually wouldn't work for these LUTs, because they > > are > > programmed using methods instead of pointing them to a surface. I'm > > actually not > > sure how slow it actually is, would need to benchmark it. I think not > > exposing > > them at all would be overkill, since it would mean you can't use the > > preblending > > scaler or tonemapper, and animation isn't necessary for that. > > > > The AMD 3DLUT is another example of a LUT that is slow to update, and it > > would > > obviously be a major loss if that wasn't exposed. There just needs to be > > some > > way for clients to know if they are going to kill performance by trying to > > change it every frame. > > Might a first step be to require the ALLOW_MODESET flag to be set when > changing the values for a colorop which is too slow to be updated per refresh > cycle? > > This would tell the compositor: You can use this colorop, but you can't > change its values on the fly. I argued before that changing any color op to passthrough should never require ALLOW_MODESET and while this is really hard to guarantee from a driver perspective I still believe that
Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> Alex Goins wrote:
>
> > Thank you Harry and all other contributors for your work on this. Responses
> > inline -
> >
> > On Mon, 23 Oct 2023, Pekka Paalanen wrote:
> >
> > > On Fri, 20 Oct 2023 11:23:28 -0400
> > > Harry Wentland wrote:
> > >
> > > > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > > > Sebastian Wick wrote:
> > > > >
> > > > >> Thanks for continuing to work on this!
> > > > >>
> > > > >> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:
> > > > >>> v2:
> > > > >>> - Update colorop visualizations to match reality (Sebastian, Alex
> > > > >>> Hung)
> > > > >>> - Updated wording (Pekka)
> > > > >>> - Change BYPASS wording to make it non-mandatory (Sebastian)
> > > > >>> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane
> > > > >>> Property
> > > > >>>section (Pekka)
> > > > >>> - Use PQ EOTF instead of its inverse in Pipeline Programming
> > > > >>> example (Melissa)
> > > > >>> - Add "Driver Implementer's Guide" section (Pekka)
> > > > >>> - Add "Driver Forward/Backward Compatibility" section (Sebastian,
> > > > >>> Pekka)
> > > > >
> > > > > ...
> > > > >
> > > > >>> +An example of a drm_colorop object might look like one of these::
> > > > >>> +
> > > > >>> +/* 1D enumerated curve */
> > > > >>> +Color operation 42
> > > > >>> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3
> > > > >>> matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
> > > > >>> +├─ "BYPASS": bool {true, false}
> > > > >>> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ
> > > > >>> EOTF, PQ inverse EOTF, …}
> > > > >>> +└─ "NEXT": immutable color operation ID = 43
> >
> > I know these are just examples, but I would also like to suggest the
> > possibility
> > of an "identity" CURVE_1D_TYPE. BYPASS = true might get different results
> > compared to setting an identity in some cases depending on the hardware. See
> > below for more on this, RE: implicit format conversions.
> >
> > Although NVIDIA hardware doesn't use a ROM for enumerated curves, it came
> > up in
> > offline discussions that it would nonetheless be helpful to expose
> > enumerated
> > curves in order to hide the vendor-specific complexities of programming
> > segmented LUTs from clients. In that case, we would simply refer to the
> > enumerated curve when calculating/choosing segmented LUT entries.
>
> That's a good idea.
>
> > Another thing that came up in offline discussions is that we could use
> > multiple
> > color operations to program a single operation in hardware. As I understand
> > it,
> > AMD has a ROM-defined LUT, followed by a custom 4K entry LUT, followed by an
> > "HDR Multiplier". On NVIDIA we don't have these as separate hardware
> > stages, but
> > we could combine them into a singular LUT in software, such that you can
> > combine
> > e.g. segmented PQ EOTF with night light. One caveat is that you will lose
> > precision from the custom LUT where it overlaps with the linear section of
> > the
> > enumerated curve, but that is unavoidable and shouldn't be an issue in most
> > use-cases.
>
> Indeed.
>
> > Actually, the current examples in the proposal don't include a multiplier
> > color
> > op, which might be useful. For AMD as above, but also for NVIDIA as the
> > following issue arises:
> >
> > As discussed further below, the NVIDIA "degamma" LUT performs an implicit
> > fixed
> > point to FP16 conversion. In that conversion, what fixed point 0x
> > maps
> > to in floating point varies depending on the source content. If it's SDR
> > content, we want the max value in FP16 to be 1.0 (80 nits), subject to a
> > potential boost multiplier if we want SDR content to be brighter. If it's
> > HDR PQ
> &
Re: [PATCH v3 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB range
Honestly, the less time people spend on this property the better. Lift the Intel one into core and be done with it. We'll hopefully be able to remove it in the not-to-distant future with the new color pipeline API and adding a new property which only sets the connector metadata instead of influencing the color pipeline as well. On Mon, Oct 23, 2023 at 4:58 PM Maxime Ripard wrote: > > Hi Hans, > > On Thu, Oct 19, 2023 at 10:26:40AM +0200, Hans Verkuil wrote: > > Hi Maxime, > > > > On 19/10/2023 10:02, Maxime Ripard wrote: > > > Hi, > > > > > > On Wed, Oct 11, 2023 at 03:23:18PM +0200, Daniel Vetter wrote: > > >> On Mon, 6 Mar 2023 at 11:49, Maxime Ripard wrote: > > >>> > > >>> From: Dave Stevenson > > >>> > > >>> Copy Intel's "Broadcast RGB" property semantics to add manual override > > >>> of the HDMI pixel range for monitors that don't abide by the content > > >>> of the AVI Infoframe. > > >>> > > >>> Signed-off-by: Dave Stevenson > > >>> Signed-off-by: Maxime Ripard > > >> > > >> Stumbled over this grepping around, but would have been nice to lift > > >> this into drm code and document the property. It's one of the legacy > > >> ones from the table of horrors after all ... > > >> > > >> Shouldn't be an uapi problem because it's copypasted to much, just not > > >> great. > > > > > > We already discussed it on IRC, but just for the record I have a current > > > series that should address exactly that: > > > > > > https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v2-3-17932dadd...@kernel.org/ > > > > > > Maxime > > > > I've pasted a snippet from that patch below for a quick review: > > > > > /** > > > * DOC: HDMI connector properties > > > * > > > + * Broadcast RGB (HDMI Specific): > > > > Full vs Limited is actually not HDMI specific, DisplayPort can signal this > > as > > well for whatever it is worth. > > Sure, what I (and the original patch I guess) meant is that it's only > ever used on HDMI connectors these days. If that ever changes, then we > can update the doc. > > > > + * Indicates the RGB Range (Full vs Limited) used. > > > > RGB Range -> RGB Quantization Range > > > > > + * > > > + * The value of this property can be one of the following: > > > + * > > > + * Automatic: > > > + * RGB Range is selected automatically based on the mode > > > + * according to the HDMI specifications. > > > + * > > > + * Full: > > > + * Full RGB Range is forced. > > > + * > > > + * Limited 16:235: > > > > It is very unfortunate that this is called "Limited 16:235" instead of just > > "Limited" > > since for color component bit depths > 8 these values are different. > > > > I have no idea if it is possible to add an alias "Limited" that you can use > > instead. > > In any case, this should document that it works just as well for higher bit > > depths, > > but with different limits. > > I had a look and it doesn't look like the property infrastructure can > deal with aliases. I'll add something in the doc > > Thanks! > Maxime
Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
Thanks for continuing to work on this! On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote: > v2: > - Update colorop visualizations to match reality (Sebastian, Alex Hung) > - Updated wording (Pekka) > - Change BYPASS wording to make it non-mandatory (Sebastian) > - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property >section (Pekka) > - Use PQ EOTF instead of its inverse in Pipeline Programming example > (Melissa) > - Add "Driver Implementer's Guide" section (Pekka) > - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) > > Signed-off-by: Harry Wentland > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Sima > Cc: Uma Shankar > Cc: Naseer Ahmed > Cc: Christopher Braga > Cc: Abhinav Kumar > Cc: Arthur Grillo > Cc: Hector Martin > Cc: Liviu Dudau > Cc: Sasha McIntosh > --- > Documentation/gpu/rfc/color_pipeline.rst | 347 +++ > 1 file changed, 347 insertions(+) > create mode 100644 Documentation/gpu/rfc/color_pipeline.rst > > diff --git a/Documentation/gpu/rfc/color_pipeline.rst > b/Documentation/gpu/rfc/color_pipeline.rst > new file mode 100644 > index ..af5f2ea29116 > --- /dev/null > +++ b/Documentation/gpu/rfc/color_pipeline.rst > @@ -0,0 +1,347 @@ > + > +Linux Color Pipeline API > + > + > +What problem are we solving? > + > + > +We would like to support pre-, and post-blending complex color > +transformations in display controller hardware in order to allow for > +HW-supported HDR use-cases, as well as to provide support to > +color-managed applications, such as video or image editors. > + > +It is possible to support an HDR output on HW supporting the Colorspace > +and HDR Metadata drm_connector properties, but that requires the > +compositor or application to render and compose the content into one > +final buffer intended for display. Doing so is costly. > + > +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other > +operations to support color transformations. These operations are often > +implemented in fixed-function HW and therefore much more power efficient than > +performing similar operations via shaders or CPU. > + > +We would like to make use of this HW functionality to support complex color > +transformations with no, or minimal CPU or shader load. > + > + > +How are other OSes solving this problem? > + > + > +The most widely supported use-cases regard HDR content, whether video or > +gaming. > + > +Most OSes will specify the source content format (color gamut, encoding > transfer > +function, and other metadata, such as max and average light levels) to a > driver. > +Drivers will then program their fixed-function HW accordingly to map from a > +source content buffer's space to a display's space. > + > +When fixed-function HW is not available the compositor will assemble a > shader to > +ask the GPU to perform the transformation from the source content format to > the > +display's format. > + > +A compositor's mapping function and a driver's mapping function are usually > +entirely separate concepts. On OSes where a HW vendor has no insight into > +closed-source compositor code such a vendor will tune their color management > +code to visually match the compositor's. On other OSes, where both mapping > +functions are open to an implementer they will ensure both mappings match. > + > +This results in mapping algorithm lock-in, meaning that no-one alone can > +experiment with or introduce new mapping algorithms and achieve > +consistent results regardless of which implementation path is taken. > + > +Why is Linux different? > +=== > + > +Unlike other OSes, where there is one compositor for one or more drivers, on > +Linux we have a many-to-many relationship. Many compositors; many drivers. > +In addition each compositor vendor or community has their own view of how > +color management should be done. This is what makes Linux so beautiful. > + > +This means that a HW vendor can now no longer tune their driver to one > +compositor, as tuning it to one could make it look fairly different from > +another compositor's color mapping. > + > +We need a better solution. > + > + > +Descriptive API > +=== >
Re: [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property
On Tue, Aug 29, 2023 at 10:48:16AM +0300, Pekka Paalanen wrote: > On Mon, 28 Aug 2023 17:05:07 -0700 > Jessica Zhang wrote: > > > Add support for pixel_source property to drm_plane and related > > documentation. In addition, force pixel_source to > > DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break > > legacy userspace. > > > > This enum property will allow user to specify a pixel source for the > > plane. Possible pixel sources will be defined in the > > drm_plane_pixel_source enum. > > > > Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the > > default value) and DRM_PLANE_PIXEL_SOURCE_NONE. > > > > Signed-off-by: Jessica Zhang > > --- > > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > > drivers/gpu/drm/drm_blend.c | 90 > > +++ > > drivers/gpu/drm/drm_plane.c | 19 +-- > > include/drm/drm_blend.h | 2 + > > include/drm/drm_plane.h | 21 > > 6 files changed, 133 insertions(+), 4 deletions(-) > > ... > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > index 6e74de833466..c3c57bae06b7 100644 > > --- a/drivers/gpu/drm/drm_blend.c > > +++ b/drivers/gpu/drm/drm_blend.c > > @@ -185,6 +185,21 @@ > > * plane does not expose the "alpha" property, then this is > > * assumed to be 1.0 > > * > > + * pixel_source: > > + * pixel_source is set up with drm_plane_create_pixel_source_property(). > > + * It is used to toggle the active source of pixel data for the plane. > > + * The plane will only display data from the set pixel_source -- any > > + * data from other sources will be ignored. > > + * > > + * Possible values: > > + * > > + * "NONE": > > + * No active pixel source. > > + * Committing with a NONE pixel source will disable the plane. > > + * > > + * "FB": > > + * Framebuffer source set by the "FB_ID" property. > > + * > > * 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). > > This UAPI: > Acked-by: Pekka Paalanen Thanks Jessica, same for me Acked-by: Sebastian Wick > > > Thanks, > pq
Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Wed, Oct 11, 2023 at 12:20 PM Pekka Paalanen wrote:
>
> On Tue, 10 Oct 2023 15:13:46 -0100
> Melissa Wen wrote:
>
> > O 09/08, Harry Wentland wrote:
> > > Signed-off-by: Harry Wentland
> > > Cc: Ville Syrjala
> > > Cc: Pekka Paalanen
> > > Cc: Simon Ser
> > > Cc: Harry Wentland
> > > Cc: Melissa Wen
> > > Cc: Jonas Ådahl
> > > Cc: Sebastian Wick
> > > Cc: Shashank Sharma
> > > Cc: Alexander Goins
> > > Cc: Joshua Ashton
> > > Cc: Michel Dänzer
> > > Cc: Aleix Pol
> > > Cc: Xaver Hugl
> > > Cc: Victoria Brekenfeld
> > > Cc: Daniel Vetter
> > > Cc: Uma Shankar
> > > Cc: Naseer Ahmed
> > > Cc: Christopher Braga
> > > ---
> > > Documentation/gpu/rfc/color_pipeline.rst | 278 +++
> > > 1 file changed, 278 insertions(+)
> > > create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> > >
> > > diff --git a/Documentation/gpu/rfc/color_pipeline.rst
> > > b/Documentation/gpu/rfc/color_pipeline.rst
> > > new file mode 100644
> > > index ..bfa4a8f12087
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/color_pipeline.rst
>
> ...
>
> > > +Color Pipeline Discovery
> > > +
> > > +
> > > +A DRM client wanting color management on a drm_plane will:
> > > +
> > > +1. Read all drm_colorop objects
> > > +2. Get the COLOR_PIPELINE property of the plane
> > > +3. iterate all COLOR_PIPELINE enum values
> > > +4. for each enum value walk the color pipeline (via the NEXT pointers)
> > > + and see if the available color operations are suitable for the
> > > + desired color management operations
> > > +
> > > +An example of chained properties to define an AMD pre-blending color
> > > +pipeline might look like this::
> >
> > Hi Harry,
> >
> > Thanks for sharing this proposal. Overall I think it's very aligned with
> > Simon's description of the generic KMS color API. I think it's a good
> > start point and we can refine over iterations. My general questions have
> > already been pointed out by Sebastian and Pekka (mainly regarding the
> > BYPASS property).
> >
> > I still have some doubts on how to fit these set of colorops with some
> > AMD corners cases as below:
> >
> > > +
> > > +Plane 10
> > > +├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
> > > +└─ "color_pipeline": enum {0, 42} = 0
> > > +Color operation 42 (input CSC)
> > > +├─ "type": enum {Bypass, Matrix} = Matrix
> > > +├─ "matrix_data": blob
> > > +└─ "next": immutable color operation ID = 43
> >
> > IIUC, for input CSC, there are currently two possiblities, or we use
> > `drm_plane_color_encoding` and `drm_plane_color range` to get
> > pre-defined coefficients or we set a custom matrix here, right? If so, I
> > think we need some kind of pre-defined matrix option?
Seems reasonable. If they are mutually exclusive you might want to
expose 2 different pipelines for it.
> > Also, with this new plane API in place, I understand that we will
> > already need think on how to deal with the mixing between old drm color
> > properties (color encoding and color range) and these new way of setting
> > plane color properties. IIUC, Pekka asked a related question about it
> > when talking about CRTC automatic RGB->YUV (?)
Indeed, good catch! I listed some of them in my proposal more than one
year ago but completely forgot about them already.
>
> I didn't realize color encoding and color range KMS plane properties
> even existed. There is even color space on rockchip!
>
> https://drmdb.emersion.fr/properties?object-type=4008636142
>
> That list has even more conflicts: DEGAMMA_MODE, EOTF, FEATURE,
> NV_INPUT_COLORSPACE, SCALING_FILTER, WATERMARK, alpha, GLOBAL_ALPHA,
> brightness, colorkey, contrast, and more. I hope most of them are
> actually from downstream drivers.
>
> I think they should be forbidden to be used together with the new
> pipeline UAPI. Mixing does not work in the long run, it would be
> undefined at what position do the old properties apply in a pipeline.
>
> Apparently, we already need a DRM client cap for the new color pipeline
> UAPI to hide these legacy things.
Agreed. We'll need one cap for planes and one in the future for CRTCs then.
>
> This is different from "CRTC automatic RGB->YUV&quo
Re: [PATCH v4 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt
On Thu, Oct 05, 2023 at 04:14:55PM -0100, Melissa Wen wrote: > Hello, > > Just another iteration for AMD driver-specific color properties. > Basically, addressing comments from the previous version. > > Recap: this series extends the current KMS color management API with AMD > driver-specific properties to enhance the color management support on > AMD Steam Deck. The key additions to the color pipeline include: Did you talk with the maintainers about this already? The last few times driver specific properties, and even kind of generic plane properties with a fixed position in the pipeline were proposed they were all NAKed. Just putting them behind a define doesn't sound great and I don't think there is any precedence for allowing this in. This is basically just more burden for upstream without any benefits for upstream. Maybe you can separate the uAPI changes from the internal improvements to land at least parts of this faster. > - plane degamma LUT and pre-defined TF; > - plane HDR multiplier; > - plane CTM 3x4; > - plane shaper LUT and pre-defined TF; > - plane 3D LUT; > - plane blend LUT and pre-defined TF; > - CRTC gamma pre-defined TF; > > You can find the AMD HW color capabilities documented here: > https://dri.freedesktop.org/docs/drm/gpu/amdgpu/display/display-manager.html#color-management-properties > > The userspace case is Gamescope[1], the compositor for SteamOS. > Gamescope has already adopted AMD driver-specific properties to > implement comprehensive color management support, including gamut > mapping, HDR rendering, SDR on HDR, HDR on SDR. Using these features in > the SteamOS 3.5[2] users can expect a significantly enhanced visual > experience. > > You can find a brief overview of the Steam Deck color pipeline here: > https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png > > Changes from: > > [RFC] > https://lore.kernel.org/dri-devel/20230423141051.702990-1-m...@igalia.com > - Remove KConfig and guard properties with `AMD_PRIVATE_COLOR`; > - Remove properties for post-blending/CRTC shaper TF+LUT and 3D LUT; > - Use color caps to improve the support of pre-defined curve; > > [v1] > https://lore.kernel.org/dri-devel/20230523221520.3115570-1-m...@igalia.com > - Replace DRM_ by AMDGPU_ prefix for transfer function (TF) enum; > - Explicitly define EOTFs and inverse EOTFs and set props accordingly; > - Document pre-defined transfer functions; > - Remove HLG transfer function from supported TFs; > - Remove misleading comments; > - Remove post-blending shaper TF+LUT and 3D LUT support; > - Move driver-specific property operations from amdgpu_display.c to > amdgpu_dm_color.c; > - Reset planes if any color props change; > - Add plane CTM 3x4 support; > - Removed two DC fixes already applied upstream; > > [v2] https://lore.kernel.org/dri-devel/20230810160314.48225-1-m...@igalia.com > - Many documentation fixes: BT.709 OETF, description of sRGB and pure > power functions, TF+1D LUT behavior; > - Rename CTM2 to CTM 3x4 and fix misleading comment about DC gamut remap; > - Squash `Linear` and `Unity` TF in `Identity`; > - Remove the `MPC gamut remap` patch already applied upstream[3]; > - Remove outdated delta segmentation fix; > - Nits/small fixes; > > [v3] https://lore.kernel.org/amd-gfx/20230925194932.1329483-1-m...@igalia.com > - Add table to describe value range in linear and non-linear forms > - Comment the PQ TF need after HDR multiplier > - Advertise the 3D LUT size as the size of a single-dimension (read-only) > - remove function to check expected size from 3DLUT caps > - cleanup comments > > It's worth noting that driver-specific properties are guarded by > `AMD_PRIVATE_COLOR`. So, finally, this is the color management API when > driver-specific properties are enabled: > > +--+ > | PLANE | > | | > | ++ | > | | AMD Degamma| | > | || | > | | EOTF | 1D LUT | | > | ++---+ | > | | | > | +v---+ | > | |AMD HDR | | > | |Multiply| | > | ++---+ | > | | | > | +v---+ | > | | AMD CTM (3x4) | | > | ++---+ | > | | | > | +v---+ | > | | AMD Shaper | | > | || | > | | inv_EOTF | | | > | | Custom 1D LUT | | > | ++---+ | > | | | > | +v---+ | > | | AMD 3D LUT | | > | | 17^3/12-bit | | > | ++---+ | > | | | > | +v---+ | > | | AMD Blend | | > | || | > | | EOTF | 1D LUT | | > | ++---+ | > | | | > ++--v-++ > || Blending || > ++--+-++ > |CRTC | | > | | | > | +---v---+ | > | | DRM Degamma | | > | |
Re: [PATCH v4 09/32] drm/amd/display: add plane 3D LUT driver-specific properties
On Thu, Oct 05, 2023 at 04:15:04PM -0100, Melissa Wen wrote:
> Add 3D LUT property for plane color transformations using a 3D lookup
> table. 3D LUT allows for highly accurate and complex color
> transformations and is suitable to adjust the balance between color
> channels. It's also more complex to manage and require more
> computational resources.
>
> Since a 3D LUT has a limited number of entries in each dimension we want
> to use them in an optimal fashion. This means using the 3D LUT in a
> colorspace that is optimized for human vision, such as sRGB, PQ, or
> another non-linear space. Therefore, userpace may need one 1D LUT
> (shaper) before it to delinearize content and another 1D LUT after 3D
> LUT (blend) to linearize content again for blending. The next patches
> add these 1D LUTs to the plane color mgmt pipeline.
>
> v3:
> - improve commit message about 3D LUT
> - describe the 3D LUT entries and size (Harry)
>
> v4:
> - advertise 3D LUT max size as the size of a single-dimension
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 18 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 14 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 23 +++
> 4 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 62044d41da75..f7adaa52c23f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -363,6 +363,24 @@ struct amdgpu_mode_info {
>* @plane_hdr_mult_property:
>*/
> struct drm_property *plane_hdr_mult_property;
> + /**
> + * @plane_lut3d_property: Plane property for color transformation using
> + * a 3D LUT (pre-blending), a three-dimensional array where each
> + * element is an RGB triplet. Each dimension has a size of the cubed
> + * root of lut3d_size. The array contains samples from the approximated
This should be "Each dimension has a size of lut3d_size" now.
> + * function. On AMD, values between samples are estimated by
> + * tetrahedral interpolation. The array is accessed with three indices,
> + * one for each input dimension (color channel), blue being the
> + * outermost dimension, red the innermost.
> + */
> + struct drm_property *plane_lut3d_property;
> + /**
> + * @plane_degamma_lut_size_property: Plane property to define the max
> + * size of 3D LUT as supported by the driver (read-only). The max size
> + * is the max size of one dimension and, therefore, the max number of
> + * entries for 3D LUT array is the 3D LUT size cubed;
> + */
> + struct drm_property *plane_lut3d_size_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index bb2ce843369d..7a2350c62cf1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -784,6 +784,11 @@ struct dm_plane_state {
>* TF is needed for any subsequent linear-to-non-linear transforms.
>*/
> __u64 hdr_mult;
> + /**
> + * @lut3d: 3D lookup table blob. The blob (if not NULL) is an array of
> + * drm_color_lut.
> + */
> + struct drm_property_blob *lut3d;
> };
>
> struct dm_crtc_state {
> @@ -869,6 +874,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector
> *connector,
>
> void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
>
> +/* 3D LUT max size is 17x17x17 (4913 entries) */
> +#define MAX_COLOR_3DLUT_SIZE 17
> +#define MAX_COLOR_3DLUT_BITDEPTH 12
> +/* 1D LUT size */
> #define MAX_COLOR_LUT_ENTRIES 4096
> /* Legacy gamm LUT users such as X doesn't like large LUT sizes */
> #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index caf49a044ab4..011f2f9ec890 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -230,6 +230,20 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
> *adev)
> return -ENOMEM;
> adev->mode_info.plane_hdr_mult_property = prop;
>
> + prop = drm_property_create(adev_to_drm(adev),
> +DRM_MODE_PROP_BLOB,
> +"AMD_PLANE_LUT3D", 0);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_lut3d_property = prop;
> +
> + prop = drm_property_create_range(adev_to_drm(adev),
> + DRM_MODE_PROP_IMMUTABLE,
> + "AMD_PLANE_LUT3D_SIZE", 0, UINT_MAX);
> + if (!prop)
> +
Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed
Hey Harry, Thank you and Simon for this great document. Really happy about it, but obviously I've got a few notes and questions inline. On Fri, Sep 08, 2023 at 11:02:26AM -0400, Harry Wentland wrote: > Signed-off-by: Harry Wentland > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Daniel Vetter > Cc: Uma Shankar > Cc: Naseer Ahmed > Cc: Christopher Braga > --- > Documentation/gpu/rfc/color_pipeline.rst | 278 +++ > 1 file changed, 278 insertions(+) > create mode 100644 Documentation/gpu/rfc/color_pipeline.rst > > diff --git a/Documentation/gpu/rfc/color_pipeline.rst > b/Documentation/gpu/rfc/color_pipeline.rst > new file mode 100644 > index ..bfa4a8f12087 > --- /dev/null > +++ b/Documentation/gpu/rfc/color_pipeline.rst > @@ -0,0 +1,278 @@ > + > +Linux Color Pipeline API > + > + > +What problem are we solving? > + > + > +We would like to support pre-, and post-blending complex color > transformations > +in order to allow for HW-supported HDR use-cases, as well as to provide > support > +to color-managed applications, such as video or image editors. > + > +While it is possible to support an HDR output on HW supporting the Colorspace > +and HDR Metadata drm_connector properties that requires the compositor or > +application to render and compose the content into one final buffer intended > for > +display. Doing so is costly. > + > +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other > +operations to support color transformations. These operations are often > +implemented in fixed-function HW and therefore much more power efficient than > +performing similar operations via shaders or CPU. > + > +We would like to make use of this HW functionality to support complex color > +transformations with no, or minimal CPU or shader load. > + > + > +How are other OSes solving this problem? > + > + > +The most widely supported use-cases regard HDR content, whether video or > +gaming. > + > +Most OSes will specify the source content format (color gamut, encoding > transfer > +function, and other metadata, such as max and average light levels) to a > driver. > +Drivers will then program their fixed-function HW accordingly to map from a > +source content buffer's space to a display's space. > + > +When fixed-function HW is not available the compositor will assemble a > shader to > +ask the GPU to perform the transformation from the source content format to > the > +display's format. > + > +A compositor's mapping function and a driver's mapping function are usually > +entirely separate concepts. On OSes where a HW vendor has no insight into > +closed-source compositor code such a vendor will tune their color management > +code to visually match the compositor's. On other OSes, where both mapping > +functions are open to an implementer they will ensure both mappings match. > + > + > +Why is Linux different? > +=== > + > +Unlike other OSes, where there is one compositor for one or more drivers, on > +Linux we have a many-to-many relationship. Many compositors; many drivers. > +In addition each compositor vendor or community has their own view of how > +color management should be done. This is what makes Linux so beautiful. > + > +This means that a HW vendor can now no longer tune their driver to one > +compositor, as tuning it to one will almost inevitably make it look very > +different from another compositor's color mapping. > + > +We need a better solution. > + > + > +Descriptive API > +=== > + > +An API that describes the source and destination colorspaces is a descriptive > +API. It describes the input and output color spaces but does not describe > +how precisely they should be mapped. Such a mapping includes many minute > +design decision that can greatly affect the look of the final result. > + > +It is not feasible to describe such mapping with enough detail to ensure the > +same result from each implementation. In fact, these mappings are a very > active > +research area. > + > + > +Prescriptive API > + > + > +A prescriptive API describes not the source and destination colorspaces. It > +instead prescribes a recipe for how to manipulate pixel values to arrive at > the > +desired o
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote: > On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > > On Mon, 4 Sep 2023 14:29:56 + > > "Shankar, Uma" wrote: > > > > > > -Original Message- > > > > From: Sebastian Wick > > > > Sent: Thursday, August 31, 2023 2:46 AM > > > > To: Shankar, Uma > > > > Cc: Harry Wentland ; intel- > > > > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; wayland- > > > > de...@lists.freedesktop.org; Ville Syrjala > > > > ; Pekka > > > > Paalanen ; Simon Ser > > > > ; > > > > Melissa Wen ; Jonas Ådahl ; Shashank > > > > Sharma ; Alexander Goins ; > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Harry Wentland > > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > > To: Shankar, Uma ; > > > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > > > > ; Pekka Paalanen > > > > > > ; Simon Ser ; > > > > > > Melissa Wen ; Jonas Ådahl ; > > > > > > Sebastian Wick ; Shashank Sharma > > > > > > ; Alexander Goins ; > > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole > > > > > > series. > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > > Introduction > > > > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > > The current drm implementation exposes only the post-blending > > > > > > > color hardware blocks. Support for pre-blending hardware is > > > > > > > missing. > > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > > will be > > > > > > > useful: > > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > > > functions. > > > > > > > b) Color Space conversion > > > > > > > c) Tone mapping > > > > > > > d) Frame buffer format conversion > > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > > f) 3D Luts > > > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > > display hardware for color processing and blending instead of > > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > > similar but you beat me to it. :) > > > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on > > > > > this so far. > > > > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address > > > > > > > the same. > > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > > suf
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > On Mon, 4 Sep 2023 14:29:56 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Sebastian Wick > > > Sent: Thursday, August 31, 2023 2:46 AM > > > To: Shankar, Uma > > > Cc: Harry Wentland ; intel- > > > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; wayland- > > > de...@lists.freedesktop.org; Ville Syrjala > > > ; Pekka > > > Paalanen ; Simon Ser ; > > > Melissa Wen ; Jonas Ådahl ; Shashank > > > Sharma ; Alexander Goins ; > > > Naseer Ahmed ; Christopher Braga > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Harry Wentland > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > To: Shankar, Uma ; > > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > > > ; Pekka Paalanen > > > > > ; Simon Ser ; > > > > > Melissa Wen ; Jonas Ådahl ; > > > > > Sebastian Wick ; Shashank Sharma > > > > > ; Alexander Goins ; > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > Introduction > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > The current drm implementation exposes only the post-blending > > > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > will be > > > > > > useful: > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > >functions. > > > > > > b) Color Space conversion > > > > > > c) Tone mapping > > > > > > d) Frame buffer format conversion > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > f) 3D Luts > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > display hardware for color processing and blending instead of > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > similar but you beat me to it. :) > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on this > > > > so far. > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the > > > > > > same. > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > suffice the use case of various HW vendors. Below are the links > > > > > > capturing the discussion so far. > > > > > > > > > > > > Intel's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > > AMD's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > > > > Hackfest conclus
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > -Original Message- > > From: Harry Wentland > > Sent: Wednesday, August 30, 2023 12:56 AM > > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > > dri- > > de...@lists.freedesktop.org > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > ; Pekka Paalanen > > ; > > Simon Ser ; Melissa Wen ; Jonas Ådahl > > ; Sebastian Wick ; Shashank > > Sharma ; Alexander Goins ; > > Naseer Ahmed ; Christopher Braga > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > +CC Naseer and Chris, FYI > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > Introduction > > > > > > > > > Modern hardwares have various color processing capabilities both at > > > pre-blending and post-blending phases in the color pipeline. > > > The current drm implementation exposes only the post-blending color > > > hardware blocks. Support for pre-blending hardware is missing. > > > There are multiple use cases where pre-blending color hardware will be > > > useful: > > > a) Linearization of input buffers encoded in various transfer > > > functions. > > > b) Color Space conversion > > > c) Tone mapping > > > d) Frame buffer format conversion > > > e) Non-linearization of buffer(apply transfer function) > > > f) 3D Luts > > > > > > and other miscellaneous color operations. > > > > > > Hence, there is a need to expose the color capabilities of the > > > hardware to user-space. This will help userspace/middleware to use > > > display hardware for color processing and blending instead of doing it > > > through GPU shaders. > > > > > > > Thanks, Uma, for sending this. I've been working on something similar but > > you beat > > me to it. :) > > Thanks Harry for the useful feedback and overall collaboration on this so far. > > > > > > > Work done so far and relevant references > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the same. > > > Broad consensus is there that we need a generic API at drm core to > > > suffice the use case of various HW vendors. Below are the links > > > capturing the discussion so far. > > > > > > Intel's Plane Color Implementation: > > > https://patchwork.freedesktop.org/series/90825/ > > > AMD's Plane Color Implementation: > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > Hackfest conclusions > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the industry > > > stakeholders together and converge on a common uapi expectations. > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia and > > > other prominent user-space developers and maintainers. > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > hardware of multiple hardware vendors, challenges in generalizing the > > > same and the path forward. Consensus was made that drm core should > > > implement descriptive APIs and not go with prescriptive APIs. DRM core > > > should just expose the hardware capabilities; enabling, customizing > > > and programming the same should be done by the user-space. Driver should > > > just > > honor the user space request without doing any operations internally. > > > > > > Thanks to Simon Ser, for nicely documenting the design consensus and > > > an UAPI RFC which can be referred to here: > > > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5 > > > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1Q > > Wn48 > > > 8=@emersion.fr/ > > > > > > > > > Design considerations > > > = > > > > > > Following are the important aspects taken into account while designing > > > the current RFC > > > proposal: > > > > > > 1. Individual HW blocks can be muxed. (e.g. out of two HW blocks only > > > one > > can be used) > > > 2. Position of the HW block in the pipeline can be programmable > > > 3. LUTs can be one dimention
Re: [PATCH RFC v6 00/10] Support for Solid Fill Planes
On Mon, Aug 28, 2023 at 05:05:06PM -0700, Jessica Zhang wrote: > Some drivers support hardware that have optimizations for solid fill > planes. This series aims to expose these capabilities to userspace as > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > hardware composer HAL) that can be set by apps like the Android Gears > app. > > In order to expose this capability to userspace, this series will: > > - Introduce solid_fill and pixel_source properties to allow userspace to > toggle between FB and solid fill sources > - Loosen NULL FB checks within the DRM atomic commit callstack to allow > for NULL FB when solid fill is enabled. > - Add NULL FB checks in methods where FB was previously assumed to be > non-NULL > - Have MSM DPU driver use drm_plane_state.solid_fill instead of > dpu_plane_state.color_fill > > Note: The solid fill planes feature depends on both the solid_fill *and* > pixel_source properties. > > To use this feature, userspace can set the solid_fill property to a blob > containing the appropriate version number and solid fill color (in > RGB323232 format) and and setting the pixel_source property to > DRM_PLANE_PIXEL_SOURCE_COLOR. This will disable memory fetch and the > resulting plane will display the color specified by the solid_fill blob. > > Currently, there's only one version of the solid_fill blob property. > However if other drivers want to support a similar feature, but require > more than just the solid fill color, they can extend this feature by > creating additional versions of the drm_solid_fill struct. > > This 2 property approach was chosen because passing in a special 1x1 FB > with the necessary color information would have unecessary overhead that > does not reflect the behavior of the solid fill feature. In addition, > assigning the solid fill blob to FB_ID would require loosening some core > drm_property checks that might cause unwanted side effects elsewhere. The cover letter is a bit outdated by now. Anyway, with Pekkas issues addressed the core drm parts are Acked-by: Sebastian Wick > --- > Changes in v6: > - Have _dpu_plane_color_fill() take in a single ABGR color instead > of having separate alpha and BGR color parameters (Dmitry) > - Drop plane->state->pixel_source != DRM_PLANE_PIXEL_SOURCE_FB check > in SetPlane ioctl (Dmitry) > - Add DRM_PLANE_PIXEL_SOURCE_NONE as a default pixel source (Sebastian) > - Dropped versioning from solid fill property blob (Dmitry) > - Use DRM_ENUM_NAME_FN (Dmitry) > - Use drm_atomic_replace_property_blob_from_id() (Dmitry) > - drm_atomic_check_fb -> drm_atomic_plane_check_fb (Dmitry) > - Group redundant NULL FB checks (Dmitry) > - Squashed drm_plane_needs_disable() implementation with > DRM_PLANE_PIXEL_SOURCE_NONE declaration (Sebastian) > - Add comment to support RGBA solid fill color in the future (Dmitry) > - Link to v5: > https://lore.kernel.org/r/20230728-solid-fill-v5-0-053dbefa9...@quicinc.com > > Changes in v5: > - Added support for PIXEL_SOURCE_NONE (Sebastian) > - Added WARN_ON() in drm_plane_has_visible_data() if pixel_source isn't > set (Dmitry) > - Added debugfs support for both properties (Dmitry) > - Corrected u32 to u8 conversion (Pekka) > - Moved drm_solid_fill_info struct and related documentation to > include/uapi (Pekka) > - Changed drm_solid_fill_info.version to __u32 for data alignment (Pekka) > - Added more detailed UAPI and kernel documentation (Pekka) > - Reordered patch series so that the pixel_source property is introduced > before solid_fill (Dmitry) > - Fixed inconsistent ABGR/RGBA format declaration (Pekka) > - Reset pixel_source to FB in drm_mode_setplane() (Dmitry) > - Rename supported_sources to extra_sources (Dmitry) > - Only destroy old solid_fill blob state if new state is valid (Pekka) > - Link to v4: > https://lore.kernel.org/r/20230404-solid-fill-v4-0-f4ec0caa7...@quicinc.com > > Changes in v4: > - Rebased onto latest kernel > - Reworded cover letter for clarity (Dmitry) > - Reworded commit messages for clarity > - Split existing changes into smaller commits > - Added pixel_source enum property (Dmitry, Pekka, Ville) > - Updated drm-kms comment docs with pixel_source and solid_fill > properties (Dmitry) > - Inlined drm_atomic_convert_solid_fill_info() (Dmitry) > - Passed in plane state alpha value to _dpu_plane_color_fill_pipe() > - Link to v3: > https://lore.kernel.org/r/20230104234036.636-1-quic_jessz...@quicinc.com > > Changes in v3: > - Fixed some logic errors in atomic checks (Dmitry) > - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper > methods (Dmitry) > - Fixed typo in drm_solid_fill struct documentation &
Re: [PATCH RFC v6 02/10] drm: Introduce solid fill DRM plane property
On Mon, Aug 28, 2023 at 05:05:08PM -0700, Jessica Zhang wrote:
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill" plane property containing the following information:
>
> struct drm_mode_solid_fill {
> u32 r, g, b;
> };
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9
> drivers/gpu/drm/drm_atomic_uapi.c | 26 ++
> drivers/gpu/drm/drm_blend.c | 30 ++
> include/drm/drm_blend.h | 1 +
> include/drm/drm_plane.h | 36
> +++
> include/uapi/drm/drm_mode.h | 24 +
> 6 files changed, 126 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 01638c51ce0a..86fb876efbe6 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -254,6 +254,11 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
>
> + if (plane_state->solid_fill_blob) {
> + drm_property_blob_put(plane_state->solid_fill_blob);
> + plane_state->solid_fill_blob = NULL;
> + }
> +
> if (plane->color_encoding_property) {
> if (!drm_object_property_get_default_value(>base,
>
> plane->color_encoding_property,
> @@ -336,6 +341,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> if (state->fb)
> drm_framebuffer_get(state->fb);
>
> + if (state->solid_fill_blob)
> + drm_property_blob_get(state->solid_fill_blob);
> +
> state->fence = NULL;
> state->commit = NULL;
> state->fb_damage_clips = NULL;
> @@ -385,6 +393,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->fb_damage_clips);
> + drm_property_blob_put(state->solid_fill_blob);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 454f980e16c9..1cae596ab693 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -316,6 +316,20 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> }
> EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
>
> +static void drm_atomic_set_solid_fill_prop(struct drm_plane_state *state)
> +{
> + struct drm_mode_solid_fill *user_info;
> +
> + if (!state->solid_fill_blob)
> + return;
> +
> + user_info = (struct drm_mode_solid_fill *)state->solid_fill_blob->data;
> +
> + state->solid_fill.r = user_info->r;
> + state->solid_fill.g = user_info->g;
> + state->solid_fill.b = user_info->b;
> +}
> +
> static void set_out_fence_for_crtc(struct drm_atomic_state *state,
> struct drm_crtc *crtc, s32 __user *fence_ptr)
> {
> @@ -546,6 +560,15 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->src_h = val;
> } else if (property == plane->pixel_source_property) {
> state->pixel_source = val;
> + } else if (property == plane->solid_fill_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >solid_fill_blob,
> + val, sizeof(struct drm_mode_solid_fill),
> + -1, );
> + if (ret)
> + return ret;
> +
> + drm_atomic_set_solid_fill_prop(state);
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> } else if (property == plane->blend_mode_property) {
> @@ -620,6 +643,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->src_h;
> } else if (property == plane->pixel_source_property) {
> *val = state->pixel_source;
> + } else if (property == plane->solid_fill_property) {
> + *val = state->solid_fill_blob ?
> + state->solid_fill_blob->base.id : 0;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> } else if (property == plane->blend_mode_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index c3c57bae06b7..273021cc21c8 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -200,6 +200,10 @@
Re: [PATCH v7] drm/doc: Document DRM device reset expectations
; +Vulkan > +~~ > + > +Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for submissions. > +This error code means, among other things, that a device reset has happened > and > +it needs to recreate the contexts to keep going. > + > +Reporting causes of resets > +-- > + > +Apart from propagating the reset through the stack so apps can recover, it's > +really useful for driver developers to learn more about what caused the > reset in > +the first place. DRM devices should make use of devcoredump to store relevant > +information about the reset, so this information can be added to user bug > +reports. > + > .. _drm_driver_ioctl: > > IOCTL Support on Device Nodes Acked-by: Sebastian Wick > -- > 2.41.0 >
Re: [PATCH v6 5/6] drm: Refuse to async flip with atomic prop changes
On Tue, Aug 15, 2023 at 03:57:09PM -0300, André Almeida wrote:
> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the mode ID, that could be referring to an identical mode.
FYI, the solid fill series adds an enum drm_plane_pixel_source and and a
new solid fill pixel source. Changing the solid fill color would be
effectively the same as changing the FB_ID. On the other hand, changing
the FB_ID no longer necessarily results in an update when the pixel
source is set to solid fill.
> Signed-off-by: André Almeida
> ---
> v5: no changes
> v4: new patch
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 5 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 52 +++--
> drivers/gpu/drm/drm_crtc_internal.h | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 2 +-
> 4 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 292e38eb6218..b34e3104afd1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -629,6 +629,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> WARN_ON(!drm_modeset_is_locked(>mutex));
>
> if (!drm_mode_equal(_crtc_state->mode,
> _crtc_state->mode)) {
> + if (new_crtc_state->async_flip) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] no mode
> changes allowed during async flip\n",
> +crtc->base.id, crtc->name);
> + return -EINVAL;
> + }
> drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> crtc->base.id, crtc->name);
> new_crtc_state->mode_changed = true;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a15121e75a0a..6c423a7e8c7b 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1006,13 +1006,28 @@ int drm_atomic_connector_commit_dpms(struct
> drm_atomic_state *state,
> return ret;
> }
>
> +static int drm_atomic_check_prop_changes(int ret, uint64_t old_val, uint64_t
> prop_value,
> + struct drm_property *prop)
> +{
> + if (ret != 0 || old_val != prop_value) {
> + drm_dbg_atomic(prop->dev,
> +"[PROP:%d:%s] No prop can be changed during
> async flip\n",
> +prop->base.id, prop->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> int drm_atomic_set_property(struct drm_atomic_state *state,
> struct drm_file *file_priv,
> struct drm_mode_object *obj,
> struct drm_property *prop,
> - uint64_t prop_value)
> + uint64_t prop_value,
> + bool async_flip)
> {
> struct drm_mode_object *ref;
> + uint64_t old_val;
> int ret;
>
> if (!drm_property_change_valid_get(prop, prop_value, ))
> @@ -1029,6 +1044,13 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> break;
> }
>
> + if (async_flip) {
> + ret = drm_atomic_connector_get_property(connector,
> connector_state,
> + prop, _val);
> + ret = drm_atomic_check_prop_changes(ret, old_val,
> prop_value, prop);
> + break;
> + }
> +
> ret = drm_atomic_connector_set_property(connector,
> connector_state, file_priv,
> prop, prop_value);
> @@ -1037,6 +1059,7 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> case DRM_MODE_OBJECT_CRTC: {
> struct drm_crtc *crtc = obj_to_crtc(obj);
> struct drm_crtc_state *crtc_state;
> + struct drm_mode_config *config = >dev->mode_config;
>
> crtc_state = drm_atomic_get_crtc_state(state, crtc);
> if (IS_ERR(crtc_state)) {
> @@ -1044,6 +1067,18 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> break;
> }
>
> + /*
> + * We allow mode_id changes here for async flips, because we
> + * check later on drm_atomic_helper_check_modeset() callers if
> + * there are modeset changes or they are equal
> + */
> + if (async_flip && prop != config->prop_mode_id) {
> + ret = drm_atomic_crtc_get_property(crtc, crtc_state,
> +
Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations
On Fri, Aug 4, 2023 at 3:03 PM Daniel Vetter wrote: > > On Tue, Jun 27, 2023 at 10:23:23AM -0300, André Almeida wrote: > > Create a section that specifies how to deal with DRM device resets for > > kernel and userspace drivers. > > > > Acked-by: Pekka Paalanen > > Signed-off-by: André Almeida > > --- > > > > v4: > > https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/ > > > > Changes: > > - Grammar fixes (Randy) > > > > Documentation/gpu/drm-uapi.rst | 68 ++ > > 1 file changed, 68 insertions(+) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 65fb3036a580..3cbffa25ed93 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a third > > handler for > > mmapped regular files. Threads cause additional pain with signal > > handling as well. > > > > +Device reset > > + > > + > > +The GPU stack is really complex and is prone to errors, from hardware bugs, > > +faulty applications and everything in between the many layers. Some errors > > +require resetting the device in order to make the device usable again. This > > +sections describes the expectations for DRM and usermode drivers when a > > +device resets and how to propagate the reset status. > > + > > +Kernel Mode Driver > > +-- > > + > > +The KMD is responsible for checking if the device needs a reset, and to > > perform > > +it as needed. Usually a hang is detected when a job gets stuck executing. > > KMD > > +should keep track of resets, because userspace can query any time about the > > +reset stats for an specific context. This is needed to propagate to the > > rest of > > +the stack that a reset has happened. Currently, this is implemented by each > > +driver separately, with no common DRM interface. > > + > > +User Mode Driver > > + > > + > > +The UMD should check before submitting new commands to the KMD if the > > device has > > +been reset, and this can be checked more often if the UMD requires it. > > After > > +detecting a reset, UMD will then proceed to report it to the application > > using > > +the appropriate API error code, as explained in the section below about > > +robustness. > > + > > +Robustness > > +-- > > + > > +The only way to try to keep an application working after a reset is if it > > +complies with the robustness aspects of the graphical API that it is using. > > + > > +Graphical APIs provide ways to applications to deal with device resets. > > However, > > +there is no guarantee that the app will use such features correctly, and > > the > > +UMD can implement policies to close the app if it is a repeating offender, > > Not sure whether this one here is due to my input, but s/UMD/KMD. Repeat > offender killing is more a policy where the kernel enforces policy, and no > longer up to userspace to dtrt (because very clearly userspace is not > really doing the right thing anymore when it's just hanging the gpu in an > endless loop). Also maybe tune it down further to something like "the > kernel driver may implemnent ..." > > In my opinion the umd shouldn't implement these kind of magic guesses, the > entire point of robustness apis is to delegate responsibility for > correctly recovering to the application. And the kernel is left with > enforcing fair resource usage policies (which eventually might be a > cgroups limit on how much gpu time you're allowed to waste with gpu > resets). Killing apps that the kernel thinks are misbehaving really doesn't seem like a good idea to me. What if the process is a service getting restarted after getting killed? What if killing that process leaves the system in a bad state? Can't the kernel provide some information to user space so that e.g. systemd can handle those situations? > > +likely in a broken loop. This is done to ensure that it does not keep > > blocking > > +the user interface from being correctly displayed. This should be done > > even if > > +the app is correct but happens to trigger some bug in the hardware/driver. > > + > > +OpenGL > > +~~ > > + > > +Apps using OpenGL should use the available robust interfaces, like the > > +extension ``GL_ARB_robustness`` (or ``GL_EXT_robustness`` for OpenGL ES). > > This > > +interface tells if a reset has happened, and if so, all the context state > > is > > +considered lost and the app proceeds by creating new ones. If it is > > possible to > > +determine that robustness is not in use, the UMD will terminate the app > > when a > > +reset is detected, giving that the contexts are lost and the app won't be > > able > > +to figure this out and recreate the contexts. > > + > > +Vulkan > > +~~ > > + > > +Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for > > submissions. > > +This error code means, among other things, that a device reset has > >
Re: [PATCH RFC v5 01/10] drm: Introduce pixel_source DRM plane property
On Mon, Aug 7, 2023 at 7:52 PM Jessica Zhang wrote:
>
>
>
> On 8/4/2023 6:15 AM, Sebastian Wick wrote:
> > On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> >> documentation. In addition, force pixel_source to
> >> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> >> legacy userspace.
> >>
> >> This enum property will allow user to specify a pixel source for the
> >> plane. Possible pixel sources will be defined in the
> >> drm_plane_pixel_source enum.
> >>
> >> The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_NONE and
> >> DRM_PLANE_PIXEL_SOURCE_FB with *_PIXEL_SOURCE_FB being the default value.
> >>
> >> Signed-off-by: Jessica Zhang
> >> ---
> >> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_blend.c | 85
> >> +++
> >> drivers/gpu/drm/drm_plane.c | 3 ++
> >> include/drm/drm_blend.h | 2 +
> >> include/drm/drm_plane.h | 21
> >> 6 files changed, 116 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> index 784e63d70a42..01638c51ce0a 100644
> >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct
> >> drm_plane_state *plane_state,
> >>
> >> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> >> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >> + plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >>
> >> if (plane->color_encoding_property) {
> >> if (!drm_object_property_get_default_value(>base,
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index d867e7f9f2cd..454f980e16c9 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -544,6 +544,8 @@ static int drm_atomic_plane_set_property(struct
> >> drm_plane *plane,
> >> state->src_w = val;
> >> } else if (property == config->prop_src_h) {
> >> state->src_h = val;
> >> + } else if (property == plane->pixel_source_property) {
> >> + state->pixel_source = val;
> >> } else if (property == plane->alpha_property) {
> >> state->alpha = val;
> >> } else if (property == plane->blend_mode_property) {
> >> @@ -616,6 +618,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >> *val = state->src_w;
> >> } else if (property == config->prop_src_h) {
> >> *val = state->src_h;
> >> + } else if (property == plane->pixel_source_property) {
> >> + *val = state->pixel_source;
> >> } else if (property == plane->alpha_property) {
> >> *val = state->alpha;
> >> } else if (property == plane->blend_mode_property) {
> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> index 6e74de833466..c500310a3d09 100644
> >> --- a/drivers/gpu/drm/drm_blend.c
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -185,6 +185,21 @@
> >>* plane does not expose the "alpha" property, then this is
> >>* assumed to be 1.0
> >>*
> >> + * pixel_source:
> >> + * pixel_source is set up with
> >> drm_plane_create_pixel_source_property().
> >> + * It is used to toggle the active source of pixel data for the plane.
> >> + * The plane will only display data from the set pixel_source -- any
> >> + * data from other sources will be ignored.
> >> + *
> >> + * Possible values:
> >> + *
> >> + * "NONE":
> >> + * No active pixel source.
> >> + * Committing with a NONE pixel source will disable the plane.
> >> + *
> >> + * "FB":
> >> + * Framebuffer
Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
wrote:
>
> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
> >
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace must assign a property blob to
> > the "solid_fill" plane property containing the following information:
> >
> > struct drm_mode_solid_fill {
> > u32 version;
> > u32 r, g, b;
> > };
> >
> > Signed-off-by: Jessica Zhang
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 55
> > +++
> > drivers/gpu/drm/drm_blend.c | 30 +
> > include/drm/drm_blend.h | 1 +
> > include/drm/drm_plane.h | 35
> > include/uapi/drm/drm_mode.h | 24 ++
> > 6 files changed, 154 insertions(+)
> >
>
> [skipped most of the patch]
>
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 43691058d28f..53c8efa5ad7f 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -259,6 +259,30 @@ struct drm_mode_modeinfo {
> > char name[DRM_DISPLAY_MODE_LEN];
> > };
> >
> > +/**
> > + * struct drm_mode_solid_fill - User info for solid fill planes
> > + *
> > + * This is the userspace API solid fill information structure.
> > + *
> > + * Userspace can enable solid fill planes by assigning the plane
> > "solid_fill"
> > + * property to a blob containing a single drm_mode_solid_fill struct
> > populated with an RGB323232
> > + * color and setting the pixel source to "SOLID_FILL".
> > + *
> > + * For information on the plane property, see
> > drm_plane_create_solid_fill_property()
> > + *
> > + * @version: Version of the blob. Currently, there is only support for
> > version == 1
> > + * @r: Red color value of single pixel
> > + * @g: Green color value of single pixel
> > + * @b: Blue color value of single pixel
> > + */
> > +struct drm_mode_solid_fill {
> > + __u32 version;
> > + __u32 r;
> > + __u32 g;
> > + __u32 b;
>
> Another thought about the drm_mode_solid_fill uABI. I still think we
> should add alpha here. The reason is the following:
>
> It is true that we have drm_plane_state::alpha and the plane's
> "alpha" property. However it is documented as "the plane-wide opacity
> [...] It can be combined with pixel alpha. The pixel values in the
> framebuffers are expected to not be pre-multiplied by the global alpha
> associated to the plane.".
>
> I can imagine a use case, when a user might want to enable plane-wide
> opacity, set "pixel blend mode" to "Coverage" and then switch between
> partially opaque framebuffer and partially opaque solid-fill without
> touching the plane's alpha value.
The only reason I see against this is that there might be some
hardware which supports only RGB but not alpha on planes and they
could then not use this property. Maybe another COLOR_FILL enum value
with alpha might be better? Maybe just doing the alpha via the alpha
property is good enough.
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Mon, Jul 31, 2023 at 6:01 AM Dmitry Baryshkov
wrote:
>
> On 28/07/2023 20:02, Jessica Zhang wrote:
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace must assign a property blob to
> > the "solid_fill" plane property containing the following information:
> >
> > struct drm_mode_solid_fill {
> > u32 version;
> > u32 r, g, b;
> > };
> >
> > Signed-off-by: Jessica Zhang
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 55
> > +++
> > drivers/gpu/drm/drm_blend.c | 30 +
> > include/drm/drm_blend.h | 1 +
> > include/drm/drm_plane.h | 35
> > include/uapi/drm/drm_mode.h | 24 ++
> > 6 files changed, 154 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 01638c51ce0a..86fb876efbe6 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -254,6 +254,11 @@ void __drm_atomic_helper_plane_state_reset(struct
> > drm_plane_state *plane_state,
> > plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> > plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >
> > + if (plane_state->solid_fill_blob) {
> > + drm_property_blob_put(plane_state->solid_fill_blob);
> > + plane_state->solid_fill_blob = NULL;
> > + }
> > +
> > if (plane->color_encoding_property) {
> > if (!drm_object_property_get_default_value(>base,
> >
> > plane->color_encoding_property,
> > @@ -336,6 +341,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> > drm_plane *plane,
> > if (state->fb)
> > drm_framebuffer_get(state->fb);
> >
> > + if (state->solid_fill_blob)
> > + drm_property_blob_get(state->solid_fill_blob);
> > +
> > state->fence = NULL;
> > state->commit = NULL;
> > state->fb_damage_clips = NULL;
> > @@ -385,6 +393,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> > drm_plane_state *state)
> > drm_crtc_commit_put(state->commit);
> >
> > drm_property_blob_put(state->fb_damage_clips);
> > + drm_property_blob_put(state->solid_fill_blob);
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 454f980e16c9..039686c78c2a 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -316,6 +316,51 @@ drm_atomic_set_crtc_for_connector(struct
> > drm_connector_state *conn_state,
> > }
> > EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
> >
> > +static int drm_atomic_set_solid_fill_prop(struct drm_plane_state *state,
> > + struct drm_property_blob *blob)
> > +{
> > + int blob_version;
> > +
> > + if (blob == state->solid_fill_blob)
> > + return 0;
> > +
> > + if (blob) {
> > + struct drm_mode_solid_fill *user_info = (struct
> > drm_mode_solid_fill *)blob->data;
> > +
> > + if (blob->length != sizeof(struct drm_mode_solid_fill)) {
> > + drm_dbg_atomic(state->plane->dev,
> > +"[PLANE:%d:%s] bad solid fill blob
> > length: %zu\n",
> > +state->plane->base.id,
> > state->plane->name,
> > +blob->length);
> > + return -EINVAL;
> > + }
> > +
> > + blob_version = user_info->version;
>
> I remember that we had versioning for quite some time. However it stroke
> me while reviewing that we do not a way to negotiate supported
> SOLID_FILL versions. However as we now have support for different
> pixel_source properties, maybe we can drop version completely. If at
> some point a driver needs to support different kind of SOLID_FILL
> property (consider v2), we can add new pixel source to the enum.
Agreed. Let's drop the versioning.
>
> > +
> > + /* Add more versions if necessary */
> > + if (blob_version == 1) {
> > + state->solid_fill.r = user_info->r;
> > + state->solid_fill.g = user_info->g;
> > + state->solid_fill.b = user_info->b;
> > + } else {
> > + drm_dbg_atomic(state->plane->dev,
> > +"[PLANE:%d:%s] unsupported solid fill
> > version (version=%d)\n",
> > +state->plane->base.id,
> > state->plane->name,
> > +
Re: [PATCH RFC v5 01/10] drm: Introduce pixel_source DRM plane property
On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation. In addition, force pixel_source to
> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> legacy userspace.
>
> This enum property will allow user to specify a pixel source for the
> plane. Possible pixel sources will be defined in the
> drm_plane_pixel_source enum.
>
> The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_NONE and
> DRM_PLANE_PIXEL_SOURCE_FB with *_PIXEL_SOURCE_FB being the default value.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_blend.c | 85
> +++
> drivers/gpu/drm/drm_plane.c | 3 ++
> include/drm/drm_blend.h | 2 +
> include/drm/drm_plane.h | 21
> 6 files changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 784e63d70a42..01638c51ce0a 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
>
> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> + plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
>
> if (plane->color_encoding_property) {
> if (!drm_object_property_get_default_value(>base,
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d867e7f9f2cd..454f980e16c9 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -544,6 +544,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_w = val;
> } else if (property == config->prop_src_h) {
> state->src_h = val;
> + } else if (property == plane->pixel_source_property) {
> + state->pixel_source = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> } else if (property == plane->blend_mode_property) {
> @@ -616,6 +618,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->src_w;
> } else if (property == config->prop_src_h) {
> *val = state->src_h;
> + } else if (property == plane->pixel_source_property) {
> + *val = state->pixel_source;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> } else if (property == plane->blend_mode_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 6e74de833466..c500310a3d09 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -185,6 +185,21 @@
> * plane does not expose the "alpha" property, then this is
> * assumed to be 1.0
> *
> + * pixel_source:
> + * pixel_source is set up with drm_plane_create_pixel_source_property().
> + * It is used to toggle the active source of pixel data for the plane.
> + * The plane will only display data from the set pixel_source -- any
> + * data from other sources will be ignored.
> + *
> + * Possible values:
> + *
> + * "NONE":
> + * No active pixel source.
> + * Committing with a NONE pixel source will disable the plane.
> + *
> + * "FB":
> + * Framebuffer source set by the "FB_ID" property.
> + *
> * 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).
> @@ -615,3 +630,73 @@ int drm_plane_create_blend_mode_property(struct
> drm_plane *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
> +
> +/**
> + * drm_plane_create_pixel_source_property - create a new pixel source
> property
> + * @plane: DRM plane
> + * @extra_sources: Bitmask of additional supported pixel_sources for the
> driver.
> + *DRM_PLANE_PIXEL_SOURCE_FB always be enabled as a supported
> + *source.
> + *
> + * This creates a new property describing the current source of pixel data
> for the
> + * plane. The pixel_source will be initialized as DRM_PLANE_PIXEL_SOURCE_FB
> by default.
> + *
> + * Drivers can set a custom default source by overriding the pixel_source
> value in
> + * drm_plane_funcs.reset()
> + *
> + * The property is exposed to userspace as an enumeration property called
> + * "pixel_source" and has the following enumeration values:
> + *
> + * "NONE":
> + * No active pixel source
> + *
> + * "FB":
> + * Framebuffer
Re: [PATCH] drm/vkms: avoid race-condition between flushing and destroying
On Sun, Jul 30, 2023 at 12:51 AM Maíra Canal wrote:
>
> After we flush the workqueue at the commit tale, we need to make sure
> that no work is queued until we destroy the state. Currently, new work
> can be queued in the workqueue, even after the commit tale, as the
> vblank thread is still running.
>
> Therefore, to avoid a race-condition that will lead to the trigger of a
> WARN_ON() at the function vkms_atomic_crtc_destroy_state(), add a mutex
> to protect the sections where the queue is manipulated.
>
> This way we can make sure that no work will be added to the workqueue
> between flushing the queue (at the commit tail) and destroying the
> state.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 10 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 1 +
> drivers/gpu/drm/vkms/vkms_drv.h | 8
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 3c5ebf106b66..e5ec21a0da05 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -49,7 +49,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
> state->crc_pending = true;
> spin_unlock(>composer_lock);
>
> + mutex_lock(>queue_lock);
> ret = queue_work(output->composer_workq,
> >composer_work);
> + mutex_unlock(>queue_lock);
> if (!ret)
> DRM_DEBUG_DRIVER("Composer worker already queued\n");
> }
> @@ -129,6 +131,7 @@ vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
>
> __drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
>
> + mutex_init(_state->queue_lock);
> INIT_WORK(_state->composer_work, vkms_composer_worker);
>
> return _state->base;
> @@ -142,6 +145,9 @@ static void vkms_atomic_crtc_destroy_state(struct
> drm_crtc *crtc,
> __drm_atomic_helper_crtc_destroy_state(state);
>
> WARN_ON(work_pending(_state->composer_work));
> + mutex_unlock(_state->queue_lock);
> +
> + mutex_destroy(_state->queue_lock);
> kfree(vkms_state->active_planes);
> kfree(vkms_state);
> }
> @@ -155,8 +161,10 @@ static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> vkms_atomic_crtc_destroy_state(crtc, crtc->state);
>
> __drm_atomic_helper_crtc_reset(crtc, _state->base);
> - if (vkms_state)
> + if (vkms_state) {
> + mutex_init(_state->queue_lock);
> INIT_WORK(_state->composer_work, vkms_composer_worker);
> + }
> }
>
> static const struct drm_crtc_funcs vkms_crtc_funcs = {
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index dd0af086e7fa..9212686ca88a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -84,6 +84,7 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state
> *old_state)
> struct vkms_crtc_state *vkms_state =
> to_vkms_crtc_state(old_crtc_state);
>
> + mutex_lock(_state->queue_lock);
I haven't looked at the code in detail but doesn't this need to be
unlocked after flush_work again?
> flush_work(_state->composer_work);
> }
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index c7ae6c2ba1df..83767692469a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -89,6 +89,14 @@ struct vkms_crtc_state {
> struct vkms_writeback_job *active_writeback;
> struct vkms_color_lut gamma_lut;
>
> + /* protects the access to the workqueue
> +*
> +* we need to hold this lock between flushing the workqueue and
> +* destroying the state to avoid work to be queued by the worker
> +* thread
> +*/
> + struct mutex queue_lock;
> +
> /* below four are protected by vkms_output.composer_lock */
> bool crc_pending;
> bool wb_pending;
> --
> 2.41.0
>
Re: [PATCH v2 0/2] doc: uapi: Document dma-buf interop design & semantics
For what it's worth this series is Reviewed-by: Sebastian Wick On Thu, Aug 3, 2023 at 5:49 PM Daniel Stone wrote: > > Hi all, > This is v2 to the linked patch series; thanks to everyone for reviewing > the initial version. I've moved this out of a pure DRM scope and into > the general userspace-API design section. Hopefully it helps others and > answers a bunch of questions. > > I think it'd be great to have input/links/reflections from other > subsystems as well here. > > Cheers, > Daniel > >
Re: [PATCH v4 1/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
On Sat, Jul 1, 2023 at 4:09 AM André Almeida wrote:
>
> From: Simon Ser
>
> If the driver supports it, allow user-space to supply the
> DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
> Set drm_crtc_state.async_flip accordingly.
>
> Document that drivers will reject atomic commits if an async
> flip isn't possible. This allows user-space to fall back to
> something else. For instance, Xorg falls back to a blit.
> Another option is to wait as close to the next vblank as
> possible before performing the page-flip to reduce latency.
>
> Signed-off-by: Simon Ser
> Reviewed-by: Alex Deucher
> Co-developed-by: André Almeida
> Signed-off-by: André Almeida
> ---
> v4: no changes
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 28 +---
> include/uapi/drm/drm_mode.h | 9 +
> 2 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d867e7f9f2cd..dfd4cf7169df 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1286,6 +1286,18 @@ static void complete_signaling(struct drm_device *dev,
> kfree(fence_state);
> }
>
> +static void
> +set_async_flip(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + int i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + crtc_state->async_flip = true;
> + }
> +}
> +
> int drm_mode_atomic_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
> {
> @@ -1326,9 +1338,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> }
>
> if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> - drm_dbg_atomic(dev,
> - "commit failed: invalid flag
> DRM_MODE_PAGE_FLIP_ASYNC\n");
> - return -EINVAL;
> + if (!dev->mode_config.async_page_flip) {
> + drm_dbg_atomic(dev,
> + "commit failed:
> DRM_MODE_PAGE_FLIP_ASYNC not supported\n");
> + return -EINVAL;
> + }
> + if (dev->mode_config.atomic_async_page_flip_not_supported) {
> + drm_dbg_atomic(dev,
> + "commit failed:
> DRM_MODE_PAGE_FLIP_ASYNC not supported with atomic\n");
> + return -EINVAL;
> + }
> }
>
> /* can't test and expect an event at the same time. */
> @@ -1426,6 +1445,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> + if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
> + set_async_flip(state);
> +
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> ret = drm_atomic_check_only(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 46becedf5b2f..56342ba2c11a 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -949,6 +949,15 @@ struct hdr_output_metadata {
> * Request that the page-flip is performed as soon as possible, ie. with no
> * delay due to waiting for vblank. This may cause tearing to be visible on
> * the screen.
> + *
> + * When used with atomic uAPI, the driver will return an error if the
> hardware
> + * doesn't support performing an asynchronous page-flip for this update.
> + * User-space should handle this, e.g. by falling back to a regular
> page-flip.
> + *
> + * Note, some hardware might need to perform one last synchronous page-flip
> + * before being able to switch to asynchronous page-flips. As an exception,
> + * the driver will return success even though that first page-flip is not
> + * asynchronous.
What would happen if one commits another async KMS update before the
first page flip? Does one receive EAGAIN, does it amend the previous
commit? What happens to the timing feedback?
This seems really risky to include tbh. I would prefer if we would not
add such special cases for now.
> */
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 2.41.0
>
Re: [PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property
On Fri, Jun 30, 2023 at 11:27 PM Jessica Zhang
wrote:
>
>
>
> On 6/30/2023 7:43 AM, Sebastian Wick wrote:
> > On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang
> > wrote:
> >>
> >> Add support for pixel_source property to drm_plane and related
> >> documentation.
> >>
> >> This enum property will allow user to specify a pixel source for the
> >> plane. Possible pixel sources will be defined in the
> >> drm_plane_pixel_source enum.
> >>
> >> The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
> >> DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.
> >>
> >> Signed-off-by: Jessica Zhang
> >> ---
> >> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_blend.c | 81
> >> +++
> >> include/drm/drm_blend.h | 2 +
> >> include/drm/drm_plane.h | 21
> >> 5 files changed, 109 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> index fe14be2bd2b2..86fb876efbe6 100644
> >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct
> >> drm_plane_state *plane_state,
> >>
> >> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> >> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >> + plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >>
> >> if (plane_state->solid_fill_blob) {
> >> drm_property_blob_put(plane_state->solid_fill_blob);
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index a28b4ee79444..6e59c21af66b 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct
> >> drm_plane *plane,
> >> drm_property_blob_put(solid_fill);
> >>
> >> return ret;
> >> + } else if (property == plane->pixel_source_property) {
> >> + state->pixel_source = val;
> >> } else if (property == plane->alpha_property) {
> >> state->alpha = val;
> >> } else if (property == plane->blend_mode_property) {
> >> @@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >> } else if (property == plane->solid_fill_property) {
> >> *val = state->solid_fill_blob ?
> >> state->solid_fill_blob->base.id : 0;
> >> + } else if (property == plane->pixel_source_property) {
> >> + *val = state->pixel_source;
> >> } else if (property == plane->alpha_property) {
> >> *val = state->alpha;
> >> } else if (property == plane->blend_mode_property) {
> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> index 38c3c5d6453a..8c100a957ee2 100644
> >> --- a/drivers/gpu/drm/drm_blend.c
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -189,6 +189,18 @@
> >>* solid_fill is set up with drm_plane_create_solid_fill_property().
> >> It
> >>* contains pixel data that drivers can use to fill a plane.
> >>*
> >> + * pixel_source:
> >> + * pixel_source is set up with
> >> drm_plane_create_pixel_source_property().
> >> + * It is used to toggle the source of pixel data for the plane.
> >> + *
> >> + * Possible values:
> >> + *
> >> + * "FB":
> >> + * Framebuffer source
> >> + *
> >> + * "COLOR":
> >> + * solid_fill source
> >> + *
> >>* 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).
> >> @@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct
> >> drm_plane *plane)
> >> return 0;
> >
Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations
On Fri, Jun 30, 2023 at 4:59 PM Alex Deucher wrote: > > On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick > wrote: > > > > On Tue, Jun 27, 2023 at 3:23 PM André Almeida > > wrote: > > > > > > Create a section that specifies how to deal with DRM device resets for > > > kernel and userspace drivers. > > > > > > Acked-by: Pekka Paalanen > > > Signed-off-by: André Almeida > > > --- > > > > > > v4: > > > https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/ > > > > > > Changes: > > > - Grammar fixes (Randy) > > > > > > Documentation/gpu/drm-uapi.rst | 68 ++ > > > 1 file changed, 68 insertions(+) > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > b/Documentation/gpu/drm-uapi.rst > > > index 65fb3036a580..3cbffa25ed93 100644 > > > --- a/Documentation/gpu/drm-uapi.rst > > > +++ b/Documentation/gpu/drm-uapi.rst > > > @@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a > > > third handler for > > > mmapped regular files. Threads cause additional pain with signal > > > handling as well. > > > > > > +Device reset > > > + > > > + > > > +The GPU stack is really complex and is prone to errors, from hardware > > > bugs, > > > +faulty applications and everything in between the many layers. Some > > > errors > > > +require resetting the device in order to make the device usable again. > > > This > > > +sections describes the expectations for DRM and usermode drivers when a > > > +device resets and how to propagate the reset status. > > > + > > > +Kernel Mode Driver > > > +-- > > > + > > > +The KMD is responsible for checking if the device needs a reset, and to > > > perform > > > +it as needed. Usually a hang is detected when a job gets stuck > > > executing. KMD > > > +should keep track of resets, because userspace can query any time about > > > the > > > +reset stats for an specific context. This is needed to propagate to the > > > rest of > > > +the stack that a reset has happened. Currently, this is implemented by > > > each > > > +driver separately, with no common DRM interface. > > > + > > > +User Mode Driver > > > + > > > + > > > +The UMD should check before submitting new commands to the KMD if the > > > device has > > > +been reset, and this can be checked more often if the UMD requires it. > > > After > > > +detecting a reset, UMD will then proceed to report it to the application > > > using > > > +the appropriate API error code, as explained in the section below about > > > +robustness. > > > + > > > +Robustness > > > +-- > > > + > > > +The only way to try to keep an application working after a reset is if it > > > +complies with the robustness aspects of the graphical API that it is > > > using. > > > + > > > +Graphical APIs provide ways to applications to deal with device resets. > > > However, > > > +there is no guarantee that the app will use such features correctly, and > > > the > > > +UMD can implement policies to close the app if it is a repeating > > > offender, > > > +likely in a broken loop. This is done to ensure that it does not keep > > > blocking > > > +the user interface from being correctly displayed. This should be done > > > even if > > > +the app is correct but happens to trigger some bug in the > > > hardware/driver. > > > > I still don't think it's good to let the kernel arbitrarily kill > > processes that it thinks are not well-behaved based on some heuristics > > and policy. > > > > Can't this be outsourced to user space? Expose the information about > > processes causing a device and let e.g. systemd deal with coming up > > with a policy and with killing stuff. > > I don't think it's the kernel doing the killing, it would be the UMD. > E.g., if the app is guilty and doesn't support robustness the UMD can > just call exit(). Ah, right, completely skipped over the UMD part. That makes more sense. > > Alex > > > > > > + > > > +OpenGL > > > +~~ > > > + > > > +Apps using OpenGL should use the available robust interfaces,
Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations
On Tue, Jun 27, 2023 at 3:23 PM André Almeida wrote: > > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Acked-by: Pekka Paalanen > Signed-off-by: André Almeida > --- > > v4: > https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/ > > Changes: > - Grammar fixes (Randy) > > Documentation/gpu/drm-uapi.rst | 68 ++ > 1 file changed, 68 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 65fb3036a580..3cbffa25ed93 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a third > handler for > mmapped regular files. Threads cause additional pain with signal > handling as well. > > +Device reset > + > + > +The GPU stack is really complex and is prone to errors, from hardware bugs, > +faulty applications and everything in between the many layers. Some errors > +require resetting the device in order to make the device usable again. This > +sections describes the expectations for DRM and usermode drivers when a > +device resets and how to propagate the reset status. > + > +Kernel Mode Driver > +-- > + > +The KMD is responsible for checking if the device needs a reset, and to > perform > +it as needed. Usually a hang is detected when a job gets stuck executing. KMD > +should keep track of resets, because userspace can query any time about the > +reset stats for an specific context. This is needed to propagate to the rest > of > +the stack that a reset has happened. Currently, this is implemented by each > +driver separately, with no common DRM interface. > + > +User Mode Driver > + > + > +The UMD should check before submitting new commands to the KMD if the device > has > +been reset, and this can be checked more often if the UMD requires it. After > +detecting a reset, UMD will then proceed to report it to the application > using > +the appropriate API error code, as explained in the section below about > +robustness. > + > +Robustness > +-- > + > +The only way to try to keep an application working after a reset is if it > +complies with the robustness aspects of the graphical API that it is using. > + > +Graphical APIs provide ways to applications to deal with device resets. > However, > +there is no guarantee that the app will use such features correctly, and the > +UMD can implement policies to close the app if it is a repeating offender, > +likely in a broken loop. This is done to ensure that it does not keep > blocking > +the user interface from being correctly displayed. This should be done even > if > +the app is correct but happens to trigger some bug in the hardware/driver. I still don't think it's good to let the kernel arbitrarily kill processes that it thinks are not well-behaved based on some heuristics and policy. Can't this be outsourced to user space? Expose the information about processes causing a device and let e.g. systemd deal with coming up with a policy and with killing stuff. > + > +OpenGL > +~~ > + > +Apps using OpenGL should use the available robust interfaces, like the > +extension ``GL_ARB_robustness`` (or ``GL_EXT_robustness`` for OpenGL ES). > This > +interface tells if a reset has happened, and if so, all the context state is > +considered lost and the app proceeds by creating new ones. If it is possible > to > +determine that robustness is not in use, the UMD will terminate the app when > a > +reset is detected, giving that the contexts are lost and the app won't be > able > +to figure this out and recreate the contexts. > + > +Vulkan > +~~ > + > +Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for submissions. > +This error code means, among other things, that a device reset has happened > and > +it needs to recreate the contexts to keep going. > + > +Reporting causes of resets > +-- > + > +Apart from propagating the reset through the stack so apps can recover, it's > +really useful for driver developers to learn more about what caused the > reset in > +first place. DRM devices should make use of devcoredump to store relevant > +information about the reset, so this information can be added to user bug > +reports. > + > .. _drm_driver_ioctl: > > IOCTL Support on Device Nodes > -- > 2.41.0 >
Re: [PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property
On Fri, Jun 30, 2023 at 2:26 AM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation.
>
> This enum property will allow user to specify a pixel source for the
> plane. Possible pixel sources will be defined in the
> drm_plane_pixel_source enum.
>
> The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
> DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_blend.c | 81
> +++
> include/drm/drm_blend.h | 2 +
> include/drm/drm_plane.h | 21
> 5 files changed, 109 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index fe14be2bd2b2..86fb876efbe6 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
>
> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> + plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
>
> if (plane_state->solid_fill_blob) {
> drm_property_blob_put(plane_state->solid_fill_blob);
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a28b4ee79444..6e59c21af66b 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> drm_property_blob_put(solid_fill);
>
> return ret;
> + } else if (property == plane->pixel_source_property) {
> + state->pixel_source = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> } else if (property == plane->blend_mode_property) {
> @@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> } else if (property == plane->solid_fill_property) {
> *val = state->solid_fill_blob ?
> state->solid_fill_blob->base.id : 0;
> + } else if (property == plane->pixel_source_property) {
> + *val = state->pixel_source;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> } else if (property == plane->blend_mode_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 38c3c5d6453a..8c100a957ee2 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -189,6 +189,18 @@
> * solid_fill is set up with drm_plane_create_solid_fill_property(). It
> * contains pixel data that drivers can use to fill a plane.
> *
> + * pixel_source:
> + * pixel_source is set up with drm_plane_create_pixel_source_property().
> + * It is used to toggle the source of pixel data for the plane.
> + *
> + * Possible values:
> + *
> + * "FB":
> + * Framebuffer source
> + *
> + * "COLOR":
> + * solid_fill source
> + *
> * 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).
> @@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct
> drm_plane *plane)
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_solid_fill_property);
> +
> +/**
> + * drm_plane_create_pixel_source_property - create a new pixel source
> property
> + * @plane: drm plane
> + * @supported_sources: bitmask of supported pixel_sources for the driver (NOT
> + * including DRM_PLANE_PIXEL_SOURCE_FB, as it will be
> supported
> + * by default).
> + *
> + * This creates a new property describing the current source of pixel data
> for the
> + * plane.
> + *
> + * The property is exposed to userspace as an enumeration property called
> + * "pixel_source" and has the following enumeration values:
> + *
> + * "FB":
> + * Framebuffer pixel source
> + *
> + * "COLOR":
> + * Solid fill color pixel source
Can we add a "NONE" value?
I know it has been discussed earlier if we *need* this and I don't
think we do. I just think it would be better API design to disable
planes this way than having to know that a framebuffer pixel source
with a NULL framebuffer disables the plane. Obviously also keep the
old behavior for backwards compatibility.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_plane_create_pixel_source_property(struct drm_plane *plane,
> + unsigned int supported_sources)
> +{
> +
Re: [RFC 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem
On Fri, May 26, 2023 at 6:21 PM Aravind Iddamsetty wrote: > > Our hardware supports RAS(Reliability, Availability, Serviceability) by > exposing a set of error counters which can be used by observability > tools to take corrective actions or repairs. Traditionally there were > being exposed via PMU (for relative counters) and sysfs interface (for > absolute value) in our internal branch. But, due to the limitations in > this approach to use two interfaces and also not able to have an event > based reporting or configurability, an alternative approach to try > netlink was suggested by community for drm subsystem wide UAPI for RAS > and telemetry as discussed in [1]. > > This [1] is the inspiration to this series. It uses the generic > netlink(genl) family subsystem and exposes a set of commands that can > be used by every drm driver, the framework provides a means to have > custom commands too. Each drm driver instance in this example xe driver > instance registers a family and operations to the genl subsystem through > which it enumerates and reports the error counters. An event based > notification is also supported to which userpace can subscribe to and > be notified when any error occurs and read the error counter this avoids > continuous polling on error counter. This can also be extended to > threshold based notification. Be aware that netlink can be quite awkward in user space because it's attached to the netns while the device is in the mount ns and there are special rules for netlink regarding namespacing. > [1]: > https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html > > this series is on top of https://patchwork.freedesktop.org/series/116181/ > > Below is an example tool drm_ras which demonstrates the use of the > supported commands. The tool will be sent to ML with the subject > "[RFC i-g-t 0/1] A tool to demonstrate use of netlink sockets to read RAS > error counters" > > read single error counter: > > $ ./drm_ras READ_ONE --device=drm:/dev/dri/card1 --error_id=0x0005 > counter value 0 > > read all error counters: > > $ ./drm_ras READ_ALL --device=drm:/dev/dri/card1 > nameconfig-id > counter > > error-gt0-correctable-guc 0x0001 > 0 > error-gt0-correctable-slm 0x0003 > 0 > error-gt0-correctable-eu-ic 0x0004 > 0 > error-gt0-correctable-eu-grf0x0005 > 0 > error-gt0-fatal-guc 0x0009 > 0 > error-gt0-fatal-slm 0x000d > 0 > error-gt0-fatal-eu-grf 0x000f > 0 > error-gt0-fatal-fpu 0x0010 > 0 > error-gt0-fatal-tlb 0x0011 > 0 > error-gt0-fatal-l3-fabric 0x0012 > 0 > error-gt0-correctable-subslice 0x0013 > 0 > error-gt0-correctable-l3bank0x0014 > 0 > error-gt0-fatal-subslice0x0015 > 0 > error-gt0-fatal-l3bank 0x0016 > 0 > error-gt0-sgunit-correctable0x0017 > 0 > error-gt0-sgunit-nonfatal 0x0018 > 0 > error-gt0-sgunit-fatal 0x0019 > 0 > error-gt0-soc-fatal-psf-csc-0 0x001a > 0 > error-gt0-soc-fatal-psf-csc-1 0x001b > 0 > error-gt0-soc-fatal-psf-csc-2 0x001c > 0 > error-gt0-soc-fatal-punit 0x001d > 0 > error-gt0-soc-fatal-psf-0 0x001e > 0 > error-gt0-soc-fatal-psf-1 0x001f > 0 > error-gt0-soc-fatal-psf-2 0x0020 > 0 > error-gt0-soc-fatal-cd0 0x0021 > 0 > error-gt0-soc-fatal-cd0-mdfi0x0022 > 0 > error-gt0-soc-fatal-mdfi-east 0x0023 > 0 > error-gt0-soc-fatal-mdfi-south 0x0024 > 0 > error-gt0-soc-fatal-hbm-ss0-0 0x0025 > 0 > error-gt0-soc-fatal-hbm-ss0-1 0x0026 > 0 > error-gt0-soc-fatal-hbm-ss0-2 0x0027 > 0 > error-gt0-soc-fatal-hbm-ss0-3
Re: [PATCH 06/36] drm/amd/display: add CRTC driver-specific property for gamma TF
On Tue, Jun 6, 2023 at 6:19 PM Joshua Ashton wrote:
>
>
>
> On 6/1/23 20:17, Harry Wentland wrote:
> >
> >
> > On 5/23/23 18:14, Melissa Wen wrote:
> >> Hook up driver-specific atomic operations for managing AMD color
> >> properties and create AMD driver-specific color management properties
> >> and attach them according to HW capabilities defined by `struct
> >> dc_color_caps`. Add enumerated transfer function property to DRM CRTC
> >> gamma to convert to wire encoding with or without a user gamma LUT.
> >> Enumerated TFs are not supported yet by the DRM color pipeline,
> >> therefore, create a DRM enum list with the predefined TFs supported by
> >> the AMD display driver.
> >>
> >> Co-developed-by: Joshua Ashton
> >> Signed-off-by: Joshua Ashton
> >> Signed-off-by: Melissa Wen
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 36 ++
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 8 +++
> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 22 ++
> >> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++-
> >> 4 files changed, 137 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> index 389396eac222..88af075e6c18 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> @@ -1247,6 +1247,38 @@ amdgpu_display_user_framebuffer_create(struct
> >> drm_device *dev,
> >> return _fb->base;
> >> }
> >>
> >> +static const struct drm_prop_enum_list drm_transfer_function_enum_list[]
> >> = {
> >> +{ DRM_TRANSFER_FUNCTION_DEFAULT, "Default" },
> >> +{ DRM_TRANSFER_FUNCTION_SRGB, "sRGB" },
> >> +{ DRM_TRANSFER_FUNCTION_BT709, "BT.709" },
> >> +{ DRM_TRANSFER_FUNCTION_PQ, "PQ (Perceptual Quantizer)" },
> >> +{ DRM_TRANSFER_FUNCTION_LINEAR, "Linear" },
> >> +{ DRM_TRANSFER_FUNCTION_UNITY, "Unity" },
> >> +{ DRM_TRANSFER_FUNCTION_HLG, "HLG (Hybrid Log Gamma)" },
> >> +{ DRM_TRANSFER_FUNCTION_GAMMA22, "Gamma 2.2" },
> >> +{ DRM_TRANSFER_FUNCTION_GAMMA24, "Gamma 2.4" },
> >> +{ DRM_TRANSFER_FUNCTION_GAMMA26, "Gamma 2.6" },
> >> +};
> >
> > Let's not use the DRM_/drm_ prefix here. It might clash later when
> > we introduce DRM_ core interfaces for enumerated transfer functions.
> >
> > We'll want to specify whether something is an EOTF or an inverse EOTF,
> > or possibly an OETF. Of course that wouldn't apply to "Linear" or
> > "Unity" (I'm assuming the two are the same?).
> >
> > EOTF = electro-optical transfer function
> > This is the transfer function to go from the encoded value to an
> > optical (linear) value.
> >
> > Inverse EOTF = simply the inverse of the EOTF
> > This is usually intended to go from an optical/linear space (which
> > might have been used for blending) back to the encoded values.
> >
> > OETF = opto-electronic transfer function
> > This is usually used for converting optical signals into encoded
> > values. Usually that's done on the camera side but I think HLG might
> > define the OETF instead of the EOTF. A bit fuzzy on that. If you're
> > unclear about HLG I recommend we don't include it yet.
> >
> > It would also be good to document a bit more what each of the TFs
> > mean, but I'm fine if that comes later with a "driver-agnostic"
> > API. The key thing to clarify is whether we have an EOTF or inv_EOTF,
> > i.e. whether we use the TF to go from encoded to optical or vice
> > versa.
>
> Whether we use the inverse or not is just determined per-block though.
>
> I think we should definitely document it per-block very explicitly
> (whether it is EOTF or inv EOTF) but I don't think we need to touch the
> enums here.
Either the drm prefix has to be removed or the enum variant names have
to be explicitly be the EOTF, OETF, inverse EOTF or inverse OETF.
> - Joshie ✨
>
> >
> > I know DC is sloppy and doesn't define those but it will still use
> > them as either EOTF or inv_EOTF, based on which block they're being
> > programmed, if I'm not mistaken.
> >
> >> +
> >> +#ifdef AMD_PRIVATE_COLOR
> >> +static int
> >> +amdgpu_display_create_color_properties(struct amdgpu_device *adev)
> >> +{
> >> +struct drm_property *prop;
> >> +
> >> +prop = drm_property_create_enum(adev_to_drm(adev),
> >> +DRM_MODE_PROP_ENUM,
> >> +"AMD_REGAMMA_TF",
> >> +drm_transfer_function_enum_list,
> >> +
> >> ARRAY_SIZE(drm_transfer_function_enum_list));
> >> +if (!prop)
> >> +return -ENOMEM;
> >> +adev->mode_info.regamma_tf_property = prop;
> >> +
> >> +return 0;
> >> +}
> >> +#endif
> >> +
> >
> > It'd be nice if we have this function and the above enum_list
> > in amdgpu_dm, possibly in amdgpu_dm_color.c. You could call it
> > directly after the amdgpu_display_modeset_create_prop() call
Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu
With the documentation about RGB and YCC variants added the drm core patches are Reviewed-by: Sebastian Wick On Fri, May 26, 2023 at 6:24 PM Sebastian Wick wrote: > > On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote: > > > > On Thu, 25 May 2023 15:17:56 -0400 > > Harry Wentland wrote: > > > > > This patchset is based on Joshua's previous patchset [1], as well > > > as my previous patchset [2]. > > > > > > It is > > > - enabling support for the colorspace property in amdgpu, as well as > > > - allowing drivers to specify the supported set of colorspaces, and > > > > > > Colorspace, Infoframes, and YCbCr matrix > > > --- > > > > > > Even though the initial intent of the colorspace property was to set the > > > colorspace field in the respective HDMI AVI and DP SDP infoframes that > > > is not sufficient in all scenarios. For DP the colorspace information > > > also affects the MSA (main stream attribute) packet. For YUV output the > > > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > > > field of the infopackets also depends on the encoding used, which is > > > something that is decided by the driver and not known to userspace. > > > > Hi Harry, > > > > the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. > > Should there still be a patch that adds some UAPI documentation only, > > saying that drivers are free to swap e.g. between BT2020 RGB and YCC > > based which encoding they actually chose? > > Yes please! > > > Even if just BT2020 variant specifically. > > > > I have nothing against with this series now. > > > > > > Thanks, > > pq > > > > > > > > For these reasons a driver will need to be able to select the supported > > > colorspaces at property creation. > > > > > > Note: There seems to be an understanding that the colorspace property > > > should ONLY modify the infoframe. While this is current behavior and > > > sufficient in some cases it is nowhere specified that this should be the > > > only use of this property. As outlined above this limitation is not > > > going to work in all cases. > > > > > > This patchset does not affect current behavior for the drivers that > > > implement this property: i915 and vc4. > > > > > > In the future we might want to give userspace control over the encoding > > > format on the wire, in particular to avoid use of YUV420 when image > > > fidelity is important. This work would likely go hand in hand with a > > > min_bpc property and wouldn't conflict with the work done in this > > > patchset. I would expect this future work to tag along with a drm_crtc > > > or drm_connector's Color Pipeline, similar to the one propsed for > > > drm_plane [3]. > > > > > > Colorspace on crtc or connector? > > > > > > > > > There have been suggestions of programming 'colorspace' on the drm_crtc > > > but I don't think the crtc is the right place for this property. The > > > drm_plane and drm_crtc will be used to offload color processing that > > > would normally be done via the GFX or other pipelines. The drm_connector > > > controls the signalling with the display and ensures the wire format is > > > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > > > > > [1] https://patchwork.freedesktop.org/series/113632/ > > > [2] https://patchwork.freedesktop.org/series/111865/ > > > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Fri, May 26, 2023 at 6:37 PM Simon Ser wrote: > > On Friday, May 26th, 2023 at 18:27, Sebastian Wick > wrote: > > > > + * @DRM_MODE_COLORIMETRY_DEFAULT: > > > + * Driver specific behavior. > > > + * @DRM_MODE_COLORIMETRY_NO_DATA: > > > + * Driver specific behavior. > > > > TBH this is still confusing me. Is DEFAULT really just driver specific > > behavior? What's the difference to NO_DATA? Is NO_DATA actually not > > driver-specific but display-specific? I.e. the default colorimetry of > > the display? > > DEFAULT == NO_DATA == 0 > *sight* and backwards compat... Alright, not much we can do then.
Re: [PATCH v4 08/13] drm/amd/display: Register Colorspace property for DP and HDMI
On Thu, May 25, 2023 at 9:18 PM Harry Wentland wrote:
>
> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.
This commit message seems wrong for multiple reasons. The Colorspace
property documentation explicitly says that user space has to check
the sink EDID for support:
> The expectation from userspace is that it should parse the EDID and get
> supported colorspaces.
The code doesn't seem to care about EDID at all. Instead it exposes
the variants it knows how to support with e.g. the appropriate YCC
transform when necessary, independent of the sink support.
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ca093396d1ac..dc99a8ffac70 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7238,6 +7238,12 @@ static int amdgpu_dm_connector_get_modes(struct
> drm_connector *connector)
> return amdgpu_dm_connector->num_modes;
> }
>
> +static const u32 supported_colorspaces =
> + BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> + BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
> +
> void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> struct amdgpu_dm_connector *aconnector,
> int connector_type,
> @@ -7318,6 +7324,15 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> adev->mode_info.abm_level_property, 0);
> }
>
> + if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> + if
> (!drm_mode_create_hdmi_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + if
> (!drm_mode_create_dp_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + }
> +
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> connector_type == DRM_MODE_CONNECTOR_eDP) {
> --
> 2.40.1
>
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Thu, May 25, 2023 at 9:18 PM Harry Wentland wrote:
>
> From: Joshua Ashton
>
> To match the other enums, and add more information about these values.
>
> v2:
> - Specify where an enum entry comes from
> - Clarify DEFAULT and NO_DATA behavior
> - BT.2020 CYCC is "constant luminance"
> - correct type for BT.601
>
> v4:
> - drop DP/HDMI clarifications that might create
> more questions than answers
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Harry Wentland
> Reviewed-by: Harry Wentland
>
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> include/drm/drm_connector.h | 62 +++--
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 77401e425341..ee597593d7e6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -363,13 +363,71 @@ enum drm_privacy_screen_status {
> PRIVACY_SCREEN_ENABLED_LOCKED,
> };
>
> -/*
> - * This is a consolidated colorimetry list supported by HDMI and
> +/**
> + * enum drm_colorspace - color space
> + *
> + * This enum is a consolidated colorimetry list supported by HDMI and
> * DP protocol standard. The respective connectors will register
> * a property with the subset of this list (supported by that
> * respective protocol). Userspace will set the colorspace through
> * a colorspace property which will be created and exposed to
> * userspace.
> + *
> + * DP definitions come from the DP v2.0 spec
> + * HDMI definitions come from the CTA-861-H spec
> + *
> + * @DRM_MODE_COLORIMETRY_DEFAULT:
> + * Driver specific behavior.
> + * @DRM_MODE_COLORIMETRY_NO_DATA:
> + * Driver specific behavior.
TBH this is still confusing me. Is DEFAULT really just driver specific
behavior? What's the difference to NO_DATA? Is NO_DATA actually not
driver-specific but display-specific? I.e. the default colorimetry of
the display?
> + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> + * (HDMI)
> + * SMPTE ST 170M colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> + * (HDMI, DP)
> + * xvYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_709:
> + * (HDMI, DP)
> + * xvYCC709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_SYCC_601:
> + * (HDMI, DP)
> + * sYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPYCC_601:
> + * (HDMI, DP)
> + * opYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPRGB:
> + * (HDMI, DP)
> + * opRGB colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> + * (HDMI, DP)
> + * ITU-R BT.2020 R' G' B' colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y' C'b C'r colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> + * (HDMI)
> + * SMPTE ST 2113 P3D65 colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> + * (HDMI)
> + * SMPTE ST 2113 P3DCI colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> + * (DP)
> + * RGB wide gamut fixed point colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> + * (DP)
> + * RGB wide gamut floating point
> + * (scRGB (IEC 61966-2-2)) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT601_YCC:
> + * (DP)
> + * ITU-R BT.601 colorimetry format
> + * The DP spec does not say whether this is the 525 or the 625
> + * line version.
> */
> enum drm_colorspace {
> /* For Default case, driver will set the colorspace */
> --
> 2.40.1
>
Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu
On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote: > > On Thu, 25 May 2023 15:17:56 -0400 > Harry Wentland wrote: > > > This patchset is based on Joshua's previous patchset [1], as well > > as my previous patchset [2]. > > > > It is > > - enabling support for the colorspace property in amdgpu, as well as > > - allowing drivers to specify the supported set of colorspaces, and > > > > Colorspace, Infoframes, and YCbCr matrix > > --- > > > > Even though the initial intent of the colorspace property was to set the > > colorspace field in the respective HDMI AVI and DP SDP infoframes that > > is not sufficient in all scenarios. For DP the colorspace information > > also affects the MSA (main stream attribute) packet. For YUV output the > > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > > field of the infopackets also depends on the encoding used, which is > > something that is decided by the driver and not known to userspace. > > Hi Harry, > > the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. > Should there still be a patch that adds some UAPI documentation only, > saying that drivers are free to swap e.g. between BT2020 RGB and YCC > based which encoding they actually chose? Yes please! > Even if just BT2020 variant specifically. > > I have nothing against with this series now. > > > Thanks, > pq > > > > > For these reasons a driver will need to be able to select the supported > > colorspaces at property creation. > > > > Note: There seems to be an understanding that the colorspace property > > should ONLY modify the infoframe. While this is current behavior and > > sufficient in some cases it is nowhere specified that this should be the > > only use of this property. As outlined above this limitation is not > > going to work in all cases. > > > > This patchset does not affect current behavior for the drivers that > > implement this property: i915 and vc4. > > > > In the future we might want to give userspace control over the encoding > > format on the wire, in particular to avoid use of YUV420 when image > > fidelity is important. This work would likely go hand in hand with a > > min_bpc property and wouldn't conflict with the work done in this > > patchset. I would expect this future work to tag along with a drm_crtc > > or drm_connector's Color Pipeline, similar to the one propsed for > > drm_plane [3]. > > > > Colorspace on crtc or connector? > > > > > > There have been suggestions of programming 'colorspace' on the drm_crtc > > but I don't think the crtc is the right place for this property. The > > drm_plane and drm_crtc will be used to offload color processing that > > would normally be done via the GFX or other pipelines. The drm_connector > > controls the signalling with the display and ensures the wire format is > > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > > > [1] https://patchwork.freedesktop.org/series/113632/ > > [2] https://patchwork.freedesktop.org/series/111865/ > > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote: > > On Fri, 5 May 2023 at 01:23, Simon Ser wrote: > > > > Hi all, > > > > The goal of this RFC is to expose a generic KMS uAPI to configure the color > > pipeline before blending, ie. after a pixel is tapped from a plane's > > framebuffer and before it's blended with other planes. With this new uAPI we > > aim to reduce the battery life impact of color management and HDR on mobile > > devices, to improve performance and to decrease latency by skipping > > composition on the 3D engine. This proposal is the result of discussions at > > the Red Hat HDR hackfest [1] which took place a few days ago. Engineers > > familiar with the AMD, Intel and NVIDIA hardware have participated in the > > discussion. > > > > This proposal takes a prescriptive approach instead of a descriptive > > approach. > > Drivers describe the available hardware blocks in terms of low-level > > mathematical operations, then user-space configures each block. We decided > > against a descriptive approach where user-space would provide a high-level > > description of the colorspace and other parameters: we want to give more > > control and flexibility to user-space, e.g. to be able to replicate exactly > > the > > color pipeline with shaders and switch between shaders and KMS pipelines > > seamlessly, and to avoid forcing user-space into a particular color > > management > > policy. > > I'm not 100% sold on the prescriptive here, let's see if someone can > get me over the line with some questions later. > > My feeling is color pipeline hw is not a done deal, and that hw > vendors will be revising/evolving/churning the hw blocks for a while > longer, as there is no real standards in the area to aim for, all the > vendors are mostly just doing whatever gets Windows over the line and > keeps hw engineers happy. So I have some concerns here around forwards > compatibility and hence the API design. > > I guess my main concern is if you expose a bunch of hw blocks and > someone comes up with a novel new thing, will all existing userspace > work, without falling back to shaders? > Do we have minimum guarantees on what hardware blocks have to be > exposed to build a useable pipeline? > If a hardware block goes away in a new silicon revision, do I have to > rewrite my compositor? or will it be expected that the kernel will > emulate the old pipelines on top of whatever new fancy thing exists. I think there are two answers to those questions. The first one is that right now KMS already doesn't guarantee that every property is supported on all hardware. The guarantee we have is that properties that are supported on a piece of hardware on a specific kernel will be supported on the same hardware on later kernels. The color pipeline is no different here. For a specific piece of hardware a newer kernel might only change the pipelines in a backwards compatible way and add new pipelines. So to answer your question: if some hardware with a novel pipeline will show up it might not be supported and that's fine. We already have cases where some hardware does not support the gamma lut property but only the CSC property and that breaks night light because we never bothered to write a shader fallback. KMS provides ways to offload work but a generic user space always has to provide a fallback and this doesn't change. Hardware specific user space on the other hand will keep working with the forward compatibility guarantees we want to provide. The second answer is that we want to provide a user space library which takes a description of a color pipeline and tries to map that to the available KMS color pipelines. If there is a novel color operation, adding support in this library would then make it possible to offload compatible color pipelines on this new hardware for all consumers of the library. Obviously there is no guarantee that whatever color pipeline compositors come up with can actually be realized on specific hardware but that's just an inherent hardware issue. > We are not Android, or even Steam OS on a Steamdeck, we have to be > able to independently update the kernel for new hardware and not > require every compositor currently providing HDR to need to support > new hardware blocks and models at the same time. > > Dave. >
Re: [RFC] Plane color pipeline KMS uAPI
On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
>
> On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffer and before it's blended with other planes. With this new uAPI we
> > aim to reduce the battery life impact of color management and HDR on mobile
> > devices, to improve performance and to decrease latency by skipping
> > composition on the 3D engine. This proposal is the result of discussions at
> > the Red Hat HDR hackfest [1] which took place a few days ago. Engineers
> > familiar with the AMD, Intel and NVIDIA hardware have participated in the
> > discussion.
> >
> > This proposal takes a prescriptive approach instead of a descriptive
> > approach.
> > Drivers describe the available hardware blocks in terms of low-level
> > mathematical operations, then user-space configures each block. We decided
> > against a descriptive approach where user-space would provide a high-level
> > description of the colorspace and other parameters: we want to give more
> > control and flexibility to user-space, e.g. to be able to replicate exactly
> > the
> > color pipeline with shaders and switch between shaders and KMS pipelines
> > seamlessly, and to avoid forcing user-space into a particular color
> > management
> > policy.
>
> Ack on the prescriptive approach, but generic imo. Descriptive pretty much
> means you need the shaders at the same api level for fallback purposes,
> and we're not going to have that ever in kms. That would need something
> like hwc in userspace to work.
Which would be nice to have but that would be forcing a specific color
pipeline on everyone and we explicitly want to avoid that. There are
just too many trade-offs to consider.
> And not generic in it's ultimate consquence would mean we just do a blob
> for a crtc with all the vendor register stuff like adf (android display
> framework) does, because I really don't see a point in trying a
> generic-looking-but-not vendor uapi with each color op/stage split out.
>
> So from very far and pure gut feeling, this seems like a good middle
> ground in the uapi design space we have here.
Good to hear!
> > We've decided against mirroring the existing CRTC properties
> > DEGAMMA_LUT/CTM/GAMMA_LUT onto KMS planes. Indeed, the color management
> > pipeline can significantly differ between vendors and this approach cannot
> > accurately abstract all hardware. In particular, the availability, ordering
> > and
> > capabilities of hardware blocks is different on each display engine. So,
> > we've
> > decided to go for a highly detailed hardware capability discovery.
> >
> > This new uAPI should not be in conflict with existing standard KMS
> > properties,
> > since there are none which control the pre-blending color pipeline at the
> > moment. It does conflict with any vendor-specific properties like
> > NV_INPUT_COLORSPACE or the patches on the mailing list adding AMD-specific
> > properties. Drivers will need to either reject atomic commits configuring
> > both
> > uAPIs, or alternatively we could add a DRM client cap which hides the vendor
> > properties and shows the new generic properties when enabled.
> >
> > To use this uAPI, first user-space needs to discover hardware capabilities
> > via
> > KMS objects and properties, then user-space can configure the hardware via
> > an
> > atomic commit. This works similarly to the existing KMS uAPI, e.g. planes.
> >
> > Our proposal introduces a new "color_pipeline" plane property, and a new KMS
> > object type, "COLOROP" (short for color operation). The "color_pipeline"
> > plane
> > property is an enum, each enum entry represents a color pipeline supported
> > by
> > the hardware. The special zero entry indicates that the pipeline is in
> > "bypass"/"no-op" mode. For instance, the following plane properties
> > describe a
> > primary plane with 2 supported pipelines but currently configured in bypass
> > mode:
> >
> > Plane 10
> > ├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
> > ├─ …
> > └─ "color_pipeline": enum {0, 42, 52} = 0
>
> A bit confused, why is this an enum, and not just an immutable prop that
> points at the first element? You already can disable elements with the
> bypass thing, also bypassing by changing the pointers to the next node in
> the graph seems a bit confusing and redundant.
We want to allow multiple pipelines to exist and a plane can choose
the pipeline by selecting the first element of the pipeline. The enum
here lists all the possible pipelines that can be attached to the
surface.
> > The non-zero entries describe color pipelines as a linked list of COLOROP
> > KMS
> > objects. The entry value is an object ID pointing to the head of the linked
> > list (the first operation in the color pipeline).
> >
> > The new COLOROP objects also
Re: [PATCH v2 00/21] Enable Colorspace connector property in amdgpu
FWIW, I still think this series is good (minus the UAPI changes) and would allow us to work on user space HDR support without custom kernels. On Fri, Jan 13, 2023 at 5:24 PM Harry Wentland wrote: > > This patchset enables the DP and HDMI infoframe properties > in amdgpu. > > The first two patches are not completely related to the rest. The > first patch allows for HDR_OUTPUT_METADATA with EOTFs that are > unknown in the kernel. > > The second one prints a connector's max_bpc as part of the atomic > state debugfs print. > > The following patches rework the connector colorspace code to > 1) allow for easy printing of the colorspace in the drm_atomic >state debugfs, and > 2) allow drivers to specify the supported colorspaces on a >connector. > > The rest of the patches deal with the Colorspace enablement > in amdgpu. > > Why do drivers need to specify supported colorspaces? The amdgpu > driver needs support for RGB-to-YCbCr conversion when we drive > the display in YCbCr. This is currently not implemented for all > colorspaces. > > Since the Colorspace property didn't have an IGT test I added > one to kms_hdr. The relevant patchset can be found on the IGT > mailing list or on > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry > > We tested v1 of the patchset and confirmed that the infoframes > are as expected for both DP and HDMI when running the IGT > colorimetry tests. > > Open Items > -- > > A couple comments from Pekka about colorspace documentation are > left unaddressed. I hope they won't block merging this set but > should still be addressed separately. > > Pekka's questions really got me thinking of how this colorspace > property should be used and working with it more closely with > Joshua who is enabling HDR in gamescope made me wonder even more. > > Uma, is there a (canonical, upstream) userspace that uses this > property that I can look at to understand more? > > One of the key challenges that is currently not addressed is that > userspace is expected to pick a colorspace format straight from the > list of definitions out of the DP or HDMI spec. But the kernel > driver are the ones deciding on the output encoding (RGB, YCBCR444, > YCBCR420, etc.). So there is no way for userspace to decide correctly > between, for example, BT2020_RGB, BT2020_CYCC, BT2020_YCC. > > So we end up in a scenario where gamescope sets BT2020_RGB but we > output YCBCR444 so have to correct the colorspace value to > BT2020_YCC. This in turn breaks the colorspace IGT tests I > wrote. I don't think "fixing" the IGT tests to accept this is > the right thing to do. > > The way it stands this patchset allows us to specify the output > colorspace on amdgpu and we try to do the right thing, but I don't > thing the way the colorspace property is defined is right. We're trying > to expose things to userspace that should be under driver control. A > much better approach would be to give userspace options for colorspace > that are not tied to DP or HDMI specs, i.e., sRGB, BT709, BT2020, etc., > and have the driver do the right thing to fill the infoframe, e.g., by > picking BT2020_YCC if the requested colorspace is BT2020 and the > is YCBCR444. > > If no upstream userspace currently makes use of this property I > can make that change, i.e., no longer tie the colorspace property > directly to the infoframe and reduce the options to sRGB, BT709, > BT601, and BT2020 (and possibly opRGB). > > v2: > - Tested with DP and HDMI analyzers > - Confirmed driver will fallback to lower bpc when needed > - Dropped hunk to set HDMI AVI infoframe as it was a no-op > - Fixed BT.2020 YCbCr colorimetry (JoshuaAshton) > - Simplify initialization of supported colorspaces (Jani) > - Fix kerneldoc (kernel test robot) > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Joshua Ashton > Cc: Jani Nikula > Cc: Michel Dänzer > Cc: dri-devel@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > > Harry Wentland (16): > drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF > drm/connector: print max_requested_bpc in state debugfs > drm/connector: Drop COLORIMETRY_NO_DATA > drm/connector: Convert DRM_MODE_COLORIMETRY to enum > drm/connector: Pull out common create_colorspace_property code > drm/connector: Allow drivers to pass list of supported colorspaces > drm/connector: Print connector colorspace in state debugfs > drm/amd/display: Always pass connector_state to stream validation > drm/amd/display: Register Colorspace property for DP and HDMI > drm/amd/display: Signal mode_changed if color
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä wrote: > > On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote: > > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä > > wrote: > > > > > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > > > On Fri, 17 Mar 2023 16:14:38 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka > > > > > > > > > > > > > Paalanen wrote: > > > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, > > > > > > > > > > > > > > > Sebastian Wick wrote: > > > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the > > > > > > > > > > > > > > > > > output > > > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user > > > > > > > > > > > > > > > > space has to check the > > > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking > > > > > > > > > > > > > > > > if the sink supports > > > > > > > > > > > > > > > > both RGB and YUV variants because both could be > > > > > > > > > > > > > > > > used by the driver. > > > > > > > > > > > > > > > > Not great at all. Something to remember for the > > > > > > > > > > > > > > > > new property. > >
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä wrote: > > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote: > > On Fri, 17 Mar 2023 16:14:38 +0200 > > Ville Syrjälä wrote: > > > > > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote: > > > > On Fri, 17 Mar 2023 14:50:40 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote: > > > > > > On Fri, 17 Mar 2023 01:01:38 +0200 > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote: > > > > > > > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen > > > > > > > > > wrote: > > > > > > > > > > On Thu, 16 Mar 2023 12:47:51 +0200 > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > > > > > > > > > Ville Syrjälä wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian > > > > > > > > > > > > > Wick wrote: > > > > > > > > > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > > > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > > > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > About that... The documentation says that user > > > > > > > > > > > > > > space has to check the > > > > > > > > > > > > > > EDID for what the sink actually supports. So > > > > > > > > > > > > > > whatever is in > > > > > > > > > > > > > > supported_colorspaces is just what the > > > > > > > > > > > > > > driver/hardware is able to set > > > > > > > > > > > > > > but doesn't actually indicate that the sink > > > > > > > > > > > > > > supports it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the only way to enable bt2020 is by checking if > > > > > > > > > > > > > > the sink supports > > > > > > > > > > > > > > both RGB and YUV variants because both could be > > > > > > > > > > > > > > used by the driver. > > > > > > > > > > > > > > Not great at all. Something to remember for the new > > > > > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like > > > > > > > > > > > > > maybe it > > > > > > > > > > > > > is since I can't immediately spot anything in CTA-861 > > > > > > > > > > > > > to > > > > > > > > > > > > > forbid it :/ > > > > > > > > > > > > > > > > > > > > > > > > Wouldn't the driver do the same EDID check before > > > > > > > > > > > > choosing whether it > > > > > > > > > > > > uses RGB or YCbCr signalling? > > > &
Re: [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 11:59 PM Rob Clark wrote: > > On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick > wrote: > > > > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote: > > > > > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming > > > > > > > > > deadline, such as > > > > > > > > > vblank, which the fence waiter would prefer not to miss. > > > > > > > > > This is to aid > > > > > > > > > the fence signaler in making power management decisions, like > > > > > > > > > boosting > > > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > > > deadlines > > > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter > > > > > > > > > duplicate > > > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > > > fence-context > > > > > > > > > implementation will need similar logic to track deadlines > > > > > > > > > of all > > > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > > > v6: More docs > > > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > > > Reviewed-by: Christian König > > > > > > > > > Acked-by: Pekka Paalanen > > > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > > > --- > > > > > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > > > + > > > > > > > > > + > > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > > + :doc: deadline hints > > > > > > > > > + > > > > > > > > > DMA Fences Functions Reference > > > > > > > > > ~~~
Re: [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote: > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote: > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > From: Rob Clark > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming deadline, > > > > > > > such as > > > > > > > vblank, which the fence waiter would prefer not to miss. This is > > > > > > > to aid > > > > > > > the fence signaler in making power management decisions, like > > > > > > > boosting > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > deadlines > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter duplicate > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > fence-context > > > > > > > implementation will need similar logic to track deadlines of > > > > > > > all > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > v6: More docs > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > Reviewed-by: Christian König > > > > > > > Acked-by: Pekka Paalanen > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > --- > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > + > > > > > > > + > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > + :doc: deadline hints > > > > > > > + > > > > > > > DMA Fences Functions Reference > > > > > > > ~~ > > > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence > > > > > > > **fences, uint32_t count, > > > > > > > } > > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > > > +/** > > > > > > > + * DOC: deadline hints > > > > > > > + * > > > > > > > + * In an ideal world, it would be possible to pipeline a > > > > > > > workload sufficiently > > > > > > > + * that a utilization based device frequency governor could > > > > > > > arrive at a minimum > > > > > > > + * frequency that meets the requirements of the use-case, in > > > > > > > order to minimize > > > > > > > + * power consumption. But in the real world there are many > > > > > > > workloads which > > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > > + * > > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > > alternating periods > > > > > > > + * of CPU waiting for device, and device waiting on CPU. This > > > > > > > can result in > > > > > > > + * devfreq and cpufreq seeing idle time in their respective > > > > > > > domains and in > > > > > > > + * result reduce frequency. > > > > > > > + * > > > > > > > + * * Workloads that interact with a periodic time based > > > > > > > deadline, such as double > > > > > > > + * buffered GPU rendering vs vblank sync'd page flipping. In > > > > > > > this scenario, > > > > > > > + * missing a vblank deadline results in an *increase* in idle > > > > > > > time on the GPU > > > > > > > + * (since it has to wait an additional vblank period), sending > > > > > > > a signal to > > > > > > > + * the GPU's devfreq to reduce frequency, when in fact the > > > > > > > opposite is what is > > > > > > > + * needed. > > > > > > > > > > > > This is the use case I'd like to get some
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä wrote: > > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote: > > On Thu, 16 Mar 2023 12:47:51 +0200 > > Ville Syrjälä wrote: > > > > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote: > > > > On Thu, 16 Mar 2023 11:50:27 +0200 > > > > Ville Syrjälä wrote: > > > > > > > > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote: > > > > > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland > > > > > > wrote: > > > > > > > > > > > > > > We want compositors to be able to set the output > > > > > > > colorspace on DP and HDMI outputs, based on the > > > > > > > caps reported from the receiver via EDID. > > > > > > > > > > > > About that... The documentation says that user space has to check > > > > > > the > > > > > > EDID for what the sink actually supports. So whatever is in > > > > > > supported_colorspaces is just what the driver/hardware is able to > > > > > > set > > > > > > but doesn't actually indicate that the sink supports it. > > > > > > > > > > > > So the only way to enable bt2020 is by checking if the sink supports > > > > > > both RGB and YUV variants because both could be used by the driver. > > > > > > Not great at all. Something to remember for the new property. > > > > > > > > > > Hmm. I wonder if that's even legal... Looks like maybe it > > > > > is since I can't immediately spot anything in CTA-861 to > > > > > forbid it :/ > > > > > > > > Wouldn't the driver do the same EDID check before choosing whether it > > > > uses RGB or YCbCr signalling? > > > > > > I suppose it could. The modeset would then fail, which is perhaps > > > > Could? What are they missing? > > The fact that the new property that also affects the rgb->ycbcr matrix > doesn't even exist? I think the question was about the current Colorspace property. > > > > I mean, drivers are already automatically choosing between RGB and YCbCr > > signalling based on e.g. available bandwidth. Surely they already will > > not attempt to send a signal format to a monitor that does not say it > > supports that? That's exactly what they do. The drivers don't check the EDID for the colorimetry the sink supports and the responsibility is punted off to user space. > > We just signal default/bt.709 colorimetry. There is nothing to > check for those IIRC. You do support bt.2020, no? > > > > > not a huge issue, except maybe for suspend+resume if we fail in > > > the resume path. Although I guess the EDID/etc. should not yet > > > be refreshed at that point so if the modeset worked before suspend > > > resume should be able to restore it without failures. > > > > I assumed that if a monitor can be driven, and it supports any BT2020 > > format, then it always supports the BT2020 format it is being driven > > in (RGB vs. YCbCr flavors). Bad assumption? > > I didn't spot any rule that both must be there. But didn't look > too hard either. Didn't see anything like that either and I looked a bit harder as well. > > -- > Ville Syrjälä > Intel >
Re: [PATCH v3 09/17] drm/amd/display: Register Colorspace property for DP and HDMI
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.
About that... The documentation says that user space has to check the
EDID for what the sink actually supports. So whatever is in
supported_colorspaces is just what the driver/hardware is able to set
but doesn't actually indicate that the sink supports it.
So the only way to enable bt2020 is by checking if the sink supports
both RGB and YUV variants because both could be used by the driver.
Not great at all. Something to remember for the new property.
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Reviewed-By: Joshua Ashton
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index f91b2ea13d96..2d883c6dae90 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7184,6 +7184,12 @@ static int amdgpu_dm_connector_get_modes(struct
> drm_connector *connector)
> return amdgpu_dm_connector->num_modes;
> }
>
> +static const u32 supported_colorspaces =
> + BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> + BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED);
> +
> void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> struct amdgpu_dm_connector *aconnector,
> int connector_type,
> @@ -7264,6 +7270,15 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> adev->mode_info.abm_level_property, 0);
> }
>
> + if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> + if
> (!drm_mode_create_hdmi_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + if
> (!drm_mode_create_dp_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + }
> +
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> connector_type == DRM_MODE_CONNECTOR_eDP) {
> --
> 2.39.2
>
Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace
On Thu, Mar 9, 2023 at 11:03 AM Pekka Paalanen wrote:
>
> On Thu, 9 Mar 2023 01:56:11 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 7 Mar 2023 10:10:52 -0500
> > > Harry Wentland wrote:
> > >
> > > > From: Joshua Ashton
> > > >
> > > > To match the other enums, and add more information about these values.
> > > >
> > > > v2:
> > > > - Specify where an enum entry comes from
> > > > - Clarify DEFAULT and NO_DATA behavior
> > > > - BT.2020 CYCC is "constant luminance"
> > > > - correct type for BT.601
> > > >
> > > > Signed-off-by: Joshua Ashton
> > > > Signed-off-by: Harry Wentland
> > > > Reviewed-by: Harry Wentland
> > >
> > > Hi,
> > >
> > > this effort is really good, but of course I still find things to
> > > nitpick about. If there is no answer to my questions, then I would
> > > prefer the documentation to spell out the unknowns and ambiguities.
> > >
> > > > Cc: Pekka Paalanen
> > > > Cc: Sebastian Wick
> > > > Cc: vitaly.pros...@amd.com
> > > > Cc: Uma Shankar
> > > > Cc: Ville Syrjälä
> > > > Cc: Joshua Ashton
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: amd-...@lists.freedesktop.org
> > > > ---
> > > > include/drm/drm_connector.h | 67 +++--
> > > > 1 file changed, 65 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index 6d6a53a6b010..bb078666dc34 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > > > PRIVACY_SCREEN_ENABLED_LOCKED,
> > > > };
> > > >
> > > > -/*
> > > > - * This is a consolidated colorimetry list supported by HDMI and
> > > > +/**
> > > > + * enum drm_colorspace - color space
> > > > + *
> > > > + * This enum is a consolidated colorimetry list supported by HDMI and
> > > > * DP protocol standard. The respective connectors will register
> > > > * a property with the subset of this list (supported by that
> > > > * respective protocol). Userspace will set the colorspace through
> > > > * a colorspace property which will be created and exposed to
> > > > * userspace.
> > > > + *
> > > > + * DP definitions come from the DP v2.0 spec
> > > > + * HDMI definitions come from the CTA-861-H spec
> > > > + *
> > > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > > + * Driver specific behavior.
> > > > + * For DP:
> > > > + * RGB encoded: sRGB (IEC 61966-2-1)
> > > > + * YCbCr encoded: ITU-R BT.601 colorimetry format
> > >
> > > Does this mean that HDMI behavior is driver-specific while DP behavior
> > > is as defined?
> > >
> > > Is it intentional that YCbCr encoding also uses different RGB-primaries
> > > than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> > >
> > > Or do you need to be more explicit on which parts of each spec apply
> > > (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> > > CICP parlance)?
> > >
> > > E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
> >
> > Yeah, just adding to this: The Default Colorspace is something well
> > defined. CTA-861 says:
> >
> > "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> > default colorimetry defined in Section 5.1"
> >
> > and in Section 5.1
> >
> > "In all cases described above, the RGB color space used should be the
> > RGB color space the Sink declares in the Basic Display Parameters and
> > Feature Block of its EDID."
> >
> > If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
> > EDID reports to be in effect and not some driver specific nonsense.
>
> Does that also define the MatrixCoefficients for YCbCr signal with
> DRM_MODE_COLORIMETRY_DEFAULT?
Good question. It doesn't seem like it does, which would make
supporting YCC with the default color space impossible.
> Not that userspace would even care, since RGB-to-YCbCr is all
> driver-internal.
>
> It is interesting you point that out. I guess it means that the basic
> colorimetry from EDID is supposed to be really only the default
> colorimetry and might not have anything to do with the actual panel
> primaries.
>
>
> Thanks,
> pq
Re: [PATCH v3 14/17] drm/amd/display: Add debugfs for testing output colorspace
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> In order to IGT test colorspace we'll want to print
> the currently enabled colorspace on a stream. We add
> a new debugfs to do so, using the same scheme as
> current bpc reporting.
>
> This might also come in handy when debugging display
> issues.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Reviewed-By: Joshua Ashton
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 4a5dae578d97..f0022c16b708 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -906,6 +906,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m,
> void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
>
> +/*
> + * Returns the current bpc for the crtc.
> + * Example usage: cat
> /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
> + */
> +static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
> +{
> + struct drm_crtc *crtc = m->private;
> + struct drm_device *dev = crtc->dev;
> + struct dm_crtc_state *dm_crtc_state = NULL;
> + int res = -ENODEV;
> +
> + mutex_lock(>mode_config.mutex);
> + drm_modeset_lock(>mutex, NULL);
> + if (crtc->state == NULL)
> + goto unlock;
> +
> + dm_crtc_state = to_dm_crtc_state(crtc->state);
> + if (dm_crtc_state->stream == NULL)
> + goto unlock;
> +
> + switch (dm_crtc_state->stream->output_color_space) {
> + case COLOR_SPACE_SRGB:
> + seq_printf(m, "RGB");
> + break;
Why does it print "RGB" when it says the color space is sRGB? Looking
at the value when I didn't specify any color space it says RGB. Why is
your default color space sRGB?
> + case COLOR_SPACE_YCBCR601:
> + case COLOR_SPACE_YCBCR601_LIMITED:
> + seq_printf(m, "BT601_YCC");
> + break;
> + case COLOR_SPACE_YCBCR709:
> + case COLOR_SPACE_YCBCR709_LIMITED:
> + seq_printf(m, "BT709_YCC");
> + break;
> + case COLOR_SPACE_ADOBERGB:
> + seq_printf(m, "opRGB");
> + break;
> + case COLOR_SPACE_2020_RGB_FULLRANGE:
> + seq_printf(m, "BT2020_RGB");
> + break;
> + case COLOR_SPACE_2020_YCBCR:
> + seq_printf(m, "BT2020_YCC");
> + break;
> + default:
> + goto unlock;
> + }
> + res = 0;
> +
> +unlock:
> + drm_modeset_unlock(>mutex);
> + mutex_unlock(>mode_config.mutex);
> +
> + return res;
> +}
> +DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
> +
> +
> /*
> * Example usage:
> * Disable dsc passthrough, i.e.,: have dsc decoding at converver, not
> external RX
> @@ -3235,6 +3290,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
> #endif
> debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
> crtc, _current_bpc_fops);
> + debugfs_create_file("amdgpu_current_colorspace", 0644,
> crtc->debugfs_entry,
> + crtc, _current_colorspace_fops);
> }
>
> /*
> --
> 2.39.2
>
Re: [PATCH v3 11/17] drm/amd/display: Send correct DP colorspace infopacket
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> Look at connector->colorimetry to determine output colorspace.
>
> We don't want to impact current SDR behavior, so
> DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Reviewed-By: Joshua Ashton
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 58fc719bec8d..cdfd09d50ee6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5302,21 +5302,21 @@ get_aspect_ratio(const struct drm_display_mode
> *mode_in)
> }
>
> static enum dc_color_space
> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
> + const struct drm_connector_state *connector_state)
> {
> enum dc_color_space color_space = COLOR_SPACE_SRGB;
>
> - switch (dc_crtc_timing->pixel_encoding) {
> - case PIXEL_ENCODING_YCBCR422:
> - case PIXEL_ENCODING_YCBCR444:
> - case PIXEL_ENCODING_YCBCR420:
> - {
> + switch (connector_state->colorspace) {
> + case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
So, I do get random behavior with DRM_MODE_COLORIMETRY_DEFAULT instead
of the colorimetry that the EDID specifies? That doesn't sound good at
all.
> + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
> + color_space = COLOR_SPACE_SRGB;
> /*
> * 27030khz is the separation point between HDTV and SDTV
> * according to HDMI spec, we use YCbCr709 and YCbCr601
> * respectively
> */
> - if (dc_crtc_timing->pix_clk_100hz > 270300) {
> + } else if (dc_crtc_timing->pix_clk_100hz > 270300) {
> if (dc_crtc_timing->flags.Y_ONLY)
> color_space =
> COLOR_SPACE_YCBCR709_LIMITED;
> @@ -5329,15 +5329,21 @@ get_output_color_space(const struct dc_crtc_timing
> *dc_crtc_timing)
> else
> color_space = COLOR_SPACE_YCBCR601;
> }
> -
> - }
> - break;
> - case PIXEL_ENCODING_RGB:
> - color_space = COLOR_SPACE_SRGB;
> break;
> -
> - default:
> - WARN_ON(1);
> + case DRM_MODE_COLORIMETRY_BT709_YCC:
> + if (dc_crtc_timing->flags.Y_ONLY)
> + color_space = COLOR_SPACE_YCBCR709_LIMITED;
> + else
> + color_space = COLOR_SPACE_YCBCR709;
> + break;
> + case DRM_MODE_COLORIMETRY_OPRGB:
> + color_space = COLOR_SPACE_ADOBERGB;
> + break;
> + case DRM_MODE_COLORIMETRY_BT2020:
> + color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
> + break;
> + case DRM_MODE_COLORIMETRY_BT2020_DEPRECATED:
> + color_space = COLOR_SPACE_2020_YCBCR;
> break;
> }
>
> @@ -5476,7 +5482,7 @@ static void
> fill_stream_properties_from_drm_display_mode(
> }
> }
>
> - stream->output_color_space = get_output_color_space(timing_out);
> + stream->output_color_space = get_output_color_space(timing_out,
> connector_state);
> }
>
> static void fill_audio_info(struct audio_info *audio_info,
> --
> 2.39.2
>
Re: [PATCH v3 05/17] drm/connector: Use common colorspace_names array
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> We an use bitfields to track the support ones for HDMI
> and DP. This allows us to print colorspaces in a consistent
> manner without needing to know whether we're dealing with
> DP or HDMI.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Joshua Ashton
> Cc: Jani Nikula
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_connector.c | 131 +++-
> include/drm/drm_connector.h | 1 +
> 2 files changed, 78 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ff4af48c029a..7649f0ac454f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1012,64 +1012,70 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> drm_dp_subconnector_enum_list)
>
> -static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> +
> +static const char * const colorspace_names[] = {
> /* For Default case, driver will set the colorspace */
> - { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + [DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
> /* Standard Definition Colorimetry based on CEA 861 */
> - { DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
> - { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> + [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
> + [DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
> /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> - { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> + [DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
> /* High Definition Colorimetry based on IEC 61966-2-4 */
> - { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> + [DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
> /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> - { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> + [DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
> /* Colorimetry based on IEC 61966-2-5 [33] */
> - { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> + [DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
> /* Colorimetry based on IEC 61966-2-5 */
> - { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + [DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> + [DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> + [DRM_MODE_COLORIMETRY_BT2020] = "BT2020",
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> - /* Added as part of Additional Colorimetry Extension in 861.G */
> - { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> - { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = "BT2020_DEPRECATED",
> + /* Colorimetry based on SMPTE RP 431-2 */
> + [DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "P3_RGB_D65",
> + [DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "P3_RGB_Theater",
> + [DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
> + /* Colorimetry based on scRGB (IEC 61966-2-2) */
> + [DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
> + [DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
> };
>
> +static const u32 hdmi_colorspaces =
> + BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
> + BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> + BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
> + BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
> + BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
> + BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
> + BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_DEPRECATED) |
> + BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> + BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> +
&g
Re: [PATCH v3 03/17] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Wed, Mar 8, 2023 at 10:09 AM Pekka Paalanen wrote:
>
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland wrote:
>
> > From: Joshua Ashton
> >
> > Userspace has no way of controlling or knowing the pixel encoding
> > currently, so there is no way for it to ever get the right values here.
> >
> > When we do add pixel_encoding control from userspace,we can pick the
> > right value for the colorimetry packet based on the
> > pixel_encoding + the colorspace.
> >
> > Let's deprecate these values, and have one BT.2020 colorspace entry
> > that userspace can use.
> >
> > v2:
> > - leave CYCC alone for now; it serves a purpose
> > - leave BT2020_RGB the new default BT2020
> >
> > Signed-off-by: Joshua Ashton
> > Signed-off-by: Harry Wentland
> > Reviewed-by: Harry Wentland
> >
> > Cc: Pekka Paalanen
> > Cc: Sebastian Wick
> > Cc: vitaly.pros...@amd.com
> > Cc: Uma Shankar
> > Cc: Ville Syrjälä
> > Cc: Joshua Ashton
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/display/drm_hdmi_helper.c | 7 +++
> > drivers/gpu/drm/drm_connector.c | 8
> > drivers/gpu/drm/i915/display/intel_dp.c | 14 +++---
> > include/drm/drm_connector.h | 15 +--
> > 4 files changed, 23 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > index faf5e9efa7d3..05a0d03ffcda 100644
> > --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > @@ -97,8 +97,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> > #define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
> > #define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
> > +#define HDMI_COLORIMETRY_BT2020 (C(3) | EC(6) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) | ACE(1))
> >
> > @@ -112,8 +111,8 @@ static const u32 hdmi_colorimetry_val[] = {
> > [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> > [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> > [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> > - [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> > - [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> > + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED] = HDMI_COLORIMETRY_BT2020,
> > + [DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
> > };
> >
> > #undef C
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 61c29ce74b03..fe7eab15f727 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1031,9 +1031,9 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > /* Colorimetry based on ITU-R BT.2020 */
> > { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > /* Colorimetry based on ITU-R BT.2020 */
> > - { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > + { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> > /* Colorimetry based on ITU-R BT.2020 */
> > - { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > + { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED, "BT2020_DEPRECATED" },
> > /* Added as part of Additional Colorimetry Extension in 861.G */
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> > @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list
> > dp_colorspaces[] = {
> > /* Colorimetry based on SMPTE RP 431-2 */
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > /* Colorimetry based on ITU-R BT.2020 */
> > - { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > + { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> > { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC"
Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace
On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
>
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland wrote:
>
> > From: Joshua Ashton
> >
> > To match the other enums, and add more information about these values.
> >
> > v2:
> > - Specify where an enum entry comes from
> > - Clarify DEFAULT and NO_DATA behavior
> > - BT.2020 CYCC is "constant luminance"
> > - correct type for BT.601
> >
> > Signed-off-by: Joshua Ashton
> > Signed-off-by: Harry Wentland
> > Reviewed-by: Harry Wentland
>
> Hi,
>
> this effort is really good, but of course I still find things to
> nitpick about. If there is no answer to my questions, then I would
> prefer the documentation to spell out the unknowns and ambiguities.
>
> > Cc: Pekka Paalanen
> > Cc: Sebastian Wick
> > Cc: vitaly.pros...@amd.com
> > Cc: Uma Shankar
> > Cc: Ville Syrjälä
> > Cc: Joshua Ashton
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-...@lists.freedesktop.org
> > ---
> > include/drm/drm_connector.h | 67 +++--
> > 1 file changed, 65 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 6d6a53a6b010..bb078666dc34 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > PRIVACY_SCREEN_ENABLED_LOCKED,
> > };
> >
> > -/*
> > - * This is a consolidated colorimetry list supported by HDMI and
> > +/**
> > + * enum drm_colorspace - color space
> > + *
> > + * This enum is a consolidated colorimetry list supported by HDMI and
> > * DP protocol standard. The respective connectors will register
> > * a property with the subset of this list (supported by that
> > * respective protocol). Userspace will set the colorspace through
> > * a colorspace property which will be created and exposed to
> > * userspace.
> > + *
> > + * DP definitions come from the DP v2.0 spec
> > + * HDMI definitions come from the CTA-861-H spec
> > + *
> > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > + * Driver specific behavior.
> > + * For DP:
> > + * RGB encoded: sRGB (IEC 61966-2-1)
> > + * YCbCr encoded: ITU-R BT.601 colorimetry format
>
> Does this mean that HDMI behavior is driver-specific while DP behavior
> is as defined?
>
> Is it intentional that YCbCr encoding also uses different RGB-primaries
> than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
>
> Or do you need to be more explicit on which parts of each spec apply
> (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> CICP parlance)?
>
> E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
Yeah, just adding to this: The Default Colorspace is something well
defined. CTA-861 says:
"If bits C0 and C1 are zero, the colorimetry shall correspond to the
default colorimetry defined in Section 5.1"
and in Section 5.1
"In all cases described above, the RGB color space used should be the
RGB color space the Sink declares in the Basic Display Parameters and
Feature Block of its EDID."
If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
EDID reports to be in effect and not some driver specific nonsense.
> > + * @DRM_MODE_COLORIMETRY_NO_DATA:
> > + * Driver specific behavior.
> > + * For HDMI:
> > + * Sets "No Data" in infoframe
>
> Does DEFAULT mean that something else than "No Data" may be set in the
> HDMI infoframe?
>
> If so, since these two have the same value, where is the difference? Is
> DEFAULT purely an UAPI token, and NO_DATA used internally? Or NO_DATA
> used only when crafting actual infoframe packets?
>
> Should NO_DATA be documented to be a strictly driver-internal value,
> and not documented with UAPI?
>
> I am unclear if userspace is using these enum values directly, or do
> they use the string names only.
>
> > + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> > + * (HDMI)
> > + * SMPTE ST 170M colorimetry format
>
> Does "colorimetry format" mean that the spec is used in full, for all
> of ColourPrimaries, TransferCharacteristics and MatrixCoefficients?
>
> If yes, good. If not, the wording misleads me.
>
> > + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> > + * (HDMI, DP)
> > + * ITU-R BT.709 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> > + * (HDMI, DP)
> > + * xvYCC601 colorimetry format
> > + * @DRM_MODE_COLORIMETRY_XV
Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
On Tue, Feb 28, 2023 at 11:52 PM Rob Clark wrote: > > On Tue, Feb 28, 2023 at 6:30 AM Sebastian Wick > wrote: > > > > On Tue, Feb 28, 2023 at 12:48 AM Rob Clark wrote: > > > > > > On Mon, Feb 27, 2023 at 2:44 PM Sebastian Wick > > > wrote: > > > > > > > > On Mon, Feb 27, 2023 at 11:20 PM Rob Clark wrote: > > > > > > > > > > On Mon, Feb 27, 2023 at 1:36 PM Rodrigo Vivi > > > > > wrote: > > > > > > > > > > > > On Fri, Feb 24, 2023 at 09:59:57AM -0800, Rob Clark wrote: > > > > > > > On Fri, Feb 24, 2023 at 7:27 AM Luben Tuikov > > > > > > > wrote: > > > > > > > > > > > > > > > > On 2023-02-24 06:37, Tvrtko Ursulin wrote: > > > > > > > > > > > > > > > > > > On 24/02/2023 11:00, Pekka Paalanen wrote: > > > > > > > > >> On Fri, 24 Feb 2023 10:50:51 + > > > > > > > > >> Tvrtko Ursulin wrote: > > > > > > > > >> > > > > > > > > >>> On 24/02/2023 10:24, Pekka Paalanen wrote: > > > > > > > > >>>> On Fri, 24 Feb 2023 09:41:46 + > > > > > > > > >>>> Tvrtko Ursulin wrote: > > > > > > > > >>>> > > > > > > > > >>>>> On 24/02/2023 09:26, Pekka Paalanen wrote: > > > > > > > > >>>>>> On Thu, 23 Feb 2023 10:51:48 -0800 > > > > > > > > >>>>>> Rob Clark wrote: > > > > > > > > >>>>>> > > > > > > > > >>>>>>> On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen > > > > > > > > >>>>>>> wrote: > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>>> On Wed, 22 Feb 2023 07:37:26 -0800 > > > > > > > > >>>>>>>> Rob Clark wrote: > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>>>> On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen > > > > > > > > >>>>>>>>> wrote: > > > > > > > > >>>>>> > > > > > > > > >>>>>> ... > > > > > > > > >>>>>> > > > > > > > > >>>>>>>>>> On another matter, if the application uses > > > > > > > > >>>>>>>>>> SET_DEADLINE with one > > > > > > > > >>>>>>>>>> timestamp, and the compositor uses SET_DEADLINE on > > > > > > > > >>>>>>>>>> the same thing with > > > > > > > > >>>>>>>>>> another timestamp, what should happen? > > > > > > > > >>>>>>>>> > > > > > > > > >>>>>>>>> The expectation is that many deadline hints can be > > > > > > > > >>>>>>>>> set on a fence. > > > > > > > > >>>>>>>>> The fence signaller should track the soonest deadline. > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>>> You need to document that as UAPI, since it is > > > > > > > > >>>>>>>> observable to userspace. > > > > > > > > >>>>>>>> It would be bad if drivers or subsystems would differ > > > > > > > > >>>>>>>> in behaviour. > > > > > > > > >>>>>>>> > > > > > > > > >>>>>>> > > > > > > > > >>>>>>> It is in the end a hint. It is about giving the driver > > > > > > > > >>>>>>> more > > > > > > > > >>>>>>> information so that it can make better choices. But > > > > > > > > >>>>>>> the driver is > > > > > > > > >>>>>>> even free to ig
Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
On Tue, Feb 28, 2023 at 12:48 AM Rob Clark wrote: > > On Mon, Feb 27, 2023 at 2:44 PM Sebastian Wick > wrote: > > > > On Mon, Feb 27, 2023 at 11:20 PM Rob Clark wrote: > > > > > > On Mon, Feb 27, 2023 at 1:36 PM Rodrigo Vivi > > > wrote: > > > > > > > > On Fri, Feb 24, 2023 at 09:59:57AM -0800, Rob Clark wrote: > > > > > On Fri, Feb 24, 2023 at 7:27 AM Luben Tuikov > > > > > wrote: > > > > > > > > > > > > On 2023-02-24 06:37, Tvrtko Ursulin wrote: > > > > > > > > > > > > > > On 24/02/2023 11:00, Pekka Paalanen wrote: > > > > > > >> On Fri, 24 Feb 2023 10:50:51 + > > > > > > >> Tvrtko Ursulin wrote: > > > > > > >> > > > > > > >>> On 24/02/2023 10:24, Pekka Paalanen wrote: > > > > > > >>>> On Fri, 24 Feb 2023 09:41:46 + > > > > > > >>>> Tvrtko Ursulin wrote: > > > > > > >>>> > > > > > > >>>>> On 24/02/2023 09:26, Pekka Paalanen wrote: > > > > > > >>>>>> On Thu, 23 Feb 2023 10:51:48 -0800 > > > > > > >>>>>> Rob Clark wrote: > > > > > > >>>>>> > > > > > > >>>>>>> On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen > > > > > > >>>>>>> wrote: > > > > > > >>>>>>>> > > > > > > >>>>>>>> On Wed, 22 Feb 2023 07:37:26 -0800 > > > > > > >>>>>>>> Rob Clark wrote: > > > > > > >>>>>>>> > > > > > > >>>>>>>>> On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen > > > > > > >>>>>>>>> wrote: > > > > > > >>>>>> > > > > > > >>>>>> ... > > > > > > >>>>>> > > > > > > >>>>>>>>>> On another matter, if the application uses SET_DEADLINE > > > > > > >>>>>>>>>> with one > > > > > > >>>>>>>>>> timestamp, and the compositor uses SET_DEADLINE on the > > > > > > >>>>>>>>>> same thing with > > > > > > >>>>>>>>>> another timestamp, what should happen? > > > > > > >>>>>>>>> > > > > > > >>>>>>>>> The expectation is that many deadline hints can be set on > > > > > > >>>>>>>>> a fence. > > > > > > >>>>>>>>> The fence signaller should track the soonest deadline. > > > > > > >>>>>>>> > > > > > > >>>>>>>> You need to document that as UAPI, since it is observable > > > > > > >>>>>>>> to userspace. > > > > > > >>>>>>>> It would be bad if drivers or subsystems would differ in > > > > > > >>>>>>>> behaviour. > > > > > > >>>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>> It is in the end a hint. It is about giving the driver more > > > > > > >>>>>>> information so that it can make better choices. But the > > > > > > >>>>>>> driver is > > > > > > >>>>>>> even free to ignore it. So maybe "expectation" is too > > > > > > >>>>>>> strong of a > > > > > > >>>>>>> word. Rather, any other behavior doesn't really make > > > > > > >>>>>>> sense. But it > > > > > > >>>>>>> could end up being dictated by how the hw and/or fw works. > > > > > > >>>>>> > > > > > > >>>>>> It will stop being a hint once it has been implemented and > > > > > > >>>>>> used in the > > > > > > >>>>>> wild long enough. The kernel userspace regression rules m
Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
On Mon, Feb 27, 2023 at 11:20 PM Rob Clark wrote: > > On Mon, Feb 27, 2023 at 1:36 PM Rodrigo Vivi wrote: > > > > On Fri, Feb 24, 2023 at 09:59:57AM -0800, Rob Clark wrote: > > > On Fri, Feb 24, 2023 at 7:27 AM Luben Tuikov wrote: > > > > > > > > On 2023-02-24 06:37, Tvrtko Ursulin wrote: > > > > > > > > > > On 24/02/2023 11:00, Pekka Paalanen wrote: > > > > >> On Fri, 24 Feb 2023 10:50:51 + > > > > >> Tvrtko Ursulin wrote: > > > > >> > > > > >>> On 24/02/2023 10:24, Pekka Paalanen wrote: > > > > On Fri, 24 Feb 2023 09:41:46 + > > > > Tvrtko Ursulin wrote: > > > > > > > > > On 24/02/2023 09:26, Pekka Paalanen wrote: > > > > >> On Thu, 23 Feb 2023 10:51:48 -0800 > > > > >> Rob Clark wrote: > > > > >> > > > > >>> On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen > > > > >>> wrote: > > > > > > > > On Wed, 22 Feb 2023 07:37:26 -0800 > > > > Rob Clark wrote: > > > > > > > > > On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen > > > > > wrote: > > > > >> > > > > >> ... > > > > >> > > > > >> On another matter, if the application uses SET_DEADLINE with > > > > >> one > > > > >> timestamp, and the compositor uses SET_DEADLINE on the same > > > > >> thing with > > > > >> another timestamp, what should happen? > > > > > > > > > > The expectation is that many deadline hints can be set on a > > > > > fence. > > > > > The fence signaller should track the soonest deadline. > > > > > > > > You need to document that as UAPI, since it is observable to > > > > userspace. > > > > It would be bad if drivers or subsystems would differ in > > > > behaviour. > > > > > > > > >>> > > > > >>> It is in the end a hint. It is about giving the driver more > > > > >>> information so that it can make better choices. But the driver > > > > >>> is > > > > >>> even free to ignore it. So maybe "expectation" is too strong > > > > >>> of a > > > > >>> word. Rather, any other behavior doesn't really make sense. > > > > >>> But it > > > > >>> could end up being dictated by how the hw and/or fw works. > > > > >> > > > > >> It will stop being a hint once it has been implemented and used > > > > >> in the > > > > >> wild long enough. The kernel userspace regression rules make > > > > >> sure of > > > > >> that. > > > > > > > > > > Yeah, tricky and maybe a gray area in this case. I think we eluded > > > > > elsewhere in the thread that renaming the thing might be an > > > > > option. > > > > > > > > > > So maybe instead of deadline, which is a very strong word, use > > > > > something > > > > > along the lines of "present time hint", or "signalled time hint"? > > > > > Maybe > > > > > reads clumsy. Just throwing some ideas for a start. > > > > > > > > You can try, but I fear that if it ever changes behaviour and > > > > someone notices that, it's labelled as a kernel regression. I don't > > > > think documentation has ever been the authoritative definition of > > > > UABI > > > > in Linux, it just guides drivers and userspace towards a common > > > > understanding and common usage patterns. > > > > > > > > So even if the UABI contract is not documented (ugh), you need to > > > > be > > > > prepared to set the UABI contract through kernel implementation. > > > > >>> > > > > >>> To be the devil's advocate it probably wouldn't be an ABI > > > > >>> regression but > > > > >>> just an regression. Same way as what nice(2) priorities mean hasn't > > > > >>> always been the same over the years, I don't think there is a strict > > > > >>> contract. > > > > >>> > > > > >>> Having said that, it may be different with latency sensitive stuff > > > > >>> such > > > > >>> as UIs though since it is very observable and can be very painful > > > > >>> to users. > > > > >>> > > > > If you do not document the UABI contract, then different drivers > > > > are > > > > likely to implement it differently, leading to differing behaviour. > > > > Also userspace will invent wild ways to abuse the UABI if there is > > > > no > > > > documentation guiding it on proper use. If userspace or end users > > > > observe different behaviour, that's bad even if it's not a > > > > regression. > > > > > > > > I don't like the situation either, but it is what it is. UABI > > > > stability > > > > trumps everything regardless of whether it was documented or not. > > > > > > > > I bet userspace is going to use this as a "make it faster, make it > > > > hotter" button. I would not be surprised if someone wrote a > > > > LD_PRELOAD > > > > library that stamps any and all fences with an expired
Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
On Tue, Feb 21, 2023 at 9:38 AM Pekka Paalanen wrote:
>
> On Mon, 20 Feb 2023 08:14:47 -0800
> Rob Clark wrote:
>
> > On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen wrote:
> > >
> > > On Sat, 18 Feb 2023 13:15:49 -0800
> > > Rob Clark wrote:
> > >
> > > > From: Rob Clark
> > > >
> > > > Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
> > > > wait (as opposed to a "housekeeping" wait to know when to cleanup after
> > > > some work has completed). Usermode components of GPU driver stacks
> > > > often poll() on fence fd's to know when it is safe to do things like
> > > > free or reuse a buffer, but they can also poll() on a fence fd when
> > > > waiting to read back results from the GPU. The EPOLLPRI/POLLPRI flag
> > > > lets the kernel differentiate these two cases.
> > > >
> > > > Signed-off-by: Rob Clark
> > >
> > > Hi,
> > >
> > > where would the UAPI documentation of this go?
> > > It seems to be missing.
> >
> > Good question, I am not sure. The poll() man page has a description,
> > but my usage doesn't fit that _exactly_ (but OTOH the description is a
> > bit vague).
> >
> > > If a Wayland compositor is polling application fences to know which
> > > client buffer to use in its rendering, should the compositor poll with
> > > PRI or not? If a compositor polls with PRI, then all fences from all
> > > applications would always be PRI. Would that be harmful somehow or
> > > would it be beneficial?
> >
> > I think a compositor would rather use the deadline ioctl and then poll
> > without PRI. Otherwise you are giving an urgency signal to the fence
> > signaller which might not necessarily be needed.
> >
> > The places where I expect PRI to be useful is more in mesa (things
> > like glFinish(), readpix, and other similar sorts of blocking APIs)
>
> Sounds good. Docs... ;-)
>
> Hmm, so a compositor should set the deadline when it processes the
> wl_surface.commit, and not when it actually starts repainting, to give
> time for the driver to react and the GPU to do some more work. The
> deadline would be the time when the compositor starts its repaint, so
> it knows if the buffer is ready or not.
Technically we don't know when the commit is supposed to be shown.
Just passing a deadline of the next possible deadline however is
probably a good enough guess for this feature to be useful.
One thing that neither API allows us to do is tell the kernel in
advance when we're going to submit work and what the deadline for it
is and unfortunately that work is the most timing sensitive.
>
>
> Thanks,
> pq
>
>
> >
> > BR,
> > -R
> >
> > >
> > >
> > > Thanks,
> > > pq
> > >
> > > > ---
> > > > drivers/dma-buf/sync_file.c | 8
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > > > index fb6ca1032885..c30b2085ee0a 100644
> > > > --- a/drivers/dma-buf/sync_file.c
> > > > +++ b/drivers/dma-buf/sync_file.c
> > > > @@ -192,6 +192,14 @@ static __poll_t sync_file_poll(struct file *file,
> > > > poll_table *wait)
> > > > {
> > > > struct sync_file *sync_file = file->private_data;
> > > >
> > > > + /*
> > > > + * The POLLPRI/EPOLLPRI flag can be used to signal that
> > > > + * userspace wants the fence to signal ASAP, express this
> > > > + * as an immediate deadline.
> > > > + */
> > > > + if (poll_requested_events(wait) & EPOLLPRI)
> > > > + dma_fence_set_deadline(sync_file->fence, ktime_get());
> > > > +
> > > > poll_wait(file, _file->wq, wait);
> > > >
> > > > if (list_empty(_file->cb.node) &&
> > >
>
Re: [PATCH v2 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB range
On Mon, Feb 20, 2023 at 4:24 PM Dave Stevenson
wrote:
>
> Hi Hans
>
> On Sat, 18 Feb 2023 at 11:33, Hans Verkuil wrote:
> >
> > Hi Maxime, Dave,
> >
> > On 26/01/2023 14:46, Maxime Ripard wrote:
> > > From: Dave Stevenson
> > >
> > > Copy Intel's "Broadcast RGB" property semantics to add manual override
> > > of the HDMI pixel range for monitors that don't abide by the content
> > > of the AVI Infoframe.
> >
> > Do we have to copy that property as-is?
>
> Firstly I'll agree with your later comment that having this control
> allows testing of a range of output modes, and working around HDMI
> sinks that have dodgy implementations.
> (In our vendor kernel we now also have a property to override the
> kernel chosen output format to enable testing of YCbCr4:4:4 and 4:2:2
> output).
>
> The DRM subsystem has the requirement for an open-source userspace
> project to be using any new property before it will be merged [1].
> This property already exists for i915 and gma-500, therefore avoids
> that requirement.
>
> There are objections to the UAPI for Broadcast RGB [2], but if it's
> good enough for the existing implementations then there can be no
> objection to it being implemented in the same way for other drivers.
> Otherwise it is a missing feature of the DRM API, and the linked
> discussion is realistically at least a year away from being resolved.
> Why bury our heads in the sand for that period?
>
> [1]
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> [2] https://lists.freedesktop.org/archives/dri-devel/2023-February/391061.html
FWIW, from a user space perspective I'm still very much in favor of
adding the `Broadcast RGB` property to more drivers and even moving it
to drm core. Splitting things into color pipeline control properties
and infoframe/connector properties is much harder than it seems at
first and IMO needs a more holistic approach that you can't get from
just converting the one property.
>
> > First of all, I think this should really be a drm-level property, rather
> > than
> > a driver property: RGB Quantization Range mismatches are the bane of my
> > life,
> > and I think a way to override this would help everyone.
>
> Linked to above, if it were the preferred method for controlling this
> then I would expect it to become a drm-level property.
>
> > Secondly, I hate the name they came up with: 'Broadcast RGB' is pretty
> > meaningless.
> > Can't we stick to something closer to what the CTA-861/HDMI specs use,
> > which is
> > 'RGB Quantization Range'? So either use that, or just 'RGB Range'.
> >
> > In addition, 'Limited 16:235' should just be 'Limited' since the actual
> > range
> > depends on the bits-per-color-component.
>
> It's documented UAPI with those names[3], therefore any change would
> be a change to user-space's expectation and a regression. At least by
> sticking with the same names then any user space implementation that
> exists for i915 or gma-500 will also work in the same way on vc4.
>
> [3]
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#existing-kms-properties
>
> > >
> > > Signed-off-by: Dave Stevenson
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/vc4/vc4_hdmi.c | 97
> > > --
> > > drivers/gpu/drm/vc4/vc4_hdmi.h | 9
> > > 2 files changed, 102 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > index 4b3bf77bb5cd..78749c6fa837 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > @@ -150,10 +150,16 @@ static bool vc4_hdmi_mode_needs_scrambling(const
> > > struct drm_display_mode *mode,
> > > }
> > >
> > > static bool vc4_hdmi_is_full_range_rgb(struct vc4_hdmi *vc4_hdmi,
> > > -const struct drm_display_mode *mode)
> > > +struct vc4_hdmi_connector_state
> > > *vc4_state)
> > > {
> > > + const struct drm_display_mode *mode =
> > > _hdmi->saved_adjusted_mode;
> > > struct drm_display_info *display =
> > > _hdmi->connector.display_info;
> > >
> > > + if (vc4_state->broadcast_rgb == VC4_HDMI_BROADCAST_RGB_LIMITED)
> > > + return false;
> > > + else if (vc4_state->broadcast_rgb == VC4_HDMI_BROADCAST_RGB_FULL)
> > > + return true;
> > > +
> > > return !display->is_hdmi ||
> > > drm_default_rgb_quant_range(mode) ==
> > > HDMI_QUANTIZATION_RANGE_FULL;
> > > }
> > > @@ -524,8 +530,12 @@ static int vc4_hdmi_connector_atomic_check(struct
> > > drm_connector *connector,
> > > {
> > > struct drm_connector_state *old_state =
> > > drm_atomic_get_old_connector_state(state, connector);
> > > + struct vc4_hdmi_connector_state *old_vc4_state =
> > > + conn_state_to_vc4_hdmi_conn_state(old_state);
> > > struct drm_connector_state *new_state =
> > >
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä wrote: > > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland > > wrote: > > > > > > > > > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > > > wrote: > > > >> > > > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > >>> > > > >>> > > > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > > > >>>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > >>>>> > > > >>>>> > > > >>>>> On 2/3/23 07:59, Sebastian Wick wrote: > > > >>>>>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > > >>>>>> wrote: > > > >>>>>>> > > > >>>>>>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > >>>>>>>> Userspace has no way of controlling or knowing the pixel encoding > > > >>>>>>>> currently, so there is no way for it to ever get the right > > > >>>>>>>> values here. > > > >>>>>>> > > > >>>>>>> That applies to a lot of the other values as well (they are > > > >>>>>>> explicitly RGB or YCC). The idea was that this property sets the > > > >>>>>>> infoframe/MSA/SDP value exactly, and other properties should be > > > >>>>>>> added to for use userspace to control the pixel > > > >>>>>>> encoding/colorspace > > > >>>>>>> conversion(if desired, or userspace just makes sure to > > > >>>>>>> directly feed in correct kind of data). > > > >>>>>> > > > >>>>>> I'm all for getting userspace control over pixel encoding but even > > > >>>>>> then the kernel always knows which pixel encoding is selected and > > > >>>>>> which InfoFrame has to be sent. Is there a reason why userspace > > > >>>>>> would > > > >>>>>> want to control the variant explicitly to the wrong value? > > > >>>>>> > > > >>>>> > > > >>>>> I've asked this before but haven't seen an answer: Is there an > > > >>>>> existing > > > >>>>> upstream userspace project that makes use of this property (other > > > >>>>> than > > > >>>>> what Joshua is working on in gamescope right now)? That would help > > > >>>>> us > > > >>>>> understand the intent better. > > > >>>> > > > >>>> The intent was to control the infoframe colorimetry bits, > > > >>>> nothing more. No idea what real userspace there was, if any. > > > >>>> > > > >>>>> > > > >>>>> I don't think giving userspace explicit control over the exact > > > >>>>> infoframe > > > >>>>> values is the right thing to do. > > > >>>> > > > >>>> Only userspace knows what kind of data it's stuffing into > > > >>>> the pixels (and/or how it configures the csc units/etc.) to > > > >>>> generate them. > > > >>>> > > > >>> > > > >>> Yes, but userspace doesn't control or know whether we drive > > > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > > > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > > > >>> is currently no way for userspace to know that and I don't > > > >>> think it makes sense. > > > >> > > > >> People want that control as well for whatever reason. We've > > > >> been asked to allow YCbCr 4:4:4 output many times. > > > > > > > > I don't really think it's a question of if we want it but rather how > > > > we get there. Harry is completely right that if we would make the > > > > subsampling controllable by user space instead of the kernel handling > > > > it magically, user space which does not adapt to
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote: > > > > On 2/14/23 10:49, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä > > wrote: > >> > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > >>> > >>> > >>> On 2/3/23 10:19, Ville Syrjälä wrote: > >>>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > >>>>> > >>>>> > >>>>> On 2/3/23 07:59, Sebastian Wick wrote: > >>>>>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > >>>>>> wrote: > >>>>>>> > >>>>>>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > >>>>>>>> Userspace has no way of controlling or knowing the pixel encoding > >>>>>>>> currently, so there is no way for it to ever get the right values > >>>>>>>> here. > >>>>>>> > >>>>>>> That applies to a lot of the other values as well (they are > >>>>>>> explicitly RGB or YCC). The idea was that this property sets the > >>>>>>> infoframe/MSA/SDP value exactly, and other properties should be > >>>>>>> added to for use userspace to control the pixel encoding/colorspace > >>>>>>> conversion(if desired, or userspace just makes sure to > >>>>>>> directly feed in correct kind of data). > >>>>>> > >>>>>> I'm all for getting userspace control over pixel encoding but even > >>>>>> then the kernel always knows which pixel encoding is selected and > >>>>>> which InfoFrame has to be sent. Is there a reason why userspace would > >>>>>> want to control the variant explicitly to the wrong value? > >>>>>> > >>>>> > >>>>> I've asked this before but haven't seen an answer: Is there an existing > >>>>> upstream userspace project that makes use of this property (other than > >>>>> what Joshua is working on in gamescope right now)? That would help us > >>>>> understand the intent better. > >>>> > >>>> The intent was to control the infoframe colorimetry bits, > >>>> nothing more. No idea what real userspace there was, if any. > >>>> > >>>>> > >>>>> I don't think giving userspace explicit control over the exact infoframe > >>>>> values is the right thing to do. > >>>> > >>>> Only userspace knows what kind of data it's stuffing into > >>>> the pixels (and/or how it configures the csc units/etc.) to > >>>> generate them. > >>>> > >>> > >>> Yes, but userspace doesn't control or know whether we drive > >>> RGB or YCbCr on the wire. In fact, in some cases our driver > >>> needs to fallback to YCbCr420 for bandwidth reasons. There > >>> is currently no way for userspace to know that and I don't > >>> think it makes sense. > >> > >> People want that control as well for whatever reason. We've > >> been asked to allow YCbCr 4:4:4 output many times. > > > > I don't really think it's a question of if we want it but rather how > > we get there. Harry is completely right that if we would make the > > subsampling controllable by user space instead of the kernel handling > > it magically, user space which does not adapt to the new control won't > > be able to light up some modes which worked before. > > > > Thanks for continuing this discussion and touching on the model of how > we get to where we want to go. > > > This is obviously a problem and not one we can easily fix. We would > > need a new cap for user space to signal "I know that I can control > > bpc, subsampling and compression to lower the bandwidth and light up > > modes which otherwise fail". That cap would also remove all the > > properties which require kernel magic to work (that's also what I > > proposed for my KMS color pipeline API). > > > > We all want to expose more of the scanout capability and give user > > space more control but I don't think an incremental approach works > > here and we would all do better if we accept that the current API > > requires kernel magic to work and has a few implicit assumptions baked > > in. > > > > With all that being said, I think the
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > > > > On 2/3/23 10:19, Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > >> > > >> > > >> On 2/3/23 07:59, Sebastian Wick wrote: > > >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > >>> wrote: > > >>>> > > >>>> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > >>>>> Userspace has no way of controlling or knowing the pixel encoding > > >>>>> currently, so there is no way for it to ever get the right values > > >>>>> here. > > >>>> > > >>>> That applies to a lot of the other values as well (they are > > >>>> explicitly RGB or YCC). The idea was that this property sets the > > >>>> infoframe/MSA/SDP value exactly, and other properties should be > > >>>> added to for use userspace to control the pixel encoding/colorspace > > >>>> conversion(if desired, or userspace just makes sure to > > >>>> directly feed in correct kind of data). > > >>> > > >>> I'm all for getting userspace control over pixel encoding but even > > >>> then the kernel always knows which pixel encoding is selected and > > >>> which InfoFrame has to be sent. Is there a reason why userspace would > > >>> want to control the variant explicitly to the wrong value? > > >>> > > >> > > >> I've asked this before but haven't seen an answer: Is there an existing > > >> upstream userspace project that makes use of this property (other than > > >> what Joshua is working on in gamescope right now)? That would help us > > >> understand the intent better. > > > > > > The intent was to control the infoframe colorimetry bits, > > > nothing more. No idea what real userspace there was, if any. > > > > > >> > > >> I don't think giving userspace explicit control over the exact infoframe > > >> values is the right thing to do. > > > > > > Only userspace knows what kind of data it's stuffing into > > > the pixels (and/or how it configures the csc units/etc.) to > > > generate them. > > > > > > > Yes, but userspace doesn't control or know whether we drive > > RGB or YCbCr on the wire. In fact, in some cases our driver > > needs to fallback to YCbCr420 for bandwidth reasons. There > > is currently no way for userspace to know that and I don't > > think it makes sense. > > People want that control as well for whatever reason. We've > been asked to allow YCbCr 4:4:4 output many times. I don't really think it's a question of if we want it but rather how we get there. Harry is completely right that if we would make the subsampling controllable by user space instead of the kernel handling it magically, user space which does not adapt to the new control won't be able to light up some modes which worked before. This is obviously a problem and not one we can easily fix. We would need a new cap for user space to signal "I know that I can control bpc, subsampling and compression to lower the bandwidth and light up modes which otherwise fail". That cap would also remove all the properties which require kernel magic to work (that's also what I proposed for my KMS color pipeline API). We all want to expose more of the scanout capability and give user space more control but I don't think an incremental approach works here and we would all do better if we accept that the current API requires kernel magic to work and has a few implicit assumptions baked in. With all that being said, I think the right decision here is to 1. Ignore subsampling for now 2. Let the kernel select YCC or RGB on the cable 3. Let the kernel figure out the conversion between RGB and YCC based on the color space selected 4. Let the kernel send the correct infoframe based on the selected color space and cable encoding 5. Only expose color spaces for which the kernel can do the conversion and send the infoframe 6. Work on the new API which is hidden behind a cap > The automagic 4:2:0 fallback I think is rather fundementally > incompatible with fancy color management. How would we even > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > that stuff is just always BT.709 limited range, no questions > asked. > > So I think if userspace wants real color management it's > going to have to set up the whole pipeline. And for that > we
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > wrote: > > > > > > On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > > Userspace has no way of controlling or knowing the pixel encoding > > > > currently, so there is no way for it to ever get the right values here. > > > > > > That applies to a lot of the other values as well (they are > > > explicitly RGB or YCC). The idea was that this property sets the > > > infoframe/MSA/SDP value exactly, and other properties should be > > > added to for use userspace to control the pixel encoding/colorspace > > > conversion(if desired, or userspace just makes sure to > > > directly feed in correct kind of data). > > > > I'm all for getting userspace control over pixel encoding but even > > then the kernel always knows which pixel encoding is selected and > > which InfoFrame has to be sent. Is there a reason why userspace would > > want to control the variant explicitly to the wrong value? > > What do you mean wrong value? Userspace sets it based on what > kind of data it has generated (or asked the display hardware > to generate if/when we get explicit control over that part). Wrong in the sense of sending the YCC variant when the pixel encoding is RGB for example. Maybe I'm missing something here but my assumption is that the kernel always has to know the pixel encoding anyway. The color pipeline also assumes that the pixel values are RGB. User space might be able to generate YCC content but for subsampling etc the pixel encoding still has to be explicitly set. So with the kernel always knowing exactly what pixel encoding is sent, why do we need those variants? I just don't see why this is necessary. > > -- > Ville Syrjälä > Intel >
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
wrote:
>
> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> > Userspace has no way of controlling or knowing the pixel encoding
> > currently, so there is no way for it to ever get the right values here.
>
> That applies to a lot of the other values as well (they are
> explicitly RGB or YCC). The idea was that this property sets the
> infoframe/MSA/SDP value exactly, and other properties should be
> added to for use userspace to control the pixel encoding/colorspace
> conversion(if desired, or userspace just makes sure to
> directly feed in correct kind of data).
I'm all for getting userspace control over pixel encoding but even
then the kernel always knows which pixel encoding is selected and
which InfoFrame has to be sent. Is there a reason why userspace would
want to control the variant explicitly to the wrong value?
>
> >
> > When we do add pixel_encoding control from userspace,we can pick the
> > right value for the colorimetry packet based on the
> > pixel_encoding + the colorspace.
> >
> > Let's deprecate these values, and have one BT.2020 colorspace entry
> > that userspace can use.
> >
> > Note: _CYCC was effectively 'removed' by this change, but that was not
> > possible to be taken advantage of anyway, as there is currently no
> > pixel_encoding control so it would not be possible to output
> > linear YCbCr.
> >
> > Signed-off-by: Joshua Ashton
> >
> > Cc: Pekka Paalanen
> > Cc: Sebastian Wick
> > Cc: vitaly.pros...@amd.com
> > Cc: Uma Shankar
> > Cc: Ville Syrjälä
> > Cc: Joshua Ashton
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: amd-...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/display/drm_hdmi_helper.c | 9 -
> > drivers/gpu/drm/drm_connector.c | 12 ++--
> > drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
> > include/drm/drm_connector.h | 19 ++-
> > 4 files changed, 29 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > index 0264abe55278..c85860600395 100644
> > --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > @@ -99,8 +99,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> > #define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
> > #define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
> > -#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
> > +#define HDMI_COLORIMETRY_BT2020 (C(3) | EC(6) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) |
> > ACE(0))
> > #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) | ACE(1))
> >
> > @@ -113,9 +112,9 @@ static const u32 hdmi_colorimetry_val[] = {
> > [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
> > [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> > [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> > - [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> > - [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> > - [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> > + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_1] = HDMI_COLORIMETRY_BT2020,
> > + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_2] = HDMI_COLORIMETRY_BT2020,
> > + [DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
> > };
> >
> > #undef C
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 61c29ce74b03..58699ab15a6a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1029,11 +1029,11 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > /* Colorimetry based on IEC 61966-2-5 */
> > { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> > /* Colorimetry based on ITU-R BT.2020 */
> > - { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > + { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_1, "BT2020_DEPRECATED_1" },
> > /* Colorimetry based on ITU-R BT.2020 */
> > - { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB"
Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB
On Tue, Jan 24, 2023 at 7:57 PM Harry Wentland wrote: > > > > On 1/24/23 10:37, Harry Wentland wrote: > > > > > > On 1/23/23 15:30, Sebastian Wick wrote: > >> A new property to control YCC and subsampling would be the more > >> complete path here. If we actually want to fix this in the short-term > >> though, we should handle the YCC and RGB Colorspace values as > >> equivalent, everywhere. Technically we're breaking the user space API > >> here so it should be documented on the KMS property and other drivers > >> must be adjusted accordingly as well. > >> > > > > Could someone point me to a userspace that uses this currently? > > > > To elaborate a bit more... > > A driver has always had the ability to pick the wire format, whether > it'd be RGB or YCbCr (444, or 420). In some cases that selection > is required in order to satisfy bandwidth requirements. In others > we follow a certain policy to ensure similar behaviors between our > Windows and Linux drivers. I don't think it makes sense for userspace > to control this. I disagree. The subsampling is degrading the image considerably in some cases. We need control over this. It does mean that user space has to be smart and try to reduce the bandwidth if a KMS commit fails, but the same is true for resolution and refresh rate right now and will be true for a min bpc property as well. > Based on what I see I am not convinced the entirety of the > colorspace definition has a corresponding implementation in an > upstream, canonical userspace, hence my question. Not even an IGT > test existed when I started looking at this. In the absence of a > missing userspace implementation I am not convinced we're breaking > anything. Even then, this was never implemented in amdgpu so > there is no way this regresses any existing behavior. I don't think this breaks anything in practice. The change would only break use cases where you want to set the infoframe to a variant which does not match the wire format and that would be broken. So yes, I agree. We can't just remove the enum values though. If we deprecate the YCC variants that must be documented and user space has to understand that choosing the RGB variant will result in the kernel just doing the "right thing". > > Harry > > > Harry > > > >> On Fri, Jan 13, 2023 at 5:26 PM Harry Wentland > >> wrote: > >>> > >>> From: Joshua Ashton > >>> > >>> Userspace might not aware whether we're sending RGB or YCbCr > >>> data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is > >>> requested but the output encoding is YCbCr we should > >>> send COLOR_SPACE_2020_YCBCR. > >>> > >>> Signed-off-by: Joshua Ashton > >>> Signed-off-by: Harry Wentland > >>> Cc: Pekka Paalanen > >>> Cc: Sebastian Wick > >>> Cc: vitaly.pros...@amd.com > >>> Cc: Joshua Ashton > >>> Cc: dri-devel@lists.freedesktop.org > >>> Cc: amd-...@lists.freedesktop.org > >>> Reviewed-by: Harry Wentland > >>> --- > >>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 - > >>> 1 file changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >>> index f74b125af31f..16940ea61b59 100644 > >>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >>> @@ -5184,7 +5184,10 @@ get_output_color_space(const struct dc_crtc_timing > >>> *dc_crtc_timing, > >>> color_space = COLOR_SPACE_ADOBERGB; > >>> break; > >>> case DRM_MODE_COLORIMETRY_BT2020_RGB: > >>> - color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >>> + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) > >>> + color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >>> + else > >>> + color_space = COLOR_SPACE_2020_YCBCR; > >>> break; > >>> case DRM_MODE_COLORIMETRY_BT2020_YCC: > >>> color_space = COLOR_SPACE_2020_YCBCR; > >>> -- > >>> 2.39.0 > >>> > >> > > >
Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB
On Wed, Jan 25, 2023 at 2:00 PM Joshua Ashton wrote: > > > > On 1/23/23 20:30, Sebastian Wick wrote: > > A new property to control YCC and subsampling would be the more > > complete path here. If we actually want to fix this in the short-term > > though, we should handle the YCC and RGB Colorspace values as > > equivalent, everywhere. Technically we're breaking the user space API > > here so it should be documented on the KMS property and other drivers > > must be adjusted accordingly as well. > > I am happy with treating 2020_YCC and 2020_RGB as the same. > > I think having the YCC/RGB split here in Colorspace is a mistake. > Pixel encoding should be completely separate from colorspace from a uAPI > perspective when we want to expose that. > It's just a design flaw from when it was added as it just mirrors the > values in the colorimetry packets 1:1. I understand why this happened, > and I don't think it's a big deal for us to correct ourselves now: > > I suggest we deprecate the _YCC variants, treat them the same as the RGB > enum to avoid any potential uAPI breakage and key the split entirely off > the pixel_encoding value. Yeah, I agree. The kernel must know the wire encoding and can thus always choose the correct variant. If anyone wants to provide a patch I'll review it. > That way when we do want to plumb more explicit pixel encoding down the > line, userspace only has to manage one thing. There's no advantage for > anything more here. > > - Joshie ✨ > > > > > On Fri, Jan 13, 2023 at 5:26 PM Harry Wentland > > wrote: > >> > >> From: Joshua Ashton > >> > >> Userspace might not aware whether we're sending RGB or YCbCr > >> data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is > >> requested but the output encoding is YCbCr we should > >> send COLOR_SPACE_2020_YCBCR. > >> > >> Signed-off-by: Joshua Ashton > >> Signed-off-by: Harry Wentland > >> Cc: Pekka Paalanen > >> Cc: Sebastian Wick > >> Cc: vitaly.pros...@amd.com > >> Cc: Joshua Ashton > >> Cc: dri-devel@lists.freedesktop.org > >> Cc: amd-...@lists.freedesktop.org > >> Reviewed-by: Harry Wentland > >> --- > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 - > >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> index f74b125af31f..16940ea61b59 100644 > >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > >> @@ -5184,7 +5184,10 @@ get_output_color_space(const struct dc_crtc_timing > >> *dc_crtc_timing, > >> color_space = COLOR_SPACE_ADOBERGB; > >> break; > >> case DRM_MODE_COLORIMETRY_BT2020_RGB: > >> - color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >> + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) > >> + color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > >> + else > >> + color_space = COLOR_SPACE_2020_YCBCR; > >> break; > >> case DRM_MODE_COLORIMETRY_BT2020_YCC: > >> color_space = COLOR_SPACE_2020_YCBCR; > >> -- > >> 2.39.0 > >> > > >
Re: [ANNOUNCE] pixfmtdb
On Mon, Jan 23, 2023 at 11:43 PM Simon Ser wrote: > > On Monday, January 23rd, 2023 at 21:25, Sebastian Wick > wrote: > > > Why is the TF defined for GL formats and both the primaries and TF for > > Vulkan formats? The only exception here should be sRGB formats. Where > > did you get the information from? > > This is what upstream dfdutils does [1]. Can you explain why you think > it should be undefined instead of linear? The channels have no meaning. You can put whatever you want in there. It doesn't have to be linear, it doesn't have to be colors and especially not colors with specific primaries. It's only when it's used to form an image that the TF and primaries are known. Vulkan specifically requires you to explicitly provide this information to the WSI and YCC samplers (generally everywhere where knowing them is required) and never assumes that certain pixel formats imply certain TFs and primaries (exception being the sRGB variants). (See also https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#_issues_26, Q 23) The problem here seems to be that the Data Format spec describes more than the pixel format. If you want to share an image, the TF and primaries are essential but they are not an inherent part of the pixel format of the image. So yeah, I think what dfdutils does is... probably not wrong but not what you're after. > > I was wondering what to do for DRM formats regarding these. I think it > would be worthwhile to do like Vulkan: set TF = linear, primaries = > BT.709, pre-multiplied alpha = yes. These are the things KMS assume > when there is no override (ie, when there is no KMS property saying > otherwise). Please no. All undefined is absolutely the right thing to do. Adding any more meaning to pixel formats is a horrible idea. The KMS properties are also not an override, they describe the image and the description has default values. > > [1]: > https://github.com/KhronosGroup/dfdutils/blob/5cd41cbdf63e80b00c085c6906a1152709e4c0f2/createdfd.c#L47 >
Re: [PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB
A new property to control YCC and subsampling would be the more complete path here. If we actually want to fix this in the short-term though, we should handle the YCC and RGB Colorspace values as equivalent, everywhere. Technically we're breaking the user space API here so it should be documented on the KMS property and other drivers must be adjusted accordingly as well. On Fri, Jan 13, 2023 at 5:26 PM Harry Wentland wrote: > > From: Joshua Ashton > > Userspace might not aware whether we're sending RGB or YCbCr > data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is > requested but the output encoding is YCbCr we should > send COLOR_SPACE_2020_YCBCR. > > Signed-off-by: Joshua Ashton > Signed-off-by: Harry Wentland > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Joshua Ashton > Cc: dri-devel@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Reviewed-by: Harry Wentland > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index f74b125af31f..16940ea61b59 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -5184,7 +5184,10 @@ get_output_color_space(const struct dc_crtc_timing > *dc_crtc_timing, > color_space = COLOR_SPACE_ADOBERGB; > break; > case DRM_MODE_COLORIMETRY_BT2020_RGB: > - color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > + if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) > + color_space = COLOR_SPACE_2020_RGB_FULLRANGE; > + else > + color_space = COLOR_SPACE_2020_YCBCR; > break; > case DRM_MODE_COLORIMETRY_BT2020_YCC: > color_space = COLOR_SPACE_2020_YCBCR; > -- > 2.39.0 >
