Re: [PATCH] drm/tegra: Enable cmu for Tegra186 and Tegra194

[Jasper Korten <jja2000@gmail.com>]

On 09/12/2025 05:23, Aaron Kling wrote:

> On Wed, Nov 5, 2025 at 3:28 PM Jasper Korten <jja2000@gmail.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@gmail.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@gmail.com> wrote:
>>>>>> On Sat, Nov 01, 2025 at 06:15:17PM -0500, Aaron Kling via B4 Relay wrote:
>>>>>>> From: Aaron Kling <webgeek1234@gmail.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@gmail.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