meson: Enabling full-range HDMI output

meson: Enabling full-range HDMI output

[Francisco Ayala Le Brun]

Hello,

I am seeking some guidance regarding enabling full-range HDMI output.
Specifically, I am wondering which component in the video pipeline
could be clamping HDMI output values to 16-235? Further details
follow:

I have been trying to get full-range HDMI output from a Le Potato
s905x SBC. At the moment, HDMI output seems to be hard-coded to color
quantization limited range (16-235). This greatly diminishes the
contrast in full range displays.

So far setting the VIU_OSD1/2_FULL_RANGE bit in the
VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
looked at the color space conversion matrix in dw_hdmi in case that is
the culprit, but the values seem fine and setting that to zero does
produce a signal in the full range (0). The buffer from the VIU is
using a YUV format so dw_hdmi is not using the full to limited range
conversion matrix.

Thank you in advance,
Francisco

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[neil.armstrong]

Hi,

On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
> Hello,
> 
> I am seeking some guidance regarding enabling full-range HDMI output.
> Specifically, I am wondering which component in the video pipeline
> could be clamping HDMI output values to 16-235? Further details
> follow:
> 
> I have been trying to get full-range HDMI output from a Le Potato
> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
> quantization limited range (16-235). This greatly diminishes the
> contrast in full range displays.
> 
> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
> looked at the color space conversion matrix in dw_hdmi in case that is
> the culprit, but the values seem fine and setting that to zero does
> produce a signal in the full range (0). The buffer from the VIU is
> using a YUV format so dw_hdmi is not using the full to limited range
> conversion matrix.

Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?

Could you revert:
d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420

This would give you direct YUV444 HDMI output without CSC involved, reverting
is not an options because of low-cost HDMI panels lying in their EDID
and not really supporting YUV HDMI...

So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
table.

Neil

> 
> Thank you in advance,
> Francisco
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[Francisco Ayala Le Brun]

Thank you for your response. I can confirm reverting the commit solves
the issue. However, it only leaves me more confused as to the root
cause.

If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
then it will show a correctly completely black output. However, if you
set the first column of the YUV-to-RGB matrix to ones, and show a
black image via DRM, then the tone is in the limited range. This
seemed to indicate dw-hdmi can output full range RGB, and the problem
was farther upstream.

Perhaps the problem is the CSC matrices? I was under the assumption
0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
suggest with a csc_scale of 1, then 0x800 would correspond to 1.
Still, I would expect at least fully black to be correct as that would
give a multiplication by zero.

Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
VIU hardware is made to clamp luminance when dw_hdmi is outputting
RGB? I noticed for the CSC there is only a special matrix for
RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
seems to suggest the clamping may be done upstream in those cases.

Francisco


On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
>
> Hi,
>
> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
> > Hello,
> >
> > I am seeking some guidance regarding enabling full-range HDMI output.
> > Specifically, I am wondering which component in the video pipeline
> > could be clamping HDMI output values to 16-235? Further details
> > follow:
> >
> > I have been trying to get full-range HDMI output from a Le Potato
> > s905x SBC. At the moment, HDMI output seems to be hard-coded to color
> > quantization limited range (16-235). This greatly diminishes the
> > contrast in full range displays.
> >
> > So far setting the VIU_OSD1/2_FULL_RANGE bit in the
> > VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
> > looked at the color space conversion matrix in dw_hdmi in case that is
> > the culprit, but the values seem fine and setting that to zero does
> > produce a signal in the full range (0). The buffer from the VIU is
> > using a YUV format so dw_hdmi is not using the full to limited range
> > conversion matrix.
>
> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
>
> Could you revert:
> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
>
> This would give you direct YUV444 HDMI output without CSC involved, reverting
> is not an options because of low-cost HDMI panels lying in their EDID
> and not really supporting YUV HDMI...
>
> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
> table.
>
> Neil
>
> >
> > Thank you in advance,
> > Francisco
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[neil.armstrong]

On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
> Thank you for your response. I can confirm reverting the commit solves
> the issue. However, it only leaves me more confused as to the root
> cause.
> 
> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
> then it will show a correctly completely black output. However, if you
> set the first column of the YUV-to-RGB matrix to ones, and show a
> black image via DRM, then the tone is in the limited range. This
> seemed to indicate dw-hdmi can output full range RGB, and the problem
> was farther upstream.
> 
> Perhaps the problem is the CSC matrices? I was under the assumption
> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
> Still, I would expect at least fully black to be correct as that would
> give a multiplication by zero.
> 
> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
> VIU hardware is made to clamp luminance when dw_hdmi is outputting
> RGB? I noticed for the CSC there is only a special matrix for
> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
> seems to suggest the clamping may be done upstream in those cases.


No the dw-hdmi setup doesn't affect VIU, the VIU output is configured
in meson_encoder_hdmi in the VPU_HDMI_FMT_CTRL register, it's only
affected if the YUV420 HDMNI output is selected.

I think it's a problem in the CSC configuration.

The dwc_hdmi_tx databoook has somehow leaked on internet, and you
can have a look at the Color Space Converter registers section to
understand how the matrix works.

Neil

> 
> Francisco
> 
> 
> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
>>
>> Hi,
>>
>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
>>> Hello,
>>>
>>> I am seeking some guidance regarding enabling full-range HDMI output.
>>> Specifically, I am wondering which component in the video pipeline
>>> could be clamping HDMI output values to 16-235? Further details
>>> follow:
>>>
>>> I have been trying to get full-range HDMI output from a Le Potato
>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
>>> quantization limited range (16-235). This greatly diminishes the
>>> contrast in full range displays.
>>>
>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
>>> looked at the color space conversion matrix in dw_hdmi in case that is
>>> the culprit, but the values seem fine and setting that to zero does
>>> produce a signal in the full range (0). The buffer from the VIU is
>>> using a YUV format so dw_hdmi is not using the full to limited range
>>> conversion matrix.
>>
>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
>>
>> Could you revert:
>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
>>
>> This would give you direct YUV444 HDMI output without CSC involved, reverting
>> is not an options because of low-cost HDMI panels lying in their EDID
>> and not really supporting YUV HDMI...
>>
>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
>> table.
>>
>> Neil
>>
>>>
>>> Thank you in advance,
>>> Francisco
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[neil.armstrong]

On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
> Thank you for your response. I can confirm reverting the commit solves
> the issue. However, it only leaves me more confused as to the root
> cause.
> 
> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
> then it will show a correctly completely black output. However, if you
> set the first column of the YUV-to-RGB matrix to ones, and show a
> black image via DRM, then the tone is in the limited range. This
> seemed to indicate dw-hdmi can output full range RGB, and the problem
> was farther upstream.
> 
> Perhaps the problem is the CSC matrices? I was under the assumption
> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
> Still, I would expect at least fully black to be correct as that would
> give a multiplication by zero.
> 
> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
> VIU hardware is made to clamp luminance when dw_hdmi is outputting
> RGB? I noticed for the CSC there is only a special matrix for
> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
> seems to suggest the clamping may be done upstream in those cases.
> 
> Francisco
> 
> 
> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
>>
>> Hi,
>>
>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
>>> Hello,
>>>
>>> I am seeking some guidance regarding enabling full-range HDMI output.
>>> Specifically, I am wondering which component in the video pipeline
>>> could be clamping HDMI output values to 16-235? Further details
>>> follow:
>>>
>>> I have been trying to get full-range HDMI output from a Le Potato
>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
>>> quantization limited range (16-235). This greatly diminishes the
>>> contrast in full range displays.
>>>
>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
>>> looked at the color space conversion matrix in dw_hdmi in case that is
>>> the culprit, but the values seem fine and setting that to zero does
>>> produce a signal in the full range (0). The buffer from the VIU is
>>> using a YUV format so dw_hdmi is not using the full to limited range
>>> conversion matrix.
>>
>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
>>
>> Could you revert:
>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
>>
>> This would give you direct YUV444 HDMI output without CSC involved, reverting
>> is not an options because of low-cost HDMI panels lying in their EDID
>> and not really supporting YUV HDMI...
>>
>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
>> table.

So seems the current CSC tables outputs limited range from YUV, could you try:

=================><==================================
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 0031f3c54882..9e1cb9be4622 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1769,8 +1769,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
         drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);

         if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
+               bool is_input_rgb = hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format);
+               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range |!is_input_rgb;
+
                 drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
-                                                  hdmi->hdmi_data.rgb_limited_range ?
+                                                  is_limited_range ?
                                                    HDMI_QUANTIZATION_RANGE_LIMITED :
                                                    HDMI_QUANTIZATION_RANGE_FULL);
         } else {
=================><==================================

It won't output full range, but at least the monitor will know the real
signal quant range.

The real fix would be to calculate some new parameters for full range,
but I'm not able to do that personally.

Neil

>>
>> Neil
>>
>>>
>>> Thank you in advance,
>>> Francisco
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[Neil Armstrong]

On 24/10/2024 10:38, neil.armstrong@linaro.org wrote:
> On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
>> Thank you for your response. I can confirm reverting the commit solves
>> the issue. However, it only leaves me more confused as to the root
>> cause.
>>
>> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
>> then it will show a correctly completely black output. However, if you
>> set the first column of the YUV-to-RGB matrix to ones, and show a
>> black image via DRM, then the tone is in the limited range. This
>> seemed to indicate dw-hdmi can output full range RGB, and the problem
>> was farther upstream.
>>
>> Perhaps the problem is the CSC matrices? I was under the assumption
>> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
>> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
>> Still, I would expect at least fully black to be correct as that would
>> give a multiplication by zero.
>>
>> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
>> VIU hardware is made to clamp luminance when dw_hdmi is outputting
>> RGB? I noticed for the CSC there is only a special matrix for
>> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
>> seems to suggest the clamping may be done upstream in those cases.
>>
>> Francisco
>>
>>
>> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
>>>
>>> Hi,
>>>
>>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
>>>> Hello,
>>>>
>>>> I am seeking some guidance regarding enabling full-range HDMI output.
>>>> Specifically, I am wondering which component in the video pipeline
>>>> could be clamping HDMI output values to 16-235? Further details
>>>> follow:
>>>>
>>>> I have been trying to get full-range HDMI output from a Le Potato
>>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
>>>> quantization limited range (16-235). This greatly diminishes the
>>>> contrast in full range displays.
>>>>
>>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
>>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
>>>> looked at the color space conversion matrix in dw_hdmi in case that is
>>>> the culprit, but the values seem fine and setting that to zero does
>>>> produce a signal in the full range (0). The buffer from the VIU is
>>>> using a YUV format so dw_hdmi is not using the full to limited range
>>>> conversion matrix.
>>>
>>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
>>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
>>>
>>> Could you revert:
>>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
>>>
>>> This would give you direct YUV444 HDMI output without CSC involved, reverting
>>> is not an options because of low-cost HDMI panels lying in their EDID
>>> and not really supporting YUV HDMI...
>>>
>>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
>>> table.
> 
> So seems the current CSC tables outputs limited range from YUV, could you try:
> 
> =================><==================================
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 0031f3c54882..9e1cb9be4622 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1769,8 +1769,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
>          drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
> 
>          if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> +               bool is_input_rgb = hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format);
> +               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range |!is_input_rgb;

Of course:

              bool is_limited_range = hdmi->hdmi_data.rgb_limited_range || !is_input_rgb;

Sorry for the typo.

> +
>                  drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
> -                                                  hdmi->hdmi_data.rgb_limited_range ?
> +                                                  is_limited_range ?
>                                                     HDMI_QUANTIZATION_RANGE_LIMITED :
>                                                     HDMI_QUANTIZATION_RANGE_FULL);
>          } else {
> =================><==================================
> 
> It won't output full range, but at least the monitor will know the real
> signal quant range.
> 
> The real fix would be to calculate some new parameters for full range,
> but I'm not able to do that personally.
> 
> Neil
> 
>>>
>>> Neil
>>>
>>>>
>>>> Thank you in advance,
>>>> Francisco
>>>>
>>>> _______________________________________________
>>>> linux-amlogic mailing list
>>>> linux-amlogic@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>>
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> 
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[Francisco Ayala Le Brun]

On Thu, Oct 24, 2024 at 8:51 AM Neil Armstrong
<neil.armstrong@linaro.org> wrote:
>
> On 24/10/2024 10:38, neil.armstrong@linaro.org wrote:
> > On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
> >> Thank you for your response. I can confirm reverting the commit solves
> >> the issue. However, it only leaves me more confused as to the root
> >> cause.
> >>
> >> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
> >> then it will show a correctly completely black output. However, if you
> >> set the first column of the YUV-to-RGB matrix to ones, and show a
> >> black image via DRM, then the tone is in the limited range. This
> >> seemed to indicate dw-hdmi can output full range RGB, and the problem
> >> was farther upstream.
> >>
> >> Perhaps the problem is the CSC matrices? I was under the assumption
> >> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
> >> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
> >> Still, I would expect at least fully black to be correct as that would
> >> give a multiplication by zero.
> >>
> >> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
> >> VIU hardware is made to clamp luminance when dw_hdmi is outputting
> >> RGB? I noticed for the CSC there is only a special matrix for
> >> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
> >> seems to suggest the clamping may be done upstream in those cases.
> >>
> >> Francisco
> >>
> >>
> >> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
> >>>> Hello,
> >>>>
> >>>> I am seeking some guidance regarding enabling full-range HDMI output.
> >>>> Specifically, I am wondering which component in the video pipeline
> >>>> could be clamping HDMI output values to 16-235? Further details
> >>>> follow:
> >>>>
> >>>> I have been trying to get full-range HDMI output from a Le Potato
> >>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
> >>>> quantization limited range (16-235). This greatly diminishes the
> >>>> contrast in full range displays.
> >>>>
> >>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
> >>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
> >>>> looked at the color space conversion matrix in dw_hdmi in case that is
> >>>> the culprit, but the values seem fine and setting that to zero does
> >>>> produce a signal in the full range (0). The buffer from the VIU is
> >>>> using a YUV format so dw_hdmi is not using the full to limited range
> >>>> conversion matrix.
> >>>
> >>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
> >>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
> >>>
> >>> Could you revert:
> >>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
> >>>
> >>> This would give you direct YUV444 HDMI output without CSC involved, reverting
> >>> is not an options because of low-cost HDMI panels lying in their EDID
> >>> and not really supporting YUV HDMI...
> >>>
> >>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
> >>> table.
> >
> > So seems the current CSC tables outputs limited range from YUV, could you try:
> >
> > =================><==================================
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 0031f3c54882..9e1cb9be4622 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1769,8 +1769,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> >          drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
> >
> >          if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> > +               bool is_input_rgb = hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format);
> > +               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range |!is_input_rgb;
>
> Of course:
>
>               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range || !is_input_rgb;
>
> Sorry for the typo.
>
> > +
> >                  drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
> > -                                                  hdmi->hdmi_data.rgb_limited_range ?
> > +                                                  is_limited_range ?
> >                                                     HDMI_QUANTIZATION_RANGE_LIMITED :
> >                                                     HDMI_QUANTIZATION_RANGE_FULL);
> >          } else {
> > =================><==================================
> >
> > It won't output full range, but at least the monitor will know the real
> > signal quant range.
> >
> > The real fix would be to calculate some new parameters for full range,
> > but I'm not able to do that personally.
> >
> > Neil
> >
> >>>
> >>> Neil
> >>>
> >>>>
> >>>> Thank you in advance,
> >>>> Francisco
> >>>>
> >>>> _______________________________________________
> >>>> linux-amlogic mailing list
> >>>> linux-amlogic@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>>
> >>>
> >>> _______________________________________________
> >>> linux-amlogic mailing list
> >>> linux-amlogic@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
>

Thank you for the patch. However, it does not fix the issue in the
panel I am using. Perhaps it does not support limited quantization
range at all.

Hopefully I can have a look at the CSC tables soon.

Francisco

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[neil.armstrong]

Hi,

On 25/10/2024 10:57, Francisco Ayala Le Brun wrote:
> On Thu, Oct 24, 2024 at 8:51 AM Neil Armstrong
> <neil.armstrong@linaro.org> wrote:
>>
>> On 24/10/2024 10:38, neil.armstrong@linaro.org wrote:
>>> On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
>>>> Thank you for your response. I can confirm reverting the commit solves
>>>> the issue. However, it only leaves me more confused as to the root
>>>> cause.
>>>>
>>>> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
>>>> then it will show a correctly completely black output. However, if you
>>>> set the first column of the YUV-to-RGB matrix to ones, and show a
>>>> black image via DRM, then the tone is in the limited range. This
>>>> seemed to indicate dw-hdmi can output full range RGB, and the problem
>>>> was farther upstream.
>>>>
>>>> Perhaps the problem is the CSC matrices? I was under the assumption
>>>> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
>>>> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
>>>> Still, I would expect at least fully black to be correct as that would
>>>> give a multiplication by zero.
>>>>
>>>> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
>>>> VIU hardware is made to clamp luminance when dw_hdmi is outputting
>>>> RGB? I noticed for the CSC there is only a special matrix for
>>>> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
>>>> seems to suggest the clamping may be done upstream in those cases.
>>>>
>>>> Francisco
>>>>
>>>>
>>>> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am seeking some guidance regarding enabling full-range HDMI output.
>>>>>> Specifically, I am wondering which component in the video pipeline
>>>>>> could be clamping HDMI output values to 16-235? Further details
>>>>>> follow:
>>>>>>
>>>>>> I have been trying to get full-range HDMI output from a Le Potato
>>>>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
>>>>>> quantization limited range (16-235). This greatly diminishes the
>>>>>> contrast in full range displays.
>>>>>>
>>>>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
>>>>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
>>>>>> looked at the color space conversion matrix in dw_hdmi in case that is
>>>>>> the culprit, but the values seem fine and setting that to zero does
>>>>>> produce a signal in the full range (0). The buffer from the VIU is
>>>>>> using a YUV format so dw_hdmi is not using the full to limited range
>>>>>> conversion matrix.
>>>>>
>>>>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
>>>>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
>>>>>
>>>>> Could you revert:
>>>>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
>>>>>
>>>>> This would give you direct YUV444 HDMI output without CSC involved, reverting
>>>>> is not an options because of low-cost HDMI panels lying in their EDID
>>>>> and not really supporting YUV HDMI...
>>>>>
>>>>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
>>>>> table.
>>>
>>> So seems the current CSC tables outputs limited range from YUV, could you try:
>>>
>>> =================><==================================
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index 0031f3c54882..9e1cb9be4622 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1769,8 +1769,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
>>>           drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
>>>
>>>           if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
>>> +               bool is_input_rgb = hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format);
>>> +               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range |!is_input_rgb;
>>
>> Of course:
>>
>>                bool is_limited_range = hdmi->hdmi_data.rgb_limited_range || !is_input_rgb;
>>
>> Sorry for the typo.
>>
>>> +
>>>                   drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
>>> -                                                  hdmi->hdmi_data.rgb_limited_range ?
>>> +                                                  is_limited_range ?
>>>                                                      HDMI_QUANTIZATION_RANGE_LIMITED :
>>>                                                      HDMI_QUANTIZATION_RANGE_FULL);
>>>           } else {
>>> =================><==================================
>>>
>>> It won't output full range, but at least the monitor will know the real
>>> signal quant range.
>>>
>>> The real fix would be to calculate some new parameters for full range,
>>> but I'm not able to do that personally.
>>>
>>> Neil
>>>
>>>>>
>>>>> Neil
>>>>>
>>>>>>
>>>>>> Thank you in advance,
>>>>>> Francisco
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-amlogic mailing list
>>>>>> linux-amlogic@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> linux-amlogic mailing list
>>>>> linux-amlogic@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>>
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
> 
> Thank you for the patch. However, it does not fix the issue in the
> panel I am using. Perhaps it does not support limited quantization
> range at all.

What monitor is this ?

The HDMI 1.4b spec says clearly:
========================><=========================================================
Black and white levels for video components shall be either “Full Range” or “Limited Range.”
Limited Range shall be used for all video formats defined in CEA-861-D, with the exception of
VGA (640x480) format, which requires Full Range.
========================><=========================================================

So if the monitor is compliant with HDMI spec, it should support limited range. But it seems
to be ok with the YUV limited range.

But perhaps the EDID declares a selectable YCC Quantization Range and expects full range ?

Neil

> 
> Hopefully I can have a look at the CSC tables soon.
> 
> Francisco


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: meson: Enabling full-range HDMI output

[Francisco Ayala Le Brun]

Hi Neil,

On Mon, Oct 28, 2024 at 8:24 AM <neil.armstrong@linaro.org> wrote:
>
> Hi,
>
> On 25/10/2024 10:57, Francisco Ayala Le Brun wrote:
> > On Thu, Oct 24, 2024 at 8:51 AM Neil Armstrong
> > <neil.armstrong@linaro.org> wrote:
> >>
> >> On 24/10/2024 10:38, neil.armstrong@linaro.org wrote:
> >>> On 23/10/2024 14:12, Francisco Ayala Le Brun wrote:
> >>>> Thank you for your response. I can confirm reverting the commit solves
> >>>> the issue. However, it only leaves me more confused as to the root
> >>>> cause.
> >>>>
> >>>> If dw-hdmi is set to output RGB, and you set the CSC matrix to zeroes,
> >>>> then it will show a correctly completely black output. However, if you
> >>>> set the first column of the YUV-to-RGB matrix to ones, and show a
> >>>> black image via DRM, then the tone is in the limited range. This
> >>>> seemed to indicate dw-hdmi can output full range RGB, and the problem
> >>>> was farther upstream.
> >>>>
> >>>> Perhaps the problem is the CSC matrices? I was under the assumption
> >>>> 0x2000 corresponded to 1, even though i.MX6 manual chapter 33 seems to
> >>>> suggest with a csc_scale of 1, then 0x800 would correspond to 1.
> >>>> Still, I would expect at least fully black to be correct as that would
> >>>> give a multiplication by zero.
> >>>>
> >>>> Or the state of dw_hdmi is affecting the VIU in some way? Perhaps the
> >>>> VIU hardware is made to clamp luminance when dw_hdmi is outputting
> >>>> RGB? I noticed for the CSC there is only a special matrix for
> >>>> RGB-to-limited-RGB, but no special matrix for YUV-to-limited-RGB. That
> >>>> seems to suggest the clamping may be done upstream in those cases.
> >>>>
> >>>> Francisco
> >>>>
> >>>>
> >>>> On Wed, Oct 23, 2024 at 8:30 AM <neil.armstrong@linaro.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 23/10/2024 10:00, Francisco Ayala Le Brun wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I am seeking some guidance regarding enabling full-range HDMI output.
> >>>>>> Specifically, I am wondering which component in the video pipeline
> >>>>>> could be clamping HDMI output values to 16-235? Further details
> >>>>>> follow:
> >>>>>>
> >>>>>> I have been trying to get full-range HDMI output from a Le Potato
> >>>>>> s905x SBC. At the moment, HDMI output seems to be hard-coded to color
> >>>>>> quantization limited range (16-235). This greatly diminishes the
> >>>>>> contrast in full range displays.
> >>>>>>
> >>>>>> So far setting the VIU_OSD1/2_FULL_RANGE bit in the
> >>>>>> VIU_OSD1/2_CTRL_STAT2 register does not seem to work. I have also
> >>>>>> looked at the color space conversion matrix in dw_hdmi in case that is
> >>>>>> the culprit, but the values seem fine and setting that to zero does
> >>>>>> produce a signal in the full range (0). The buffer from the VIU is
> >>>>>> using a YUV format so dw_hdmi is not using the full to limited range
> >>>>>> conversion matrix.
> >>>>>
> >>>>> Indeed the internal VPU pipeline is in 10bit YUV444, so it requires enabling
> >>>>> the dw-hdmi CSC, so perhaps those are not designed to output full-range RGB ?
> >>>>>
> >>>>> Could you revert:
> >>>>> d3d6b1bf85ae drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420
> >>>>>
> >>>>> This would give you direct YUV444 HDMI output without CSC involved, reverting
> >>>>> is not an options because of low-cost HDMI panels lying in their EDID
> >>>>> and not really supporting YUV HDMI...
> >>>>>
> >>>>> So if the original YUV is in full range, the culprit is in the DW-HDMI CSC
> >>>>> table.
> >>>
> >>> So seems the current CSC tables outputs limited range from YUV, could you try:
> >>>
> >>> =================><==================================
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> index 0031f3c54882..9e1cb9be4622 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> @@ -1769,8 +1769,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> >>>           drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
> >>>
> >>>           if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> >>> +               bool is_input_rgb = hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format);
> >>> +               bool is_limited_range = hdmi->hdmi_data.rgb_limited_range |!is_input_rgb;
> >>
> >> Of course:
> >>
> >>                bool is_limited_range = hdmi->hdmi_data.rgb_limited_range || !is_input_rgb;
> >>
> >> Sorry for the typo.
> >>
> >>> +
> >>>                   drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
> >>> -                                                  hdmi->hdmi_data.rgb_limited_range ?
> >>> +                                                  is_limited_range ?
> >>>                                                      HDMI_QUANTIZATION_RANGE_LIMITED :
> >>>                                                      HDMI_QUANTIZATION_RANGE_FULL);
> >>>           } else {
> >>> =================><==================================
> >>>
> >>> It won't output full range, but at least the monitor will know the real
> >>> signal quant range.
> >>>
> >>> The real fix would be to calculate some new parameters for full range,
> >>> but I'm not able to do that personally.
> >>>
> >>> Neil
> >>>
> >>>>>
> >>>>> Neil
> >>>>>
> >>>>>>
> >>>>>> Thank you in advance,
> >>>>>> Francisco
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> linux-amlogic mailing list
> >>>>>> linux-amlogic@lists.infradead.org
> >>>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> linux-amlogic mailing list
> >>>>> linux-amlogic@lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>>
> >>>
> >>> _______________________________________________
> >>> linux-amlogic mailing list
> >>> linux-amlogic@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>
> >
> > Thank you for the patch. However, it does not fix the issue in the
> > panel I am using. Perhaps it does not support limited quantization
> > range at all.
>
> What monitor is this ?
>
> The HDMI 1.4b spec says clearly:
> ========================><=========================================================
> Black and white levels for video components shall be either “Full Range” or “Limited Range.”
> Limited Range shall be used for all video formats defined in CEA-861-D, with the exception of
> VGA (640x480) format, which requires Full Range.
> ========================><=========================================================
>
>

This an application-specific panel not available in the general
market. However, I can share its EDID:
00 ff ff ff ff ff ff 00 06 89 4c 0c 46 53 4d 30
0b 1d 01 03 80 3d 23 78 2a 5f b1 a2 57 4f a2 28
0f 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 60 59 21 00 00 1e 00 00 00 fd 00 18 4b 1e
87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4d
57 0a 20 20 20 20 20 20 20 20 20 20 00 00 00 ff
00 48 54 50 4d 33 30 30 33 39 39 0a 20 20 01 8c

02 03 34 f0 4d 61 12 03 13 04 20 22 1f 10 5f 60
5d 5e 23 09 07 07 83 01 00 00 6d 03 0c 00 20 00
80 40 20 00 60 01 02 03 67 d8 5d c4 01 78 80 03
e3 0f 01 04 02 3a 80 18 71 38 2d 40 58 2c 45 00
60 59 21 00 00 1e 02 3a 80 d0 72 38 2d 40 10 2c
45 80 60 59 21 00 00 1e 01 1d 00 72 51 d0 1e 20
6e 28 55 00 60 59 21 00 00 1e 56 5e 00 a0 a0 a0
29 50 30 20 35 00 60 59 21 00 00 1a 00 00 0

I agree according to my understanding the panel is acting out of spec.
However, strangely every other device I have tried (Linux AMDGPU,
Linux i915, and Apple) behave correctly. During my research I came
across several other users who reported similar problems with this
family of SoCs, with both the mainline and legacy driver:
https://hub.libre.computer/t/aml-s905x-cc-le-potato-hdmi-black-levels-washed-out/3056/4
https://forum.odroid.com/viewtopic.php?t=39944
https://forum.odroid.com/viewtopic.php?t=26003
https://discourse.coreelec.org/t/colorspace-yuv-rgb-problem-gpus-rgb-full-range-setup/2963
https://forum.kodi.tv/showthread.php?tid=294916

What may have helped those users is an option to override the CSC's
output format. Perhaps exposed as a DRM property on the HDMI
connector. Would you consider that a good approach in this case?

> So if the monitor is compliant with HDMI spec, it should support limited range. But it seems
> to be ok with the YUV limited range.

I don't think the YUV output is being clamped to limited range at all
because there are no YUV-to-YUV CSC matrices, and I don't see the
output value clamping feature of the CSC being used either.

> But perhaps the EDID declares a selectable YCC Quantization Range and expects full range ?

I don't see this in the EDID. I think the panel is not following the spec.

>
> Neil
>
> >
> > Hopefully I can have a look at the CSC tables soon.
> >
> > Francisco
>

Francisco

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic