From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DADDC43461 for ; Wed, 19 May 2021 09:34:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 22085613B4 for ; Wed, 19 May 2021 09:34:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 22085613B4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AFFCA6ECF6; Wed, 19 May 2021 09:34:12 +0000 (UTC) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1D4D26E243; Wed, 19 May 2021 09:34:11 +0000 (UTC) Received: by mail-lj1-x233.google.com with SMTP id e11so14790337ljn.13; Wed, 19 May 2021 02:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=ctT/5/xc2v60tfVBuU70gynhEus2tJ7LfF9eRAMDp4bVW23Cr0l+KtN+5BqZP9MDJ4 nhFID3wbcOoaTIuqXJhDPpKEdteb8QGiPnlr9VVU3PRP88NgwKd5xrphibllssFumL5B lbarigZtnY7bBYjDsn4CHr+fsE0C1xS0PMwZ9+Ru+bw4u0yFzfxLIVwUEFb/xTfGzaVR dHLdX8oKXAyKrv8ZzE4BU7zttHSXAT5Q4x0nue05f3FbMts075JF2zrA9otR/UGAsfry Ntuj5MKev/hi78YRQFiwRcON0VVHn3tMUCBmgLzquPEAs+WHanljz02CsKwNDN9xbFa2 Xqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=jCNSGBSEB6VJSkSTi+FDlAs/DQxyVYdx9wKdvE4TWzQhCIy6B/oFlUWibQqWasqHCG ptc2shoeP0EViGbUrY/AiuFP0uinFJsScxXVO0c01s+i4rEHi2H42b9xbllDcqr0BvMj YyFUYhrWN6a6nZYNxroE+qHk4VQqIHKgOux/LvVunDcO1VmnWiH3yLJJKCbG3BnipfRm YtQNjdY6f5Z8MsKceR0rfXmS9y2KNhRGmFEeqeLqIUpQgYp0XuRsIUB8Ju3OxpAUXjfu fuCzWEHdYiVjwqGl4nYsCTu9k4oEhL/o301W8YJFsnCqxVIc1cskRaUNM36QZxCWbW0R 8EbQ== X-Gm-Message-State: AOAM5309yh03kAvDSY0WtfSSZHtrEy2rNmf0kvbLQxGMH15zy0Zat1ZB RRUd0tTgvkiUcs6Y0qpOrEw= X-Google-Smtp-Source: ABdhPJyRQECAfrcbN5v3yeUw8aJU5JkoSFeNQDtliwjRgoR1Spo74K9d5cjC0Neq19S1JoMcJAUfkA== X-Received: by 2002:a2e:a7c7:: with SMTP id x7mr7907151ljp.417.1621416849423; Wed, 19 May 2021 02:34:09 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id n8sm450380lfi.60.2021.05.19.02.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 02:34:09 -0700 (PDT) Date: Wed, 19 May 2021 12:34:05 +0300 From: Pekka Paalanen To: Ville =?UTF-8?B?U3lyasOkbMOk?= Subject: Re: New uAPI for color management proposal and feedback request Message-ID: <20210519123405.4d3218a7@eldfell> In-Reply-To: References: <8c0d7ad8-7ade-bf8a-0414-cc795fbb6aa2@tuxedocomputers.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AozgflNR6L4c7UMgl=YE5w="; protocol="application/pgp-signature" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Deucher, Alexander" , intel-gfx@lists.freedesktop.org, amd-gfx list , Maling list - DRI developers , Werner Sembach Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 12 May 2021 16:04:16 +0300 Ville Syrj=C3=A4l=C3=A4 wrote: > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > >=20 > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" d= rm properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range",= and "active pixel encoding" > >=20 > >=20 > > Motivation: > >=20 > > Current monitors have a variety pixel encodings available: RGB, YCbCr 4= :4:4, YCbCr 4:2:2, YCbCr 4:2:0. > >=20 > > In addition they might be full or limited RGB range and the monitors ac= cept different bit depths. > >=20 > > Currently the kernel driver for AMD and Intel GPUs automatically config= ure the color settings automatically with little > > to no influence of the user. However there are several real world scena= rios where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preferenc= e. > >=20 > > Some examples: > >=20 > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color i= nformation, some screens might look better on one > > than the other because of bad internal conversion. The driver currently= however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to chan= ge this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > >=20 > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some = hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the m= onitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work = fine without changing hardware. The drivers > > currently however always default to the "best available" option even if= it might be broken. > >=20 > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit c= olor by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but = the user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > >=20 > > 4. Some screens are falsely classified as full RGB range wile they actu= ally use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be hel= pful to manually fix this issue when it occurs. > >=20 > > There already exist several requests, discussion, and patches regarding= the thematic: > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > >=20 > > - https://lkml.org/lkml/2021/5/7/695 > >=20 > > - https://lkml.org/lkml/2021/5/11/416 > >=20 ... > > Adoption: > >=20 > > A KDE dev wants to implement the settings in the KDE settings GUI: > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 > >=20 > > Tuxedo Computers (my employer) wants to implement the settings desktop = environment agnostic in Tuxedo Control Center. I > > will start work on this in parallel to implementing the new kernel code= . =20 >=20 > I suspect everyone would be happier to accept new uapi if we had > multiple compositors signed up to implement it. I think having Weston support for these would be good, but for now it won't be much of an UI: just weston.ini to set, and the log to see what happened. However, knowing what happened is going to be important for color calibration auditing: https://gitlab.freedesktop.org/wayland/weston/-/issues/467 Yes, please, very much for read-only properties for the feedback part. Properties that both userspace and kernel will write are hard to deal with in general. Btw. "max bpc" I can kind of guess that conversion from framebuffer format to the wire bpc happens automatically and only as the final step, but "Broadcast RGB" is more complicated: is the output from the abstract pixel pipeline sent as-is and "Broadcast RGB" is just another inforframe bit to the monitor, or does "Broadcast RGB" setting actually change what happens in the pixel pipeline *and* set infoframe bits? My vague recollection is that framebuffer was always assumed to be in full range, and then if "Broadcast RGB" was set to limited range, the driver would mangle the pixel pipeline to convert from full to limited range. This means that it would be impossible to have limited range data in a framebuffer, or there might be a double-conversion by userspace programming a LUT for limited->full and then the driver adding full->limited. I'm also confused how full/limited works when framebuffer is in RGB/YCbCr and the monitor wire format is in RGB/YCbCr and there may be RGB->YCbCR or YCbCR->RGB conversions going on - or maybe even FB YCbCR -> RGB -> DEGAMMA -> CTM -> GAMMA -> YCbCR. I wish someone drew a picture of the KMS abstract pixel pipeline with all the existing KMS properties in it. :-) Thanks, pq --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmCk240ACgkQI1/ltBGq qqevjxAAhqOqJwTNqTH43n9o45nT828CVJEhixDW68u5frawVH93+7DA2UqiTLVL cmwFOF+9mH2H2qOI0rCGZuPlUzeWhLFgKWTiKbjApRw69Jc+IVZo10Odm49tdcnI 068nF/02vvO7jrCTZ/F1wjHXSBg6vwBATrefIhjS7h4QP/6IaDI/5F1xqwPehsnz p+FDG5Vh4cIqSkgFSbzNAl+r3nyiiaYbfVaZpbJwYpXC9Jzse2J9kSuaa03WPnSR OsbhhQV//nj9z2YWIvpAAYQg6RXQMeVrmNP3F/V3woByZ/1SHj+0upYtYFY/gCMz aNiWfv+ryD03k4HmZCcu4bQX5/X6neOUMVyo2zBSLORhRiFdIO6+hpzRLhW3JZN5 URbJmnms+XXFB+6L5iOpBvZnUn5Nn9RYZqdq+84Hu4qA35Q7Q7VNPz59OUJpK+ew SvylMv3Ryt5WyRC7bIYxrNNIVHScXhu7et4S4euE2frnz+ef+wIHAQU/ufKnj7mt 0dctUeYdngW5ks9Jdt/e+jz0W9wAYNW5gkcR5MtdWHh/mI3V5eKNo0v0q22VHi7z dflGuJNgy6wTL+vvIkoA0d+4Fs193Mm8rlXQScZxEzTFwlIGjrKfOAibq2rbifOh T8fF0EdwePkbiaa4yNuo0TGrQYRvi6HyfjIzxmwUK84EwA6F6Jg= =RQOw -----END PGP SIGNATURE----- --Sig_/AozgflNR6L4c7UMgl=YE5w=-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC1FDC433ED for ; Wed, 19 May 2021 09:34:13 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76D62613B9 for ; Wed, 19 May 2021 09:34:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76D62613B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 749B56ECDB; Wed, 19 May 2021 09:34:12 +0000 (UTC) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1D4D26E243; Wed, 19 May 2021 09:34:11 +0000 (UTC) Received: by mail-lj1-x233.google.com with SMTP id e11so14790337ljn.13; Wed, 19 May 2021 02:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=ctT/5/xc2v60tfVBuU70gynhEus2tJ7LfF9eRAMDp4bVW23Cr0l+KtN+5BqZP9MDJ4 nhFID3wbcOoaTIuqXJhDPpKEdteb8QGiPnlr9VVU3PRP88NgwKd5xrphibllssFumL5B lbarigZtnY7bBYjDsn4CHr+fsE0C1xS0PMwZ9+Ru+bw4u0yFzfxLIVwUEFb/xTfGzaVR dHLdX8oKXAyKrv8ZzE4BU7zttHSXAT5Q4x0nue05f3FbMts075JF2zrA9otR/UGAsfry Ntuj5MKev/hi78YRQFiwRcON0VVHn3tMUCBmgLzquPEAs+WHanljz02CsKwNDN9xbFa2 Xqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=jCNSGBSEB6VJSkSTi+FDlAs/DQxyVYdx9wKdvE4TWzQhCIy6B/oFlUWibQqWasqHCG ptc2shoeP0EViGbUrY/AiuFP0uinFJsScxXVO0c01s+i4rEHi2H42b9xbllDcqr0BvMj YyFUYhrWN6a6nZYNxroE+qHk4VQqIHKgOux/LvVunDcO1VmnWiH3yLJJKCbG3BnipfRm YtQNjdY6f5Z8MsKceR0rfXmS9y2KNhRGmFEeqeLqIUpQgYp0XuRsIUB8Ju3OxpAUXjfu fuCzWEHdYiVjwqGl4nYsCTu9k4oEhL/o301W8YJFsnCqxVIc1cskRaUNM36QZxCWbW0R 8EbQ== X-Gm-Message-State: AOAM5309yh03kAvDSY0WtfSSZHtrEy2rNmf0kvbLQxGMH15zy0Zat1ZB RRUd0tTgvkiUcs6Y0qpOrEw= X-Google-Smtp-Source: ABdhPJyRQECAfrcbN5v3yeUw8aJU5JkoSFeNQDtliwjRgoR1Spo74K9d5cjC0Neq19S1JoMcJAUfkA== X-Received: by 2002:a2e:a7c7:: with SMTP id x7mr7907151ljp.417.1621416849423; Wed, 19 May 2021 02:34:09 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id n8sm450380lfi.60.2021.05.19.02.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 02:34:09 -0700 (PDT) Date: Wed, 19 May 2021 12:34:05 +0300 From: Pekka Paalanen To: Ville =?UTF-8?B?U3lyasOkbMOk?= Message-ID: <20210519123405.4d3218a7@eldfell> In-Reply-To: References: <8c0d7ad8-7ade-bf8a-0414-cc795fbb6aa2@tuxedocomputers.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Subject: Re: [Intel-gfx] New uAPI for color management proposal and feedback request X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Deucher, Alexander" , intel-gfx@lists.freedesktop.org, amd-gfx list , Maling list - DRI developers Content-Type: multipart/mixed; boundary="===============1349498898==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============1349498898== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AozgflNR6L4c7UMgl=YE5w="; protocol="application/pgp-signature" --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 12 May 2021 16:04:16 +0300 Ville Syrj=C3=A4l=C3=A4 wrote: > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > >=20 > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" d= rm properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range",= and "active pixel encoding" > >=20 > >=20 > > Motivation: > >=20 > > Current monitors have a variety pixel encodings available: RGB, YCbCr 4= :4:4, YCbCr 4:2:2, YCbCr 4:2:0. > >=20 > > In addition they might be full or limited RGB range and the monitors ac= cept different bit depths. > >=20 > > Currently the kernel driver for AMD and Intel GPUs automatically config= ure the color settings automatically with little > > to no influence of the user. However there are several real world scena= rios where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preferenc= e. > >=20 > > Some examples: > >=20 > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color i= nformation, some screens might look better on one > > than the other because of bad internal conversion. The driver currently= however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to chan= ge this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > >=20 > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some = hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the m= onitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work = fine without changing hardware. The drivers > > currently however always default to the "best available" option even if= it might be broken. > >=20 > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit c= olor by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but = the user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > >=20 > > 4. Some screens are falsely classified as full RGB range wile they actu= ally use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be hel= pful to manually fix this issue when it occurs. > >=20 > > There already exist several requests, discussion, and patches regarding= the thematic: > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > >=20 > > - https://lkml.org/lkml/2021/5/7/695 > >=20 > > - https://lkml.org/lkml/2021/5/11/416 > >=20 ... > > Adoption: > >=20 > > A KDE dev wants to implement the settings in the KDE settings GUI: > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 > >=20 > > Tuxedo Computers (my employer) wants to implement the settings desktop = environment agnostic in Tuxedo Control Center. I > > will start work on this in parallel to implementing the new kernel code= . =20 >=20 > I suspect everyone would be happier to accept new uapi if we had > multiple compositors signed up to implement it. I think having Weston support for these would be good, but for now it won't be much of an UI: just weston.ini to set, and the log to see what happened. However, knowing what happened is going to be important for color calibration auditing: https://gitlab.freedesktop.org/wayland/weston/-/issues/467 Yes, please, very much for read-only properties for the feedback part. Properties that both userspace and kernel will write are hard to deal with in general. Btw. "max bpc" I can kind of guess that conversion from framebuffer format to the wire bpc happens automatically and only as the final step, but "Broadcast RGB" is more complicated: is the output from the abstract pixel pipeline sent as-is and "Broadcast RGB" is just another inforframe bit to the monitor, or does "Broadcast RGB" setting actually change what happens in the pixel pipeline *and* set infoframe bits? My vague recollection is that framebuffer was always assumed to be in full range, and then if "Broadcast RGB" was set to limited range, the driver would mangle the pixel pipeline to convert from full to limited range. This means that it would be impossible to have limited range data in a framebuffer, or there might be a double-conversion by userspace programming a LUT for limited->full and then the driver adding full->limited. I'm also confused how full/limited works when framebuffer is in RGB/YCbCr and the monitor wire format is in RGB/YCbCr and there may be RGB->YCbCR or YCbCR->RGB conversions going on - or maybe even FB YCbCR -> RGB -> DEGAMMA -> CTM -> GAMMA -> YCbCR. I wish someone drew a picture of the KMS abstract pixel pipeline with all the existing KMS properties in it. :-) Thanks, pq --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmCk240ACgkQI1/ltBGq qqevjxAAhqOqJwTNqTH43n9o45nT828CVJEhixDW68u5frawVH93+7DA2UqiTLVL cmwFOF+9mH2H2qOI0rCGZuPlUzeWhLFgKWTiKbjApRw69Jc+IVZo10Odm49tdcnI 068nF/02vvO7jrCTZ/F1wjHXSBg6vwBATrefIhjS7h4QP/6IaDI/5F1xqwPehsnz p+FDG5Vh4cIqSkgFSbzNAl+r3nyiiaYbfVaZpbJwYpXC9Jzse2J9kSuaa03WPnSR OsbhhQV//nj9z2YWIvpAAYQg6RXQMeVrmNP3F/V3woByZ/1SHj+0upYtYFY/gCMz aNiWfv+ryD03k4HmZCcu4bQX5/X6neOUMVyo2zBSLORhRiFdIO6+hpzRLhW3JZN5 URbJmnms+XXFB+6L5iOpBvZnUn5Nn9RYZqdq+84Hu4qA35Q7Q7VNPz59OUJpK+ew SvylMv3Ryt5WyRC7bIYxrNNIVHScXhu7et4S4euE2frnz+ef+wIHAQU/ufKnj7mt 0dctUeYdngW5ks9Jdt/e+jz0W9wAYNW5gkcR5MtdWHh/mI3V5eKNo0v0q22VHi7z dflGuJNgy6wTL+vvIkoA0d+4Fs193Mm8rlXQScZxEzTFwlIGjrKfOAibq2rbifOh T8fF0EdwePkbiaa4yNuo0TGrQYRvi6HyfjIzxmwUK84EwA6F6Jg= =RQOw -----END PGP SIGNATURE----- --Sig_/AozgflNR6L4c7UMgl=YE5w=-- --===============1349498898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1349498898==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8B82C433B4 for ; Wed, 19 May 2021 09:34:12 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AC40D613B9 for ; Wed, 19 May 2021 09:34:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC40D613B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 451996E243; Wed, 19 May 2021 09:34:12 +0000 (UTC) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1D4D26E243; Wed, 19 May 2021 09:34:11 +0000 (UTC) Received: by mail-lj1-x233.google.com with SMTP id e11so14790337ljn.13; Wed, 19 May 2021 02:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=ctT/5/xc2v60tfVBuU70gynhEus2tJ7LfF9eRAMDp4bVW23Cr0l+KtN+5BqZP9MDJ4 nhFID3wbcOoaTIuqXJhDPpKEdteb8QGiPnlr9VVU3PRP88NgwKd5xrphibllssFumL5B lbarigZtnY7bBYjDsn4CHr+fsE0C1xS0PMwZ9+Ru+bw4u0yFzfxLIVwUEFb/xTfGzaVR dHLdX8oKXAyKrv8ZzE4BU7zttHSXAT5Q4x0nue05f3FbMts075JF2zrA9otR/UGAsfry Ntuj5MKev/hi78YRQFiwRcON0VVHn3tMUCBmgLzquPEAs+WHanljz02CsKwNDN9xbFa2 Xqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=M4/CJdize/QPrExYkYoO17mX9iuO/FeUCuYX4ZYy1Eg=; b=jCNSGBSEB6VJSkSTi+FDlAs/DQxyVYdx9wKdvE4TWzQhCIy6B/oFlUWibQqWasqHCG ptc2shoeP0EViGbUrY/AiuFP0uinFJsScxXVO0c01s+i4rEHi2H42b9xbllDcqr0BvMj YyFUYhrWN6a6nZYNxroE+qHk4VQqIHKgOux/LvVunDcO1VmnWiH3yLJJKCbG3BnipfRm YtQNjdY6f5Z8MsKceR0rfXmS9y2KNhRGmFEeqeLqIUpQgYp0XuRsIUB8Ju3OxpAUXjfu fuCzWEHdYiVjwqGl4nYsCTu9k4oEhL/o301W8YJFsnCqxVIc1cskRaUNM36QZxCWbW0R 8EbQ== X-Gm-Message-State: AOAM5309yh03kAvDSY0WtfSSZHtrEy2rNmf0kvbLQxGMH15zy0Zat1ZB RRUd0tTgvkiUcs6Y0qpOrEw= X-Google-Smtp-Source: ABdhPJyRQECAfrcbN5v3yeUw8aJU5JkoSFeNQDtliwjRgoR1Spo74K9d5cjC0Neq19S1JoMcJAUfkA== X-Received: by 2002:a2e:a7c7:: with SMTP id x7mr7907151ljp.417.1621416849423; Wed, 19 May 2021 02:34:09 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id n8sm450380lfi.60.2021.05.19.02.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 02:34:09 -0700 (PDT) Date: Wed, 19 May 2021 12:34:05 +0300 From: Pekka Paalanen To: Ville =?UTF-8?B?U3lyasOkbMOk?= Subject: Re: New uAPI for color management proposal and feedback request Message-ID: <20210519123405.4d3218a7@eldfell> In-Reply-To: References: <8c0d7ad8-7ade-bf8a-0414-cc795fbb6aa2@tuxedocomputers.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Deucher, Alexander" , intel-gfx@lists.freedesktop.org, amd-gfx list , Maling list - DRI developers , Werner Sembach Content-Type: multipart/mixed; boundary="===============0502358379==" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" --===============0502358379== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AozgflNR6L4c7UMgl=YE5w="; protocol="application/pgp-signature" --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 12 May 2021 16:04:16 +0300 Ville Syrj=C3=A4l=C3=A4 wrote: > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: > > Hello, > >=20 > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" d= rm properties I propose 4 new properties: > > "preferred pixel encoding", "active color depth", "active color range",= and "active pixel encoding" > >=20 > >=20 > > Motivation: > >=20 > > Current monitors have a variety pixel encodings available: RGB, YCbCr 4= :4:4, YCbCr 4:2:2, YCbCr 4:2:0. > >=20 > > In addition they might be full or limited RGB range and the monitors ac= cept different bit depths. > >=20 > > Currently the kernel driver for AMD and Intel GPUs automatically config= ure the color settings automatically with little > > to no influence of the user. However there are several real world scena= rios where the user might disagree with the > > default chosen by the drivers and wants to set his or her own preferenc= e. > >=20 > > Some examples: > >=20 > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color i= nformation, some screens might look better on one > > than the other because of bad internal conversion. The driver currently= however has a fixed default that is chosen if > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to chan= ge this currently is by editing and overloading > > the edid reported by the monitor to the kernel. > >=20 > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some = hardware might report that it supports the higher > > port clock, but because of bad shielding on the PC, the cable, or the m= onitor the screen cuts out every few seconds when > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work = fine without changing hardware. The drivers > > currently however always default to the "best available" option even if= it might be broken. > >=20 > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit c= olor by rapidly switching between 2 adjacent > > colors. They advertise themselves to the kernel as 10-bit monitors but = the user might not like the "fake" 10-bit effect > > and prefer running at the native 8-bit per color. > >=20 > > 4. Some screens are falsely classified as full RGB range wile they actu= ally use limited RGB range. This results in > > washed out colors in dark and bright scenes. A user override can be hel= pful to manually fix this issue when it occurs. > >=20 > > There already exist several requests, discussion, and patches regarding= the thematic: > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476 > >=20 > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 > >=20 > > - https://lkml.org/lkml/2021/5/7/695 > >=20 > > - https://lkml.org/lkml/2021/5/11/416 > >=20 ... > > Adoption: > >=20 > > A KDE dev wants to implement the settings in the KDE settings GUI: > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 > >=20 > > Tuxedo Computers (my employer) wants to implement the settings desktop = environment agnostic in Tuxedo Control Center. I > > will start work on this in parallel to implementing the new kernel code= . =20 >=20 > I suspect everyone would be happier to accept new uapi if we had > multiple compositors signed up to implement it. I think having Weston support for these would be good, but for now it won't be much of an UI: just weston.ini to set, and the log to see what happened. However, knowing what happened is going to be important for color calibration auditing: https://gitlab.freedesktop.org/wayland/weston/-/issues/467 Yes, please, very much for read-only properties for the feedback part. Properties that both userspace and kernel will write are hard to deal with in general. Btw. "max bpc" I can kind of guess that conversion from framebuffer format to the wire bpc happens automatically and only as the final step, but "Broadcast RGB" is more complicated: is the output from the abstract pixel pipeline sent as-is and "Broadcast RGB" is just another inforframe bit to the monitor, or does "Broadcast RGB" setting actually change what happens in the pixel pipeline *and* set infoframe bits? My vague recollection is that framebuffer was always assumed to be in full range, and then if "Broadcast RGB" was set to limited range, the driver would mangle the pixel pipeline to convert from full to limited range. This means that it would be impossible to have limited range data in a framebuffer, or there might be a double-conversion by userspace programming a LUT for limited->full and then the driver adding full->limited. I'm also confused how full/limited works when framebuffer is in RGB/YCbCr and the monitor wire format is in RGB/YCbCr and there may be RGB->YCbCR or YCbCR->RGB conversions going on - or maybe even FB YCbCR -> RGB -> DEGAMMA -> CTM -> GAMMA -> YCbCR. I wish someone drew a picture of the KMS abstract pixel pipeline with all the existing KMS properties in it. :-) Thanks, pq --Sig_/AozgflNR6L4c7UMgl=YE5w= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmCk240ACgkQI1/ltBGq qqevjxAAhqOqJwTNqTH43n9o45nT828CVJEhixDW68u5frawVH93+7DA2UqiTLVL cmwFOF+9mH2H2qOI0rCGZuPlUzeWhLFgKWTiKbjApRw69Jc+IVZo10Odm49tdcnI 068nF/02vvO7jrCTZ/F1wjHXSBg6vwBATrefIhjS7h4QP/6IaDI/5F1xqwPehsnz p+FDG5Vh4cIqSkgFSbzNAl+r3nyiiaYbfVaZpbJwYpXC9Jzse2J9kSuaa03WPnSR OsbhhQV//nj9z2YWIvpAAYQg6RXQMeVrmNP3F/V3woByZ/1SHj+0upYtYFY/gCMz aNiWfv+ryD03k4HmZCcu4bQX5/X6neOUMVyo2zBSLORhRiFdIO6+hpzRLhW3JZN5 URbJmnms+XXFB+6L5iOpBvZnUn5Nn9RYZqdq+84Hu4qA35Q7Q7VNPz59OUJpK+ew SvylMv3Ryt5WyRC7bIYxrNNIVHScXhu7et4S4euE2frnz+ef+wIHAQU/ufKnj7mt 0dctUeYdngW5ks9Jdt/e+jz0W9wAYNW5gkcR5MtdWHh/mI3V5eKNo0v0q22VHi7z dflGuJNgy6wTL+vvIkoA0d+4Fs193Mm8rlXQScZxEzTFwlIGjrKfOAibq2rbifOh T8fF0EdwePkbiaa4yNuo0TGrQYRvi6HyfjIzxmwUK84EwA6F6Jg= =RQOw -----END PGP SIGNATURE----- --Sig_/AozgflNR6L4c7UMgl=YE5w=-- --===============0502358379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx --===============0502358379==--