On Wed, Nov 5, 2025 at 3:28 PM Jasper Korten <[email protected]> wrote: > > Hi all, > > On 11/4/25 19:12, Aaron Kling wrote: > > 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. > 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
