I can confirm this happens, at least when using the Intel driver. The extension returns the yinvert value from egl_config that never seems to be set.

oh - thanks gustavo. someone else was filing a bug too.

i've also prepared a workaround for now where we blacklist mesa + intel drvires in egl mode from detecting this extension. i will need to know when this is fixed so i can add a version check to disable the blacklist in versions at and after the fix.

The Piglit test for the extension is not passing either. If the intention of the bit is to tell if Y is inverted by the driver (can't find the spec), then Mesa is correctly reporting false.

but it is wrong - it IS inverted. without the extension at all the default assumption is to assume inversion. it all worked fine until we added support for this extension and then everything flipped on mesa + egl + intel. i can't say for other drivers etc. but it's wrong ... as it displays inverted and is reporting inversion at 0.

(In reply to comment #4)
> but it is wrong - it IS inverted. without the extension at all the default
> assumption is to assume inversion. it all worked fine until we added support
> for this extension and then everything flipped on mesa + egl + intel. i
> can't say for other drivers etc. but it's wrong ... as it displays inverted
> and is reporting inversion at 0.

Now I found the spec from Khronos CVS. Yep indeed, the bit should tell if OpenGL coordinate system differs from the window system one and with X Pixmaps it certainly does, this is probably true for any relevant X implementation out there right now (?) Then the fix would be to set the default value TRUE. This does not seem to make the Piglit test pass (something else wrong there) but I assume it would be then correct for EFL.

indeed. and thus why we noticed... as we had it right without the extension assuming the default of inversion... :) once we actually ASKED for it... it told us the wrong thing. fyi we already handled inversion from glx so we've handled those cases already with the same rendering code - for years. so if glx says to invert or not we did what it said. :)

I've sent 2 patches to mesa-dev list that should fix the issue.

I seem to recall that there was a similar bug related to GLX_EXT_texture_from_pixmap a few months ago, but I'm having trouble finding it now.  There was some change in the xserver (commit 2eedf42), so it may be fixed with an updated xserver?

(In reply to comment #8)
> I seem to recall that there was a similar bug related to
> GLX_EXT_texture_from_pixmap a few months ago, but I'm having trouble finding
> it now.  There was some change in the xserver (commit 2eedf42), so it may be
> fixed with an updated xserver?

related to this?
http://lists.x.org/archives/xorg-devel/2013-October/038492.html

I wonder what the original issue there was (?) I think X server should not really report this but rather the origin (top left), then GL could compare origin it is using and see if invert is true or false. I guess X driver is using top left always or can it choose not to?

well exact same xserver on the same machine, but using glx instead of egl and it works correctly... so i am not so sure it's in the server. is glx inversion value leads to correct rendering. egl one does not.

unless glx has literally been wrong for ... the past 10 years or whatever and every compositor has adapted to its wrongness for 10 years in which case fixing glx will break every single compositor...

Gustavo, fix was pushed in, please test with Mesa master.

is there some way to know/tell the fix is in - i need to adapt my blacklist cost (using renderer/vendor strings atm)

(In reply to comment #12)
> is there some way to know/tell the fix is in - i need to adapt my blacklist
> cost (using renderer/vendor strings atm)

As a runtime check, you could check for intel and next released Mesa version (whatever that will be), that should then include the fix.

I mean check for Mesa and the version as affects all Mesa drivers.

i already check for mesa + intel - ignore version as i assume it affects all versions. i was just hoping to know in advance what version the fix will go out in so i can filter for that :) our release cycle means we will do another efl release (1.9) in 6 weeks so i was hoping to know before then so the blacklist can be adapted for that release when the fixed mesa comes out.

FWIW, the extension spec is now posted.

http://www.khronos.org/registry/egl/extensions/NOK/EGL_NOK_texture_from_pixmap.txt

With spec in hand, we should create some piglit tests.

(In reply to comment #16)
> FWIW, the extension spec is now posted.
> 
> http://www.khronos.org/registry/egl/extensions/NOK/
> EGL_NOK_texture_from_pixmap.txt
> 
> With spec in hand, we should create some piglit tests.

Cool, I can give it a shot