From: Daniel Vetter <daniel@ffwll.ch>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Sean Paul <seanpaul@chromium.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-arm-kernel@lists.infradead.org, thomas@vitsch.nl
Subject: Re: [PATCH 06/19] drm/blend: Add a generic alpha property
Date: Tue, 9 Jan 2018 15:28:34 +0100 [thread overview]
Message-ID: <20180109142834.GZ26573@phenom.ffwll.local> (raw)
In-Reply-To: <20180109135322.7lb3snbxfcezobhz@flea>
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.
> > >
> > > Let's create a helper in order to move that to the core.
> > >
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Do we have userspace for this?
>
> Wayland seems to be on its way to implement this, with ChromeOS using
> it:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>
> and more specifically:
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
Yay, would be good to include these links in the patch description. Really
happy we're having a real standard now used by multiple people.
> > Is encoding a fixed 0-255 range really the best idea?
>
> I don't really know, is there hardware or formats where there is more
> than 255? Or did you mean less than that?
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. Using 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.
> > I know other drivers have skimped on the rules here a bit ... But at least
> > internally (i.e. within the drm_plane_state) we probably should restrict
> > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > drivers are supposed to implement).
>
> You mean straight vs premultiplied? Maybe we should implement this as
> an additional property in read only depending on how the hardware
> behaves?
No need for an additional property right now, but definitely document
whether you mean straight or pre-multiplied. Just writing down the blend
equation is probably best.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: daniel@ffwll.ch (Daniel Vetter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/19] drm/blend: Add a generic alpha property
Date: Tue, 9 Jan 2018 15:28:34 +0100 [thread overview]
Message-ID: <20180109142834.GZ26573@phenom.ffwll.local> (raw)
In-Reply-To: <20180109135322.7lb3snbxfcezobhz@flea>
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.
> > >
> > > Let's create a helper in order to move that to the core.
> > >
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Do we have userspace for this?
>
> Wayland seems to be on its way to implement this, with ChromeOS using
> it:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>
> and more specifically:
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
Yay, would be good to include these links in the patch description. Really
happy we're having a real standard now used by multiple people.
> > Is encoding a fixed 0-255 range really the best idea?
>
> I don't really know, is there hardware or formats where there is more
> than 255? Or did you mean less than that?
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. Using 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.
> > I know other drivers have skimped on the rules here a bit ... But at least
> > internally (i.e. within the drm_plane_state) we probably should restrict
> > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > drivers are supposed to implement).
>
> You mean straight vs premultiplied? Maybe we should implement this as
> an additional property in read only depending on how the hardware
> behaves?
No need for an additional property right now, but definitely document
whether you mean straight or pre-multiplied. Just writing down the blend
equation is probably best.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
linux-kernel@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@intel.com>,
thomas@vitsch.nl, linux-arm-kernel@lists.infradead.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 06/19] drm/blend: Add a generic alpha property
Date: Tue, 9 Jan 2018 15:28:34 +0100 [thread overview]
Message-ID: <20180109142834.GZ26573@phenom.ffwll.local> (raw)
In-Reply-To: <20180109135322.7lb3snbxfcezobhz@flea>
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.
> > >
> > > Let's create a helper in order to move that to the core.
> > >
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Do we have userspace for this?
>
> Wayland seems to be on its way to implement this, with ChromeOS using
> it:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>
> and more specifically:
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
Yay, would be good to include these links in the patch description. Really
happy we're having a real standard now used by multiple people.
> > Is encoding a fixed 0-255 range really the best idea?
>
> I don't really know, is there hardware or formats where there is more
> than 255? Or did you mean less than that?
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. Using 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.
> > I know other drivers have skimped on the rules here a bit ... But at least
> > internally (i.e. within the drm_plane_state) we probably should restrict
> > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > drivers are supposed to implement).
>
> You mean straight vs premultiplied? Maybe we should implement this as
> an additional property in read only depending on how the hardware
> behaves?
No need for an additional property right now, but definitely document
whether you mean straight or pre-multiplied. Just writing down the blend
equation is probably best.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-01-09 14:28 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 10:56 [PATCH 00/19] drm/sun4i: Support more planes, zpos and plane-wide alpha Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:26 ` Boris Brezillon
2018-01-09 12:26 ` Boris Brezillon
2018-01-09 12:29 ` Laurent Pinchart
2018-01-09 12:29 ` Laurent Pinchart
2018-01-09 12:29 ` Laurent Pinchart
2018-01-09 13:28 ` Maxime Ripard
2018-01-09 13:28 ` Maxime Ripard
2018-01-09 13:28 ` Maxime Ripard
2018-01-15 15:47 ` Ayan Halder
2018-01-15 15:47 ` Ayan Halder
2018-01-15 15:47 ` Ayan Halder
2018-01-16 20:17 ` Maxime Ripard
2018-01-17 17:55 ` Ayan Halder
2018-01-16 10:37 ` Ayan Halder
2018-01-16 10:37 ` Ayan Halder
2018-01-09 10:56 ` [PATCH 02/19] drm/atmel-hlcdc: Use the alpha format helper Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:27 ` Boris Brezillon
2018-01-09 12:27 ` Boris Brezillon
2018-01-09 12:27 ` Boris Brezillon
2018-01-09 10:56 ` [PATCH 03/19] drm/exynos: " Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-12 1:20 ` Inki Dae
2018-01-12 1:20 ` Inki Dae
2018-01-09 10:56 ` [PATCH 04/19] drm/rockchip: " Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-16 0:42 ` Sandy Huang
2018-01-16 0:42 ` Sandy Huang
2018-01-16 0:42 ` Sandy Huang
2018-01-09 10:56 ` [PATCH 05/19] drm/vc4: " Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:34 ` Daniel Vetter
2018-01-09 12:34 ` Daniel Vetter
2018-01-09 12:34 ` Daniel Vetter
2018-01-09 17:34 ` Eric Anholt
2018-01-09 17:34 ` Eric Anholt
2018-01-09 17:34 ` Eric Anholt
2018-01-09 10:56 ` [PATCH 06/19] drm/blend: Add a generic alpha property Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 12:32 ` Daniel Vetter
2018-01-09 12:32 ` Daniel Vetter
2018-01-09 12:32 ` Daniel Vetter
2018-01-09 13:53 ` Maxime Ripard
2018-01-09 13:53 ` Maxime Ripard
2018-01-09 13:53 ` Maxime Ripard
2018-01-09 14:28 ` Daniel Vetter [this message]
2018-01-09 14:28 ` Daniel Vetter
2018-01-09 14:28 ` Daniel Vetter
2018-01-11 15:58 ` Maxime Ripard
2018-01-11 15:58 ` Maxime Ripard
2018-01-11 15:58 ` Maxime Ripard
2018-01-11 16:36 ` Daniel Vetter
2018-01-11 16:36 ` Daniel Vetter
2018-01-11 16:36 ` Daniel Vetter
2018-01-11 18:34 ` Laurent Pinchart
2018-01-11 18:34 ` Laurent Pinchart
2018-01-11 18:34 ` Laurent Pinchart
2018-01-17 9:20 ` Maxime Ripard
2018-01-17 9:20 ` Maxime Ripard
2018-01-17 9:20 ` Maxime Ripard
2018-01-17 9:30 ` Daniel Vetter
2018-01-17 9:30 ` Daniel Vetter
2018-01-17 9:30 ` Daniel Vetter
2018-01-09 12:34 ` Laurent Pinchart
2018-01-09 12:34 ` Laurent Pinchart
2018-01-09 13:59 ` Maxime Ripard
2018-01-09 13:59 ` Maxime Ripard
2018-01-09 13:59 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 07/19] drm/atmel-hclcdc: Convert to the new " Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 12:31 ` Boris Brezillon
2018-01-09 10:56 ` [PATCH 08/19] drm/rcar-du: " Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 12:37 ` Laurent Pinchart
2018-01-09 12:37 ` Laurent Pinchart
2018-01-09 12:37 ` Laurent Pinchart
2018-01-09 10:56 ` [PATCH 09/19] drm/sun4i: backend: Fix structure indentation Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 10/19] drm/sun4i: backend: Fix define typo Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 11/19] drm/sun4i: framebuffer: Add a custom atomic_check Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 12/19] drm/sun4i: backend: Move the coord function in the shared part Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 13/19] drm/sun4i: backend: Set a default zpos in our reset hook Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 14/19] drm/sun4i: backend: Add support for zpos Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 15/19] drm/sun4i: backend: Check for the number of alpha planes Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 16/19] drm/sun4i: backend: Assign the pipes automatically Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 17/19] drm/sun4i: backend: Make zpos configurable Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 18/19] drm/sun4i: Add support for plane alpha Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` [PATCH 19/19] drm/sun4i: backend: Remove ARGB spoofing Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
2018-01-09 10:56 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180109142834.GZ26573@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=boris.brezillon@free-electrons.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=seanpaul@chromium.org \
--cc=thomas.petazzoni@free-electrons.com \
--cc=thomas@vitsch.nl \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.