so i upgraded to 24.11 last weekend, but had to revert back to 24.05, because ever since the upgrade some applications like steam, pavucontrol, and virtual machine manager take like 20-30 seconds to start. after some digging i found a reddit comment that suggested running
systemctl --user mask xdg-desktop-portal-gnome
which does the trick and solves the problem, but it seems like a hacky solution, and it also doesn’t solve my greeter (regreet) having this same delay as well, i tried adding it to my sway configuration for regreet but it didn’t solve the problem. has anyone else had this problem before? i already tried adding the gtk and gnome portal to extraPortals but it didn’t change anything.
I have the same problem, but it starts for around 3 weeks ago (I use nixos-unstable channel), and in my case org.freedesktop.impl.portal.desktop.gtk is failed to activate. In logs I have something like
dbus-daemon[2079]: [session uid=1000 pid=2079] Activating systemd to hand-off: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.0' [...]
.xdg-desktop-po[2083]: Choosing gtk.portal for org.freedesktop.impl.portal.Lockdown as a last-resort fallback
.xdg-desktop-po[2083]: The preferred method to match portal implementations to desktop environments is to use the portals.conf(5) configuration file
dbus-daemon[2079]: [session uid=1000 pid=2079] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk' unit='xdg-desktop-portal-gtk.service' requested by ':1.2' [...]
systemd[1947]: Starting Portal service (GTK/GNOME implementation)...
.xdg-desktop-po[2135]: cannot open display:
systemd[1947]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
systemd[1947]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
systemd[1947]: Failed to start Portal service (GTK/GNOME implementation).
Timeout is 2 minutes
/etc/xdg/xdg-desktop-portal/sway-portals.conf looks like
[preferred]
default=gtk
org.freedesktop.impl.portal.Inhibit=none
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr
so I guess gtk is chosen because of this default
After systemctl --user mask xdg-desktop-portal-gtk everything starts normally
Sadly when I set
xdg.portal.config.sway.default = lib.mkForce ["wlr" "gtk"];
it doesn’t help
it’s been a while, but i wanted to give an update, because i decided to give NixOS another try after spending a couple of months on Void, because i started to miss being able to declare everything lol, but when i did a clean install yesterday and rebuild my old config, the same issue was still there, and updating the lock file and rebuilding didn’t help either. however, masking xdg-desktop-gnome did not work anymore because the service didn’t even exist on my system. so i decided to dig deeper and it looks to me like this has nothing to do with the desktop portals at all, atleast not in my case. what i ended up trying was running my window manager wrapped with dbus-run-session, which solved the problem and all my issues went away. for me this is an acceptable solution because i already had to wrap my window managers on void linux anyway, because of the fact that it doesn’t use systemd, but usually systemd should handle this i think. if i understand correctly, projects like sway and hyprland don’t hook into systemd on their own, but you can use something called uwsm, you can find options for this to configure it when you search for it on the nixos options page. i haven’t tried it yet myself to see if this solves it properly, but i think that’s where the problem lies. it does still make me wonder though why it worked just fine without this in 24.05.
I’m not sure if this is your case, but I had a similar problem, using sway as my window manager. In my case, the solution was to put the line include /etc/sway/config.d/* in my ~/.config/sway/config.
1 Like
i just took a look at what is inside that directory, a nixos.conf file, and it looks like in there they are also importing the env variables for systemd and dbus, and enabling systemd integration, so it makes sense that that indeed would also solve the issue. it should probably be possible to set that up manually for other compositors as well, or use uwsm like mentioned previously, but i haven’t tried it for myself yet.
edit: yes this is indeed the solution and no need to bother with uwsm. i just added the commands that are used in /etc/sway/config.d/nixos.conf to my other window manager’s config files (without SWAYSOCK though since that is sway-specific), and now my window managers function correctly without needing to use dbus-run-session