Summary: | KDE TRUNK (4) won't run with unpatched XCB | ||
---|---|---|---|
Product: | [I don't know] kde | Reporter: | James Richard Tyrer <tyrerj> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED NOT A BUG | ||
Severity: | major | CC: | l.lunak |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Log of attempt to run KDE 4 from Xterm |
Description
James Richard Tyrer
2007-10-05 22:19:35 UTC
Created attachment 21760 [details]
Log of attempt to run KDE 4 from Xterm
IIUC, this is a KDE bug.
IMHO, this is a major bug. To my knowledge neither KDE nor Qt lock the X connection, so this looks like a bug in some of the underlying libraries (including other X11 libraries, I suggest updating). Especially given that I don't see any such problem here. Re: Comment #3 This seems quite possible. It is a known bug in Sun Java for instance. Do you think that the 'startkde' script should set: LIBXCB_ALLOW_SLOPPY_LOCK="true" and then we should consider the issue resolved? I don't see why KDE should do that. More than just KDE is affected, and X libraries should not have affected backwards compatibility in such a bad way in the first place. I suggest asking your distribution to patch X libraries to merely issue a warning (like e.g. openSUSE does). If you can identify specific places in KDE which cause this problem, please report a bug for them, but I don't see this generic bugreport to be a KDE problem (especially given that in my KDE4 log there's not a single message about this, so this really looks like a problem in underlying libraries in your system). |