Message-ID: <CALHNRZ_k6e9ZRmpK6Pzpet=RzUQ0fRYmfnea6U+9E2oZc8=z7w@mail.gmail.com>
Date: Tue, 4 Nov 2025 12:12:11 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Mikko Perttunen <mperttunen@...dia.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, 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. 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.

Aaron

Powered by blists - more mailing lists