[Mesa-dev] [PATCH] egl_dri2: Allow both 24 and 32 bit X visuals for RGBA configs

Pekka Paalanen ppaalanen at gmail.com
Sat Nov 8 00:49:51 PST 2014


On Fri, 07 Nov 2014 11:32:04 -0800
Eric Anholt <eric at anholt.net> wrote:

> Pekka Paalanen <ppaalanen at gmail.com> writes:
> 
> > On Thu, 06 Nov 2014 13:01:03 -0800
> > Ian Romanick <idr at freedesktop.org> wrote:
> >
> >> I thought Eric and Chad already NAKed it in bugzilla.  The problem is
> >> that applications ask for an RGBA visual for GL blending.  They use the
> >> alpha channel to generate their images, but the final alpha values are,
> >> basically, random... and the composited result would be pure garbage.
> >
> > Reading
> > https://bugs.freedesktop.org/show_bug.cgi?id=67676#c5
> > "We should certainly be exposing EGLConfigs that match up to the rgba
> > visual, though, so you can find it when you try." - Eric
> >
> > To me that sounds like Eric would accept having the visuals there
> > in additional configs (as long as they are sorted after the otherwise
> > equivalent xRGB configs?). Eric, would you like to confirm your current
> > opinion?
> 
> What I believe we want:
> 
> Somebody just requesting RGBA with ChooseConfig doesn't end up forced
> into the depth-32 (blending) X visual.  This is the most important.
> 
> There is some mechanism for somebody that does want the depth 32 visual
> to get an EGL config to draw to it.  This is important but secondary to
> not breaking everything else, and them having to jump through hoops is
> reasonable but probably avoidable.

I think that is exactly what everybody already agrees on.

The remaining question seems to be, should we add new configs with
the blending X visual, or wait for an EGL extension to allow to
request blending in generic terms (*and* add configs with the
blending X visual, since that is essentially required for making,
say, a new value for EGL_TRANSPARENT_TYPE to work on X11).

Can you imagine other reasonable mechanisms?

Btw. I noticed that EGL_TRANSPARENT_TYPE defaults to EGL_NONE for
eglChooseConfig, not DONT_CARE (which is not even allowed in EGL
1.4). So if we add only configs now, and add the
EGL_TRANSPARENT_TYPE=alpha extension later, apps using
eglChooseConfig for initial config filtering and wanting a blending
config will be broken yet again. I suppose one might even claim,
that exposing bleding configs when EGL_TRANSPARENT_TYPE=NONE is a
violation of the spirit of the spec.

EGL 1.4 says that EGL_TRANSPARENT_TYPE is not a sorting key at all,
but NATIVE_VISUAL_ID is with an implementation specified order.


Thanks,
pq


More information about the mesa-dev mailing list