From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E466A33B6CC for ; Wed, 4 Feb 2026 20:32:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237147; cv=none; b=UnWsV3YSLMmoYYBKby4UwMdfAABfx0tVmswqLoF4sDvAiUHha7lLx40bT9iNPBsUyJ8XZYD2NW5AFY3TDuTTE4gbp5X0SU+v003958OIUTjxBZGR2ZudUOoBQ/zwoovcHAV7eu2SJLGyec0fViijRj8QqzbaQPxwSAlNKMvrHRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237147; c=relaxed/simple; bh=a5HSgzMe6JzpxSmMVQbxrnjFpksd7486GnNw1YVR+nc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jpRxB+Nwfm7ErZ7GYOCostaFN4KYtLywpwEVegAc0wsF6cDzIMjZx2qvNo/mdcPJXYXfaDW6pmnQ2s3p21Cu5oTvonpHSR8mJGiAbxE8SFJgh+ulz1nfLUGJUXliXt2E7XFWP+PVWRImYwfjJiVWzB4UxQxkaSmBZMy88NULocM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=cs3rpa8F; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="cs3rpa8F" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770237145; bh=a5HSgzMe6JzpxSmMVQbxrnjFpksd7486GnNw1YVR+nc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=cs3rpa8Fe3jTdxyppmsK8KRRNbyqKWp39e7A/bIbO5JqbczcCVOE67fj8m7N/Muud 3nH7ZY734SEWfGASW7iONGl1Bx/QN12mv2OOxhybhJ5GIINJL81uQwmaf678/YsHLn 1Qooo+akVTa1j5ujmGUdNs27RrNZHUbR0Uo6IwcK1Fq2ZKWs5iCGYbTUoOLeKFa4AR R0n2pLbJS3KCcuvZEuscTuR2UXOlAH9DAbgNPz1f16tAe8E/YFYfn9fziP8Ub7OhWN FYXiuE6HedPjNyTwyJXelCkZ2VpsFg5zlGG2vLRDJYcu6kzi8cxfTvHKit1cZ9okUp 1kFu9OA8PMARw== Received: from [192.168.1.90] (unknown [82.79.138.145]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 4863917E12C6; Wed, 4 Feb 2026 21:32:24 +0100 (CET) Message-ID: <97a4fd2d-62e2-41ad-8ee9-d2551c3ab312@collabora.com> Date: Wed, 4 Feb 2026 22:32:23 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 2/4] drm: Add CRTC background color property To: Andy Shevchenko Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Louis Chauvet , Haneen Mohammed , Melissa Wen , Jani Nikula , Robert Mader , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, Matt Roper , =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , Diederik de Haas References: <20260129-rk3588-bgcolor-v6-0-c15f755a4055@collabora.com> <20260129-rk3588-bgcolor-v6-2-c15f755a4055@collabora.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/29/26 11:37 AM, Andy Shevchenko wrote: > On Thu, Jan 29, 2026 at 02:58:52AM +0200, Cristian Ciocaltea wrote: >> Some display controllers can be hardware programmed to show non-black >> colors for pixels that are either not covered by any plane or are >> exposed through transparent regions of higher planes. This feature can >> help reduce memory bandwidth usage, e.g. in compositors managing a UI >> with a solid background color while using smaller planes to render the >> remaining content. >> >> To support this capability, introduce the BACKGROUND_COLOR standard DRM >> mode property, which can be attached to a CRTC through the >> drm_crtc_attach_background_color_property() helper function. >> >> Additionally, define a 64-bit ARGB format value to be built with the >> help of a couple of dedicated DRM_ARGB64_PREP*() helpers. Individual >> color components can be extracted with desired precision using the >> corresponding DRM_ARGB64_GET*() macros. > > ... > >> +/* >> + * Put 16-bit ARGB values into a standard 64-bit representation that can be >> + * used for ioctl parameters, inter-driver communication, etc. >> + * >> + * If the component values being provided contain less than 16 bits of >> + * precision, use a conversion ratio to get a better color approximation. >> + * The ratio is computed as (2^16 - 1) / (2^bpc - 1), where bpc and 16 are >> + * the input and output precision, respectively. > > Not sure if you should explicitly mention that "bpc must not be 0" > (it can be derived from the "division by 0" in the given formula, > but still...). Comment section updated in v7 [1], though I somehow missed to mention it in the changelog. :-( > >> + */ >> +#define __DRM_ARGB64_PREP(c, shift) \ >> + (((__u64)(c) & __GENMASK(15, 0)) << (shift)) >> + >> +#define __DRM_ARGB64_PREP_BPC(c, shift, bpc)({ \ > > Not sure if this is an accepted style in DRM, by I find it difficult > to follow. I would expect the "({" be on a separate line. I initially got confused by the plethora of different styles, e.g. in "include/linux/math.h" we can find: #define rounddown(x, y) ( \ [...] #define DIV_ROUND_CLOSEST_ULL(x, divisor)( \ [...] #define mult_frac(x, n, d) \ ({ \ [...] #define abs_diff(a, b) ({ \ [...] I agree your option is the most readable one, hence I used it consistently in v7. Thanks, Cristian [1] https://lore.kernel.org/all/20260204-rk3588-bgcolor-v7-0-78d1d01c5ca1@collabora.com/