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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 8CFA7C43463 for ; Mon, 21 Sep 2020 11:09:05 +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 425392076B for ; Mon, 21 Sep 2020 11:09:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="xzCS8kBD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 425392076B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.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 6E6446E258; Mon, 21 Sep 2020 11:09:04 +0000 (UTC) Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by gabe.freedesktop.org (Postfix) with ESMTPS id 78FD56E258 for ; Mon, 21 Sep 2020 11:09:02 +0000 (UTC) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 08LB8pLq014499; Mon, 21 Sep 2020 06:08:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1600686531; bh=Xx5E8XBm8ifY/Auds7gGllxPhDxRoNq4OSQoLqr6xfU=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=xzCS8kBDDwlK9WBNU2n8WxILG9jVasBXdoU5fnDgk59VR0ReX2CFPZYdD6aHZ1C9m x8h0uM2gkr5z2huoK5/CnqkwrGEZPCZtXn69NjYrXKzbdRQR/cHKuSiHCnKWvmytAR L9gWCaMLxpFBgcDKW3Zg5DKv/VzBV9XtY9qoHyUY= Received: from DFLE108.ent.ti.com (dfle108.ent.ti.com [10.64.6.29]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTP id 08LB8pB5108617; Mon, 21 Sep 2020 06:08:51 -0500 Received: from DFLE108.ent.ti.com (10.64.6.29) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Mon, 21 Sep 2020 06:08:50 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Mon, 21 Sep 2020 06:08:50 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 08LB8mpl093457; Mon, 21 Sep 2020 06:08:49 -0500 Subject: Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix To: Ilia Mirkin , Laurent Pinchart , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Daniel Vetter References: <20190902125359.18001-1-tomi.valkeinen@ti.com> <20190902125359.18001-5-tomi.valkeinen@ti.com> <20190903152413.GB8247@pendragon.ideasonboard.com> <20190904111105.GA4811@pendragon.ideasonboard.com> From: Tomi Valkeinen Message-ID: <5beadfb2-86a5-a782-ff88-ce77c727ecfe@ti.com> Date: Mon, 21 Sep 2020 14:08:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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: dri-devel , Jyri Sarha Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On 04/09/2019 23:20, Ilia Mirkin wrote: >>>>>> Implement CTM color management property for OMAP CRTC using DSS >>>>>> overlay manager's Color Phase Rotation matrix. The CPR matrix does not >>>>>> exactly match the CTM property documentation. On DSS the CPR matrix is >>>>>> applied after gamma table look up. However, it seems stupid to add a >>>>>> custom property just for that. >>>>> >>>>> In that case the DRM documentation should be updated to mention that >>>>> both options are allowed. >>>> >>>> Ok, if that is alright. But if we do that, then I guess all the drivers >>>> implementing CTM should document the point where it is applied in the >>>> pipeline. >>> >>> Whatever solution we end up picking, I think it should at least be >>> discussed with a broader upstream audience and not just swept under the >>> omapdrm carpet :-) >>> >> >> I'll try to write something and send the next series to wider audience. >> Let's see what jury says. > > In case it's useful ... the pipeline normally goes degamma -> ctm -> > gamma. If your ctm is applied after gamma, perhaps you can just rename > "gamma" to "degamma" and be done? (There's the unfortunate case of > legacy gamma which does end up in "GAMMA" when using atomic helpers. > But in such a case, you won't have a CTM.) Waking up old thread, as I started looking at these patches again. So the problem was that DRM defines the output color transformations as: degamma -> ctm -> gamma -> out whereas OMAP DSS has gamma -> ctm -> out The omapdrm driver could declare the gamma table as degamma, as suggested by Ilia, and for the legacy drmModeCrtcSetGamma, the omapdrm driver could implement its own version, and use the degamma table internally (with no ctm). For legacy, that would work fine and as expected, but I think the atomic version would be a bit odd, with only degamma, and no gamma. Quick grep for drm_crtc_enable_color_mgmt shows that there are other drivers that have CTM and gamma, but no degamma. I wonder if all those have ctm -> gamma -> out, or are they similar to OMAP DSS. Any thoughts on how to proceed with this? Should we have a property that describes the order? Or new property name for gamma before ctm (PREGAMMA)? Or just have it as degamma, and let the userspace deal with it (i.e. figure out there's no gamma, but there's degamma, so use degamma)? Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel