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 <ras...@rasterman.com> wrote: > On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." <arunkris...@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 <ppaala...@gmail.com> > wrote: > > > > > On Fri, 26 Aug 2016 16:02:19 +0530 > > > "arunkrish20 ." <arunkris...@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) ras...@rasterman.com > >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel