On 09/12/2025 05:23, Aaron Kling wrote:
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
I've finally captured some footage of the colors of my TX2 within tty.
I've also added a reference in the form of my X13s doing the same thing.[1]
I will at a later date try the patch and update the MR comment,
but at least this shows the difference while recording using the same setup.
Kindest regards,
Jasper
[1]: https://gitlab.freedesktop.org/drm/tegra/-/issues/8#note_3242611
