<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Carsten,<br><br></div>Thanks for your valuable inputs and suggestions.<br><br></div><div>Our hardware is IMX 6 infotainment product.<br></div>We have already implemented X11 window system and X11 window composited output will be updated to /dev/fb0.<br></div>And we used V4lsink(Freescale modified version) to play a video and output to FB1.<br><br></div>V4lsink will use one of X11 window and update color key values to entire buffer.<br><br></div>So GUI X11 window and Video color key window will be composited and output to fb0.<br><br></div>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.<br><br></div>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).<br><br></div>Because of this issue we configured Local alpha in pixel mode for IPU configuration for FB0.<br><br></div>So that if X11 output is with alpha to the FB0 then blending will happen perfectly and no color bleed issue.<br><br></div>But in X11 we couldn't make the output of X11 with alpha values.<br><br></div>Now with the wayland we are trying to achieve FB0 update with alpha.<br><br></div>We have 3 solutions to achieve this.<br><br></div>1. Making Wayland output with alpha.<br></div>2. instead of using V4lsink, need to use waylandsink.<br></div>3. instead of using V4lsink, need to use imxeglvivsink(provided by freescale)<br><br></div>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.<br></div><div>So we dont want to change any applications and selecting any of these solutions.<br></div><div><br><br></div><div>Please suggest me.<br></div><div><br></div>Thanks,<br></div>Arun<br><div><div><div><div><div><div><div><br><div><div><div><div><div><div><div><div><div><div><div><br><br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 31, 2016 at 5:31 AM, Carsten Haitzler <span dir="ltr"><<a href="mailto:raster@rasterman.com" target="_blank">raster@rasterman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." <<a href="mailto:arunkrish20@gmail.com">arunkrish20@gmail.com</a>> said:<br>
<br>
> Hi pq,<br>
><br>
> Thanks for your valuable input...<br>
><br>
> I have tried to change the "alpha_attribs" for creating the output surface.<br>
> But still no update to alpha.<br>
><br>
> As you said, i have to look into some gl_blend function calls(for enable<br>
> and disable) and gl_blendfunc function calls.<br>
><br>
> As per your comment there is no gl_clear in the code and double buffer is<br>
> used for rendering, so that i am getting previous rendered output merged<br>
> with the latest output in the display.<br>
><br>
> I will check and update you once i get some more clues.<br>
<br>
</span>why... are you trying to do this? why do you want weston to have a transparent<br>
background? as already mentioned you have to then worry about the rest of the<br>
pipeline to ensure the alpha pixels are 0xff when solid and depending how you do<br>
your shaders and blend modes that may not be the case.<br>
<br>
now given the context - you want alpha in the "framebuffer". a whole design<br>
"ethos" with wayland would be that the COMPOSITOR (weston or whatever) CONTROLS<br>
all the layers, so it will render 1 or more buffers of data (maybe with or<br>
without alpha), may just directly assign input buffers (if enough hw layers are<br>
available that match incoming buffers from clients - including yuv video layers<br>
etc.).<br>
<br>
video play should be going VIA wayland. it should be a client with a<br>
window/surface and it should be SENDING yuv buffers every frame to the<br>
compositor and the compositor should be ASSIGNING that yuv buffer to a hw layer<br>
OR if the layer is not available, rendering the buffer itself directly.<br>
<br>
what you are doing is perpetuating a horrible "hack".<br>
<br>
the point of this is that frames can be updated in sync so content matches - eg<br>
overlayed data on the video feed, or surrounding decorations etc. - as long as<br>
you do the above kind of "hacking" you will forever have problems wit these<br>
things until you alter design and keep these things together going via the<br>
compositor.<br>
<br>
so my advice - don't take a shortcut. move the video to go via the compositor<br>
as a client and then work out how to render alpha (argb) data to a buffer with<br>
egl/gles (if you look efl does this with egl in the evas engines in x11, as<br>
wayland clients and even with egl+gles for drm/kms support destination alpha<br>
channel but you have to set up you context/surface correctly for it to work).<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks,<br>
> Arunkumar R<br>
><br>
><br>
><br>
><br>
> On Fri, Aug 26, 2016 at 9:03 PM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
><br>
> > On Fri, 26 Aug 2016 16:02:19 +0530<br>
> > "arunkrish20 ." <<a href="mailto:arunkrish20@gmail.com">arunkrish20@gmail.com</a>> wrote:<br>
> ><br>
> > > Hi All,<br>
> > ><br>
> > > <a href="http://wayland-devel.freedesktop.narkive.com/" rel="noreferrer" target="_blank">http://wayland-devel.<wbr>freedesktop.narkive.com/</a><br>
> > dXZUCogH/desktop-shell-how-to-<wbr>enable-really-alpha-blending-<br>
> > of-weston-background<br>
> > ><br>
> > > Our question is related to above mentioned link question.<br>
> > ><br>
> > > Environment<br>
> > > OS : Linux kernel 3.14<br>
> > > Version : Weston 1.9.0<br>
> > ><br>
> > > Weston fbdev-backend.<br>
> > ><br>
> > > In compositor-fbdev.c<br>
> > > fbdev_output_create()<br>
> > ><br>
> > > *called *<br>
> > > gl_renderer->output_create(&<wbr>output->base,<br>
> > > (EGLNativeWindowType)NULL, NULL,<br>
> > > gl_renderer->*opaque_attribs*,<br>
> > > NULL, 0) < 0) {<br>
> > > weston_log("gl_renderer_<wbr>output_create failed.\n");<br>
> > ><br>
> > > *can be changed to*<br>
> > > gl_renderer->output_create(&<wbr>output->base,<br>
> > > (EGLNativeWindowType)NULL, NULL,<br>
> > > gl_renderer->*alpha_attribs*,<br>
> > > NULL, 0) < 0) {<br>
> > > weston_log("gl_renderer_<wbr>output_create failed.\n");<br>
> > ><br>
> > > Is that change will give some help? I havn't tried. But in that link if<br>
> > we<br>
> > > use fbdev-backend then there is no hope to expect the alpha.<br>
> > ><br>
> > > Any update or direction, Could you please suggest...<br>
> ><br>
> > Hi,<br>
> ><br>
> > I can't say if that will help, that kind of use case was never<br>
> > intended. What will happen depends on the kernel driver and the EGL<br>
> > implementation, we cannot know what they (being proprietary) do.<br>
> ><br>
> > After you get that working, you still need to get the framebuffer<br>
> > rendered such that you actually get alpha < 1.0 on some parts. You<br>
> > may have problems with Weston's rendering. A non-opaque surface is<br>
> > always rendered with blending and weston never uses glClear, so that<br>
> > might cause blending artifacts. OTOH, in some cases the<br>
> > renderer deliberately ignores the alpha channel because Xwayland<br>
> > surfaces used to have garbage there. I'm also not sure if the<br>
> > blending equation used accounts for destination alpha != 1.0.<br>
> > Therefore there may be a few things you have to fix before you see<br>
> > anything.<br>
> ><br>
> > I believe you'll find that the assumption of an opaque<br>
> > primary framebuffer is quite deeply rooted in Weston.<br>
> ><br>
> > Also note that GL support has been removed from the fbdev backend,<br>
> > too. See:<br>
> > <a href="https://cgit.freedesktop.org/wayland/weston/commit/src/" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/<wbr>wayland/weston/commit/src/</a><br>
> > compositor-fbdev.c?id=<wbr>e77f8ad79bdf3613dc7e587ea0cf5b<wbr>9d39e4f8e0<br>
> ><br>
> ><br>
> > Thanks,<br>
> > pq<br>
> ><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
------------- Codito, ergo sum - "I code, therefore I am" --------------<br>
The Rasterman (Carsten Haitzler) <a href="mailto:raster@rasterman.com">raster@rasterman.com</a><br>
<br>
</font></span></blockquote></div><br></div>