On Tue, Nov 4, 2025 at 3:14 AM Thierry Reding <[email protected]> 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 <[email protected]> > > wrote: > > > > > > On Sat, Nov 01, 2025 at 06:15:17PM -0500, Aaron Kling via B4 Relay wrote: > > > > From: Aaron Kling <[email protected]> > > > > > > > > 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 <[email protected]> > > > > --- > > > > 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
