I have screen corruption with kwin_gles (see attachment). First i thought that my configuration was wrong but after remove all files in $HOME/.kde4/ directory corruption still exists. With XRender and OpenGL (gentoo kwin USE="-gles opengl") everything is OK ( for example wooby effect works with opengl) This happen with kernel 3.7.4 and mesa-9.0.1 too. I'm not sure if this bug is related to kwin :( but I have no idea what is wrong :( system: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz kernel-3.8 xf86-video-intel-2.21.2 (SNA) libdrm-2.4.42 Reproducible: Always
Created attachment 77459 [details] screen corruption screenshot screenshot
Created attachment 77460 [details] xsession-errors
please try running normal KWin on top of EGL: KWIN_OPENGL_INTERFACE=egl kwin --replace & let's see whether that works, it would tell us whether it's a problem in the EGL backend or in the OpenGL ES code path.
OK. Now I have only remote access to my system and I don't know how to do it (if it possible) but when I came back home I will check
Created attachment 77476 [details] KWIN_OPENGL_INTERFACE=egl kwin --replace &
corruption still exists :/
corruption seems to follow the driver renderer tiles, mesa is Mesa 9.1-rc2 Does is also happen with 9.0?
>>This happen with kernel 3.7.4 and mesa-9.0.1 too. >Does is also happen with 9.0? Strange. I checked this before I created this bug (probably not good enough :/) but with mesa-9.0.2 everything is OK.
Upstream for now. If you re-encounter it on a stable mesa version (maybe report a bug against the RC ;-) please re-open the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=61197
with Intel on EGL I made the experience that not all mesa backends work. If you have the time give a try to the environment variables listed in http://www.mesa3d.org/egl.html - especially enable EGL_LOG_LEVEL
My knowledge about graphics stack is very limited but EGL_LOG_LEVEL=debug KWIN_OPENGL_INTERFACE=egl kwin --replace & libEGL debug: Native platform type: x11 (autodetected) libEGL debug: EGL search path is /usr/lib64/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: DRI2: dlopen(/usr/lib64/dri/i965_dri.so) libEGL debug: DRI2: found extension `DRI_Core' libEGL info: DRI2: found extension DRI_Core version 1 libEGL debug: DRI2: found extension `DRI_DRI2' libEGL info: DRI2: found extension DRI_DRI2 version 3 libEGL debug: DRI2: found extension `DRI_TexBuffer' libEGL info: DRI2: found extension DRI_TexBuffer version 2 libEGL debug: DRI2: found extension `DRI2_Flush' libEGL info: DRI2: found extension DRI2_Flush version 3 libEGL debug: DRI2: found extension `DRI_IMAGE' libEGL info: DRI2: found extension DRI_IMAGE version 5 libEGL debug: DRI2: found extension `DRI_CONFIG_QUERY' libEGL debug: the best driver is DRI2 EGL_DRIVER=egl_glx libEGL debug: Native platform type: x11 (autodetected) libEGL debug: EGL search path is /usr/lib64/egl libEGL debug: added egl_glx to module array libEGL debug: the best driver is GLX libEGL debug: EGL user error 0x3005 (EGL_BAD_CONFIG) in eglCreateWindowSurface libEGL debug: EGL user error 0x300d (EGL_BAD_SURFACE) in eglSurfaceAttrib libEGL debug: EGL user error 0x300d (EGL_BAD_SURFACE) in eglQuerySurface kwin(9083): query surface failed kwin(9083) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed: "Could not initialize rendering context" libEGL debug: EGL user error 0x300d (EGL_BAD_SURFACE) in eglMakeCurrent libEGL debug: EGL user error 0x3006 (EGL_BAD_CONTEXT) in eglDestroyContext libEGL debug: EGL user error 0x300d (EGL_BAD_SURFACE) in eglDestroySurface kwin(9083): Failed to initialize compositing, compositing disabled EGL_SOFTWARE=true same output as egl_dri2
ok, seems like by default egl_dri2 is used and egl_glx is not working anyway. So that seems fine.
bisected mesa git bisect bad 60894edeef973e86a73067276f658b72f84271b6 is the first bad commit commit 60894edeef973e86a73067276f658b72f84271b6 Author: Eric Anholt <eric@anholt.net> Date: Thu Jan 10 15:11:28 2013 -0800 intel: Make intel_region's pitch be bytes instead of pixels. We almost never want a stride in pixels -- if you're doing anything with a stride, you're specifying an offset or incrementing a pointer, and in both cases you had to multiply by cpp to get the bytes value you wanted. But worse, on the way to creating a region from a new tiled BO, we divided by cpp to get pitch in pixels, and for an RGB32 buffer (an upcoming change) the pitch wouldn't divide exactly, and we'd end up with a wrong stride in our region. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> :040000 040000 20cab1a9079778d75f58a105ae054602117380fd d3c03362f04930e826564ea656b5d511652e6249 M src