search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.6k stars 13.76k forks source link

sway: Optimal NixOS integration #57602

Open primeos opened 5 years ago

primeos commented 5 years ago

This is intended as an issue to collect and track possible improvements and feedback in general. Feedback form users is welcome (what is difficult, does not work, could be improved, are packages missing, etc.).

Possible improvements (feel free to propose additions and notify me of updates):

Useful software (for Wayland in general) in nixpkgs:

jtojnar commented 5 years ago

virtboard is packaged in https://github.com/NixOS/nixpkgs/pull/57614

ghost commented 5 years ago

light / brightnessctl: backlight management

Could actkbd or acpid used instead? For brightness control locally I use

  brightness = pkgs.writeShellScriptBin "brightness.sh" ''
    bl_dev=`echo /sys/class/backlight/*`
    echo $(($(< $bl_dev/brightness) $1 $2)) >$bl_dev/brightness
  '';
  services.actkbd = {
    bindings = [
      { keys = [ 224 ]; events = [ "key" "rep" ]; command = "${brightness}/bin/brightness.sh - 10"; }
      { keys = [ 225 ]; events = [ "key" "rep" ]; command = "${brightness}/bin/brightness.sh + 10"; }
    ];
  };

Will this work for all videocards? If so, I would like to add brightness control defaults to actkbd, like we already have for sound control sound.mediaKeys.enable = true;

ghost commented 5 years ago

Useful software (for Wayland in general) in nixpkgs: wallutils

Don't see it in nixpkgs.

systemd integration (user units) - WIP: #54627 (comment)

What benefits it brings? sway is capable to run applications on start by itself.

t184256 commented 5 years ago

What benefits it brings?

Starting sway itself, presumably.

primeos commented 5 years ago

Could actkbd or acpid used instead?

I do not have any preference here, it was simply meant as a list of software that could be useful (I took if from Drew's blog post). I also didn't plan to integrate this into the sway module if that was your concern (not sure if I'm interpreting your comment correctly).

If so, I would like to add brightness control defaults to actkbd, like we already have for sound control sound.mediaKeys.enable = true;

Might be a good idea if we already have this for sound. But since this is a generic solution that should work with both Wayland and X11 we should not put it in the sway module (but that was probably not your intention anyway).

Don't see it in nixpkgs.

Only the checked entries (checkbox) are already in nixpkgs.

What benefits it brings? sway is capable to run applications on start by itself.

That's a valid concern. I'm not using user units - it's mainly useful for people who already use them. I assume the main advantages are to automatically launch sway on a TTY (like with .bashrc), "dependency management" (other systemd user units) and we could better integrate it into nixpkgs than via the sway configuration (though I'm not sure how useful it would actually be - but it could be implemented in a generic and standardized way I guess).

(Edit: Also, please note that this is only a collection of possible improvements (that often require further discussion).)

amazari commented 5 years ago

Home-manager provided a nice way to set i3 declaratively [0]. Could be nice to have that in-tree and shared with i3 or add sway support to home-manager's dingy.

[0] https://github.com/rycee/home-manager/blob/master/modules/services/window-managers/i3.nix

ghost commented 5 years ago

@t184256

Starting sway itself, presumably.

Looks like we have a blocker for user services: https://github.com/NixOS/nixpkgs/issues/21460

@primeos

But since this is a generic solution that should work with both Wayland and X11 we should not put it in the sway module (but that was probably not your intention anyway).

Right, I'm just interesting whether it will work with different video cards. I only have Intel there.

Only the checked entries (checkbox) are already in nixpkgs.

Sorry. With sway 1.0-rc5, firefox and breeze dark theme they are not visible by some reason.

CrazedProgrammer commented 5 years ago

wf-recorder has been merged! #57662 :tada:

primeos commented 5 years ago

Right, I'm just interesting whether it will work with different video cards. I only have Intel there.

I also only have Intel but according to the Arch Wiki:

All methods are exposed to the user through /sys/class/backlight

it sounds like a good method that should work in most cases.

But we would have to modify the script to consider max_brightness.

According to the Arch Wiki:

The maximum brightness can be found by reading from max_brightness, which is often 15.

and on my system max_brightness has the value 7500. So the step size of 10 is either too high or too low in these cases. Using something like 10% would be better.

With sway 1.0-rc5, firefox and breeze dark theme they are not visible by some reason.

As long as it works with 1.0 :)

Home-manager provided a nice way to set i3 declaratively [0]. Could be nice to have that in-tree and shared with i3 or add sway support to home-manager's dingy.

@amazari interesting. I don't think that we can/should move it in-tree (too many configuration options IMO) but I'm assuming that adding a module for sway to home-manager would be fine - any volunteers? :)

wkral commented 5 years ago

Waybar has been merged. #54627

ghost commented 5 years ago

@primeos Would be nice to add environment setup like that https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix does For e.g. currently without doing exec dbus-update-activation-environment DISPLAY in sway config I get an error when trying to send notification gi.repository.GLib.Error: g-dbus-error-quark: Ошибка вызова StartServiceByName для org.freedesktop.Notifications: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.Notifications exited with status 1 (25)

NilsIrl commented 5 years ago

What about bemenu?

primeos commented 5 years ago

@NilsIrl good idea, I added it to the list - it's already packaged in nixpkgs (pkgs/applications/misc/bemenu/default.nix)

@gnidorah seems like I forgot to reply :o

Regarding the environment setup: Yes, that would be nice. I think there is already an issue to unify this for X11 and Wayland (I'll try to look it up and reference it).

Regarding the notification: Can this be reproduced (e.g. with notify-send and mako)? I don't use notifications but I could have a look at it if it doesn't work.

ghost commented 5 years ago

@primeos No, mako works. Looks like this is only needed for X11 programs. Thanks, I will switch to mako from now. Though with mako I see an issue that it can't be launched automatically

gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (2)

If I start mako manually, everything works fine

primeos commented 5 years ago

@gnidorah great :) Just realized that I missed the exec dbus-update-activation-environment DISPLAY part...

gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (2)

Seems like mako didn't provide a .service file but it should work after the next release: https://github.com/emersion/mako/commit/ca8e763f06756136c534b1bbd2e5b536be6b1995 (cc @dywedir maybe you could you test if it works after the next release)

ghost commented 5 years ago

@NilsIrl

How to make it work under sway? This doesn't show anything for me

nix-build -A bemenu
./result/bin/bemenu
NilsIrl commented 5 years ago

@NilsIrl

How to make it work under sway? This doesn't show anything for me

nix-build -A bemenu
./result/bin/bemenu

I had the same problem. Bemenu is only in the master branch.

git clone git@github.com:NixOS/nixpkgs.git
nix-build -A bemenu -I nixpkgs=nixpkgs/
# OR
nix-build -A bemenu -I nixpkgs/

The part after the = is the path to your local copy of the nixpkgs repository I am not sure if you need nixpkgs=

ghost commented 5 years ago

@NilsIrl I've tried it from master branch, but when I run bemenu under sway it doesn't draw anything on the screen.

NilsIrl commented 5 years ago

@NilsIrl I've tried it from master branch, but when I run bemenu under sway it doesn't draw anything on the screen.

Have you tried to run bemenu from a terminal?

ghost commented 5 years ago

Have you tried to run bemenu from a terminal?

That is. And nothing on the screen. Sway version is 1.1.1

NilsIrl commented 5 years ago

Have you tried to run bemenu from a terminal?

That is. And nothing on the screen. Sway version is 1.1.1

If you can open a terminal, you could see what bemenu outputs when it is run. If you don't have access to a terminal, you can try to redirect the output from bemenu into a file and then view the file.

NilsIrl commented 5 years ago

I personally had a problem where I couldn't even run a terminal. What I did is that I redirected stdout and stderr from the command launching the terminal in sway into a file.

I then viewed the file from the tty. And guess what... The file had an error message saying my version of opengl was too outdated for the terminal emulator, alacritty to work.

ghost commented 5 years ago

@NilsIrl Looks like my mistake was in that I've tried to run bemenu instead of bemenu-run. bemenu-run works just fine. My sorry :disappointed: BTW I hope they introduce something akin to i3-dmenu-desktop some day

NilsIrl commented 5 years ago

@gnidorah https://github.com/i3/i3/blob/6339427f017e1265a022e6537e16a8b4a921e52f/i3-dmenu-desktop You can modify this script for it to use bemenu instead of dmenu.

NilsIrl commented 5 years ago

Actually you don't even need to do that. Just run $ i3-dmenu-desktop --demenu=bemenu and it should work

If you don't want to install i3 just to have i3-dmenu-desktop you can download it from https://github.com/i3/i3/blob/6339427f017e1265a022e6537e16a8b4a921e52f/i3-dmenu-desktop

matthias-t commented 5 years ago

i'd like to suggest redshift to adjust the color temperature: https://aur.archlinux.org/packages/redshift-wlr-gamma-control-git/

optimally there could be a switch in services.redshift

matthias-t commented 5 years ago

also, https://github.com/ReimuNotMoe/ydotool

NilsIrl commented 4 years ago

wshowkeys, https://git.sr.ht/~sircmpwn/wshowkeys

mentioned in https://github.com/swaywm/sway/wiki/i3-Migration-Guide

erictapen commented 4 years ago

Regarding systemd user service integration: I started to document my setup in https://nixos.wiki/wiki/Sway. Atm I have no time to integrate these changes into NixOS, but maybe somebody else has?

ghost commented 4 years ago

Hello @erictapen, I've been trying to integrate Sway with systemd the way you proposed, but I had multiple issues doing so :

Have you been able to achieve this ?

The approach i' m currently following is to start Sway as the display-manager itself. I have the feeling the way you're doing it might be cleaner. Here is my setup :

  systemd.defaultUnit = "graphical.target";
  systemd.services.sway = {
    enable = true;
    wants = [ "systemd-machined.service" ];
    aliases = [ "display-manager.service" ];
    after =  [
      "rc-local.service"
      "systemd-machined.service"
      "systemd-user-sessions.service"
      "plymouth-quit.service"
      "plymouth-start.service"
    ];
    serviceConfig = {
      ExecStartPre = "${config.system.path}/bin/chvt ${sway.tty}";
      ExecStart = "${pkgs.dbus}/bin/dbus-launch --exit-with-session ${pkgs.sway}/bin/sway";
      TTYPath = "/dev/tty${sway.tty}";
      TTYReset = "yes";
      TTYVHangup = "yes";
      TTYVTDisallocate = "yes";
      PAMName = "login";
      User = sway.username;
      WorkingDirectory = "/home/${sway.username}";
      StandardInput = "tty";
      StandardError = "journal";
      StandardOutput = "journal";
      Restart = "no";
    };
  };

It still has one issue though.

ghost commented 4 years ago

Regarding systemd user service integration: I started to document my setup in https://nixos.wiki/wiki/Sway. Atm I have no time to integrate these changes into NixOS, but maybe somebody else has?

I tried your config, but had to make some changes (due to redshift): Remove

    package = pkgs.redshift-wlr;

Add (top level)

location = {
 latitude = 40.7;
 longitude = -74.0;
}

Also, not relevant to redshift, but

    environment.PATH = lib.mkForce null;

had to be changed to

    environment.PATH = pkgs.lib.mkForce null;

because lib does not exist (not sure if I did this one right).

ghost commented 4 years ago

I am sorry if this is not a right place to drop my idea, or this is something to create a separate issue for, but I would personally love if the Sway package in the option programs.sway was exposed so that it could be overridden with a package from the nixos-unstable.

Since the Wayland ecosystem and Sway are still in work in progress adoption-wise; many Wayland tools, and the newest releases of Wlroots and Sway themselves rarely make it into releases of Linux distributions, which follow the fixed 6 months release schedule model, in time. While using NixOS Unstable may be an option, having the latest Wayland stack is all I need.

My lack of understanding of the basic knowledge about Nix and/or NixOS'es Sway wrapper may make obvious limitations of implementing this feature inapparent to me, but I would like to hear from you what you think about it, and why it could/should (not) be implemented, nonetheless.

https://functor.tokyo/blog/2018-02-18-install-packages-from-nixos-unstable

primeos commented 4 years ago

@Bryophyllum that's a valid idea and feel free to add such comments to this issue ;)

That said, I'm not sure if having such a package option is worth it. I don't have any strong feelings on this, but AFAIK the consensus is to avoid such an option in cases like this (see https://github.com/NixOS/nixpkgs/issues/50476). Also: Mixing Sway from nixos-unstable with a system based on nixos-stable can result im problems like https://github.com/NixOS/nixpkgs/pull/76787#issuecomment-578461880.

Therefore I would avoid adding such an option. However, you should still be able to realise your use-case by using overlays. It should be sufficient to override the sway package with the one from nixos-unstable. Here is an example: https://gist.github.com/LnL7/58d687c58948e71acd7fd4d410f3cdd1 (instead of unstable = ... the following should be sufficient: sway = unstable.sway).

eoli3n commented 4 years ago

would you add : https://github.com/NixOS/nixpkgs/issues/78370 ?

primeos commented 4 years ago

For users interested in Grimshot or other scripts in contrib/: In #87979 we're currently discussing how to best package these in Nixpkgs.

flokli commented 4 years ago

I'm still missing some documentation / configuration examples on how to actually /enable/ sway.

While testing pipewire support in a VM, I hacked together the following:

      programs.sway.enable = true;

      services.xserver.enable = true; #??
      services.xserver.displayManager.sddm = {
        enable = true;
        autoLogin = {
          enable = true;
          user = "alice";
        };
      };
      services.xserver.displayManager.defaultSession = "sway";

      xdg.portal = {
        enable = true;
        extraPortals = with pkgs; [ xdg-desktop-portal-wlr ];
        gtkUsePortal = true;
      };

      services.pipewire.enable = true;

However, this is using Xwayland, and this is probably not right, i don't know.

We should also have some tests that ensure stuff doesn't break - I tried automating something with ydotool, but couldn't get it to work.

primeos commented 4 years ago

I'm still missing some documentation / configuration examples on how to actually /enable/ sway.

Where would you suggest to document this? E.g. there's a page on the NixOS wiki but that is currently only focused on systemd. Alternatively we could document it in the NixOS manual, but unfortunately there are many Wayland compositors and we don't have a general abstraction for them in Nixpkgs (i.e. documenting Sway there might be too specific).

But basically programs.sway.enable = true; is already enough and the most relevant things should already be documented via the NixOS module.

However, this is using Xwayland, and this is probably not right, i don't know.

I guess this is regarding Chromium? Unfortunately Ozone still isn't considered stable / enabled by default so you have to recompile Chromium for native Wayland support: chromium.override { useOzone = true; }. You can also disable XWayland by removing it from programs.sway.extraPackages or via the Sway config (IIRC).

We should also have some tests that ensure stuff doesn't break - I tried automating something with ydotool, but couldn't get it to work.

A NixOS VM test for Sway sounds like a good idea :)

flokli commented 4 years ago

Where would you suggest to document this? E.g. there's a page on the NixOS wiki but that is currently only focused on systemd. Alternatively we could document it in the NixOS manual, but unfortunately there are many Wayland compositors and we don't have a general abstraction for them in Nixpkgs (i.e. documenting Sway there might be too specific).

Yeah, I'd prefer having more complicated things documented in the NixOS manual via meta.doc - those hopefully are more likely to be up-to-date with the code than a page in the wiki. A Sway-specific documentation is probably better than no documentation at all :-)

Also note the Wiki Page is more a configuration dump that shows a way to get it working with systemd (and probably outdated, see https://github.com/NixOS/nixpkgs/pull/85334#issuecomment-615495925 as discussed with @Ma27)

These parts should really just end up in the sway module, and once we want to abstract that to support more wayland compositors, can be done as a follow-up.

I guess this is regarding Chromium? Unfortunately Ozone still isn't considered stable / enabled by default so you have to recompile Chromium for native Wayland support […]

Once compiled with Ozone support, is this a flag/environment variable? Could we enable this during compilation, while still having users opting in (similar to https://github.com/NixOS/nixpkgs/pull/89565)?

A NixOS VM test for Sway sounds like a good idea :)

As I posted in my previous comment, I didn't get the ydotool parts to work, so we can't really do anything in it. I'd assume for the test, we'd at least want to open a terminal and do some OCR (like in nixosTests.cage)

primeos commented 4 years ago

A Sway-specific documentation is probably better than no documentation at all :-)

Ok, I'll try to look into that then (but it might take me some time). Help is obviously welcome, if someone else who follows this issue is interested in that.

Once compiled with Ozone support, is this a flag/environment variable?

You need to run chromium --ozone-platform=wayland to select the Wayland backend (by default X11 is used).

Could we enable this during compilation, while still having users opting in (similar to #89565)?

Unfortunately not :o See https://github.com/NixOS/nixpkgs/issues/82443 and https://github.com/NixOS/nixpkgs/pull/85197 for related discussions. I'm hoping that Ozone will become stable in 2020 and current news look promising (e.g. Chrome Is Reaching The Point Of Good X11 + Wayland Support In Same Build - the X11 stability was lacking behind Wayland, which is the main focus).

As I posted in my previous comment, I didn't get the ydotool parts to work, so we can't really do anything in it. I'd assume for the test, we'd at least want to open a terminal and do some OCR (like in nixosTests.cage)

Why don't we just send the key combinations via send_keys to launch a terminal, etc.?

wkral commented 4 years ago

services.xserver.enable = true; #??

I was curious about that myself as I'd rather not have everything else that brings in.

To have just a display manager that launches sway and other wayland window managers all that is needed from xserver.nix is settingsystemd.defaultUnit and creating the display manager service. I pulled those out manually on my local machine to verify.

I'm wondering if extracting that config into display manager specific config might be a good idea. Maybe something where if services.xserver.enabled is true, then the display manager is automatically enabled, but it could be enabled without enabling the xserver.

I'd appreciate any feedback and opinions on that idea, and then I could potentially put together a PR.

Algram commented 4 years ago

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.

Maybe something like https://git.sr.ht/~kennylevinsen/gtkgreet would be perfect since it seems to be made specifically for sway?

wkral commented 4 years ago

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.

I've been using gdm with sway, as it's the only one that I'm aware of that will render with wayland and not have to start an Xserver. I did it with the proposed method above where just the display manager is enabled without enabling all of Xorg.

In my configuration.nix:

  services.xserver.displayManager.gdm = {
    enable = true;
    wayland = true;
  };

  # Extracted from nixos/modules/services/x11/xserver.nix
  systemd.defaultUnit = "graphical.target";
  systemd.services.display-manager =
    let
      cfg = config.services.xserver.displayManager;
    in
    {
      description = "Display Manager";

      after = [ "acpid.service" "systemd-logind.service" ];

      restartIfChanged = false;

      environment =
        lib.optionalAttrs
          config.hardware.opengl.setLdLibraryPath {
          LD_LIBRARY_PATH = pkgs.addOpenGLRunpath.driverLink;
        } // cfg.job.environment;

      preStart =
        ''
          ${cfg.job.preStart}

          rm -f /tmp/.X0-lock
        '';

      script = "${cfg.job.execCmd}";

      serviceConfig = {
        Restart = "always";
        RestartSec = "200ms";
        SyslogIdentifier = "display-manager";
        # Stop restarting if the display manager stops (crashes) 2 times
        # in one minute. Starting X typically takes 3-4s.
        StartLimitInterval = "30s";
        StartLimitBurst = "3";
      };
    };

I previously checked out gtkgreet, it's one of the greeters that are part of greetd. That project seems really promising but still in early phases. Maybe some progress has been made since I last looked. Also since it involves login, hopefully there will be some security minded folks looking over it.

berbiche commented 4 years ago

Has anyone gotten a different login manager than sddm working with sway? I am currently trying lightdm with the mini greeter, but I only get a black sceen with a cursor.

I have been using lightdm with Sway successfully on nixpkgs-unstable and 20.03 channel with no problems whatsoever. I use the enso greeter if it's relevant. My keyring (gnome-keyring) gets automatically unlocked too.

Excerpt from my config:

{
  services.xserver.enable = true;
  services.xserver.displayManager.defaultSession = "sway";
  services.xserver.displayManager.lightdm = {
    enable = true;
    greeters.enso.enable = true;
  };
  services.xserver.libinput.enable = true;
  services.xserver.layout = "us";

  services.gnome3.gnome-keyring.enable = true;
}
ddelabru commented 4 years ago

I am using sway on NixOS unstable right now (last upgraded from the nixos-unstable channel today, 20 August 2020) and overall it's pretty smooth -- the one reason I feel I still need to keep XFCE installed alongside sway is that I still don't have screen-sharing working under sway. Here's some excerpts from my system configuration:

  programs.sway.extraSessionCommands = ''
    export GTK_THEME=Blackbird
    export GTK_ICON_THEME=Tango
    export MOZ_ENABLE_WAYLAND=1
    export MOZ_USE_XINPUT2=1
    export XDG_SESSION_TYPE=wayland
    export XDG_CURRENT_DESKTOP=sway
  '';
  services.pipewire.enable = true;
  xdg.portal = {
    enable = true;
    gtkUsePortal = true;
    extraPortals = with pkgs; [
      xdg-desktop-portal-gtk
      xdg-desktop-portal-wlr
    ];
  };

In Firefox, I have widget.use-xdg-desktop-portal set to true. In google-chrome-stable, I have #enable-webrtc-pipewire-capturer set to enabled.

I've been using Mozilla's WebRTC gUM test to test screensharing. In Firefox, I can share either the entire screen -- which only comes through as a an empty black frame -- or individual applications that are running in XWayland, but not native Wayland applications. In Google Chrome I can only share Chrome tabs.

The above configuration excerpts are based on various snippets I've found across different GitHub issues &c, but they don't seem to do the trick with the most recent versions of everything. I'm trying to figure out what options I might be missing.

primeos commented 4 years ago

I've never tried screen sharing myself but for Firefox #84233 might fix your issues and for Chromium #89565 and linked issues/PRs might contain valuable information (configuration examples, etc.).

t184256 commented 4 years ago

Meanwhile, wf-recoder might or might not save you from relogging into XFCE.

ddelabru commented 4 years ago

Meanwhile, wf-recoder might or might not save you from relogging into XFCE.

I did try an alternate configuration involving the v4l2loopback kernel module and wf-recorder but when I tried to initialize a "webcam" feed from wf-recorder I ran into some errors. If I recreate that configuration I could share the errors I got here. It feels like kind of a hack to begin with though; if I could get one of these solutions to work I'd prefer it to be pipewire.

ddelabru commented 4 years ago

If I recreate that configuration I could share the errors I got here.

Alright, I tried again to adapt some instructions from the Arch Wiki to use wf-recorder to create a virtual webcam, and (good news!) this time I succeeded. Still feels a little hacky, but this is what I did.

In my NixOS config:

  # Obviously omitting all my non-screen-sharing-related packages:
  programs.sway.extraPackages = with pkgs; [
    v4l-utils
    wf-recorder
  ];
  boot.extraModulePackages = with config.boot.kernelPackages; [
    v4l2loopback
  ];

Then when I'm ready to start screen-sharing I do

# modprobe v4l2loopback exclusive_caps=1 card_label=WfRecorder
$ v4l2-ctl --list-devices

On my system this results in /dev/video4 being allocated with the WfRecorder label, so then I do

$ wf-recorder --muxer=v4l2 --codec=rawvideo --file=/dev/video4 -x yuv420p

I had two displays active when I first tried this, so wf-recorder asked me to specify which one I wanted to capture. I left this command running while I opened Firefox, opened a webcam-sharing test, and easily shared the "webcam" that was capturing my screen.

Now that I have this working I guess it's my solution for the time being. Would have preferred to just select applications or displays from within Firefox on the fly instead of setting up a virtual webcam first, but this is a pretty cool workaround.

mschwaig commented 3 years ago

As someone who is relatively new to NixOS and configuring this kind of thing I still found it fairly difficult to pull together all of the required pieces from different places to get a working setup with sway as the window manager and gdm as the display manager (to avoid having to enable xserver - not sure how much sway users care about this).

I'm still having trouble with kanshi, other than that I have a working config, which I wanted to share in case others find it useful: https://gist.github.com/mschwaig/195fe93ed85dea7aaceaf8e1fc6c0e99

I also added a warning in the wiki because I forgot to start the sway-session.target and this gave me trouble for a long time. If kanshi was working and I knew that GDM was a good choice for most people (SDDM is mentioned originally in this issue) I'd be happy to extend the wiki with a few lines on display manager integration..

There is a blogpost by Ongy who pulled out more stuff than just kanshi into individual units. I don't know if that would be a good idea.

primeos commented 3 years ago

@mschwaig yeah, the current module is focused on running Sway from a virtual terminal so using login/display managers (especially without X11) and/or systemd user units is unfortunately a bit tricky. For the login/display managers we'd likely need better NixOS abstractions that aren't so much X11 focused (not sure how well this is currently possible though). I'm also not sure what to do about the systemd user unit integration. Upstream doesn't officially support it (e.g. noted in the wiki and there should be a few issues/PRs IIRC) but AFAIK there are many(?) NixOS users that want/use it. I think if there are NixOS users interested in maintaining that it might make sense to add an option to the module (e.g. programs.sway.systemdIntegration) that is disabled by default but can be quickly enabled (and should then work with the Sway/Wayland related Nixpkgs packages - not sure if they can install systemd user units without a module though) (edit: this is probably too difficult to get right atm and some units (e.g. swayidle) probably even need to be configurable). But given that it's not officially supported and we likely add systemd user units that integrate with the sway unit it's likely better suited for home-manager(?).

If kanshi was working and I knew that GDM was a good choice for most people (SDDM is mentioned originally in this issue) I'd be happy to extend the wiki with a few lines on display manager integration.

That seems like a good idea. The Wiki is community maintained and the current version of the Sway page is AFAIK only a draft to document the systemd integration. So it would be good to extend it. And if there's e.g. an example for GDM that might be easily portable to other login/display managers as well.