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@xxxxxxxxxxxxxxxxxx> > > Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> > > 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 > 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? > 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? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
