search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.23k stars 14.22k 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:

mschwaig commented 4 years ago

@primeos, thank you for the reply it was really helpful to me to understand what I can expect to work.

About getting a nice default sway setup to work: @primeos's post makes me think it might be better to not use a display manager at all or get a really minimal one working instead of GDM. I have the suspicion that configuring GDM to not do any power-managment would help, but it looks like right now that would also still be quite complicated to configure, I am not sure (does #54150 apply when I try to disable GDM's power manamgent?). I will also try to run kanshi directly from sway and see if that fixes it.

About using systemd units: I have not used home-manager at all yet (I'm going one step at a time), but it seems like home-manager would be a way better fit to optinally integrate specific services as systemd user units instead of starting them from the sway config. Probably having options that move individual parts ot the desktop into user units directly in NixOS is prone to leave you with one foot inside of your configuration.nix file and the other one inside your ~/.config/sway/config file, because things you change in configuration.nix will mean you always also have make the corresponding changes in your sway config file correctly. So maybe home-manager would be a better place to do that kind of thing and maybe to do heavier customization in general.

erictapen commented 4 years ago

Probably having options that move individual parts ot the desktop into user units directly in NixOS is prone to leave you with one foot inside of your configuration.nix file and the other one inside your ~/.config/sway/config file

To avoid this situation I declare the content of global /etc/sway/config via environment.etc."sway/config" and intentionally have no file in ~/.config/sway/. Works only for single user setups of course.

Regarding the discussion wether to put sway logic into home-manager I'd like to add that this would leave us without the possibility to test sway integration via NixOS tests, like pretty much all X display-manager do and also cage.

Half a year ago I started bringing my Sway systemd user modules upstream, but never finished it. Here is my progress: https://github.com/erictapen/nixpkgs/tree/sway-systemd-integration (heavily WiP). My goal was to make the proposed systemd user integration described in the Wiki article I wrote easier for the end user. I'm still using this setup, but felt that it'd be better to wait with the PR until the discussion about where to put sway and how to integrate it into NixOS is solved.

primeos commented 4 years ago

Regarding the discussion wether to put sway logic into home-manager I'd like to add that this would leave us without the possibility to test sway integration via NixOS tests, like pretty much all X display-manager do and also cage.

Not sure about that one, what wouldn't we be able to do? Sway should be fully functional without systemd user units.

I'm still using this setup, but felt that it'd be better to wait with the PR until the discussion about where to put sway and how to integrate it into NixOS is solved.

I think it would be best to open a dedicated Nixpkgs issue regarding this (with e.g. the "0.kind: question" and "9.needs: community feedback" labels for better visibility and since this will require some discussion). I'm not too optimistic that it will be easy to nicely integrate this into Nixpkgs tbh but I guess it should be possible. I think the main problems are:

mschwaig commented 4 years ago

I have updated my config (also linked above) to use SDDM instead of GDM. Kanshi still doesn't pick up when outputs are changed on the fly, but this is now a workable setup for me, because I can recover from being left with a black screen easily and every time.

I also wanted to highlight that when I was using GDM I used the snippet that @wkral posted and that itself was working well for avoiding xserver.enable = true and looks promising to me.

UPDATE: I have given up on starting sway from a display manager for now. Right now I'm just manually launching it with exec sway, so I'm not using the config I posted myself anymore. There have been some updates in the wiki that look interesting, but I have not taken a closer look yet.

xunam commented 3 years ago

Hello,

I have been experimenting with Sway for a while so I would like to share some feedback. I am currently using NixOS 20.09 and GDM as the login manager. Things mostly work, the one thing that I find problematic is the setup of environment variables.

More specifically, when enabling Sway with no customization, simply by saying programs.sway.enable = true in configuration.nix, the session is started without reading /etc/profile nor ~/.profile, so Sway itself and anything it launches ignores any session configuration found in those places. This can be problematic when some variables need to be set up, especially PATH. Besides, when starting terminals, these profiles are not read either because they are not login shells.

My current way out of this problem is to enable Sway this way:

    programs.sway = {
      enable = true;
      extraSessionCommands = ''
        source /etc/profile
        test -f $HOME/.profile && source $HOME/.profile
        export MOZ_ENABLE_WAYLAND=1
        systemctl --user import-environment
      '';
      wrapperFeatures.gtk = true;
    };

I also tried using the systemd approach of putting files in ~/.config/environment.d/ and it works for all variables except for PATH which apparently gets reinitialized before starting the session. Besides, this approach induces some redundancy with ~/.profile (unless environment.d is somehow used also for login shells).

I would be interested if there are better ways to proceed.

For what it's worth, Gnome session on Wayland apparently does read /etc/profile and ~/.profile at some point.

A few other random thoughts while I am at it:

primeos commented 3 years ago

The startup sequence for Wayland sessions is a mystery. Is there any standard that would specify what should happen when logging into a session through a Wayland compositor, particulary regarding the role of the login manager vs the role of the compositor?

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it. For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).

For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o Edit: I just opened #109546 to track this.

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in https://github.com/NixOS/nixpkgs/issues/60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

What is the point of the option programs.sway.extraPackages ? Are these packages somehow integrated into the Sway setup or are they just installed like those in environment.systemPackages ?

The latter. I guess the main reasons are to make it easy to avoid optional packages by overriding programs.sway.extraPackages and to have a dedicated option for packages that are only/mostly relevant for Sway.

xunam commented 3 years ago

AFAIK the compositor isn't responsible for reading any startup files but I'm not aware of any official documentation regarding this. Most Sway users likely start it from a virtual terminal so the login shell will have already taken care of it.

Well, let me be the counter-example here :-)

For display managers the behaviour likely isn't consistent (IIRC each one tends to do it's own thing).

For Nixpkgs we'd need something like https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix for Wayland. I thought there was already a dedicated issue for this but couldn't find one :o

That indeed seems to be the way to proceed. If Sway appears among the possible sessions in a graphical display manager, then it is expected to be started from there and not from a login shell in the console, so the thing that is run as a session should behave accordingly. A simple sway-session script could do the job: set Wayland-specific environment variables, read profile files, then exec sway.

The NixOS wrapper for Sway apparently hard-codes the path to swaybg in PATH. That makes no sense to me. What is so special about swaybg that it has to get special treatment this way ? Before fumbling with extraSessionCommands, this weird PATH was inherited by anything launched from Sway.

The discussion is in #60434. IIRC this was because it's a fixed dependency of Sway and the solution via PATH sucked the least.

So I'll comment in that issue…

primeos commented 3 years ago

Sway 1.6 changed the default for $WAYLAND_DISPLAY which might cause a few regressions, even if you don't hard-code the value (defaults to wayland-0 when unset). For a quick workaround you might want to add the following to your Sway configuration (especially the 1st command for D-Bus, the second one is only required for some systemd user units):

exec dbus-update-activation-environment WAYLAND_DISPLAY
exec systemctl --user import-environment WAYLAND_DISPLAY

See https://github.com/NixOS/nixpkgs/issues/119445#issuecomment-820507505 for more details.

evils commented 3 years ago

is there a recommended way forward with regards to dbus on wayland? i'm specifically asking because apparently setting MOZ_DBUS_REMOTE in the wrapper for element-desktop (#123777) while fixing opening links for wayland users, broke an X11 user's ability to open links from element-desktop in (presumably) firefox

requiring every sway user to add a workaround seems like something we should avoid if this can be managed via programs.sway.enable (and equivalents for other wayland environments?) (particularly, i am unwilling to add such a workaround to my system, this should "just work" and i won't add stuff i'll have to remember to remove later)

primeos commented 3 years ago

Some updates:

@evils: If this is regarding https://github.com/NixOS/nixpkgs/issues/57602#issuecomment-820512097 / https://github.com/NixOS/nixpkgs/issues/119445 then it's fixed now by https://github.com/NixOS/nixpkgs/pull/122605. That only works for new Sway users though. If you've already copied the old /etc/sway/config then this requires adding include /etc/sway/config.d/*.

With https://github.com/NixOS/nixpkgs/pull/123034 and https://github.com/NixOS/nixpkgs/pull/122602 screen-sharing should also be easier to get to work now. We've also updated the documentation of the Sway module a little bit.

Btw: Quick heads-up that I'm planning to remove rxvt-unicode from sway.extraPackages (https://github.com/NixOS/nixpkgs/pull/121925) since Alacritty is the new default terminal for Sway for quite some time now.

We're also considering to use a wallpaper in the default configuration for the Sway module but it wasn't decided yet whether to use Sway's default wallpaper (https://github.com/NixOS/nixpkgs/pull/122995) or a NixOS wallpaper (https://github.com/NixOS/nixpkgs/pull/122992). Feedback is welcome.

Edit: Oh, and we now have a NixOS VM test for Sway: https://github.com/NixOS/nixpkgs/pull/121437

uvNikita commented 3 years ago

Btw: Quick heads-up that I'm planning to remove rxvt-unicode from sway.extraPackages (#121925) since Alacritty is the new default terminal for Sway for quite some time now.

Just wanted to mention that sway recently switched to foot as a default terminal: https://github.com/swaywm/sway/commit/009c58fc9529e284569bf58b73964cb3dc7c5baf

evils commented 3 years ago

If this is regarding ....

this is regarding 123777 as the comment about WAYLAND_DISPLAY seems to be dbus related it seemed likely related to me

ulysses4ever commented 3 years ago

vlc stopped working for me on unstable recently: it's only able to load the CLI interface for some reason. Has anyone experienced this? Google doesn't show up anything for the error I see except something from the past related to Raspberry Pi... I'm on pure Wayland (XWayland is disabled). It works fine on GNOME/XOrg.

❯ vlc
VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
[0000000001c67290] main interface error: no suitable interface module
[0000000001b66610] main libvlc error: interface "globalhotkeys,none" initialization failed
[0000000001b66610] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0000000001c67290] skins2 interface error: cannot initialize OSFactory
[0000000001bf5960] main playlist: playlist is empty
[0000000001c67290] [cli] lua interface: Listening on host "*console".
VLC media player 3.0.16 Vetinari
Command Line Interface initialized. Type `help' for help.
Synthetica9 commented 3 years ago

ulysses4ever: please open a new issue.

On Mon, 25 Oct 2021, 01:18 Artem Pelenitsyn, @.***> wrote:

vlc stopped working for me on unstable recently: it's only able to load the CLI interface for some reason. Has anyone experienced this? Google doesn't show up anything for the error I see except something from the past related to Raspberry Pi... I'm on pure Wayland (XWayland is disabled).

❯ vlc

VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)

[0000000001c67290] main interface error: no suitable interface module

[0000000001b66610] main libvlc error: interface "globalhotkeys,none" initialization failed

[0000000001b66610] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.

[0000000001c67290] skins2 interface error: cannot initialize OSFactory

[0000000001bf5960] main playlist: playlist is empty

[0000000001c67290] [cli] lua interface: Listening on host "*console".

VLC media player 3.0.16 Vetinari

Command Line Interface initialized. Type `help' for help.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NixOS/nixpkgs/issues/57602#issuecomment-950413577, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV7PJ7LB6BB43HKAXIMET3UISH5BANCNFSM4G6DESGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

ulysses4ever commented 3 years ago

@Synthetica9 thanks for suggestion! Here it is: #142863.

primeos commented 2 years ago

Heads-up: The Nix package was just updated to Sway 1.7. More details: https://github.com/NixOS/nixpkgs/commit/2e719d1cdab9e81750c19425a1f5c7678b5e73ad (https://github.com/NixOS/nixpkgs/pull/151902)

Notable (backward incompatible) changes:

Known issues:

The Electron status is tracked in https://github.com/NixOS/nixpkgs/issues/156352.

nixos-discourse commented 2 years ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/some-lose-ends-for-sway-on-nixos-which-we-should-fix/17728/1

ymatsiuk commented 2 years ago

Does anyone experience the return of firefox popup issue (literally all firefox extensions are broken since the popups don't render) on latest unstable? It started to happen since the last mass rebuild from staging has landed to unstable.

t184256 commented 2 years ago

@ymatsiuk mine render, never flicker and even have a solid chance of then never going away; willing to send the excess extraneous ones your way =D I'm now on GNOME tho

a-kenji commented 2 years ago

Here is more about the Firefox issue: https://github.com/NixOS/nixpkgs/issues/167785. I think upstream is looking at fixing it as well.

nixos-discourse commented 1 year ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/source-profile-with-gdm-and-sway/24561/1

viperML commented 1 year ago

Today I was hit by the problem of sway not sourcing /etc/profile

As most environment variables probably get set by pam_env, but SSH_AUTH_SOCK is set by a bash snippet run in /etc/profile: https://github.com/NixOS/nixpkgs/blob/c43f676c938662072772339be6269226c77b51b8/nixos/modules/programs/ssh.nix#L348-L353 I found it because vscode would fail to connect via ssh when launched outside a shell ( https://github.com/microsoft/vscode-remote-release/issues/8043 ), as SSH_AUTH_SOCK had not been set.

An ad-hoc solution is the following:

  programs.sway.extraSessionCommands = ''
    source /etc/profile
  ''

My guessings are that:

And on a side note, should we wrap sway to get this env, or should sway itself exec bash to get this environment?

primeos commented 1 year ago

Today I was hit by the problem of sway not sourcing /etc/profile

That's actually the intended behaviour (but not everyone likes it - IIRC this already came up a couple of times from users of graphical login managers). Luckily it's already documented in https://github.com/swaywm/sway/wiki/Setting-Environmental-Variables now:

Environment variables are inherited from the process that starts sway. You need to set variables there.

It would probably best to simply document this in https://nixos.wiki/wiki/Sway (just be aware that it's community maintained and not an official NixOS documentation).

teutat3s commented 7 months ago

Does anybody have working idle inhibit with firefox (e.g. video playback, video call) running in sway? Not working at all here, current workaround is waybar's idle inhibit module. Not sure where to start debugging this.

Dan-Theriault commented 7 months ago

I've had good results from https://github.com/rafaelrc7/wayland-pipewire-idle-inhibit