Bug 468110
| Summary: | Kwin Compositing (OpenGL) + picture frame plasmoid = crashy, too many windows | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Gückel <pgueckel> |
| Component: | kdebase-workspace | Assignee: | Than Ngo <than> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 10 | CC: | fedora, joshba, jreznik, kevin, lorenzo, ltinkl, pgueckel, rdieter, than, tuxbrewr, xgl-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-09 21:00:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Peter Gückel
2008-10-22 21:01:04 UTC
KWin compositing is still rather buggy, it's disabled by default for a reason. 4.2 will have some code to test whether compositing is actually working and enable it by default if the test passes, so we can only hope that it will be more reliable in 4.2. There's not much we can do to fix this stuff within Fedora, it needs to be fixed upstream. In my experience, it's not kde that's buggy, but the compositing support in drivers. I'd venture this to be a hw/driver bug. What video hw/driver is in use here? Nevermind, I see intel in the comment now. I can vouche that compositing was rock-solid for me (intel) with F-9/kde-4.1. F-10 has regressed quite a bit in that regard. Ok. Just thought I'd bring it to attention. Yes, in F9, I used kde compositing without any problem. That's why I keep enabling it in F10, hoping that it will work. Then, I had this problem, was told it was DRI, then it was allegedly mesa, then it might have been the X server, and finally the intel driver, but as of yesterday, each of these components has finally given birth to a long-awaited update, so I thought... To be clear, is it kwin or X dying? (From what I can tell the latter, which is what would likely point to a lower level issue) I've got the same hw, and previously could reproduce the issue too, I'll update fresh, to confirm. confirmed anti goodness, reassigning to i810 driver for some targetted love. In the meantime, using XRender instead of OpenGL here seems to yield much better results for me. Well, I really could not say, but, since I have a display and desktop, and am able to close, but not open windows, not even the menu, and I still have use of the mouse pointer to close those windows, and the keyboard obviously works, as I am able to switch to a virtual terminal and can type my login name (but cannot log in) and I am able to type alt-SysRq-sub, so I don't think X has died. It seems to be a kwin issue. I have removed the picture frame plasmoid since reporting this and, so far, have not experienced the problem again, but that is not a sufficiently long test for me to be convinced. I had just thought that it was opening a new 'window' or picture every 10 seconds, so perhaps they were not getting properly closed, hence that strange message about too many windows being open and the desktop freezing up. Yes, back in January, with the initial kde-4.0 release, OpenGL was not yet available, so I used XRender, but it was very slow and I ended up disabling effects as a result. I haven't given it another try yet, but will do so, if my test of not using the picture frame plasmoid proves fruitless. OK, what I'm seeing is different than what are, I'll file separately. Reassigning back to kdebase-workspace. I don't know about my picture frame plasmoid theory. It happened again, and I have had it turned off sine yesteday. I disabled OpenGL effects and am using XRender, now. Yuck! Is that ever slow and jumpy! interesting... for me it's opengl that gets "yuck... slow", xrender isn't great, but it's better... for me anyway. ymmv. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I think I am encountering this bug. When I am using Desktop Effects in KDE with the OpenGL compositing type (XRender doesn't have this problem) the system will eventually tell me that too many files are open and refuse to open any file (including programs) or even allow logins through a console. Wen that happens, killing xorg frees up enough so that I can at least reboot properly. I have been retrying to see if it happens agian after KDE and xorg updates but so far nothing has fixed it. If I let the system run (not even interacting with it) once it starts using up files it eventually uses up all of them. /proc/sys/fs/file-nr shows the number of open files rapidly rise even up to 180000+ out of about 200000 (I try not to let it get higher than that when testing because if I hit the limit, I lose all my unsaved files). I am running Fedora 10 on a Lenovo Thinkpad T61 with Intel graphics. I don't have an xorg.conf file and can't think of anything else relevant I should post. Tell me if you need anything. I would like my OpenGL compositing back :) Update: I have reported this bug to kde: http://bugs.kde.org/show_bug.cgi?id=179081 Thanks for reporting this upstream. Going to close this as UPSTREAM and we will monitor for resolution |