Hello, I found something very interesting related to the plasma crashes.
I had the following symptoms:
• Kdm never remembered my resolution (set via systemsettings or xrandr), and always reset it to 1024x768, with a weird small-scaling going on on the second display.
• Compositing couldn’t be activated. It complained about some app preventing it.
• Changing any plasma settings, either in the systemsettings, or by forcing windows e.g. to always maximize etc, had about a 42% chance of crashing plasma, and about 75% of those crashed X with them.
And now, lo and behold, the following behavior solves it:
1. chmod -R u=rwX .kde4
2. chown -R $USER:$USER .kde4
3. Go to a terminal (e.g. Ctrl-Alt-F2), kill plasma, and restart it (plasma-desktop --display :0).
✔ Compositing and all the desktop effects work
✔ Changing plasma settings does not cause any crashes anymore.
✔ X/kdm/KDE remembers the resolutions.
✘ Weirdly, the second workspace gets shifted to become the third, including all plasmids on it. A new workspace (with the default blue bg) replaces it.
Of course this is no permanent fix. I have to do it after every login. But a least the system is usable after that, and I am sure it helps you a lot, solving these bugs. :)
I’m happy to provide any additional information.
• all of KDE in 4.4.1
• on a ATi Radeon HD 4850 (R700, so no open source driver yet)
• with the latest beta fglrx driver: ati-drivers-10.4_beta (Which allowed me or the first time, to start KDE at all. Previously plasma crashed at login, like in that other bug. But it does not *have* to be caused by fglrx. :)
• with ~amd64
Steps to Reproduce:
[Set to critical because plasma hard crashes the desktop, causing data loss, severely hindering the configuration and usage of the desktop, and making it all around very annoying. (So much I thought about going back to KDE 3.5.10, just to be able to work again.)]
Unable to reproduce.
Please show your emerge --info, as well.
If you use xdm/kdm, please examine ~/.xsession-errors, it should contain some meaningful information.
Also, if plasma crashes, you should be able to obtain its backtrace - read http://www.gentoo.org/proj/en/qa/backtraces.xml for more info.
Created attachment 225583 [details]
(In reply to comment #1)
> Unable to reproduce.
Oh, do you have the new ati-drivers-10.4_beta (as in bug 310367) installed and do you use them? (Requires xorg 1.7 too.)
If not, then maybe that’s the reason (wouldn’t surprise me, but needs to be proven). Can you reproduce it with that setup?
> Please show your emerge --info, as well.
> If you use xdm/kdm, please examine ~/.xsession-errors, it should contain some
> meaningful information.
That’s the thing. 1. It’s huge, and 2. I completely searched it, and found nothing that caught my eye. I’m just not skilled in reading Plasma/KDE log output, and don’t know what all the things are. But I didn’t found anything that could be an unusual (as in: wasn’t there with older versions of KDE, and is not known to be harmless) error or warning.
> Also, if plasma crashes, you should be able to obtain its backtrace - read
> http://www.gentoo.org/proj/en/qa/backtraces.xml for more info.
Wow, makes sense, but in my current situation (don’t know the C/GNU building environment at all) it could take months til I would have figured anything out. :/
Does this still happen in 4.4.2?
The log file should me much smaller here, so it should be easier to spot anomalies...
I switched to xorg 1.8, with
(via x11 overlay), and am now on KDE 4.4.2.
The crashes are gone, because compositing now always works. No idea if it still happens when I disable compositing.
I only still get plasma crashes from time to time because of another stupid bug:
Clicks on plasmoids have delays of reaction.
This is best explained by two examples:
1. When clicking on the cashew, the menu never goes away. Unless I first click, then wait about 2 or 3 seconds while still hovering the mouse at the same position, and only then move the mouse out of the cashew button area.
2. The same thing happens when moving plasmoids. Except that here they jump back to their previous position, as soon as I move the mouse outside of that dragging bar. Unless I wait those 2-3 seconds before doing so.
When I do those things in a hurry, clicking and moving too quickly, then suddenly, plasma completely crashes. But luckily, the rest of X survives. So either plasma restarts automatically, or I do it manually, and I’m good again.
I consider this a bug, but not this bug.
But I’m not annoyed enough to create a bug out of it. I’ll perhaps do so in the future.
So I mark this as WORKSFORME. If anyone still has the problem, feel free to either re-open the bug yourself, or ask me if you can’t. :)