Re: Wayland: EGL_ALPHA_SIZE in egl_attributes_from_framebuffer_config()



Hi Richard,

My suspicion is that COGL is setting EGL_DONT_CARE incorrectly:
- fact: inside egl_attributes_from_framebuffer_config(),
CoglFramebufferConfig is initialized to default, hence
config->swap_chain->has_alpha will always be false
- fact: COGL always uses this default-initialized framebuffer config to call
eglChooseConfig()
- I *think* has_alpha should be true though: I naively think it's impossible
to create nice GL drawings without transparency

I tried to look at Mesa's code to see what eglChooseConfig() does there, in
_eglCompareConfigs() I see it uses alpha_size similarly to compare
configurations. I am guessing the available configs are also hardware
dependent, not much chance to check them, simply too many indirections in
the code.

In raspberrypi/userland, in egl_client_config.c I found the list of possible
configurations, the first two are:

   {FEATURES_PACK(8, 8, 8, 8, 24, 8, 0, 0, 0), ABGR_8888, DEPTH_32_TLBD,
IMAGE_FORMAT_INVALID, IMAGE_FORMAT_INVALID},
   {FEATURES_PACK(8, 8, 8, 0, 24, 8, 0, 0, 0), XBGR_8888, DEPTH_32_TLBD,
IMAGE_FORMAT_INVALID, IMAGE_FORMAT_INVALID},

I added debug printouts to see which is being used. It looks like that if
EGL_ALPHA_SIZE is set, then the first is returned; if it's set to
EGL_DONT_CARE, then the second one.

This behavior seems to be correct. Again, I think COGL incorrectly requests
the EGL configuration, stating it would not care about alpha -- while IMHO
it should.

As far as selecting a config goes this driver behaviour should be ok as you say.

To maybe help a bit here there though, I think Cogl's default of not
caring whether an onscreen framebuffer has an alpha component is also
ok but I think maybe there's a misunderstanding about what that means.
Not having an alpha component here doesn't mean that you can't render
transparent things. This configures whether you need to save the alpha
value for every pixel beyond the end of your frame, which is normally
only needed if your client is running under a compositor and if you
want something to either look non-rectangular or look transparent when
composited.

Since we've worked with EGL platforms in the past that don't support
any configs with an alpha component we default to not caring instead
of requiring one so we increase the chance of finding a valid config.

If you are running with a wayland compostor it would be pretty strange
to see a driver that didn't support an alpha component so forcing the
selection of a config with an alpha component should be an ok
workaround for you for now.

Something to be aware of here is that, if you don't really need the
alpha channel to either create rounded window decorations or show
translucency for a wayland surface then ideally you would not request
an alpha component since it may affect performance to have to store
that redundant alpha component in memory.

My guess a.t.m is that there's either a bug with your driver's wayland
integration or with weston on the RPi which is resulting in XBGR
client buffers being mapped to the wrong format in the compositor
perhaps resulting in swizzled RGB components or perhaps dropping the R
and taking B from the undefined X.

As a workaround your approach seems reasonable, though maybe someone
familiar with the wayland support on the RPi might be able to double
check that XBGR_8888 client buffers get handled correctly for a really
simple egl + gles2 client like simple-egl.c in the weston repo.

It might be worth even trying modifying simple-egl.c yourself so that
in init_egl it explicitly passes EGL_ALPHA_SIZE, EGL_DONT_CARE like
cogl does just to compare if that's affected in the same way. You may
need to pass -o to tell simple egl that you want an opaque window, and
comment out these lines which look like a bug introduced recently in
weston commit 78fe75368 (I don't think it's meaningful to reset
EGL_RENDERABLE_TYPE to 0 which is what these lines seem to do):

        if (window->opaque || window->buffer_size == 16)
                config_attribs[9] = 0;

I hope that helps a bit, and sorry I can't be much more help than that
a.t.m, although I do have an RPi myself I haven't found the time to
really play with it.

regards,
Robert


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]