Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752539AbeAQJUd (ORCPT + 1 other); Wed, 17 Jan 2018 04:20:33 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:48584 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbeAQJU0 (ORCPT ); Wed, 17 Jan 2018 04:20:26 -0500 Date: Wed, 17 Jan 2018 10:20:24 +0100 From: Maxime Ripard To: Laurent Pinchart Cc: Daniel Vetter , Chen-Yu Tsai , Daniel Vetter , Jani Nikula , Sean Paul , Thomas Petazzoni , Boris Brezillon , Linux Kernel Mailing List , dri-devel , Linux ARM , thomas@vitsch.nl Subject: Re: [PATCH 06/19] drm/blend: Add a generic alpha property Message-ID: <20180117092024.ggnnivv6wozcyir2@flea.lan> References: <20180111155857.bbfp4772fx56s5k3@flea.lan> <7937877.87F3UCTWB7@avalon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="khkdadv3wbh7smjp" Content-Disposition: inline In-Reply-To: <7937877.87F3UCTWB7@avalon> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: --khkdadv3wbh7smjp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote: > Hi Daniel, >=20 > On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > > >>>> On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > > >>>>> Some drivers duplicate the logic to create a property to store a > > >>>>> per-plane alpha. > > >>>>>=20 > > >>>>> Let's create a helper in order to move that to the core. > > >>>>>=20 > > >>>>> Cc: Boris Brezillon > > >>>>> Cc: Laurent Pinchart > > >>>>> Signed-off-by: Maxime Ripard > > >>>>=20 > > >>>> Do we have userspace for this? > > >>>=20 > > >>> Wayland seems to be on its way to implement this, with ChromeOS usi= ng > > >>> it: > > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/03= 4741 > > >>> .html > > >>>=20 > > >>> and more specifically: > > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party= /way > > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstabl= e-v1 > > >>> .xml#118 > > >>=20 > > >> Yay, would be good to include these links in the patch description. > > >> Really happy we're having a real standard now used by multiple peopl= e. > > >=20 > > > I will. > > >=20 > > >> > > Is encoding a fixed 0-255 range really the best idea? > > >> >=20 > > >> > I don't really know, is there hardware or formats where there is m= ore > > >> > than 255? Or did you mean less than that? > > >>=20 > > >> 30bit I'd assume wants more alpha. In the past we've done some > > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Usi= ng > > >> that for the blend equation docs is also what I recommend (and that = we > > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of= that > > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That= 's > > >> what we're doing for gamma tables already, and that way drivers can > > >> simply throw away the lower bits. > > >=20 > > > But that would also break the two users of that property that won't be > > > able to move to the generic property (with the same name) without > > > breaking userspace. The point of that patch was to allow some code > > > consolidation, and that would mean failing to do so here :/ > >=20 > > Let me try to clarify: > > - We'll keep the exact existing property semantics with the 0-255 > > range for the userspace visible property. > >=20 > > - But internally, in the decode value that we store into > > drm_plane_state, we'll do the slightly more future proof thing with a > > few more bits. > >=20 > > That gives us the option of exposing those bits in the future without > > having to change all the drivers again (which we have to do for this > > series here already anyway, since the decoded value moves into > > drm_plane_state from driver subclasses). > >=20 > > Definitely not asking to break userspace here :-) >=20 > As the property range is available to userspace, we could allow drivers t= o=20 > expose a driver-dependent number of bits for the alpha value without brea= king=20 > anything. We can even require new drivers to expose 16 bits regardless of= the=20 > number of bits that the hardware can handle, or we could keep that driver- > specific. >=20 > Please note, however, that U0.16 can only represent [0.0, 0.999984741...]= =20 > while we need [0.0, 1.0]. As all the hardware I know map the full range o= f=20 > values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend= that=20 > the 16-bit value exposed to userspace is U0.16. So this would involve not changing too much the current patch, but instead extending the type from an u8 to an u16. Would that work for you Daniel? Thanks! Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --khkdadv3wbh7smjp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlpfFVcACgkQ0rTAlCFN r3SwMA/8D2WggEfYWiN9f3JNFVWzhG+TvEy0DrDBCOBvuBbn09HCnCOv5q5VWWwI PW+soqdWqyvAhrnpJxOBPY3DlSIbyOfY7c5HLSqqZiQzPR9ftz2tw4jspdb7eI+A GHMA/WC/GgGLVKjRgQJVxKz83SUk7Ldq6u4nfHgmdcZBsVaPcjydx0lme74/YAuT T3NSPT+c3fv1C9frnBJK7Xg5N+suMMaQcoDiaHBbNkgoozg7zjw6+uHBSiOHI7OX v5Jw/ASRl6Q+95nTdTHI1SanwzBSJAmWZJS5c6RmK+OVQvZDb9+39ifpNzxRonAf 9qYITdLfiVvZk05HuoDmJ/l+qeLd28oT/CWmXBD8c7ItkrXUbgjIIFPvVEN2Ev0f 6XXP7RIoD63PEp/Jnvb/h3vOgAy1wKw8eWJYWUsttAswVg0TJn/6SxkX+wtO/9RR 0OJMidRFbI1CkhJNe/IqUewQ3JyZ6C3neAkN3d2y0XTennMyhGz4QTgem2no+cb/ oYc7eJRjd9wEapAtGoa7Y1ujow6kRN7GpMrzu0KzYuHTHlMXRuXqYRayMpVHU5sl X0qoZg7EAaitXqTgpZ1VP1fISyZJM79hyDg9kgI/Fjw1UV8Zp9/SDftsaggZEi0/ aHWdBFHygQ+GNDtjONH8JGjo2vrArWINSWP0hFuI84/4rhEi4xs= =V0JB -----END PGP SIGNATURE----- --khkdadv3wbh7smjp--