From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v3 2/3] drm: Add CRTC background color property (v3) Date: Thu, 27 Dec 2018 17:11:17 -0800 Message-ID: <878t0a5ubu.fsf@anholt.net> References: <20181115221346.27335-1-matthew.d.roper@intel.com> <20181115221346.27335-4-matthew.d.roper@intel.com> <20181119165222.GB22048@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1678984763==" Return-path: In-Reply-To: <20181119165222.GB22048@DESKTOP-E1NTVVP.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Brian Starkey , Matt Roper Cc: "wei.c.li@intel.com" , "intel-gfx@lists.freedesktop.org" , nd , "dri-devel@lists.freedesktop.org" , "harish.krupo.kps@intel.com" List-Id: intel-gfx@lists.freedesktop.org --===============1678984763== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian Starkey writes: > Hi Matt, > > On Thu, Nov 15, 2018 at 02:13:45PM -0800, Matt Roper wrote: >>Some display controllers can be programmed to present non-black colors >>for pixels not covered by any plane (or pixels covered by the >>transparent regions of higher planes). Compositors that want a UI with >>a solid color background can potentially save memory bandwidth by >>setting the CRTC background property and using smaller planes to display >>the rest of the content. >> >>To avoid confusion between different ways of encoding RGB data, we >>define a standard 64-bit format that should be used for this property's >>value. Helper functions and macros are provided to generate and dissect >>values in this standard format with varying component precision values. >> >>v2: >> - Swap internal representation's blue and red bits to make it easier >> to read if printed out. (Ville) >> - Document bgcolor property in drm_blend.c. (Sean Paul) >> - s/background_color/bgcolor/ for consistency between property name and >> value storage field. (Sean Paul) >> - Add a convenience function to attach property to a given crtc. >> >>v3: >> - Restructure ARGB component extraction macros to be easier to >> understand and enclose the parameters in () to avoid calculations >> if expressions are passed. (Sean Paul) >> - s/rgba/argb/ in helper function/macro names. Even though the idea is >> to not worry about the internal representation of the u64, it can >> still be confusing to look at code that uses 'rgba' terminology, but >> stores values with argb ordering. (Ville) >> >>Cc: dri-devel@lists.freedesktop.org >>Cc: wei.c.li@intel.com >>Cc: harish.krupo.kps@intel.com >>Cc: Ville Syrj=C3=A4l=C3=A4 >>Cc: Sean Paul >>Signed-off-by: Matt Roper >>Reviewed-by(v2): Sean Paul >>--- > >>+ * Background color is setup with drm_crtc_add_bgcolor_property(). It >>+ * controls the RGB color of a full-screen, fully-opaque layer that exis= ts >>+ * below all planes. This color will be used for pixels not covered by >>+ * any plane and may also be blended with plane contents as allowed by a >>+ * plane's alpha values. The background color defaults to black, and is >>+ * assumed to be black for drivers that do not expose this property. > > Might be worth explicitly mentioning that this value is used as-is, > without any gamma/gamut conversion before blending, i.e. it's assumed > to already be in whatever blend-space the CRTC is using (at least I > assume that's the case?). As we start making the color pipe more > complicated/explicit, the details matter more. Raspberry Pi should be able to do background color as well, but the question of where this property is in the pipeline (particularly for CTM and gamma) also came up for me. My background color would apply at the same stage as plane composition, so before gamma and CTM. FWIW, my background color on the writeback connector (the only one where the value would be relevant) can have alpha. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlwleDUACgkQtdYpNtH8 nuiw1A//QqcFjHXlcIZMPNiHFv/OztXC7oggrwF28N0yBOwD0iISEwPD99b7BF1/ c9xt8ri+VrGgfEMoAn9dTJbhe1+pexDsbBrC3H7g44eF6jPkfEEyvJADbGILNgOO PZZAEP6AUFRWUxFSW/6fxP+O2HGf6gajkq3QQPVlBw4hc3vb/Z9Jgrxk1PnxobCW Mt0lSFUYCzDUQ8IOusq8/AJcH9ayThbBcqwZ2JvzPSDipXXM03pLP77EtmGis3Z3 6AIeEm0o2bbNK9WCyyp3LDbCGTy0OoMnA+C7eabZTx3JSJYqqMvq07zFzBOhK7ic m5Abh8uneO1hJrRWPCDjqklIUAGj+iUbFPIsX6VO/DArthOhwQwasMvgTt55feLD xfF4HiC6S9HJRGiAFNxL7bnJmrAFu3yMz6/7JqR9HoqO+1OA5WcMgTpAqhQodaTE nEyk5h/coYnper0g/Z4QGlCIgobRF+q5pYIsG4uM8a1DZPqUVAfp1mBQsfRm6sjI ufiwBWLA0uoDy/XsEcJvCeOqd4oeqDknJX7pg75NQ63saV2v52rNHJ4tCMZ215t3 S6QfxvFaAKzPBD81lTPVWjWKXXt2zJO7NBsnVsskuccd2iu5u2FcWB6kSG8+gT3k c/X+3ohl3PgG0BH2Vzqcf+mE7xYErgCS/2RCuo7Jn6ohGnhrgmE= =6C9c -----END PGP SIGNATURE----- --=-=-=-- --===============1678984763== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1678984763==--