KDM not starting after upgrade

[Duncan]

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.