Weston does not do transparent backgrounds

Wed Aug 31 06:29:27 UTC 2016

Hi Carsten,

Thanks for your valuable inputs and suggestions.

Our hardware is IMX 6 infotainment product.
We have already implemented X11 window system and X11 window composited
output will be updated to /dev/fb0.
And we used V4lsink(Freescale modified version) to play a video and output
to FB1.

V4lsink will use one of X11 window and update color key values to entire
buffer.

So GUI X11 window and Video color key window will be composited and output
to fb0.

And video will be rendered in /dev/fb1 and IPU configured with color key to
blend FB0 & FB1. So IPU try to find the color in FB0 and replace with FB1
video pixel information for the final display.

So in our GUI application if use colorkey configured values for the pixel
any where then those pixels are getting transmitted( called color bleed
issue).

Because of this issue we configured Local alpha in pixel mode for IPU
configuration for FB0.

So that if X11 output is with alpha to the FB0 then blending will happen
perfectly and no color bleed issue.

But in X11 we couldn't make the output of X11 with alpha values.

Now with the wayland we are trying to achieve FB0 update with alpha.

We have 3 solutions to achieve this.

1. Making Wayland output with alpha.
2. instead of using V4lsink, need to use waylandsink.
3. instead of using V4lsink, need to use imxeglvivsink(provided by
freescale)

Based on the above 3 solutions we are trying to get better one(based on
performance also). But similar functionality, because already our product
delivered and running in the field.
So we dont want to change any applications and selecting any of these
solutions.

Please suggest me.

Thanks,
Arun

On Wed, Aug 31, 2016 at 5:31 AM, Carsten Haitzler <raster at rasterman.com>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160831/c290b4d2/attachment.html>