From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Date: Thu, 22 Feb 2018 12:47:43 -0800 Message-ID: <87a7w0rbtc.fsf@anholt.net> References: <1519271648-33102-1-git-send-email-stschake@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0163587583==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 0F9D16E0FA for ; Thu, 22 Feb 2018 20:47:46 +0000 (UTC) In-Reply-To: <1519271648-33102-1-git-send-email-stschake@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel Cc: Stefan Schake List-Id: dri-devel@lists.freedesktop.org --===============0163587583== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Stefan Schake writes: > Android assumes an implicit black background layer is always present > behind all layers it specifies for composition. drm_hwcomposer currently > punts responsibility for this to the kernel/DRM platform and puts layers > with per-pixel alpha content on the primary plane when requested. > > On some platforms (e.g. VC4) a background color fill has a cycle cost for > the hardware composer and is not enabled by default. Instead, userland can > request a background color through a CRTC property. Use this property to > specify the implicit black background Android expects. > > Signed-off-by: Stefan Schake > --- > Kernel changes for this (background_color) are available here: > > https://github.com/stschake/linux/commits/background-upstream > > Sending as RFC because I'm not entirely clear on whose responsibility > this should be, on most DRM drivers it seems to be implicit. I think > a case could also be made that VC4 should not accept alpha formats on > the lowest layer or enable background color fill when given one anyway. > On the other hand, userland control over background color seems desirable > regardless and is a feature of multiple hardware composers (i915, vc4, omap). Couldn't we just ignore the alpha channel on the primary plane, on the assumption that it's supposed to be all zeroes below it? Or are we not premultiplied, so we do still need to multiply the primary plane's colors by the alpha value? I couldn't find any obvious DRM documentation about whether alpha is premultiplied. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlqPLG8ACgkQtdYpNtH8 nujixQ//ebEpXXPeJysI8NanzBzGtSIXgS497zFnyC1lAufWg6/BupcEAGQ7pady WDLBFd3IcXPRixsLtXI3NRtzkh1aGBOVxm78Tkpg6DzJb89iEDD4UAGoQf6T8LM9 SA+vmF0gUn67fmIfwFm2JX9dieuhaII8MUvjbOIa9V8xf9L4gS1swMuLlqAvYkCd Ri1Szl0t/cA1j39elbwjaTsl47zZqvNyAk0PN7OB2r00Zw3kXQbtxpfkk0YTR5Y2 GEXImFcIN8QadoP7Cp9eSPUX/BOhqguajkhEueCUu6CXKJseTulMwo+htTnRkFGF uEOwqeW6P4hmO5Ggkmi+5zhV78XU3gZPzJlNVsFOPC6cj8d/4OsGmuZNUIv47j3t Lih9KUCwFMxPrWaEuBONF6O2jh+SBy3ZsZxilaNUPOvuIcHGXietEr7WVDBWv/zE Piz1lG1YRntvvSStcVwUh1vGe55eJV5y1GiGd/SFA0auFzah8uFUgqJmXDn1IL0O 32SDv4t8n6mlf3sS96s8I1uEuKAuCjgjY4iIOtztmAYsvLRXMuEZUlKBVemafgJ7 7j8s50V2DcjOXxDOzuIBsBuWAEee+7ihA3VE79QiWhGePfbGnB9Xf9UtQPoctd68 dQFN1Tfczj/2chQnJtdNVe5FsBqrXXkES086fv/kWXyGghkUugY= =rHpD -----END PGP SIGNATURE----- --=-=-=-- --===============0163587583== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0163587583==--