Bogus Zaba posted on Sat, 21 May 2011 10:25:35 +0100 as excerpted:
> On 05/20/2011 09:17 AM, Duncan wrote:
>> I was waiting for someone who hopefully had a clue about slackware to
>> respond, as I don't, /and/ I have little idea what's wrong with kde
>> either. However, as nobody else is taking a shot, I guess I'll post
>> what vaguely possibly helpful ideas I have that might help...
> You were right in thinking that the answer might lie with some Slackware
> expertise - I asked / searched on Slackware forums as well and was
> pointed in the direction of the version 13.37 release notes where it
> says : "If KDE crashes on startup, try disabling the Composite
> extension". It then tell you how to do this in the X11 configuration".
> Did that and it solved the immediate problem. KDE does now start up OK
> and I have opted for re-configuring it rather than putting ~/.kde back
> (either all at once or selectively) since there appear to have been some
> changes to KDE which make my previous config not fully compatible.
I'm a serious customizer, to the point that starting from scratch isn't
really viable. But fortunately I'm also reasonably technically inclined,
and as a result of the combination, I've gotten quite efficient at
bisecting issues down to individual files and even, generally, lines
withing files.
As you seem familiar enough with my replies to note customary rants, I'm
surprised you didn't note something about the bisect method I've described
a number of times. =:^)
OTOH, I fully understand that many don't customize to the extent I do, and
that for them simply dumping the limited customizations they have is often
the most efficient route around an issue, even if just the thought of
having to do that /here/ makes me shudder, due to what would very likely
be days of work (originally weeks, but redoing it would be faster),
recustomizing.
> What I don't quite understand is why compositing is a problem now when
> it was not previously under KDE 4.4.3 with the same video card and an
> updated latest nvidia (binary) driver. [I guess I should pause here
> while you provide your brief customary "servantware" lecture (: ].
Um... I guess you've demonstrated sufficient awareness thereof. =:^\
Addressing the "don't quite understand" bit, however, there's two possible
aspects to consider.
First and most directly, what I suspected might be the problem is/was bad
drm device permissions. A 'Section "DRI"' setting mode 666 permissions
for this, in your xorg.conf(.d) often helps here, but explaining how that
works when many people don't even have or otherwise need an xorg.conf(.d)
these days, is a lot of work. And explaining the other side of things,
how those permissions come to be wrong in the first place, is about a 400
line post of its own, especially if one isn't familiar with the specifics
of the distribution in question, because of the number of different
intersecting subsystems (static dev, udev, pam console, consolekit, hal,
xorg, distro group policy...) that can play a role, a bug or
misconfiguration in any one of which can trigger the device permissions
issues I was suspecting.
It was thus easier to get more information about the problem first. Thus,
all the questions about whether X could run apart from kde, glxinfo,
whether kde and qt apps would run, etc. As I said, the results from that
would narrow down the search space significantly, and I could possibly
avoid a 400 line post or two.
Second and more background info, both the plasma and the kwin folks tend
to be doing leading edge (at least for Linux desktops) development here --
they're actively updating the code they use, for new effects and/or more
efficient use of hardware acceleration for current effects, using
functionality that hasn't been widely used in Linux before.
As it happens, you missed the big hubbub in early kde 4.5 over this, but
it was a big thing at the time because a lot of systems broke that had
worked fine with 4.4.
What the kwin folks said (there's kwin dev blogs about this and articles
reporting it, if you want to go looking, but should be able to google as
well as I can, so...) was that they only use OpenGL speced functionality
that the graphics drivers explicitly claim to support, but that, for
various reasons, the drivers sometimes don't actually tell the truth.
There are a couple of ways the drivers can be broken. First, according to
the driver devs, games often test for functionality they don't actually
use. Thus, claiming to support a particular function often tested for but
rarely used can mean the difference between supporting a half dozen often
popular games with no apparent negatives due to claiming support that
isn't there, and having those games be broken for no apparent reason other
than that they told the truth about what they supported, when the game was
testing something they don't use (or actually functionality test before
they use it, in the rare cases they do, and fallback if the test returns
an error) in the first place.
Second, sometimes a driver WILL implement the functionality, but claim
hardware support when it's actually software emulation. The Intel driver
in particular was apparently doing enough of this that the AFAIK new-to-
kde-4.5 blur effect triggered slowdowns on Intel graphics that made them
practically unworkable (FWIW, I know the feeling from the kde 4.2 and
previous era, when a qt4 bug was interacting nastily with kde4 on the
older radeon 9200 I upgraded soon thereafter, but kde 4.3.1 or so had a
workaround and AFAIK, 4.4 required a newer qt4 without the bug). Turning
the blur effect off helped, but people had to figure out that was the
problem first.
There were some nvidia driver issues as well, but of course being the
black-box they are, there was neither as much information made public
about the specific cause, nor was I particularly interested in what
information there was available as the black-box issues and their cause
are well known when people buy the equipment, and it's a choice they still
make, so...
Anyway... the hubbub settled down by later 4.5, in part because the kwin
devs specifically blacklisted certain combinations of xorg/hardware/
drivers known to not return reliable information, in part because kwin
started actually function-testing instead of relying on what they drivers
claimed, and in part due to the natural distro updates (and dependency
updates) that happened over that period.
But it appears there's still some problems, at least with proprietary
drivers...
Moving forward, the 4.5 thing was only opengl 2.x functionality, for the
most part. The kwin devs have already announced their intent to upgrade
to opengl 3.0 where supported, for kde 4.7 I believe. So there's likely
to be more issues coming. But the kwin devs are supposed to be working
closer with the upstream xorg/kernel driver devs (of course, for the
native drivers...), and having the experience from early 4.5, they know to
actually test the functionality in a crash-proof way before trying to use
it, regardless of what the drivers /claim/ to support. So things
shouldn't be quite as bad this time around.
> I will probably keep the system as it is for a while and then look at
> re-introducing compositing. 90% of the eye-candy is of little interest,
> but the visual feedback supplied by the various transitions between
> virtual desktops and activities can be quite helpful.
I realized how much I had grown to depend on window translucency when I
switched to kde4, as it had worked fine on my old card in the kde 3.5 era
(which despite claims to the contrary, actually did support real
translucency using the xorg composite extension, from about 3.5.5, IIRC),
but due to the above mentioned early qt4 bug interacting badly with kde4
thru 4.3.0 or so (worked around in 4.3.1 or 4.3.2 IIRC), it initially
didn't work so well on kde4. But after some major tweaking, I was able to
get it working at least tolerably, even while the bug still existed.
However, in ordered to get there, I had to use the piece-of-kde4-at-a-time
method I mentioned in the first reply, because there were actually two
separate bits of config I had to get right to make things tolerable, and
getting only one of them right didn't help enough to know I'd fixed it, if
the other one was interfering.
Anyway, I realized that I /regularly/ set two partially overlapping
windows with the reference window on top, but then move the mouse to focus
the other one (focus-follows-mouse, click-to-raise policy) while still
keeping it below the reference window. With that setup and properly
configured translucency/transparency, I can both read the reference
material in the top window, and type into the active window partially
underneath it, seeing thru the reference window enough to see what I'm
doing.
I had actually grown dependent on being able to do that sort of thing, far
more dependent on it than I realized until I was trying to run kde4 and
having so many problems with composite and therefore translucent windows
active, and thus would have disabled them, except that when I did I
realized how dependent I actually WAS on the feature!
I also use the OpenGL based (now that I upgraded my card from the old
radeon 9200 to the hd4650 I now have, and have opengl at the resolutions I
run) scale-zoom effect quite heavily, as I'm in my mid 40s now and I can't
focus as fine as I used to, with a noticeable change in just the last two
years, since kde 4.2. (I'm running dual 22 inch full HD so 1920x1080,
stacked for 1920x2160. That's a standard 96 dpi or close enough. I plan
to upgrade to dual 37-42 inch, same 1080p full hd resolution, at some
point, but LED monitors/TVs at that size still run about $600 a piece
minimum, and I don't have the $1200 plus to spend yet, so... But that'd be
a much more practical for me now, 50-ish dpi. Until I get the money, tho,
the scale-zoom gets a lot more use now than it did two years ago!)
Those are the two effects I'd really miss, but grid-desktop is quite
useful now that they've integrated per-desktop present-windows into it,
and I enjoy translucent panel effects too. And the cube is really
impressive on a dual 20-some-inch monitor desktop, too, but that's more a
toy than a practical work tool. These three effects I'd miss, but could
do without if I had to.
But window translucency and zooming both are effects that I'd find myself
hard pressed to do without, these days.
>> That it works as root but not as a normal user indicates it's a
>> privileges/permissions issue of /some/ kind.
> I probably turned off compositing *within* KDE system settings [pause
> again for your rant about what this should really be called] for the
> root user. So the clue here that it was to do with privileges and
> permissions turned out to be a false trail.
I still think it might be the drm device permissions. I'm not sure drm
device is what nvidia calls them, but I know they have them too. And if
the permissions are wrong, you'd get the 2D splash but things would lock
up when kwin tried to engage its opengl effects, if you had them on.
> I had xfce working fine, but did not get around to your suggested tests
> with other KDE apps under xfce (strongly suspect they would have worked
> fine).
It looks like so. You'd have only encountered problems when you tried the
kwin --replace and/or plasma-desktop steps, since they use opengl, and
likely only kwin, as plasma-desktop uses opengl, but not to the same
degree. (FWIW, the comic-strip-plasmoid, of /all/ things, appears to use
opengl accelerated drawing functionality that triggered an agp-only radeon
drm kernel regression bug I had at one point. The rest of my plasma config
worked fine, as long as I didn't have a comic strip configured!)
Thanks for the update! Knowing how it was ultimately resolved... is both
potentially helpful if others have the problem, and fills my own curiosity.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
