Re: Weston does not do transparent backgrounds
On Wed, 31 Aug 2016 11:59:27 +0530 "arunkrish20 ." 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 > wrote: > > > On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." > > 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
Re: Weston does not do transparent backgrounds
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 wrote: > On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." > 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 > wrote: > > > > > On Fri, 26 Aug 2016 16:02:19 +0530 > > > "arunkrish20 ." 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, > > > >
Re: Weston does not do transparent backgrounds
On Tue, 30 Aug 2016 18:35:38 +0530 "arunkrish20 ." 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 wrote: > > > On Fri, 26 Aug 2016 16:02:19 +0530 > > "arunkrish20 ." 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 >
Re: Weston does not do transparent backgrounds
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. Thanks, Arunkumar R On Fri, Aug 26, 2016 at 9:03 PM, Pekka Paalanen wrote: > On Fri, 26 Aug 2016 16:02:19 +0530 > "arunkrish20 ." 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 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston does not do transparent backgrounds
On Fri, 26 Aug 2016 16:02:19 +0530 "arunkrish20 ." 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 pgpUPzt4jwtD6.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston does not do transparent backgrounds
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... Thanks, Arun ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel