Message-ID: <d25eb292-e019-4293-b389-d328b7b83b60@gmail.com>
Date: Sun, 21 Dec 2025 17:15:17 +0100
From: Jasper Korten <jja2000@...il.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
 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 18/12/2025 00:18, Jasper Korten wrote:
> On 09/12/2025 05:23, Aaron Kling 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'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
>
As promised, I've added my test results to the Issue[1]. It seems to 
improve colors a lot more, haven't ran into any other issues.


The patch seems to work therefore:

Tested-by: Jasper Korten <jja2000@...il.com>


Kindest regards,

Jasper Korten


[1]: https://gitlab.freedesktop.org/drm/tegra/-/issues/8#note_3246713

Powered by blists - more mailing lists