Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

sway: Optimal NixOS integration #57602

Open
17 of 22 tasks
primeos opened this issue Mar 13, 2019 · 75 comments
Open
17 of 22 tasks

sway: Optimal NixOS integration #57602

primeos opened this issue Mar 13, 2019 · 75 comments
Assignees
@primeos
Labels
0.kind: enhancement

Comments

@primeos
Copy link
Member

primeos commented Mar 13, 2019 •
edited

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:
@primeos primeos self-assigned this Mar 13, 2019
@primeos primeos mentioned this issue Mar 13, 2019
Merged
16 tasks
@CrazedProgrammer CrazedProgrammer mentioned this issue Mar 14, 2019
Merged
10 tasks
@jtojnar
Copy link
Contributor

jtojnar commented Mar 14, 2019

virtboard is packaged in #57614

@ghost
Copy link

ghost commented Mar 15, 2019 •
edited by ghost

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
Copy link

ghost commented Mar 15, 2019 •
edited by ghost

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
Copy link
Contributor

t184256 commented Mar 15, 2019

What benefits it brings?

Starting sway itself, presumably.

@primeos
Copy link
Member Author

primeos commented Mar 15, 2019 •
edited

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
Copy link
Contributor

amazari commented Mar 15, 2019

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
Copy link

ghost commented Mar 16, 2019

@t184256

Starting sway itself, presumably.

Looks like we have a blocker for user services: #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
Copy link
Contributor

wf-recorder has been merged! #57662 🎉

@primeos
Copy link
Member Author

primeos commented Mar 17, 2019

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
Copy link
Contributor

wkral commented Mar 26, 2019

Waybar has been merged. #54627

@ghost ghost mentioned this issue Apr 1, 2019
Closed
10 tasks
@ghost ghost mentioned this issue Apr 16, 2019
Closed
10 tasks
@ghost
Copy link

ghost commented May 14, 2019

@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
Copy link
Member

NilsIrl commented Jun 15, 2019

What about bemenu?

@primeos
Copy link
Member Author

primeos commented Jun 15, 2019

@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
Copy link

ghost commented Jun 16, 2019

@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
Copy link
Member Author

primeos commented Jun 16, 2019

@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:
emersion/mako@ca8e763 (cc @dywedir maybe you could you test if it works after the next release)

@ghost
Copy link

ghost commented Jun 16, 2019

@NilsIrl

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

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

@NilsIrl
Copy link
Member

NilsIrl commented Jun 16, 2019 •
edited

@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
Copy link

ghost commented Jun 16, 2019

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

@NilsIrl
Copy link
Member

NilsIrl commented Jun 16, 2019

@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
Copy link

ghost commented Jun 16, 2019

Have you tried to run bemenu from a terminal?

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

@NilsIrl
Copy link
Member

NilsIrl commented Jun 16, 2019

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
Copy link
Member

NilsIrl commented Jun 16, 2019

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
Copy link

ghost commented Jun 16, 2019

@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 😞
BTW I hope they introduce something akin to i3-dmenu-desktop some day

@NilsIrl
Copy link
Member

NilsIrl commented Jun 16, 2019

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

@mschwaig
Copy link
Member

mschwaig commented Nov 7, 2020 •
edited

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
Copy link

xunam commented Jan 4, 2021

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:

  • 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 ?
  • 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.
  • 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 ?

@primeos
Copy link
Member Author

primeos commented Jan 4, 2021 •
edited

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 #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
Copy link

xunam commented Jan 4, 2021

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…

@xunam xunam mentioned this issue Jan 4, 2021
Closed
This was referenced Jan 16, 2021
Open
Closed
@primeos
Copy link
Member Author

primeos commented Apr 15, 2021

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 #119445 (comment) for more details.

@evils evils mentioned this issue May 20, 2021
Merged
10 tasks
@evils
Copy link
Member

evils commented May 26, 2021

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
Copy link
Member Author

primeos commented May 27, 2021 •
edited

Some updates:

@evils: If this is regarding #57602 (comment) / #119445 then it's fixed now by #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 #123034 and #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 (#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 (#122995) or a NixOS wallpaper (#122992). Feedback is welcome.

Edit: Oh, and we now have a NixOS VM test for Sway: #121437

@uvNikita
Copy link
Contributor

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: swaywm/sway@009c58f

@evils
Copy link
Member

evils commented May 27, 2021

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

@primeos primeos mentioned this issue Jun 23, 2021
Merged
11 tasks
@berbiche berbiche mentioned this issue Jul 8, 2021
Closed
@ulysses4ever
Copy link
Contributor

ulysses4ever commented Oct 24, 2021 •
edited

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
Copy link
Member

Synthetica9 commented Oct 25, 2021 via email

@ulysses4ever
Copy link
Contributor

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

@primeos
Copy link
Member Author

primeos commented Jan 23, 2022

Heads-up: The Nix package was just updated to Sway 1.7.
More details: 2e719d1 (#151902)

Notable (backward incompatible) changes:

  • The default terminal changed from Alacritty to foot

Known issues:

  • swaynag will crash when Sway 1.6.1 is still running while the Nix
    package (and thus swaynag) is already updated to version 1.7.
  • The experimental Ozone/Wayland support of Electron apps will be broken
    for a while. Electron version 17 should work but the Chromium fixes
    haven't yet been backported to Electron version 16.

The Electron status is tracked in #156352.

@nixos-discourse
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

t184256 commented Apr 13, 2022

@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
Copy link
Contributor

a-kenji commented Apr 13, 2022

Here is more about the Firefox issue: #167785. I think upstream is looking at fixing it as well.

@Rosuavio Rosuavio mentioned this issue Sep 16, 2022
Closed
13 tasks
@nixos-discourse
Copy link

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
Copy link
Contributor

viperML commented Feb 16, 2023 •
edited

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:

nixpkgs/nixos/modules/programs/ssh.nix

Lines 348 to 353 in c43f676

environment.extraInit = optionalString cfg.startAgent
''
if [ -z "$SSH_AUTH_SOCK" -a -n "$XDG_RUNTIME_DIR" ]; then
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent"
fi
'';
I found it because vscode would fail to connect via ssh when launched outside a shell ( microsoft/vscode-remote-release#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:

  • X11 WM's do this sourcing in some sort of xsession init script (?)
  • Wayland DE's exec bash internally (?)

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

@primeos
Copy link
Member Author

primeos commented Feb 18, 2023

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).

@senorsmile senorsmile mentioned this issue Mar 26, 2023
Merged
11 tasks
@teutat3s
Copy link
Member

teutat3s commented Apr 7, 2024

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@primeos primeos

Labels
0.kind: enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests