From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F8A531ED66 for ; Wed, 21 Jan 2026 17:08:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769015316; cv=none; b=dQEaUKpJBdjDaJu5NhGqfSeLgqH7PXijsA6IpfECTG2HFMAhRnEgVycv+p2dBOQsv6/wSz+w4fgVYZsG5SEAdEzuCSEi1ew1P5vUwq+MW6h3aJopuIo6oJkGRGvlfIsBWWMeh0gci1A7q8q5+Fiq3tTbNqIjphwPdQgmumcRSWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769015316; c=relaxed/simple; bh=ylt8hCn+PfJWRmyhebzDTVE9RwwtBWImeihh+sFkkuU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=LGtubsxKSCY/Y165sSzlZghHzEpvxd24ZBe0muvKWmhhJSUw4VsMH0knM/caEmXX7oQZFuPJOOrCp1r0V6bNdToqiNYe+tFgXgem6BiaSi8MBk2Z86CQR4XLKzfmDq7q5n1EwrhpDG7p9oX4LlNsIbMUhzmdAkI+u0tXzlsY/F4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=h+n/GTfV; arc=none smtp.client-ip=209.85.161.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="h+n/GTfV" Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-66109b09b53so26165eaf.1 for ; Wed, 21 Jan 2026 09:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769015312; x=1769620112; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=af5XQHYCmWbE8OkeX4m6uk9+GAFVqnxcLOlrwMZ+INI=; b=h+n/GTfVDfC0BnQKeAs3UcEYynhRK2NmF92CFepuqe/EW762IF9ihms4X7s4PjWISW tqODo4WmOO5ngorVxINd+p3Ly4lvjBwpOrLVcIx58ywM8sq2vZPx7v3l5pbQTKQF4NgQ E+gBMP4+ZdwEgL+trKcQs2hEZl9Xjo1dQOaycaLMpLOI0wRGpygbIKDrIx8xKvIUYcZW za2g7LwYCRrh5GfpwvK665H41teWxsz5AhTiU5KMSdJ14c9TeRebCbq5DzpVzOXo/qHJ 5lK4PGarvyAJx+kHl41PbILCgodlFbicUKTICITOpQHdfqac0dV16JdPgwk8lTxO44KY aNag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769015312; x=1769620112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=af5XQHYCmWbE8OkeX4m6uk9+GAFVqnxcLOlrwMZ+INI=; b=JJ05KEy53n1+jcw7keD5CvpvcaHubb+cvGOV/mgR07YKd4pxzoSqHVTR74FcUYPpSk 0ITpkrnI/6FMAsni29bWoZxF9GWIZts/BHVamRhf0CQB4X8TTuWhS8T+WqDUMPqHyeJ9 6nX96884kruVggqTXF/KxqAT/O4lqkSVXt44CrgQTaXKikl/mb0geZH/srdmoGE0ev+R QVZPxSQNIBP15LE7ZWOXbY4IydfAPVWLFDNRBmDwhewLNub4qUhq5lX31WPixkLDUa5C M8keimNmj91QOl0GQXVCoYFHHkMbii3ls8LVOmljhb+OEsH5WJX99fLf/wyStOjBRN3N lHuQ== X-Forwarded-Encrypted: i=1; AJvYcCVEBr8GnQvT4uH9rK7vvM7I09JUm+E4KQyoIx1nWzerWbOiHaB81LSJMu773MVLkaWBglnIKnemwRvT7Wk=@vger.kernel.org X-Gm-Message-State: AOJu0YySa+u7uKfdMn6oDi+WTSZCf71omAN2QRNNfPyzz6uJpmC2gy34 TSIZM9vygJDKoxKaMDKHLv7WPBZaJW1682n4TY1FrS7ts0PwbjvjshcORshiww== X-Gm-Gg: AZuq6aIPcdC/A9VyFbDxgCSW1jDTU2bJyMtT6Ykt8FJha1FO6wy35WL7hhZqyPmC9yE mHTrzv3ggnE28wUR5mE+OfbW2yPf1EZxzDrllTKkohUNv1groMIDXhVhwUd5axqOfZskMQA1pzZ vuQyKTz35KUF+nTgUqatZ3MDEN0M6yyM2sm7GBqVCvUPTPOj+J33xH8wFMiF8+1eh6AhxrXZ+3W AhC9EBJ6LrqNfZ5d4W6A47GZDv6Lt9rC0U/nJGO316VDiL3F/nP9CtGHjoWCHqE9EwvO5djtXPW zW9azelV0bDzs7MOMAJERof3tPZVFa6lWmD3XHJd5xGYHZs7TVxGxz6hudTXAfV3k7tUVvJHEag sfHB10GNhdzI73nVH+qoaEBhNWt0QI4pPkRUAf4fzjmA5pM/sc4eYW368cbXFUoISRKNUtPvUGi kjJHxiuSqm4cGJwjQ20VVG1BAVMywCWuCaB2d2FiAv0nPM3Q6FfjM0HMw= X-Received: by 2002:a05:6820:480f:b0:65f:69f7:d0e4 with SMTP id 006d021491bc7-66117a3d381mr6187186eaf.83.1769015311981; Wed, 21 Jan 2026 09:08:31 -0800 (PST) Received: from smtpclient.apple ([207.154.79.109]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-661187840d8sm8111739eaf.12.2026.01.21.09.08.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2026 09:08:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: [PATCH] drm/tegra: Enable cmu for Tegra186 and Tegra194 From: Kurt Kiefer In-Reply-To: Date: Wed, 21 Jan 2026 09:08:19 -0800 Cc: Jasper Korten , Thierry Reding , Mikko Perttunen , David Airlie , Simona Vetter , Jonathan Hunter , dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <8615742F-EE35-4B37-BA0A-D62FFD5424B4@gmail.com> References: <20251101-tegra-drm-cmu-v1-1-211799755ab8@gmail.com> <72llskwvuwyllvz24zoex4ad6v6t5skiehmwylj7exoh7bmzjo@xq3v7vja5w62> To: Aaron Kling X-Mailer: Apple Mail (2.3864.300.41.1.7) > On Dec 8, 2025, at 8:23=E2=80=AFPM, Aaron Kling = wrote: >=20 > On Wed, Nov 5, 2025 at 3:28=E2=80=AFPM Jasper Korten = wrote: >>=20 >> Hi all, >>=20 >> On 11/4/25 19:12, Aaron Kling wrote: >>> On Tue, Nov 4, 2025 at 3:14=E2=80=AFAM Thierry Reding = wrote: >>>> On Mon, Nov 03, 2025 at 12:39:57PM -0600, Aaron Kling wrote: >>>>> On Mon, Nov 3, 2025 at 5:54=E2=80=AFAM Thierry Reding = wrote: >>>>>> On Sat, Nov 01, 2025 at 06:15:17PM -0500, Aaron Kling via B4 = Relay wrote: >>>>>>> From: Aaron Kling >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Signed-off-by: Aaron Kling >>>>>>> --- >>>>>>> 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. >>>>=20 >>>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >>=20 >> 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. >=20 > 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. >=20 > Aaron >=20 I can confirm that I have the same issue on a DisplayPort output of = t194. IMO, this patch will need to be reworked a bit to enable the CMU for = this output as well. I hacked this change in for DisplayPort, and then it functioned as intended there as well. I've traced back to the reason this is necessary. The DC hub driver is applying an sRGB degamma for every RGB plane (presumably for blending), and then nothing reapplies the EOTF later on. Without gamma correction in places where it is expected, images are going to look "too dark". Which does raise the point that there is an alternative implementation where we do not degamma RGB planes in the first place. But this may have unintended consequences when it comes to composition. The SOR does not appear to handle YCbCr outputs at this time, so = enabling the CMU assuming an sRGB EOTF seems like a reasonable path here, to me. Kurt=