Does e17 handle the Y correctly like discussed in #73371 ? My simple test for tfp seems to work fine though. Also the test 'opengles1/texture_from_pixmap' in mesa demos repository works just fine with Mesa master (if you do sed s/EXTURE_EXTERNAL_OES/TEXTURE_2D/ for the source).

Could you attach a test case that does not work?

it's not e that handles y invert - it's evas (library e relies on) and it does handle it - correctly. it was actually our added support of yinvert extension for egl/gles that caught the bug in #73371. since we started handling it on egl/gles on intel drivers pixmaps are inverted.

in this case pixmaps are just plain all black - no pixel data at all. everything blank. a downgrade to 10.0.3 fixes that. in fact it seems to vary from machine to machine. on some intel gfx systems it is 100% of the time black. on others its intermittent - depends on boot. reboot and then it works just fine, until randomly a boot later it's black again. i think sandybridge is always black, ivybridge is "sometimes black".

nb - this problem we currently see happening with glx+opengl (not egl/gles). i haven't tried egl/gles as i don't normally need/want it).

(In reply to comment #2)
> it's not e that handles y invert - it's evas (library e relies on) and it
> does handle it - correctly. it was actually our added support of yinvert
> extension for egl/gles that caught the bug in #73371. since we started
> handling it on egl/gles on intel drivers pixmaps are inverted.
> 
> in this case pixmaps are just plain all black - no pixel data at all.
> everything blank. a downgrade to 10.0.3 fixes that. in fact it seems to vary
> from machine to machine. on some intel gfx systems it is 100% of the time
> black. on others its intermittent - depends on boot. reboot and then it
> works just fine, until randomly a boot later it's black again. i think
> sandybridge is always black, ivybridge is "sometimes black".
> 
> nb - this problem we currently see happening with glx+opengl (not egl/gles).
> i haven't tried egl/gles as i don't normally need/want it).

Based on this I think the bug might be also in glx or x (?) I will debug some more with my test cases, will also check what is the difference between EGL and GLX in this case. Could you run evas/e17 against egl and gles2 and see if that works, just to confirm that we have same result there?

(In reply to comment #2)
> in this case pixmaps are just plain all black - no pixel data at all.

Can you bisect?  That should help things along...

i have been trying to reproduce this reliably. the problem is now - suddenly its not reproducible. well not reliably. i've reproduced it twice - total, out of maybe 50 reboots. given a know broken install version it now only happens rarely and that makes it impossible to find. it may even be a kernel bug as i have upgraded kernel since, (but not mesa so i can avoid the bug - i upgraded and no bug, i have tried everything... but it's too unreliable to reproduce.

at least for now i can't reliably reproduce and thus can't bisect. :(

same story for egl/gles

You might want to try using X server 1.15.1 or 1.14.6 and see if it helps.  xserver commit 96a28e9c914d7ae9b269f73a27b99cbd3c465ac8 (glx: Clear new FBConfig attributes to 0 by default.) fixed a bug where you could get random GLX configs.

i am on 1.15.1 now. i tried going back to 1.14.4 with no luck on repro. :(

(In reply to Carsten Haitzler from comment #7)
> i am on 1.15.1 now. i tried going back to 1.14.4 with no luck on repro. :(

Are you still encountering this?  On what intel GPU, Mesa and X intel driver versions?

nope - can't reproduce anymore. it seems to have been a transient problem between mesa, kernel etc. and has been cleared up.

seems to have fixed itself...