Launchpad has imported 9 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=30220.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-09-16T00:52:32+00:00 John Stanley wrote: Created attachment 38733 patch to Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c There currently exists a situation in KDE-4.5.X where at certain moments, a current context does not have a valid associated Window, but does have a valid pixmap drawable. If, at such a moment, a call is made to glXDestroyContext() on another no longer needed non-current context, glXDestroyContext() releases pixmap-associated resources that are in use by the current context, resulting in system hangs. A possible patch to remedy this changes BadWindow to BadDrawable in windowExistsErrorHandler of Mesa-7.8.3-rc1.old/src/glx/glxcmds.c (I have also attached the patch; does this make sense?): --- Mesa-7.8.3-rc1.old/src/glx/glxcmds.c 2010-09-16 03:14:45.074000414 -0400 +++ Mesa-7.8.3-rc1.new/src/glx/glxcmds.c 2010-09-16 03:37:43.932000358 -0400 @@ -68,14 +68,14 @@ #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL) -static Bool windowExistsFlag; +static Bool drawableExistsFlag; static int -windowExistsErrorHandler(Display * dpy, XErrorEvent * xerr) +drawableExistsErrorHandler(Display * dpy, XErrorEvent * xerr) { (void) dpy; - if (xerr->error_code == BadWindow) { - windowExistsFlag = GL_FALSE; + if (xerr->error_code == BadDrawable) { + drawableExistsFlag = GL_FALSE; } return 0; } @@ -98,13 +98,13 @@ /* Set no-op error handler so Xlib doesn't bail out if the windows * has alreay been destroyed on the server. */ XSync(dpy, GL_FALSE); - oldXErrorHandler = XSetErrorHandler(windowExistsErrorHandler); + oldXErrorHandler = XSetErrorHandler(drawableExistsErrorHandler); if (__glxHashFirst(sc->drawHash, &draw, (void *) &pdraw) == 1) { do { - windowExistsFlag = GL_TRUE; + drawableExistsFlag = GL_TRUE; XGetWindowAttributes(dpy, draw, &xwa); /* dummy request */ - if (!windowExistsFlag) { + if (!drawableExistsFlag) { /* Destroy the local drawable data, if the drawable no longer exists in the Xserver */ (*pdraw->destroyDrawable) (pdraw); Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/8 ------------------------------------------------------------------------ On 2010-09-17T02:59:04+00:00 John Stanley wrote: Created attachment 38759 Patch to fix GarbageCollectDRIDrawables for Pixmaps w/o a Window Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/14 ------------------------------------------------------------------------ On 2010-09-18T02:41:33+00:00 mint-fm2-dev wrote: Please do look into this bug as it affects a wide range of hardware and a lot of users as is evidenced in the KDE bug report. If more information is required to implement or find the proper resolution, I will try to provide what I can. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/19 ------------------------------------------------------------------------ On 2010-09-22T00:42:15+00:00 Chris Halse Rogers wrote: The code posted applies to mesa 7.8, but has been removed in 7.9. It would be useful to a) Test if this bug still applies to mesa 7.9 from git (I've been told it applies to a snapshot from 2010/09/09, but haven't been able to reproduce it myself). and if it still occurs, then b) Port the patch to the 7.9 branch & master. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/22 ------------------------------------------------------------------------ On 2010-09-22T03:44:59+00:00 John Stanley wrote: (In reply to comment #3) > The code posted applies to mesa 7.8, but has been removed in 7.9. It would be > useful to > a) Test if this bug still applies to mesa 7.9 from git (I've been told it > applies to a snapshot from 2010/09/09, but haven't been able to reproduce it > myself). > > and if it still occurs, then > b) Port the patch to the 7.9 branch & master. Thanks for looking at this. So, do I understand correctly, that the patch is ok on Mesa-7.8.x ? If this is so, then everyone now using KDE-4.5.x (and presumably Mesa-7.8.x), can use it. I'd love also to test it out on 7.9 -- but I tried several weeks ago and ran into trouble -- I think with the intel driver (xf86-video- intel-2.12.0). I'll try again and get back to you on this. Have you or anyone had a chance to look at BUG #30217 ? thanks again Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/23 ------------------------------------------------------------------------ On 2010-10-04T15:07:48+00:00 John Stanley wrote: I just did a build using Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) (i915), with xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0, kde-4.5.1, and linux-2.6.35.7. This is decidedly way downhill (from xorg- server-1.8.2/Mesa-7.8.2) - desktop effects will not even activate anymore. I can force-activate them, but then video is so slow as to be entirely unusable. Perhaps related to a new error message in .xsession- errors: i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4) This is the only error (Xorg.0.log looks good). Summary of some build variations (all using qt-4.7.0, kde-4.5.1., and linux-2.6.35.7): mesa-7.8.2, libdrm-2.4.21, xorg-server-1.8.2, xf86-video-2.12.0 ----> works (with glxcmd.c patch submitted earlier) mesa-7.8.2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0 ----> works (with glxcmd.c patch submitted earlier) mesa-7.8.2, libdrm-2.4.21, xorg-server-1.9.0, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.8.2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0 ----> cannot start X -- cannot connect to server mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0 ----> X runs, but no openGL available under kde (forcing openGL is SLOW: 5 seconds to move a window, plus various artifacts ----> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4); (src/mesa/drivers/dri/i915/i915_program.c) Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/29 ------------------------------------------------------------------------ On 2010-10-04T18:53:08+00:00 Rex Dieter wrote: Re: comment #3 Testing using Fedora 14 beta, kernel-2.6.35.4-28.fc14 libdrm-2.4.21-3.fc14 mesa-7.9-0.8.fc14 xorg-x11-server-1.9.0-9.fc14 xorg-x11-drv-intel-2.12.0-6.fc14 mesa here is a 20100922 git snapshot. I can confirm the original symptoms remain. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/31 ------------------------------------------------------------------------ On 2010-10-04T21:41:59+00:00 John Stanley wrote: An update with some good news regarding comment #3: I did further testing with the following setup: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (i915) xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0 kde-4.5.1, linux-2.6.35.7 As I stated in comment #5, with this build, desktop (GLX) effects will not activate. There's a kde desktop effect called 'blur' which is activated on first kde-desktop boot on my system, but has never worked on my system. Up to now, I've just left it on as it doesn't appear to cause any problems. However, with this new build, 'blur' is in fact the culprit: if I first manually turn off this effect then GLX effects are activated, and the Pixmap destroy issue does not occur. Conclusion: Problem exists in Mesa-7.8.2/3rc1, but has been fixed in Mesa-7.9rc2. The unrelated 'blur' issue, at least for the moment, is kde's problem... thanks for your time. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/33 ------------------------------------------------------------------------ On 2019-09-18T17:27:54+00:00 Ajax-a wrote: Closing per comment #7 Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/633406/comments/51 ** Changed in: mesa Status: Confirmed => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/633406 Title: Display freeze when changing kwin effects settings if effects are active Status in KDE Base: Won't Fix Status in Mesa: Invalid Status in Release Notes for Ubuntu: Invalid Status in mesa package in Ubuntu: Fix Released Status in mesa source package in Maverick: Fix Released Status in mesa package in Fedora: Fix Released Bug description: Binary package hint: kdebase-workspace When changing kwin (KDE window effects) effects settings if compositing is active, the screen will freeze. RELEASE NOTE: In a KDE Plasma Workspace, when changing desktop effects settings with effects active, the display will freeze. This can be avoided by disabling effects, making the desired settings change, and then re-enabling effects. If the display freezes, effects can be disabled using shift+alt+f12 and the display will, in most cases, unfreeze. To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/633406/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
