Replies: 45 comments 5 replies
-
|
Sway-Debug Log: |
Beta Was this translation helpful? Give feedback.
-
|
I am experiencing the same for the last week(s) but only on initial boot. When closing/opening after initial startup it is normal speed again. Initial boot When stopping and starting: Something is going wrong in the display detection? |
Beta Was this translation helpful? Give feedback.
-
|
Facing the same issue. kernel: 5.14.8-arch1-1 |
Beta Was this translation helpful? Give feedback.
-
|
Same issue here, with sway-master and wlroots-master. I can't reproduce this when running a nested sway -- only the "real" sway seems to reproduce this. |
Beta Was this translation helpful? Give feedback.
-
|
Today i saw some "gnome-keyring" and "xdg-desktop-portal-wlr" errors in I have decided to delete the following packages
No more errors so far! Everything works as expected! |
Beta Was this translation helpful? Give feedback.
-
|
Good call, removing xdg-desktop-portal-gtk and gnome-keyring fixed it for me as well. |
Beta Was this translation helpful? Give feedback.
-
|
Odd. Any idea how either of these interplay with waybar?
I use both applications, so not looking forward to just uninstalling them.
|
Beta Was this translation helpful? Give feedback.
-
|
Same issue here. First start of waybar takes 20 seconds: Basically, all hanging is before 'Output detection done'. I don't have either xdg-desktop-portal-gtk or gnome-keyring installed, so removing them is not an option. Also doesn't seem that I have any errors regarding xdg-desktop-portal. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, removing |
Beta Was this translation helpful? Give feedback.
-
|
Personnaly, I need an instance of Can confirm that having |
Beta Was this translation helpful? Give feedback.
-
|
Ok guys, for me it was |
Beta Was this translation helpful? Give feedback.
-
|
Just tried with Regardless of beeing installed side by side with |
Beta Was this translation helpful? Give feedback.
-
|
Similar issue here as @ordy - would like to use Can I run a debug build to capture some data that might help find the source of the startup delay? |
Beta Was this translation helpful? Give feedback.
-
|
It seems this is caused when you have multiple portals running at the same time. What I had to do to fix this was disable portals that are not relevant to my desktop. As a sway user, I only care about I did not have |
Beta Was this translation helpful? Give feedback.
-
|
I need the wlr portals for screencasting, but use the gtk one for some gtk functionality on Flatpak apps.
While the workaround works, it's not practical in my setup.
|
Beta Was this translation helpful? Give feedback.
-
|
I can also confirm this bug and could also solve the problem by uninstalling gnome-keyring & xdg-desktop-portal-gtk |
Beta Was this translation helpful? Give feedback.
-
|
At least on my system, this has been fixed in v1:40.0-1.1 of gnome-keyring. |
Beta Was this translation helpful? Give feedback.
-
|
I fully updated my Arch system today, including gnome-keyring v1:40.0-1, and Waybar is still taking 10+ seconds to launch. |
Beta Was this translation helpful? Give feedback.
-
|
@Hubro Yup, this fix needs to be released for this issue to go away. It's unclear when that will happen :( |
Beta Was this translation helpful? Give feedback.
-
|
I have exactly problem when suddenly After for a while I remove Any idea why |
Beta Was this translation helpful? Give feedback.
-
|
I observe that installing |
Beta Was this translation helpful? Give feedback.
-
|
What worked for me was removing |
Beta Was this translation helpful? Give feedback.
-
|
Waybar is no longer starting slowly for me. I assume the previously mentioned fix for xdg-desktop-portal has been released 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
I still have the issue. I'm using the default sway config and changed:
My debug log shows the following: As far as I can understand, anything I notice the issue pretty much all the time, and can get rid of it when I reduce the CPU load on start up. I'm using 100% CPU for a few seconds every time sway starts up, and that seems to trigger a race condition. Could this be a general sway issue? Everything should work with the recommended sway setup in the wiki, right? |
Beta Was this translation helpful? Give feedback.
-
|
Having the exact same issue on |
Beta Was this translation helpful? Give feedback.
-
|
I stumbled upon this issue with my i3 setup, too. I finally figured it out, though I can't explain why it works. I singled out the cause to setting the env var Before: Now all my issues concerning startup delay have disappeared, for both my i3 and sway setups. It's a very specific fix, I don't know if it'll help anyone else. |
Beta Was this translation helpful? Give feedback.
-
|
From what I have experienced so far, I can tell few things:
PS: Since the way we all have approached this issue is different and causes are different, the above steps may or may not work for all. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I have the following:
This issue also seems to be tied somehow to GNOME terminal, which is also very slow to start since boot, and after pressing The worst thing is that this happens only sometimes, so can't reproduce on a whim. About half the time, waybar is already started before even my screen refreshes from CLI to GUI (I start sway from |
Beta Was this translation helpful? Give feedback.
-
|
It appears that masking WLR portal EDIT: This was definitely it, I've never encountered this issue ever again. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like |
Beta Was this translation helpful? Give feedback.
-
|
At some point this fixed it for me but not for some time anymore: I'm starting sway from fish login session and also start if status is-login
# Start sway at login
if test -z "$DISPLAY" -a "$XDG_VTNR" = 1
set -gx XDG_CURRENT_DESKTOP sway
set -gx XDG_DATA_DIRS "/usr/local/share:/usr/share:/var/lib/flatpak/exports/share:$XDG_DATA_HOME/flatpak/exports/share"
set -gx XDG_SESSION_TYPE wayland
set -gx BEMENU_BACKEND wayland
set -gx MOZ_ENABLE_WAYLAND 1
export $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg)
exec sway
end
endOn another machine there is no such issue, I'm not sure what's the difference, both machines have It also seems to happen only on cold boots. When I restart the machine, everything starts up fast. |
Beta Was this translation helpful? Give feedback.
-
|
Are there any updates in this issue? It happening when I launch Hyprland from tty but not when launching Hyprland with sddm. I can solve the issue by removing the package xdg-desktop-portal-gtk from my system. Any new experiences to share? |
Beta Was this translation helpful? Give feedback.
-
When you launch Hyprland from the tty, is the dbus daemon already running? Is the xdg-desktop-portal already running? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your feedback. I will test it out. |
Beta Was this translation helpful? Give feedback.
-
|
I traced the issue to a race condition but forgot to document the solution. TL;DR:
It essentially boils down to the fact that the order of these snippets (1)(2)(3) is not defined/ensured (or rather, conceptually, you have to treat the order as being executed concurrently): # (1) sway setup which does not start any xdg dependent apps
# (2) some include files that start something that is xdg dependent
include ...
# (3) waybar
exec wayland_waybarFor (3), I don't start waybar directly. Execution is wrapped in a script #!/usr/bin/env bash
dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
exec waybarWaybar has now access to the correct environment variables and is guaranteed to start immediately. This part needs to be inside the sway config, otherwise the Now, the include part (2) is executed at the same time. If, let's say, you have an include file that does the following: exec flameshotSometimes Waybar is not yet available. Flameshot is xdg dependent though (tray) and needs to be started after Waybar is fully initialized. The configuration that is provided with sway in I don't load any default configuration for sway. Instead, I wait until Waybar has been initialized, for every command that needs the xdg environment (for me, everything tray related): exec wait_for_tray && flameshotThe #!/usr/bin/env bash
while ! dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.kde.Status ; do
echo waiting for tray...
sleep 0.2
doneWith this, I have no order on all my include configuration files for sway and this fixed the startup time for waybar in the end. Hope this helps someone. As a side note, I start XDG_CONFIG_HOME=${HOME}/.config
XDG_CACHE_HOME=${HOME}/.cache
XDG_STATE_HOME=${HOME}/.local/state
XDG_DATA_HOME=${HOME}/.local/share
XDG_DATA_DIRS=${HOME}/.local/bin/${USER}:${HOME}/.local/bin:${XDG_DATA_DIRS}:/usr/local/share/:/usr/share/
XDG_CURRENT_DESKTOP=sway
XDG_SESSION_DESKTOP=sway
XDG_SESSION_type=waylandAs far as I remember, the cause for the long startup time of Waybar was if |
Beta Was this translation helpful? Give feedback.
-
Starting Waybar under Sway takes about 25 seconds. After that everything works fine.
Beta Was this translation helpful? Give feedback.
All reactions