Waybar takes about 25 second to launch from config

[xezo360hye]

Description

I have a multi-file config and the first file that is sourced is setup.conf which contains exec-once commands. Here it is:

# Wallpaper
exec-once=hyprpaper

# Bar
exec-once=waybar -l debug > /home/<me>/waybar.logs

# Notifications
exec-once=fnott

As you can see, I want to launch three daemons at the beginning of Hyprland session

Expected outcome

It should set up my wallpaper, launch bar and start notifications daemon as always. I launched waybar from terminal and had no issues with it, as well as with all these programs

Noted outcome

From waybar.logs I see that waybar is started normally but about 25 seconds detects output:

[2022-07-08 12:34:50.135] [info] Using configuration file /home/<me>/.config/waybar/config
[2022-07-08 12:34:50.136] [info] Using CSS file /home/<me>/.config/waybar/style.css
[2022-07-08 12:35:15.158] [debug] Output detection done: LVDS-1 (LG Display 0x02F1)
[2022-07-08 12:35:15.160] [debug] Workspace group 1 created
[2022-07-08 12:35:15.160] [debug] Workspace 1 created
...

This behaviour doesn't change when setting "output": "LVDS-1"`` in~/.config/waybar/config. When starting from terminal (konsole`) it launches at normal speed - less than a second to show

Steps to reproduce

Add exec-once=waybar to the ~/.config/hypr/hyprland.conf or other config file that is loaded by Hyprland

[vaxerski]

https://github.com/hyprwm/Hyprland/wiki/FAQ#some-of-my-apps-take-a-really-long-time-to-open

[xezo360hye]

https://github.com/hyprwm/Hyprland/wiki/FAQ#some-of-my-apps-take-a-really-long-time-to-open

It's not the case, just tested and nothing changed. At 13:02:17 it is started, at 13:02:42 it detected output

[vaxerski]

try to launch it with a sleep 1 then

[xezo360hye]

I modified my script a bit:

# Bar
exec-once=echo "[$(date '+%Y-%m-%d %T.%N')] sleep" > /home/<me>/waybar.logs; sleep 1; echo "[$(date '+%Y-%m-%d %T.%N')] launch" >> /home/<me>/waybar.logs; waybar -l debug >> /home/<me>/waybar.logs

So that I can be sure that it really waited 1 second

From logs:

[2022-07-08 13:17:03.492669996] sleep
[2022-07-08 13:17:04.495689490] launch
[2022-07-08 13:17:04.641] [info] Using configuration file /home/<me>/.config/waybar/config
[2022-07-08 13:17:04.641] [info] Using CSS file /home/<me>/.config/waybar/style.css
[2022-07-08 13:17:29.678] [debug] Output detection done: LVDS-1 (LG Display 0x02F1)

As you can see, it really waited a second but output detection still took 25 seconds

[vaxerski]

no clue then.

[vaxerski]

try installing / fixing a desktop portal

[xezo360hye]

if you talk about xdg-desktop-portal package then it's up to date (1.14.4-1) and nothing wrong with it I guess. Seems like it was installed with KDE if that matters

[vaxerski]

thats why. If you have an xdg-desktop-portal, you also need a frontend, otherwise dbus will time out.

Install xdg-desktop-portal-wlr alongside (if you are on arch, i recommend the hyprland patched xdg-desktop-portal-wlr-hyprland-git from the AUR that won't crash)

[xezo360hye]

I guess it needs some additional configuration, doesn't it? Can you please point me somewhere? The article in Arch Wiki isn't very good. Also xdg-desktop-portal.service doesn't start (timeout) and xdg-desktop-portal-wlr.service is inactive (dead). I tried adding exec-once=systemctl --user start xdg-desktop-portal.service xdg-desktop-portal-wlr.service to the beginng of the setup.conf file

[vaxerski]

don't do that. Don't start them in the config. Simply enabling them should work. systemctl --user enable them and restart your computer.

[vaxerski]

also worth noting you need pipewire (if you sitll havent switched) and a pipewire manager, I recommend wireplumber

[xezo360hye]

don't do that. Don't start them in the config. Simply enabling them should work. systemctl --user enable them and restart your computer.

Both xdg-desktop-portal and xdg-desktop-portal-wlr:

The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

also worth noting you need pipewire (if you sitll havent switched) and a pipewire manager, I recommend wireplumber

Yeah I have that installed. Both PipeWire and Wireplumber are active but wireplumber outputs Failed to set scheduler settings: Operation not permitted

[vaxerski]

Both xdg-desktop-portal and xdg-desktop-portal-wlr:

ignore that. Have you installed xdg-desktop-portal-wlr or xdg-desktop-portal-wlr-hyprland-git? xdg-desktop-portal-wlr will segfault.

[xezo360hye]

Have you installed xdg-desktop-portal-wlr or xdg-desktop-portal-wlr-hyprland-git?

-hyprland-git one, as you suggested

[vaxerski]

Maybe try my method of doing it, with a script:

#!/bin/bash
sleep 4
killall xdg-desktop-portal-wlr
killall xdg-desktop-portal
/usr/lib/xdg-desktop-portal-wlr &
sleep 4
/usr/lib/xdg-desktop-portal &

just exec-once it. Works for me.

[xezo360hye]

So it should look like this:

exec-once=/path/to/that_script.sh
exec-once=sleep 1; waybar

right?

[vaxerski]

sleep 1 && waybar

[xezo360hye]

Well, this worked for the first times, but now it does not. Even with sleep 8. I made sure that script is run and there are those processes in background (pgrep and ps show them)

[vaxerski]

no clue then

[vaxerski]

closing due to inactivity, issue on the user's side.