Weston does not do transparent backgrounds

[Carsten Haitzler (The Rasterman)]

On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." <arunkrish20 at gmail.com> said:

> Hi pq,
> 
> Thanks for your valuable input...
> 
> I have tried to change the "alpha_attribs" for creating the output surface.
> But still no update to alpha.
> 
> As you said, i have to look into some gl_blend function calls(for enable
> and disable) and gl_blendfunc function calls.
> 
> As per your comment there is no gl_clear in the code and double buffer is
> used for rendering, so that i am getting previous rendered output merged
> with the latest output in the display.
> 
> I will check and update you once i get some more clues.

why... are you trying to do this? why do you want weston to have a transparent
background? as already mentioned you have to then worry about the rest of the
pipeline to ensure the alpha pixels are 0xff when solid and depending how you do
your shaders and blend modes that may not be the case.

now given the context - you want alpha in the "framebuffer". a whole design
"ethos" with wayland would be that the COMPOSITOR (weston or whatever) CONTROLS
all the layers, so it will render 1 or more buffers of data (maybe with or
without alpha), may just directly assign input buffers (if enough hw layers are
available that match incoming buffers from clients - including yuv video layers
etc.).

video play should be going VIA wayland. it should be a client with a
window/surface and it should be SENDING yuv buffers every frame to the
compositor and the compositor should be ASSIGNING that yuv buffer to a hw layer
OR if the layer is not available, rendering the buffer itself directly.

what you are doing is perpetuating a horrible "hack".

the point of this is that frames can be updated in sync so content matches - eg
overlayed data on the video feed, or surrounding decorations etc. - as long as
you do the above kind of "hacking" you will forever have problems wit these
things until you alter design and keep these things together going via the
compositor.

so my advice - don't take a shortcut. move the video to go via the compositor
as a client and then work out how to render alpha (argb) data to a buffer with
egl/gles (if you look efl does this with egl in the evas engines in x11, as
wayland clients and even with egl+gles for drm/kms support destination alpha
channel but you have to set up you context/surface correctly for it to work).

> Thanks,
> Arunkumar R
> 
> 
> 
> 
> On Fri, Aug 26, 2016 at 9:03 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Fri, 26 Aug 2016 16:02:19 +0530
> > "arunkrish20 ." <arunkrish20 at gmail.com> wrote:
> >
> > > Hi All,
> > >
> > > http://wayland-devel.freedesktop.narkive.com/
> > dXZUCogH/desktop-shell-how-to-enable-really-alpha-blending-
> > of-weston-background
> > >
> > > Our question is related to above mentioned link question.
> > >
> > > Environment
> > > OS : Linux kernel 3.14
> > > Version : Weston 1.9.0
> > >
> > > Weston fbdev-backend.
> > >
> > > In compositor-fbdev.c
> > > fbdev_output_create()
> > >
> > > *called *
> > > gl_renderer->output_create(&output->base,
> > >                            (EGLNativeWindowType)NULL, NULL,
> > >                            gl_renderer->*opaque_attribs*,
> > >                            NULL, 0) < 0) {
> > >             weston_log("gl_renderer_output_create failed.\n");
> > >
> > > *can be changed to*
> > > gl_renderer->output_create(&output->base,
> > >                            (EGLNativeWindowType)NULL, NULL,
> > >                            gl_renderer->*alpha_attribs*,
> > >                            NULL, 0) < 0) {
> > >             weston_log("gl_renderer_output_create failed.\n");
> > >
> > > Is that change will give some help? I havn't tried. But in that link if
> > we
> > > use fbdev-backend then there is no hope to expect the alpha.
> > >
> > > Any update or direction, Could you please suggest...
> >
> > Hi,
> >
> > I can't say if that will help, that kind of use case was never
> > intended. What will happen depends on the kernel driver and the EGL
> > implementation, we cannot know what they (being proprietary) do.
> >
> > After you get that working, you still need to get the framebuffer
> > rendered such that you actually get alpha < 1.0 on some parts. You
> > may have problems with Weston's rendering. A non-opaque surface is
> > always rendered with blending and weston never uses glClear, so that
> > might cause blending artifacts. OTOH, in some cases the
> > renderer deliberately ignores the alpha channel because Xwayland
> > surfaces used to have garbage there. I'm also not sure if the
> > blending equation used accounts for destination alpha != 1.0.
> > Therefore there may be a few things you have to fix before you see
> > anything.
> >
> > I believe you'll find that the assumption of an opaque
> > primary framebuffer is quite deeply rooted in Weston.
> >
> > Also note that GL support has been removed from the fbdev backend,
> > too. See:
> > https://cgit.freedesktop.org/wayland/weston/commit/src/
> > compositor-fbdev.c?id=e77f8ad79bdf3613dc7e587ea0cf5b9d39e4f8e0
> >
> >
> > Thanks,
> > pq
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com