meson: Enabling full-range HDMI output
Francisco Ayala Le Brun
francisco at videowindow.eu
Mon Oct 28 06:09:41 PDT 2024
Hi Neil,
On Mon, Oct 28, 2024 at 8:24 AM <neil.armstrong at 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 at linaro.org> wrote:
> >>
> >> On 24/10/2024 10:38, neil.armstrong at 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 at 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 at lists.infradead.org
> >>>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> linux-amlogic mailing list
> >>>>> linux-amlogic at lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> >>>
> >>>
> >>> _______________________________________________
> >>> linux-amlogic mailing list
> >>> linux-amlogic at 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
More information about the linux-amlogic
mailing list