Bug 315513

Summary:	screen corruption with kwin_gles after upgrade to 4.10 with Intel graphics
Product:	[Plasma] kwin	Reporter:	wojtek <wojtask9>
Component:	scene-opengl	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED UPSTREAM
Severity:	normal	Flags:	mgraesslin: Intel+
Priority:	NOR
Version:	4.10.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	screen corruption screenshot xsession-errors KWIN_OPENGL_INTERFACE=egl kwin --replace &

Description wojtek 2013-02-20 12:57:07 UTC

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

Comment 1 wojtek 2013-02-20 12:58:10 UTC

Created attachment 77459 [details]
screen corruption screenshot

screenshot

Comment 2 wojtek 2013-02-20 12:59:21 UTC

Created attachment 77460 [details]
xsession-errors

Comment 3 Martin Flöser 2013-02-20 13:03:41 UTC

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.

Comment 4 wojtek 2013-02-20 13:18:52 UTC

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

Comment 5 wojtek 2013-02-20 21:39:11 UTC

Created attachment 77476 [details]
KWIN_OPENGL_INTERFACE=egl kwin --replace &

Comment 6 wojtek 2013-02-20 21:43:23 UTC

corruption still exists :/

Comment 7 Thomas Lübking 2013-02-20 21:48:14 UTC

corruption seems to follow the driver renderer tiles, mesa is Mesa 9.1-rc2
Does is also happen with 9.0?

Comment 8 wojtek 2013-02-20 22:03:29 UTC

>>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.

Comment 9 Thomas Lübking 2013-02-20 22:21:12 UTC

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.

Comment 10 wojtek 2013-02-20 22:43:20 UTC

https://bugs.freedesktop.org/show_bug.cgi?id=61197

Comment 11 Martin Flöser 2013-02-21 07:23:16 UTC

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

Comment 12 wojtek 2013-02-21 10:00:00 UTC

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

Comment 13 Martin Flöser 2013-02-21 10:05:04 UTC

ok, seems like by default egl_dri2 is used and egl_glx is not working anyway. So that seems fine.

Comment 14 wojtek 2013-03-13 17:59:15 UTC

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