Weston does not do transparent backgrounds
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Wed Aug 31 23:12:51 UTC 2016
On Wed, 31 Aug 2016 11:59:27 +0530 "arunkrish20 ." <arunkrish20 at gmail.com> said:
> 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.
well you could do it .. just as much as in wayland... but anyway... :)
> Now with the wayland we are trying to achieve FB0 update with alpha.
you want the compositor to control BOTH fb0 AND fb1. the first/largest/whatever
surface sending yuv buffers should have its buffers redirected to fb1 - use kms
to assign them there. everything else should likely be composited. i assume fb1
is below fb0? this means using waylandsink for video. the app playing video
should just be a wayland client drawing video to the screen as it might on any
desktop or other device. you may want that surface to be maximized in size and
possibly not accept focus or be raised.
why do this? because you can test/debug outside of your device on any regular
pc with wayland running. it saves you a lot of time in the long run. if the
next product has a different chip that has no yuv layer support then it still
keeps working just fine because now it will composite the yuv buffer with every
other buffer and do a swap. it removes work for the future.
it also allows nice synchronization between subsurfaces of the videoplayer
application and its video frames.
when you use this setup then you do need egl to do an alpha supporting surface
setup in the comopostior. use EGL_ALPHA_SIZE attribute of 1 in your config
attributes when eglChooseConfig() is called. you will WILL want to glDisable
(GL_BLEND) ... and glEnable(GL_BLEND) again after you are done. with blending
disabled ensure you draw a rectangle (2 triangles) in the region you want the
video surface to be - basically detect if the video surface is being drawn by
the compositor, and then draw 2 triangle just with a color of RGBA 0.0, 0.0,
0.0, 0.0. you'll have a hole. continue drawing as normal.
to get a little bit smarter... remember that you draw this hole once, and if
nothing else OTHER than the yuv surface changed since the last frame, don't
even bother doing a compositor redraw - simply assign new yuv buffer with kms to
fb1. continue. remember to re-enable GL_BLEND when done making the hole. the
rest is all gl shader fun. you should know about this stuff if messing with the
gl rendering internals of a compositor... :)
if you do the above you will have a powerful and generic solution that is very
efficient. it's portable between different hardware and even os's. it'll make
development long-term easier. you'll also have removed display artifacts and
sync issues.
> 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
> >
> >
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the wayland-devel
mailing list