mirror of https://lore.kernel.org/linux-amlogic/
 help / color / mirror / Atom feed
From: neil.armstrong@linaro.org
To: Francisco Ayala Le Brun <francisco@videowindow.eu>
Cc: linux-amlogic@lists.infradead.org
Subject: Re: meson: Enabling full-range HDMI output
Date: Mon, 28 Oct 2024 09:24:46 +0100	[thread overview]
Message-ID: <2fb6cdf7-c22d-45bc-94ad-213a3c865495@linaro.org> (raw)
In-Reply-To: <CAN-StX04sLnx+zSSJau=7tngNBH0nikVro+_8RmpbD4cbSa8GA@mail.gmail.com>

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

  reply	other threads:[~2024-10-28  8:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-23  8:00 Francisco Ayala Le Brun
2024-10-23  8:22 ` neil.armstrong
2024-10-23 12:12   ` Francisco Ayala Le Brun
2024-10-23 12:55     ` neil.armstrong
2024-10-24  8:38     ` neil.armstrong
2024-10-24  8:51       ` Neil Armstrong
2024-10-25  8:57         ` Francisco Ayala Le Brun
2024-10-28  8:24           ` neil.armstrong [this message]
2024-10-28 13:09             ` Francisco Ayala Le Brun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2fb6cdf7-c22d-45bc-94ad-213a3c865495@linaro.org \
    --to=neil.armstrong@linaro.org \
    --cc=francisco@videowindow.eu \
    --cc=linux-amlogic@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®