Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3065626pxj; Mon, 7 Jun 2021 01:02:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZJxrs7KO/FU6zzwOvK4iim7AT42+UA6UOTum/sKjeyea/lqS+hLNKP2f8GwBHir+0tTAv X-Received: by 2002:a05:6402:35c8:: with SMTP id z8mr7475489edc.348.1623052962531; Mon, 07 Jun 2021 01:02:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623052962; cv=none; d=google.com; s=arc-20160816; b=O5RYXRCgyB0n0Ef6aG0xeJ0O5xgh5xhcePIjxzeqf5PBWjUwit4d4fjB1E9M5p5mA5 px2fK11CGDi/bcF2MrqT03/sob5Epk/1phFsjfoQe5U54UXjkxK4/mqxp2VRotPtNKc0 r9RDMdfg4EmOyOFnj70Y8aKNRUag36aOSvux6jaz816yrx75zXP0gcb5Ey8lQDLpqKnj gBIp1tFJY/E0HWfXGFJvI8PvoBV5SL8La3heEiSPoes4SL4ueM1lgoW9yXhzsPXaUHv5 tfOwnjL8UFh3gB6ntbsZvP1ZQwFlSUk1pCqFkOJGV5o8GF0hbL3IMXP9vQ9nyrMPafi+ x0vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=E1b2ASsc7pfJKuhrgyfvKjDf2TVAQuXssz7P64C1UqE=; b=VByzHGMMpBJotvOHs2agYac57qRrR1S5HwkddbDGvjBpyQhvvTHcM3N5fxqZGYRwIy 0cLLuxaBcq5Bd2smpJn1CTnZF+KK4EDztfnMEY3C8/7RcMBZJrMon08OnO4l2E5nQ9fm RJ5ctvoK3/AhkJlOoZ5qNB0+zRDlOwchoehoSEscJRcL5+/+diuQsbKEU1SEmSB14q4F QLeKMy0E3ZsGibx+QIH0kthsc4Vg37MAjaH0qnT76pqKZDpbGYaBBjzZE2kbPD6p6c5Z WOR8TxZi5y47cAttF8nbFOpYbo34HCwdQ39FQXNUMAaliRiYNYfQZ4d5sJAPOqwDpbHG 8sRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j8si7278808edj.124.2021.06.07.01.02.19; Mon, 07 Jun 2021 01:02:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230198AbhFGICi (ORCPT + 99 others); Mon, 7 Jun 2021 04:02:38 -0400 Received: from srv6.fidu.org ([159.69.62.71]:38652 "EHLO srv6.fidu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230175AbhFGICh (ORCPT ); Mon, 7 Jun 2021 04:02:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by srv6.fidu.org (Postfix) with ESMTP id CFDD9C800A2; Mon, 7 Jun 2021 10:00:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at srv6.fidu.org Received: from srv6.fidu.org ([127.0.0.1]) by localhost (srv6.fidu.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vz3RaQVqPJhP; Mon, 7 Jun 2021 10:00:44 +0200 (CEST) Received: from [IPv6:2003:e3:7f4f:6000:f5f4:4cdd:8015:9770] (p200300E37F4f6000F5f44cdD80159770.dip0.t-ipconnect.de [IPv6:2003:e3:7f4f:6000:f5f4:4cdd:8015:9770]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: wse@tuxedocomputers.com) by srv6.fidu.org (Postfix) with ESMTPSA id 480A0C800E6; Mon, 7 Jun 2021 10:00:31 +0200 (CEST) Subject: Re: [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property To: Maxime Ripard Cc: tzimmermann@suse.de, intel-gfx@lists.freedesktop.org, sunpeng.li@amd.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, airlied@linux.ie, amd-gfx@lists.freedesktop.org, rodrigo.vivi@intel.com, alexander.deucher@amd.com, christian.koenig@amd.com References: <20210604171723.10276-1-wse@tuxedocomputers.com> <20210604171723.10276-3-wse@tuxedocomputers.com> <20210607074037.oxm7qbhcx7gsg6yd@gilmour> From: Werner Sembach Message-ID: <55a45d9e-9784-0288-fc1f-144f99dc6c19@tuxedocomputers.com> Date: Mon, 7 Jun 2021 10:00:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210607074037.oxm7qbhcx7gsg6yd@gilmour> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 07.06.21 um 09:40 schrieb Maxime Ripard: > Hi, > > On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote: >> Add a new general drm property "active bpc" which can be used by graphic drivers >> to report the applied bit depth per pixel back to userspace. > Just a heads up, we'll need an open source project that has accepted it > before merging it. > > See https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements Yes, I know. > >> While "max bpc" can be used to change the color depth, there was no way to check >> which one actually got used. While in theory the driver chooses the best/highest >> color depth within the max bpc setting a user might not be fully aware what his >> hardware is or isn't capable off. This is meant as a quick way to double check >> the setup. >> >> In the future, automatic color calibration for screens might also depend on this >> information available. >> >> Signed-off-by: Werner Sembach >> --- >> drivers/gpu/drm/drm_atomic_uapi.c | 2 ++ >> drivers/gpu/drm/drm_connector.c | 40 +++++++++++++++++++++++++++++++ >> include/drm/drm_connector.h | 15 ++++++++++++ >> 3 files changed, 57 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c >> index 268bb69c2e2f..7ae4e40936b5 100644 >> --- a/drivers/gpu/drm/drm_atomic_uapi.c >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c >> @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector, >> *val = 0; >> } else if (property == connector->max_bpc_property) { >> *val = state->max_requested_bpc; >> + } else if (property == connector->active_bpc_property) { >> + *val = state->active_bpc; >> } else if (connector->funcs->atomic_get_property) { >> return connector->funcs->atomic_get_property(connector, >> state, property, val); >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c >> index 7631f76e7f34..5f42a5be5822 100644 >> --- a/drivers/gpu/drm/drm_connector.c >> +++ b/drivers/gpu/drm/drm_connector.c >> @@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { >> * drm_connector_attach_max_bpc_property() to create and attach the >> * property to the connector during initialization. >> * >> + * active bpc: >> + * This read-only range property is used by userspace check the bit depth >> + * actually applied by the GPU driver after evaluation all hardware > ^ display > > Depending on the system, the display component might have a GPU attached > or not, and the GPU might have a display component or not. Ok, I try to bee more clear in the wording > >> + * capabilities and max bpc. Drivers to use the function >> + * drm_connector_attach_active_bpc_property() to create and attach the >> + * property to the connector during initialization. >> + * >> * Connectors also have one standardized atomic property: >> * >> * CRTC_ID: >> @@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, >> } >> EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); >> >> +/** >> + * drm_connector_attach_active_bpc_property - attach "active bpc" property >> + * @connector: connector to attach active bpc property on. >> + * @min: The minimum bit depth supported by the connector. >> + * @max: The maximum bit depth supported by the connector. >> + * >> + * This is used to check the applied bit depth on a connector. >> + * >> + * Returns: >> + * Zero on success, negative errno on failure. >> + */ >> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector, >> + int min, int max) >> +{ >> + struct drm_device *dev = connector->dev; >> + struct drm_property *prop; >> + >> + prop = connector->active_bpc_property; >> + if (!prop) { >> + prop = drm_property_create_range(dev, 0, "active bpc", min, max); >> + if (!prop) >> + return -ENOMEM; >> + >> + connector->active_bpc_property = prop; >> + } >> + >> + drm_object_attach_property(&connector->base, prop, 0); >> + connector->state->active_bpc = 0; > I guess we want to default to 8? > > Maxime The default state should only be active when no display is connected or the display is off, so I thought 0 makes more sense, as no active display = no active bpc.