After upgrading to plasma 5.11.1 (#30305), plasma no longer launches after having succesfully logged in through sddm.
This issue is separate from sddm not launching which is related to a Qt cache issue - https://github.com/NixOS/nixpkgs/pull/30305#issuecomment-336726367.
I have 2 machines with an almost identical configuration except for hardware differences and one works fine, while the other obviously doesn't.
Works: Yoga 2 Pro with Intel graphics (modesetting driver)
Doesn't: No-brand desktop with nVidia GTX650 (nouveau driver)
sddm does launch and does show the splash screen after logon although nothing after that - just mouse pointer and black screen.
@ttuegel asked:
Do you have any qmlcache directories in $HOME?
I did, but I have removed them all and there is no change.
NOTE: Refer to https://github.com/NixOS/nixpkgs/issues/30789#issuecomment-339648217 for the solution.
"x86_64-linux"Linux 4.13.9, NixOS, 18.03.git.f294d08442M (Impala)yesyesnix-env (Nix) 1.11.15"nixos-18.03pre114421.799435b7ca"""I have the exact same issue after upgrading on unstable channel. I tried with both sddm and lightdm. Deleting the home directory didn't help but with a new user plasma works. So it seems that there is some user specific cache/configuration outside the home directory. @peterhoeg if you create a new user, does it work then?
I found a fix for myself: I had some packages installed in my profile (installed with nix-env). Some of them were referring to Qt libraries and those weren't upgraded when the system KDE was upgraded. Thus, under my profile, there were two different versions of Qt available (both for KDE and for my profile packages) and this caused KDE to fail. To fix it, I just uninstalled all packages in my profile (nix-env -e '.*'). But probably it's sufficient to upgrade them, or at least just remove those that refer to the older Qt version.
Thus, under my profile, there were two different versions of Qt available
This is a huge tar pit for NixOS users: our Qt infrastructure in Nixpkgs does not play nice with nix-env at all. It's better than it used to be: at least Qt 5.6 and Qt 5.9 can peacefully coexist. The root problem is: upstream Qt _claims_ that libraries and plugins are compatible between different minor versions, e.g. 5.9.1 to 5.9.2, but this is, at best, an outright lie. If we believe the lie, some things break. (That's the current situation.) If we disbelieve the lie, other things break.
This wasn't it - I only had 2 in my user environment and they were also on the laptop where everything worked.
The digging continues...
Alright, problem solved although I don't know exactly what is going on...
So for some reason KWIN_COMPOSE=O was set which seems to have broken kwin. This should autodetect the correct OpenGL version to use (1, 2 or ES 2) ref https://community.kde.org/KWin/Environment_Variables#KWIN_COMPOSE. My ugly workaround was to create the following file ~/.config/plasma-workspace/env/a.sh with execute permissions and with the contents:
export KWIN_COMPOSE=O2
I named it a.sh to ensure it was run before anything else.
Now oddly enough, when the desktop is up, KWIN_COMPOSE is still set to "O" so it is being overridden somewhere again which also means that kwin_x11 --replace will bring us back to a black screen.
On the laptop, KWIN_COMPOSE is set to O2 right from the get-go so it looks like there is some auto-detection in kwin going wrong.
Update: turns out I was setting the variable:
{
environment.variables = { KWIN_COMPOSE = "O"; };
}
But for reasons unknown that stopped working with plasma/kwin 5.11 whereas that was OK before. Specifically what I needed was this for things to work:
{
environment.variables = {
KWIN_COMPOSE = "O2";
KWIN_OPENGL_INTERFACE = "egl";
};
}
Had the same problem - solved by deleting /var/lib/sddm/.cache as suggested by:
https://bbs.archlinux.org/viewtopic.php?id=222486
Regards
If you have a script with exit 1 in Pre-Startup (.config/plasma-workspace/env) it blocks the entire login process.
Keep this as a note, took me a lot of hours to figure out.
Most helpful comment
Had the same problem - solved by deleting /var/lib/sddm/.cache as suggested by:
https://bbs.archlinux.org/viewtopic.php?id=222486
Regards