Message-ID: <CALHNRZ-ZxBmbCNGyq77TWcNQwo9qhrB0znfRnsj7zy9GVE=jtA@mail.gmail.com>
Date: Tue, 27 Jan 2026 11:57:35 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...nel.org>
Cc: Mikko Perttunen <mperttunen@...dia.com>, Kurt Kiefer <kekiefer@...il.com>, 
	Jasper Korten <jja2000@...il.com>, Thierry Reding <thierry.reding@...il.com>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Jonathan Hunter <jonathanh@...dia.com>, dri-devel@...ts.freedesktop.org, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/tegra: Enable cmu for Tegra186 and Tegra194

On Tue, Jan 27, 2026 at 4:32 AM Thierry Reding
<thierry.reding@...nel.org> wrote:
>
> On Tue, Jan 27, 2026 at 01:12:54PM +0900, Mikko Perttunen wrote:
> > On Thursday, January 22, 2026 2:08 AM Kurt Kiefer wrote:
> > >
> > > > On Dec 8, 2025, at 8:23 PM, Aaron Kling <webgeek1234@...il.com> wrote:
> > > >
> > > > On Wed, Nov 5, 2025 at 3:28 PM Jasper Korten <jja2000@...il.com> wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> On 11/4/25 19:12, Aaron Kling wrote:
> > > >>> On Tue, Nov 4, 2025 at 3:14 AM Thierry Reding <thierry.reding@...il.com> wrote:
> > > >>>> On Mon, Nov 03, 2025 at 12:39:57PM -0600, Aaron Kling wrote:
> > > >>>>> On Mon, Nov 3, 2025 at 5:54 AM Thierry Reding <thierry.reding@...il.com> wrote:
> > > >>>>>> On Sat, Nov 01, 2025 at 06:15:17PM -0500, Aaron Kling via B4 Relay wrote:
> > > >>>>>>> From: Aaron Kling <webgeek1234@...il.com>
> > > >>>>>>>
> > > >>>>>>> Without the cmu, nvdisplay will display colors that are notably darker
> > > >>>>>>> than intended. The vendor bootloader and the downstream display driver
> > > >>>>>>> enable the cmu and sets a sRGB table. Loading that table here results in
> > > >>>>>>> the intended colors.
> > > >>>>>>>
> > > >>>>>>> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> > > >>>>>>> ---
> > > >>>>>>>  drivers/gpu/drm/tegra/dc.h  |  13 +++
> > > >>>>>>>  drivers/gpu/drm/tegra/sor.c | 206 ++++++++++++++++++++++++++++++++++++++++++++
> > > >>>>>>>  2 files changed, 219 insertions(+)
> > > >>>>>> What does "darker than intended" mean? Who defines the intention? How do
> > > >>>>>> we know what the intention is? What this patch ultimately seems to be
> > > >>>>>> doing is define sRGB to be the default colorspace. Is that always the
> > > >>>>>> right default choice? What if people want to specify a different
> > > >>>>>> colorspace?
> > > >>>>> I reported this issue almost a month ago. See kernel lore [0] and
> > > >>>>> freedesktop issue [1]. The pictures in the latter show what nvdisplay
> > > >>>>> looks like right now. It's nigh unusably dark. When booted into
> > > >>>>> Android with a tv launcher that has a black background, as is default
> > > >>>>> for LineageOS, it is really hard to read anything. Is it correct as a
> > > >>>>> default? Well, cboot hardcodes this, so... presumably? It would be
> > > >>>>> more ideal to expose this and csc to userspace, but I'm not sure if
> > > >>>>> drm has a standardized interface for that or if tegra would have to
> > > >>>>> make something vendor specific. I think that would be a separate
> > > >>>>> change concept compared to setting this default, though.
> > > >>>> The reason I'm asking is because I don't recall ever seeing "broken"
> > > >>>> colors like you do. So I suspect that this may also be related to what
> > > >>>> display is connected, or the mode that we're setting.
> > > >> I have tried it on both a MacroSilicon HDMI capture card and an Arzopa
> > > >> Z1FC 1080p portable monitor and run into the same darker colors. Both
> > > >> have in common that they use HDMI which seems to line up with what Aaron
> > > >> is reporting. I do not have an eDP display to test or another carrier
> > > >> board with a different display out to test.
> > > >>>> It could perhaps
> > > >>>> also be related to what infoframes we're sending and how these are
> > > >>>> supported/interpreted by the attached display.
> > > >>>>
> > > >>>> All of that is to say that maybe this looks broken on the particular
> > > >>>> setup that you have but may works fine on other setups. Changing the
> > > >>>> default may fix your setup and break others.
> > > >>> Do you have a device set up so you can check? Or does the regression
> > > >>> test bench have a display that can be forwarded?
> > > >>>
> > > >>> My current setup is a rack of units plugged via hdmi to a kvm which is
> > > >>> then plugged to a pikvm. I also observed this issue before I had this
> > > >>> setup, plugged directly to a 1080p monitor. I have not checked
> > > >>> displayport. I can cycle through a couple other displays without this
> > > >>> patch to see if I get any other result. I am fairly certain I have
> > > >>> consistently seen this issue since I started trying to work with
> > > >>> tegra-drm on kernel 6.1 or maybe even 5.15. I've never seen it work to
> > > >>> allow for a bisect.
> > > >>>
> > > >>> I am in contact with one other person with a tx2 devkit, who
> > > >>> replicated the issue when I asked. Who plans to reply to this thread
> > > >>> with setup info later.
> > > >>
> > > >> For reference, I am said person. I have a Jetson TX2 Devkit that uses
> > > >> the P2771 Device Tree. I'm running a Fedora distrokernel with no
> > > >> additional patches applied by myself. I have personally noticed the
> > > >> issue to at least be present on 6.14.5 and 6.17.4.
> > > >>
> > > >>
> > > >> I'm currently not at home to take screenshots with and without the
> > > >> submitted patch, but will be able to do it tomorrownight or friday.
> > > >
> > > > Any further thoughts from the maintainers on this patch? As far as I
> > > > know, this is an issue for all users, at the very least on hdmi.
> > > >
> > > > Aaron
> > > >
> > >
> > > I can confirm that I have the same issue on a DisplayPort output of t194.
> > > IMO, this patch will need to be reworked a bit to enable the CMU for this
> > > output as well. I hacked this change in for DisplayPort, and then it
> > > functioned as intended there as well.
> > >
> > > I've traced back to the reason this is necessary. The DC hub driver is
> > > applying an sRGB degamma for every RGB plane (presumably for blending),
> > > and then nothing reapplies the EOTF later on. Without gamma correction
> > > in places where it is expected, images are going to look "too dark".
> > >
> > > Which does raise the point that there is an alternative implementation
> > > where we do not degamma RGB planes in the first place. But this may have
> > > unintended consequences when it comes to composition.
> > >
> > > The SOR does not appear to handle YCbCr outputs at this time, so enabling
> > > the CMU assuming an sRGB EOTF seems like a reasonable path here, to me.
> > >
> > > Kurt
> >
> > I tested this patch locally and did some investigation. Can confirm
> > that on my Jetson AGX Xavier, this patch (or disabling degamma) fixes
> > the color output.
> >
> > The colorspace the display expects from the incoming data is specified
> > in the AVI infoframe. This is generated in
> > tegra_sor_hdmi_setup_avi_infoframe, which calls into
> > drm_hdmi_avi_infoframe_from_display_mode, which leaves a lot of fields
> > set at the default.
> >
> > Currently we're advertising:
> > * colorimetry = no data -> for HD resolutions, use Rec. 709 primaries.
> > These are the same as sRGB.
> > * itc = false -> NOT IT content.
> >
> > My understanding (based on some LLM research and otherwise) is that
> > this is likely to result in the display expecting Rec. 709 colors with
> > Rec. 709 gamma. sRGB gamma is slightly different, and setting itc =
> > true would hint the display towards using sRGB gamma.
> >
> > However, what seems clear to me is that the display would be expecting
> > nonlinear data, so enabling gamma conversion at the output LUT seems
> > correct to me. So this patch would be a clear improvement (with the
> > fixes already discussed).
>
> I think ideally we want to hook this up to the DRM color management
> facilities, so that it can both be properly reported and configured
> at runtime.

That would be ideal yes. But I don't have nearly the knowledge of DRM
or nvdisplay to wire this up. Is there someone at Nvidia that can make
time to do so?

> Obviously we also want to make sure that the output pixels match what
> is advertised via the AVI infoframe. Looks like there's concensus that
> enabling the output LUT is the correct way to do that.

If more fully featured CMU support can't be done in a reasonable
timeframe, I can address the earlier review comments and coordinate
with Kurt to replicate this for DP, then send a v2.

Aaron

Powered by blists - more mailing lists