<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64" href="https://bugs.freedesktop.org/show_bug.cgi?id=99638#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64" href="https://bugs.freedesktop.org/show_bug.cgi?id=99638">bug 99638</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>All-blue weston looks to me like alpha and blue channels are swapped. Can't say about red/green since the colors are gray. I couldn't say what the other pictures are supposed to look like. Weston has known issues on big-endian, IIRC the conversion between wl_shm and OpenGL formats is broken on big-endian. I have a vague recollection that there might not exist a matching GLESv2 format on big-endian, which means it would have to be compensated in frag shaders, which I don't think we do. While Mesa's platform_wayland.c certainly looks suspicious, there could be similar problems in the Wayland compositors too. Also the problem may be different between software-GL in clients (uses wl_shm) and hardware-GL in clients (uses EGL-specific protocol, the Wayland compositor has no room to screw that up as everything is inside the EGL implementation). Yet one more place to possibly screw things up is GBM/KMS used by the Wayland compositor, where the composite drawn with GL is exported via GBM as a buffer handle to used in KMS. That involves choosing pixel formats when creating the GBM/EGLsurface, and relaying the pixel format to KMS. OTOH if Weston is using Pixman renderer with the DRM backend, there cannot be confusion with GL formats in Weston. But, it is again a rarely (if ever) tested code path on big-endian like everything. Using Pixman renderer would force applications to use software-GL. There are so many different combinations that one really needs to choose just one to concentrate on at a time. If you want to work with Weston, maybe start with DRM backend and Pixman renderer, using programs that do *not* use OpenGL, make sure that works right, and then add complexity piece by piece. I think weston-simple-shm would be a nice test, as getting the byte order wrong would cause a cross to be drawn over the image which is otherwise unhelpful for checking if colors are correct.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>