The problem I have is that every time I boot the computer the desktop gets wiped to the bare defaults (Wallpapers revert to default "Elarun" theme and all icons disappear.) I have debugged the issue, and I've been able to deduce some things:

1) It's not the permissions. I hadn't touched them before this problem started. The owner of ~/.kde4 is me, the group is me and permissions are 755 for the dirs and 644 or 600 for the files. (Also deleting the directory and "starting from scratch" doesn't help.)

2) The problem child appears to be ~/.kde4/share/config/plasma-desktop-appletsrc. The contents of this file is just plain wrong when compared to a backup from before the issue occurred.

3) The problem is not related to the shutdown of KDE (or the ability to save to that file). By first making some desktop changes (e.g. wallpaper) and running "kquitapp plasma-desktop" I can see that reasonable content is saved to plasma-desktop-appletsrc.

4) The problem is startup-related. By re-booting into a runlevel that doesn't start X after performing the above, I can see that the contents of the file is still reasonable, which means that it's not until KDE startup that something goes full metal retard, and nukes my settings.

Some related possibly relevant info:
I'm running Gentoo (stable amd64) and KDE version 4.11.5. I have a 3-screen setup with AMD Richland GPU and open source drivers. This requires a bit of magic with krandrtray - specifically:

Code: Select all

[Display]
ApplyOnStartup=true
StartupCommands=xrandr --newmode "1600x1200_60" 160.96  1600 1704 1880 2160  1200 1201 1204 1242  -HSync +Vsync\nxrandr --addmode VGA-0 1600x1200_60\nxrandr --output VGA-0 --pos 3840x0 --mode 1600x1200_60 --refresh 59.9988\nxrandr --output HDMI-0 --pos 1920x0 --mode 1920x1200 --refresh 59.9502\nxrandr --output DVI-0 --pos 0x0 --mode 1920x1080 --refresh 60\nxrandr --output HDMI-0 --primary

[Screen_0]
OutputsUnified=false
UnifiedRect=0,0,0,0
UnifiedRotation=1

[Screen_0_Output_DVI-0]
Active=true
Rect=0,0,1920,1080
RefreshRate=60
Rotation=1

[Screen_0_Output_HDMI-0]
Active=true
Rect=1920,0,1920,1200
RefreshRate=59.9501724243164
Rotation=1

[Screen_0_Output_VGA-0]
Active=true
Rect=3840,0,1600,1200
RefreshRate=60.0038414001465
Rotation=1

The previous setup I had, used an NVidia card + proprietary drivers. I removed them as soon as I installed my new system, and everything worked. It was only when I noticed that my system was still set to use the no longer existing nvidia OpenGL, and I changed that to the xorg-x11 one that KDE started to misbehave.

So. Any ideas on what to do? Having your desktop nuked on every reboot is seriously annoying.

Check the activity ID - see https://bugs.kde.org/show_bug.cgi?id=254884
plasma-desktop might crash on start due to an uninitialized driver (causing a GL error or whatever) - do you get a crashdialog?

In fact, check if anything is written to ~.kde[4]/share/config/activitymanagerrc, or if the file is empty. I've seen this issue also with fresh installations, sometimes.

luebking wrote:do you get a crashdialog?

There are no indications of anything crashing at either startup or shutdown.

einar wrote:In fact, check if anything is written to ~.kde[4]/share/config/activitymanagerrc, or if the file is empty.

Code: Select all

$ cat .kde4/share/config/activitymanagerrc
[activities]
001b79d5-4077-4fef-a6b8-0eccd17cfb8b=Ny aktivitet
1a7847c6-9a82-40c4-87f1-66928bcfd19a=Ny aktivitet
226fd0bb-ef25-4ff0-bb91-838a6c585e68=Ny aktivitet
35631072-5a7b-4fd3-8b88-b3e95fa2e496=New Activity
81684511-ca66-48f3-b2bc-b71cc1466b15=Ny aktivitet
c60ff5e3-a665-4966-9934-af308d21cea7=New Activity
efcb6631-8d10-4ce6-a7b3-bade17518b54=Ny aktivitet

The old (working) setup looked like this:

Code: Select all

$ cat .kde4.backup/share/config/activitymanagerrc
[activities]
35631072-5a7b-4fd3-8b88-b3e95fa2e496=New Activity
c60ff5e3-a665-4966-9934-af308d21cea7=New Activity

[main]
currentActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496
lastUnlockedActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496

And for good measure, this is what the plasma-desktop-appletsrc -files have in them:

Code: Select all

$ cat .kde4/share/config/plasma-desktop-appletsrc | grep -i activity
activity=
activityId=
showOnlyCurrentActivity=true
activity=
activityId=
activity=Ny aktivitet
activityId=efcb6631-8d10-4ce6-a7b3-bade17518b54
activity=Ny aktivitet
activityId=efcb6631-8d10-4ce6-a7b3-bade17518b54
activity=Ny aktivitet
activityId=efcb6631-8d10-4ce6-a7b3-bade17518b54
activity=
activityId=

The old (backed up) plasma-desktop-appletsrc had this:

Code: Select all

$ cat .kde4.backup/share/config/plasma-desktop-appletsrc | grep -i activity
activity=New Activity
activityId=c60ff5e3-a665-4966-9934-af308d21cea7
activity=New Activity
activityId=35631072-5a7b-4fd3-8b88-b3e95fa2e496
activity=New Activity
activityId=35631072-5a7b-4fd3-8b88-b3e95fa2e496
activity=
activityId=
showOnlyCurrentActivity=true
activity=
activityId=
activity=New Activity
activityId=35631072-5a7b-4fd3-8b88-b3e95fa2e496
activity=
activityId=

I have to confess that these activityId:s are beginning to surpass my level of KDE knowledge. I have no idea if these are sane values or not, or whether they're re-generated on every startup, or something else.

Try adding, to activitymanagerrc:

Code: Select all

[main]
currentActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496
lastUnlockedActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496
runningActivities=35631072-5a7b-4fd3-8b88-b3e95fa2e496


If it doesn't work, use any of the IDs in the file. Do so while plasma is not running or your configuration will get overwritten.

einar wrote:Try adding, to activitymanagerrc:

Code: Select all

[main]
currentActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496
lastUnlockedActivity=35631072-5a7b-4fd3-8b88-b3e95fa2e496
runningActivities=35631072-5a7b-4fd3-8b88-b3e95fa2e496


If it doesn't work, use any of the IDs in the file. Do so while plasma is not running or your configuration will get overwritten.

I tried it, but unfortunatley no success. I made i tiny script that cycled through the hashes, trying everyone in turn, but unfortunately every cycle gave the same result: The blank default desktop.

Code: Select all

#!/bin/bash
for stuff in `cat .kde4/share/config/activitymanagerrc | head -12 | tail -11 | sed 's/=.*//'` ; do
        kquitapp plasma-desktop
        sleep 1
        for change in currentActivity lastUnlockedActivity runningActivities ; do
                sed -i "s/$change=.*/$change=$stuff/" .kde4/share/config/activitymanagerrc
        done
        plasma-desktop &>/dev/null &
        sleep 10
done

I also tried replacing plasma-desktop-appletsrc with the old one prior to starting plasma, but it would just be overwritten.

I'm really wondering about the role that the OpenGL plays in this... As I said, these problems started when I ran...

Code: Select all

# eselect opengl set xorg-x11

...thereby replacing the old nvidia OpenGL, which had already been uninstalled. And this new setting seems to be working. I can run glxgears, and glxinfo tells me direct rendering is enabled. The only thing that seems negatively affected is the plasma desktop. Is there a connection between OpenGL and Plasma that could explain this?

You may want to give a try again but also by killing "kactivitymanagerd" as well.

einar wrote:You may want to give a try again but also by killing "kactivitymanagerd" as well.

Still no doughnut. It seems that whatever I do, plasma-desktop ignores everything at startup, and just goes to its predefined default.

Updating GL could be purely coincidental, but you could try adding ~/.kde4/env/run_glxinfo.sh to get some GL client before plasma-desktop starts up

Code: Select all

#!/bin/sh
glxinfo > /dev/null


don't forget to chmod +x ~/.kde/env/run_glxinfo.sh

For the time being, you could make (the wanted variant of) plasma-desktop-appletsrc immutable

Code: Select all

chattr +i ~/.kde4/share/config/plasma-desktop-appletsrc


Notice that the file can no longer be altered, as a result plasma-desktop could be unusable or fail to start due to the present configuration - but it could also just ignore the config, present you a default desktop (but fail to write it back)

luebking wrote:For the time being, you could make (the wanted variant of) plasma-desktop-appletsrc immutable

Code: Select all

chattr +i ~/.kde4/share/config/plasma-desktop-appletsrc


Notice that the file can no longer be altered, as a result plasma-desktop could be unusable or fail to start due to the present configuration - but it could also just ignore the config, present you a default desktop (but fail to write it back)

I had tried something like this previously by making it owned by root and only readable by others. The system went totally nuts spewing popup errors that looked like they came from twm or some such... It's nice to know about the cleaner chattr alternative, though. May come in handy sometimes.

luebking wrote:Updating GL could be purely coincidental, but you could try adding ~/.kde4/env/run_glxinfo.sh to get some GL client before plasma-desktop starts up

Code: Select all

#!/bin/sh
glxinfo > /dev/null


I really doubt it's coincidental, because when this first occurred, I rolled my system back to a recent backup, and then re-traced the steps I had performed in the days since the backup one by one, and it was very clear (and very reproducible) that running the eselect command caused the mayhem. But, hey let's test that:

[Switches system from OpenGL to XRender and reboots] - Holy ****, it works! Let's try restoring the session I wanted to have in the first place... Nope. And now it stopped working completely. Oh. It went back to OpenGL... Well I'll just switch back to XRender, and be in business. No? WTF?!

Ok. So for the first time in a week, I've been able to boot my computer without having my desktop reset. What I did was the following:

1) Switch from OpenGL to XRender
2) Add your "glxinfo >/dev/null" -script to ~/.kde4/env
3) Change wallpapers to desired ones.
4) Log out (NOT reboot)
5) Log back in
6) Reboot
7) Put desired icons on desktops
8) Reboot again (to test) that everything was still in place.
9) Before logging in run 7 times around the building clockwise, naked, while sprinkling myself with holy water and chanting "Begone Satan!".

Okay, so the last one is a joke, but seriously changing the wallpapers and not logging out (and in) before rebooting would cause desktop reset. Also just XRender without the script (or just the script alone) wouldn't work either. At times like these I feel that the CS courses focus way too much on math, and way too little on astrology and voodoo.

Thanks to both of you who helped me troubleshoot this. If I had to wager a guess as to the cause, would say that some OpenGL-related package in my system still hasn't gotten the news that nvidia is gone, despite the Gentoo tools not being able to identify such a package. Or it could just be the unfavorable position of Saturn...

opengl ./. xrender affects the compositor of the windowmanager - what should have close to no effect on plasma-desktop.
you may be brave enough to save the plasma-appletsrc, change the stting and see what happens.

to determine whether it's really about opengl, you might just "sleep 5" in the env script (as glxinfo will block for a moment as side effect)
it may be an uninitialized driver state (leading to a plasma-crash-confusion?) as well as a timing (filesystemcache related?!) issue.

luebking wrote:opengl ./. xrender affects the compositor of the windowmanager - what should have close to no effect on plasma-desktop.

This was my understanding as well, which is why I didn't try it until now.

luebking wrote:you may be brave enough to save the plasma-appletsrc, change the stting and see what happens.

Oh, I did that while working out the exact magic spell to cure this ill with, and it blew sky high. Or to be more specific - the setting works just fine until you make the mistake of logging out.

I have/had the same problem. I use KDE 4.12.2 (but the problem was on 4.11 too) on FreeBSD. What I did to solve the problem:
Choose desired wallpaper and after that I lock widgets and it works.

How is this marked solved? I am experiencing the same issue, and the only solution I see here is to lock the desktop widgets...

I think this ended up solving itself because one of the operations got rid of that virtual sandgrain somewhere in the cogwheels that was causing mayhem.

Allow me to make an analogy **** hypothesis. At a certain level KDE is a collection of inter-connected plugins designed to be run from any application that provides the proper framework to load them. This leads to an issue in KDevelop where
- a session restores its last settings at startup (all settings, so including those of the various supported plugins)
- it then reloads the various enabled plugins in an order that may not be fixed
- each of those plugins will restore *its* last settings, which may be those from another session or simply the default settings

As a result, some of those plugins have a tendency to "nuke their settings" on occasional startups, or will do so on every startup.

If the scenario painted above is correct that it's likely that the only problem is the restore order (the session settings should be restored last).

Something similar could be at play with desktop settings. I'm currently seeing an issue where my Konsole windows aren't restored reliably at the desired location and on the desktop where I want them to be. That issue started without any obvious cause (certainly not an update to a Plasma4 component!).