Nixpkgs: Plasma Wayland

[bkchr]

I finally want to get Plasma working on Wayland with Nixos.
After trying today the whole day getting this working, I'm desperate.
I think that the problem is something with missing permissions.
My current output is:

startplasmacompositor: Starting up...
dbus-daemon[28346]: [session uid=1000 pid=28346] Activating service name='org.freedesktop.systemd1' requested by ':1.1' (uid=1000 pid=28374 comm="/nix/store/6vc0h4kldq30wz0v3424srx3n456ivir-dbus-1")
dbus-daemon[28346]: [session uid=1000 pid=28346] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
No backend specified through command line argument, trying auto resolution
FATAL ERROR: backend failed to initialize, exiting now
startplasmacompositor: Shutting down...
startplasmacompositor: Done.

I have the following patch applied:

diff --git a/nixos/modules/services/x11/display-managers/sddm.nix b/nixos/modules/services/x11/display-managers/sddm.nix
index 426b899586f..66e481bc6f5 100644
--- a/nixos/modules/services/x11/display-managers/sddm.nix
+++ b/nixos/modules/services/x11/display-managers/sddm.nix
@@ -58,6 +58,8 @@ let

     [Wayland]
     EnableHidpi=${if cfg.enableHidpi then "true" else "false"}
+    SessionCommand=${lib.getBin pkgs.sddm}/share/sddm/scripts/wayland-session
+    SessionDir=/etc/wayland

     ${optionalString cfg.autoLogin.enable ''
     [Autologin]
@@ -262,10 +264,21 @@ in
       home = "/var/lib/sddm";
       group = "sddm";
       uid = config.ids.uids.sddm;
+      extraGroups = [ "video" ];
     };

     environment.etc."sddm.conf".source = cfgFile;

+    environment.etc."wayland/plasma-wayland.desktop".text = ''
+      [Desktop Entry]
+      Encoding=UTF-8
+      Type=Application
+      Exec=/run/current-system/sw/bin/dbus-run-session ${lib.getBin pkgs.plasma-workspace}/bin/startplasmacompositor
+      TryExec=${lib.getBin pkgs.plasma-workspace}/bin/startplasmacompositor
+      DesktopNames=KDE
+      Name=Plasma-wayland
+    '';
+
     users.groups.sddm.gid = config.ids.gids.sddm;

     environment.systemPackages = [ sddm ];

Anyone has any further ideas? @peterhoeg @ttuegel @worldofpeace @adisbladis

[worldofpeace]

I think I got this working from a tty. For sddm no though.

[peterhoeg]

I've had it running since 5.11 (maybe 5.10) from sddm but haven't used it due to missing features: https://community.kde.org/Plasma/5.13_Errata

This should do it:

diff --git a/nixos/modules/services/x11/display-managers/sddm.nix b/nixos/modules/services/x11/display-managers/sddm.nix
index 8db7414e811..8f6e150df49 100644
--- a/nixos/modules/services/x11/display-managers/sddm.nix
+++ b/nixos/modules/services/x11/display-managers/sddm.nix
@@ -69,6 +69,8 @@ let

     [Wayland]
     EnableHidpi=${if cfg.enableHidpi then "true" else "false"}
+    SessionCommand=${lib.getBin pkgs.sddm}/share/sddm/scripts/wayland-session
+    SessionDir=/etc/wayland

     ${optionalString cfg.autoLogin.enable ''
     [Autologin]
@@ -277,6 +279,16 @@ in

     environment.etc."sddm.conf".source = cfgFile;

+    environment.etc."wayland/plasma-wayland.desktop".text = ''
+      [Desktop Entry]
+      Encoding=UTF-8
+      Type=Application
+      Exec=${lib.getBin pkgs.plasma-workspace}/bin/startplasmacompositor
+      TryExec=${lib.getBin pkgs.plasma-workspace}/bin/startplasmacompositor
+      DesktopNames=KDE
+      Name=Plasma-wayland
+    '';
+
     users.groups.sddm.gid = config.ids.gids.sddm;

     environment.systemPackages = [ sddm ];

[worldofpeace]

@peterhoeg with that patch sddm seems to get stuck when authenticating in a vm with the wayland session and has to be manually restarted.

[peterhoeg]

@peterhoeg with that patch sddm seems to get stuck when authenticating in
a vm with the wayland session and has to be manually restarted.

I have admittedly not tried it recently but it definitely was working in the past.

[bkchr]

My patch is based on your patch @peterhoeg :D
I also got it working from tty, but that required root. From a running X11 session it did not need any root.

[bkchr]

I got a step further, adding my user to the video group, brings me further in executing Kwin. So this means, it is really a permission problem. I thought that logind should be responsible for setting up the correct permissions...
However, KWin still does not work as expected, the screen seems to not refresh.

[bkchr]

I got it working! :D Now I just need to cleanup all the stuff :D

[bkchr]

Here is my pr: https://github.com/NixOS/nixpkgs/pull/44139
The changes are not that big.
The next big question is, how do we want to support wayland in SDDM/Nixos? As I have written in the pr, the patch for setting up SDDM is still required. I did not wanted to change that much, because I don't know what is the preferred way.

[peterhoeg]

I suggest having a look at how the X11 session files are handled and then simply doing it the same way. Polluting /etc/wayland isn't really the way to go but I did that on my side because it was easy to fiddle with.

[bkchr]

Yeah I know, that is really hacky. The x11 desktop files are generated by us, but there is some work going on to switch to the provided desktop files.

[Chiiruno]

Any updates on this?
I'd really like to be able to use Wayland, I remember it being great (but sometimes buggy) in GNOME!

[bkchr]

Currently nothing new. I think there was some work to support Wayland desktop files from the login manager. That is the last piece that is missing, AFAIK

[Chiiruno]

Is there a PR for that?
What's the difference between that and the patch in #44139?

[bkchr]

Not yet, the work that was done, was for gnome.
The patch you mentioned is just a hack. KDE already ships the desktop file, we just need to make sddm aware of it.

[Chiiruno]

Okay.
Should probably add an issue to the project, since I did some limited testing.
Plasma on Wayland is very very choppy, lots of microstutters as if vsync was multiplied like 10 times.

[bkchr]

An issue to which project? KDE? I really need to test KDE Neon an compare it with the NixOS performance. Maybe we miss something.

[Chiiruno]

My bad, sorry for not being specific.
This one: https://github.com/NixOS/nixpkgs/projects/11
That said, it's possible this may be an upstream issue.

[peterhoeg]

I created that project as a place to gather all wayland related issues - it isn't as such a concerted effort to get plasma going. I haven't spent real time on it as wayland KDE is still missing features for my use case(s).

[peterhoeg]

As a data point, I tried launching a KDE wayland session y'day which worked fine (except for the missing features).

[Chiiruno]

It wasn't stuttery at all?

[Chiiruno]

Perhaps my issue has to do with something between AMDGPU and KDE/Wayland...

[peterhoeg]

I tried it on a laptop with haswell graphics fwiw - no graphics issues.

[Chiiruno]

How strange. Latest nixpkgs, right?
I did test it out with x.org too to see if it wasn't some other issue, but who knows.

[matklad]

Am I correct that the only missing bit is getting plasma (wayland) entry to SDDM? Could we close this issue and open a separate, specific one, about SDDM support? This is the top google result for nixos plasma wayland, and it's hard to get the accurate status from the comments here :)

[bkchr]

I need to find some time to bring plasma Wayland to sddm. Should not be that hard anymore.

[peterhoeg]

While you're at it, how about plasma 5.15 as well? ;-)

[bkchr]

@peterhoeg there is already a pr: https://github.com/NixOS/nixpkgs/pull/55650
@dtzWill was fast than me this time :D

[florianjacob]

On NixOS 18.09, with the sddm patch applied, when I choose wayland, I only get a black screen and then get back into sddm, without any meaningful error message in journal. As you all seem to be on unstable, I guess I'll wait for 19.03 and hope that it'll just work then.

[bkchr]

I didn't use the patch currently, so maybe something broke in the meantime.

[bkchr]

Here we go: https://github.com/NixOS/nixpkgs/pull/56988

[nrdxp]

I'm getting:

qt.qpa.plugin: Could not load the Qt platform plugin "wayland-org.kde.kwin.qpa" in "" even though it was found.

when trying to run manually with:

dbus-run-session /nix/store/...plasma-workspace.../bin/startplasmacompositor

I got the SDDM session file to load by simply adding pkgs.plasma-workspace to services.xserver.displayManager.extraSessionFilePackages, but it doesn't work. Most likely with the same error as found above, though can't confirm since there are no journal messages.

[shatsky]

@nrdxp same problem here. It's kwin_wayland which fails. With env QT_DEBUG_PLUGINS=1 this message is preceded with:

Found metadata in lib /nix/store/1j0qllx2y9990hv9y5194c5wx7mgb2za-kwin-5.17.5-bin/lib/qt-5.12.7/plugins/platforms/KWinQpaPlugin.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "wayland-org.kde.kwin.qpa"
        ]
    },
    "archreq": 0,
    "className": "KWinIntegrationPlugin",
    "debug": false,
    "version": 330752
}
...
loaded library "/nix/store/1j0qllx2y9990hv9y5194c5wx7mgb2za-kwin-5.17.5-bin/lib/qt-5.12.7/plugins/platforms/KWinQpaPlugin.so"

loaded library suggests that plugin library was successfully located and loaded (but failed to do something). There are no preceding "loaded library" messages, so it's probably not because of a conflict with some other plugin. Nix store path suggests that it's the instance of this plugin library which had been built from the same source with the same toolchain as the kwin_wayland binary (I'm explicitly launching /nix/store/1j0qllx2y9990hv9y5194c5wx7mgb2za-kwin-5.17.5-bin/bin/kwin_wayland to avoid any unwanted effects).

I've tracked this error to https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp?h=dev#n1234 . Plugin's class is instantiated via
QGuiApplicationPrivate::platform_integration = QPlatformIntegrationFactory::create(name, arguments, argc, argv, platformPluginPath);
If QGuiApplicationPrivate::platform_integration pointer is still nullptr after this, program aborts. It can be assumed that whatever Qt library this code is compiled into, Nix guarantees that in runtime it is presented with same instance which kwin_wayland and KWinQpaPlugin.so had been built against.

Regular Qt/KDE apps can be launched under Weston successfully (without Xwayland).

UPDATE I've got it! Look at https://github.com/KDE/kwin/blob/master/plugins/qpa/main.cpp :
if (!QCoreApplication::applicationFilePath().endsWith(QLatin1String("kwin_wayland")) && !qEnvironmentVariableIsSet("KWIN_FORCE_OWN_QPA"))
In NixOS, kwin_wayland binary is renamed to .kwin_wayland-wrapped to make place for kwin_wayland shell script which sets environment with Nix paths. However its platform plugin checks that actual executable name is kwin_wayland to prevent using it for regular Qt programs (see https://blog.martin-graesslin.com/blog/2015/08/a-qt-platform-abstraction-plugin-for-kwin/).

[shatsky]

Now, the problem is that hardware acceleration is not working in kwin_wayland if it's launched with drm backend (i. e. from tty). I've tracked this to kwin compositing plugin selection mechanism ("SceneOpenGL" compositing plugin is responsible for initializing EGL, calling the code in mesa which actually adds wayland globals to compositor registry allowing clients to create hardware accelerated rendering contexts). For x11 backend, kwin_wayland instantiates "SceneOpenGL"; however, when run with drm backend, it instantiates "SceneQPainter" backend, which doesn't initialize EGL at all. Relevant code is in composite.cpp, Compositor::setupStart(). What I've already checked:

• KWinSceneOpenGL.so path (/nix/store/${kwin-output-bin}/lib/qt-5.12.7/plugins/org.kde.kwin.scenes/KWinSceneOpenGL.so) is among paths searched by KPluginLoader::findPlugins() (it is logged with env QT_LOGGING_RULES="*.debug=true" ; anyway, KWinSceneQPainter.so is in the same dir and wouldn't load otherwise)
• HAVE_GBM which is required for "SceneOpenGL" selection and EGL initialization on drm platform is not set during build of pkgs.kwin because of missing mesa dependency, but I've added overridden kwin to pkgs like

    kwin_with_gbm = pkgs.plasma5.kwin.overrideAttrs (oldAttrs: rec { 
      buildInputs = oldAttrs.buildInputs ++ [ pkgs.mesa ];
    });

and assured that libgbm is reported by cmake during build
-- Found gbm: /nix/store/8y2nakqqmqncp35w8ifdx4gc9b7lrzfn-mesa-19.3.3/lib/libgbm.so (found version "19.3.3")
and listed by ldd for lib/qt-5.12.7/plugins/org.kde.kwin.waylandbackends/KWinWaylandDrmBackend.so ; however, when I run this kwin_wayland binary which I identified like

nix-repl> :l <nixpkgs/nixos>         
Added 6 variables.

nix-repl> pkgs.kwin_with_gbm.outPath
"/nix/store/44ranqmbhxyc3wj46h4kjnv7xry1xxkz-kwin-5.17.5-bin"

, "SceneQPainter" is still instantiated instead of "SceneOpenGL".

UPDATE it is really because of missing mesa/libgbm dependency. kwin_wayland built with it provides hardware acceleration. However, if it is built as overridden pkg with its own attr name in Nix scope (kwin_with_gbm in my example), it still tries to pick kwin drm platform plugin of kwin built as plasma5.kwin which are available in /run/current-system/sw/lib/qt-5.12.7/plugins/. I couldn't override it with env QT_PLUGIN_PATH nor with qt.conf in directory which kwin_wayland binary is placed in and launched from. I ensured this path is nowhere in env but it still picks it. Finally, I've unset PATH (which has /run/current-system/sw/bin along with other paths which can be matched to ../lib paths somewhy appearing in actual Qt plugins search paths) and this did it. Now, there are 2 problems:

• I can't override plasma5.kwin (tried plasma5.overrideScope' but resulting plasma5 is somewhy missing override attr which is used somewhere else)
• Qt unconditionally adding plugin search paths based on PATH is anyway bad, I think something should be done about it; I've already seen Qt software failing on Nix and I think now it was because of this, e. g. when Qt app installed into user env tried to pick runtime-uncompatible plugin from system-wide dir

[shatsky]

Now, the problem is that normal Plasma Wayland startup routines (ones that run when startplasma-wayland is launched) fail because constructed environment becomes too large for kinit to handle, even with https://github.com/NixOS/nixpkgs/commit/c75860918f0e470bcc881414bd039d7c6c541a21 :
/nix/store/6i37rkjvalxd903gmkd63bzp5bgddsyb-kinit-5.66.0/libexec/kf5/start_kdeinit: exceeded environment length limit
/nix/store/6i37rkjvalxd903gmkd63bzp5bgddsyb-kinit-5.66.0/libexec/kf5/start_kdeinit_wrapper" ("--kded", "+kcminit_startup") exited with code 1

I have submitted proposal to change Qt plugin paths handling in nixpkgs, https://github.com/NixOS/nixpkgs/issues/86369 ; I think it will eradicate the need for these wrappers which build enormous env vars.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[pasqui23]

still important to me

[hellst0rm]

still important to me