Sway: where's the actual WM?


First time NixOS user here. Also, wayland & sway first-timer :sweat_smile:

I run sway from the terminal, but it looks like it hangs and nothing happens – I am failing to locate where is it that I can use the window manager, or if it’s even “alive”. Here’s what I see when I run sway:

From this screen I am able to switch to different virtual console with no issues. However I am failing to see the actual window manager.

For context, I’m trying to get a minimal (as in “no desktop environment”) installation working, with sway and wayland. I’ve followed a random though pretty nice tutorial, and managed to get to a point where I have sway installed.

My configuration.nix in its entirety is available here.

Don’t know where to even begin unwrapping this. What am I missing? What any other additional info could potentially help understand what’s happening here?

It looks like you’re running away in terminal in a graphical environment. You might be unclear about sways role, contrary to things like gnome or i3, which work on top of the z window system, sway as a Wayland compositor is basically doing i3 and X’s job, so you need to start it from a “raw” tty.

As a try, how about going to a terminal using Ctrl+alt+f2 and then trying sway?

I personally don’t even use a login manager anymore, i just exec sway in my .zshlogin if I’m on terminal 1.

Edit: nevermind I’m a bit slow today, just saw that this is a virtual machine :no_mouth:

The window decorations and menu are probably from the host system and the terminal and sway run in a VM, while the menu being that VMs GUI and not related to the host running it.

Have you tried using a DM?

NixOS is running in a VM, yeah :sweat_smile:

I haven’t, but now that you’ve mentioned it I intend to try. Thank you!

For educational purposes, may I ask what is the thinking process behind attempting to run sway using a DM? :thinking: Is DM known to do some setup required for sway to “run comfortably”?

Starting window managers and desktop environments through a desktop manager is the most common workflow and therefore usually what has been tested.

In general it is expected, that nixos will do some plumbing in the background to make the sessions available to your DM and that those session files again do other plumbing that is required.

I have to be honest though, I have no experience with wayland and what is idiomatic there. All I know is, that I do not have the problems it intends to fix, while at the same time, at least on my computer, it provides me nothing but a black screen… So introduces problems I do not have on X. (Not even speaking about the fact that there is no suitable awesome-wm replacement for wayland)


Try getting sway running via NixOS first before trying home-manager.

I’m not sure how well the vbox graphics emulation/drivers? work with sway and wayland. They might not be supported yet.

Looking at the arch wiki and your error log, looks like @NobbZ suggestion will work.

Or you can try out that alternative route, though I’m unsure if seatd is packaged for NixOS. There’s no option for it, if nothing else.

Doesn’t look like the NixOS options do anything of the sort, either, so I don’t think just switching to the NixOS module will fix this.

I am just realising that you just enable it via home-manager.

Please also enable sway on the system, as only that will do the necessary plumbing with systemd and polkit which home-manager simply cannot do for you.

1 Like

@NobbZ thank you, I tried two things you’ve suggested:

  • adding sway via adding the following to the top-level of my config (e.g. in addition to home-manager):

    programs.sway.enable = true;
  • setting up a DM via lightdm. The DM started & rendered the login page just fine, however proceeding with login and into a sway session still does not renders graphical interface.

I remain puzzled, mostly due to my incompetence with starting up such a custom minimal Linux environment.

I’m devouring all the resources I am able to reach to on Google, and is where I’d appreciate any pointers to where I could see & learn a holistic overview of what are required and optional runtime dependencies (libs, services, packages, ENV variables…) there are for sway :pray:

In the meantime I’m trying random things from the internet, and googling errors from journalctl hoping fixing them will give me a working sway WM :slight_smile: The errors I am looking into right now are can be seen here:

I’ve also started to use a qemu VM instead of virtualbox one, as it’s subjectively runs a lot faster in runtime, and also I am able to (at least partially) automate the set up of the “clean” root disk & subsequently the nixos installation.

One thing I am puzzled with is that I do not have a DISPLAY variable set (at least when I check it from the terminal’s shell process). I wonder if this is something sway needs, and if so - why this variable is missing :thinking:

Could you repost your configuration.nix with sway enabled at the nixos level and the error message when launching sway ?

Yes, definitely. Here’s how /etc/nixos/configuration.nix looks like right now, in its entirety:

{ config, pkgs, ... }:

  home-manager = builtins.fetchTarball "https://github.com/nix-community/home-manager/archive/release-22.05.tar.gz";
  imports =
      (import "${home-manager}/nixos")

  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  users.users.ievgen.isNormalUser = true;

  home-manager.useUserPackages = true;
  home-manager.useGlobalPkgs = true;

  home-manager.users.ievgen = { pkgs, ... }: {
    home.packages = [

    wayland.windowManager.sway = {
      enable = true;
      wrapperFeatures.gtk = true;
      config = {
        terminal = "alacritty";
        menu = "wofi --show run";

        startup = [
          # https://github.com/NixOS/nixpkgs/issues/119445
          {command = "dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK";}

        output = {
          eDP-1 = {
            scale = "1";

    programs.home-manager = {
      enable = true;

  services = {
    openssh = {
      enable = true;
      permitRootLogin = "yes";

    dbus = {
      enable = true;

  xdg.portal = {
    enable = true;
    wlr.enable = true;

  programs.sway = {
    enable = true;

  services.pipewire = {
    enable = true;
    alsa.enable = true;
    pulse.enable = true;

  system.stateVersion = "22.05";

[…] the error message when launching sway

To be precise, sway doesn’t give me an error - after running in --debug mode, the sway simply hangs in there. As if the graphical shell is running “somewhere”, just not in my tty. Here’s the screenshot:

Okay, I got it to work with:

  1. the following patch on your configuration:
--- test.nix	2022-10-14 14:52:01.660543482 +0200
+++ test2.nix	2022-10-14 14:52:46.483797102 +0200
@@ -6,7 +6,8 @@
   imports =
-      ./hardware-configuration.nix
+      <nixpkgs/nixos/modules/profiles/qemu-guest.nix>
+      <nixpkgs/nixos/modules/virtualisation/qemu-vm.nix>
       (import "${home-manager}/nixos")

@@ -14,6 +15,7 @@
   boot.loader.efi.canTouchEfiVariables = true;

   users.users.ievgen.isNormalUser = true;
+  users.users.ievgen.password = "test";

   home-manager.useUserPackages = true;
   home-manager.useGlobalPkgs = true;
  1. Building the vm with:
nix-build '<nixpkgs/nixos>' -A vm --arg configuration ./test.nix
  1. Running the vm with:
./result/bin/run-nixos-vm -vga qxl

Using informations from this topic.
Since there is little to no change to your configuration, you should simple search how to use qxl with qemu on your end.

1 Like

Thank you so much!

After figuring out how to enable qxl in my qemu installation, I finally managed to run the sway:

Wow, this took me a while! It never occurred to me that VM settings (e.g. display device in particular) can be causing problems like this.

Knowing that it works now, I’m curious: shouldn’t there be logs produced by sway, that would indicate there’s no place to render sway, etc.? Or, perhaps, some other generic logs for wayland? :thinking:

Sway logs to stdout/err. You’re probably not seeing it on screen though because sway has tried to “take over” the screen and got stuck or whatever and no new frames are rendered on-screen; neither sway or the tty.

You could try to redirect the log output into a file and read that through a more reliable mechanism such as ssh.

1 Like