MXLinux 23 sysVinit related Wayland "challenges"/ problems.

[siamhie]

Niggling problem #1: missing systray items

When running Wayland SwayWM sysV & systemd you will note differences in systray items. Several are missing from Waybar under sysV. Any ideas, why? They should be identical.

[...]

i guess would be that whatever is provide the autostart functions on swayWM has a systemd user service to launch it, which would not exist under sysV. this would likely not be a problem on DEs.

That seems reasonable. I've looked into the SwayWM autostart to see what I am able to determine. What I found is the following:

Code: Select all

# GTK3 applications take a long time to start
exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK
exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK

I'm not sure what this is or what I would do to get around it.

FWIW below is my entire autostart, in case anyone else wants to take a look.

Code: Select all

# Notification #####################
exec dunst -conf  ~/.config/dunst/dunstrc &
#exec mako

# Autolock

# Lock screen after 15 minutes; turn off display after another 5 minutes.
#
# Note that in the context of idle system power management, it is *NOT* a good
# idea to turn off displays by 'disabling outputs' for example by
# `wlr-randr --output <whatever> --off` because this re-arranges views
# (since a837fef). Instead use a wlr-output-power-management client such as
# https://git.sr.ht/~leon_plickat/wlopm
#swayidle -w \
#	timeout 900 'swaylock-fancy -f -c 000000' \
#	timeout 1200 'wlopm --off \*' \
#	resume 'wlopm --on \*' \
#	before-sleep 'swaylock-fancy -f -c 000000' 

# Lock screen after 5 minutes
#exec swayidle -w timeout 300 'swaylock-fancy' before-sleep 'swaylock-fancy -f' 
exec swayidle -w timeout 300 'swaylock' before-sleep 'swaylock -f'
# swfbar
# exec swfbar

# Wallpaper is being set in the theme script in conf.d

# To cheat & run synaptic
#exec xhost +si:localuser:root

# Network Applet
exec nm-applet --indicator

# GTK3 applications take a long time to start
exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK
exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK
     
# Welcome App
# exec dex -a -s /etc/xdg/autostart/:~/.config/autostart/  

# Sway Fader
# exec python3 ~/.config/sway/scripts/swayfader.py  

exec --no-startup-id conky -c ~/.conky/sway/.sway-1rc
exec --no-startup-id conky -c ~/.conky/sway/.sway-2rc
exec gammastep-indicator

# swayr
exec env RUST_BACKTRACE=1 RUST_LOG=swayr=debug swayrd > /tmp/swayrd.log 2>&1

###################################################################
########### Cleanup x11 wm processes  #############################
########### & add back those which work ###########################
###################################################################

# Dropbox #####################
#pkill dropbox 
#~/.dropbox-dist/dropboxd &
exec sleep 5 && DISPLAY= dropbox start -i & 

# Networking & Sounds #####################
exec nm-applet &
exec start-pulseaudio-x11 &
exec pnmixer &
exec pasystray &
exec pamixer &  ## under test
exec /usr/bin/blueman-applet &

# Notification #####################
exec dunst -conf  ~/.config/dunst/dunstrc &

# USB unmounter #####################
exec udiskie --smart-tray --automount --notify &

I take it from your QSI that your using systemd? Why not start the service automatically?

Running as a systemd service (since v0.7)

Instead of auto-starting the panel, you may use the systemd service:

Code: Select all

systemctl --user enable nwg-panel.service

DO NOT USE THIS WITH nwg-shell, as it doesn't pass necessary arguments.

If not the wiki says to add this to your sway config file

Code: Select all

exec_always nwg-panel

[dolphin_oracle]

Yeah those user level services have no interface under sysvinit. You would have to start the apps manually.

[manyroads]

Yeah those user level services have no interface under sysvinit. You would have to start the apps manually.

@siamhie I guess you guys have hit the nail on the head... it looks like there is a good reason why Wayland runs better under systemd. In the future that could be the death knell for inits that don't offer a similar set of systemd-like services. Gnome, KDE, Red Hat, IBM, Cinnamon, xfce4 and more all plan to move to Wayland in the next release or two. That does not seem to bode well for sysV init, I guess.

For me, I'll probably just stick with systemd going forward until I find something better to use.

[DukeComposed]

@siamhie I guess you guys have hit the nail on the head... it looks like there is a good reason why Wayland runs better under systemd. In the future that could be the death knell for inits that don't offer a similar set of systemd-like services. Gnome, KDE, Red Hat, IBM, Cinnamon, xfce4 and more all plan to move to Wayland in the next release or two. That does not seem to bode well for sysV init, I guess.

systemd didn't invent starting services. It seems simple enough to me to run some extra programs before starting a Wayland-based UI under sysV, or for that matter in any BSD-based system with no systemd support.

[dolphin_oracle]

Yeah those user level services have no interface under sysvinit. You would have to start the apps manually.

@siamhie I guess you guys have hit the nail on the head... it looks like there is a good reason why Wayland runs better under systemd. In the future that could be the death knell for inits that don't offer a similar set of systemd-like services. Gnome, KDE, Red Hat, IBM, Cinnamon, xfce4 and more all plan to move to Wayland in the next release or two. That does not seem to bode well for sysV init, I guess.

For me, I'll probably just stick with systemd going forward until I find something better to use.

its not actually a wayland problem. its actually on the part of the swaywm developers. KDE under wayland works fine on sysVinit.

[manyroads]

Yeah those user level services have no interface under sysvinit. You would have to start the apps manually.

@siamhie I guess you guys have hit the nail on the head... it looks like there is a good reason why Wayland runs better under systemd. In the future that could be the death knell for inits that don't offer a similar set of systemd-like services. Gnome, KDE, Red Hat, IBM, Cinnamon, xfce4 and more all plan to move to Wayland in the next release or two. That does not seem to bode well for sysV init, I guess.

For me, I'll probably just stick with systemd going forward until I find something better to use.

its not actually a wayland problem. its actually on the part of the swaywm developers. KDE under wayland works fine on sysVinit.

I think it is due to many things... lazy devs, systems built assuming everyone uses 'xyz', limited & poor testing, and a thousand other items. For example, I have no idea that I even need GTK3 yet it sits in my autostart, that I obtained from a systemd distro. If I weren't so darn lazy I could test to see what happens when I disable that set of systemd commands. I might do that. As for KDE it uses a different base wayland from Sway it all simply hurts a person's brain. Here's a decent document from Gentoo showing the confused mess:

https://wiki.gentoo.org/wiki/List_of_so ... or_Wayland

[manyroads]

@siamhie I guess you guys have hit the nail on the head... it looks like there is a good reason why Wayland runs better under systemd. In the future that could be the death knell for inits that don't offer a similar set of systemd-like services. Gnome, KDE, Red Hat, IBM, Cinnamon, xfce4 and more all plan to move to Wayland in the next release or two. That does not seem to bode well for sysV init, I guess.

systemd didn't invent starting services. It seems simple enough to me to run some extra programs before starting a Wayland-based UI under sysV, or for that matter in any BSD-based system with no systemd support.

You are correct... now if only knew what I was doing.

[Senpai]

I don't have a good answer for that... other than I don't want to build off of KDE. I'm pretty certain an install of gnome (wayland) stands a chance of fixing things but folks here are gnome-averse. In any case SwayWM should work on a vanilla Wayland base (such is this old guy's opinion).

Hi:

I don't know if it will help you, I have no idea about Wayland, but in my MX Respin with Gnome https://sourceforge.net/projects/senpai-respins/, Wayland works correctly booting from SysVinit, in fact I didn't even realize it was booting in Wayland until I read this thread and checked it...

Code: Select all

Graphics:
  Device-1: Red Hat Virtio 1.0 GPU driver: virtio-pci v: 1 ports: active: Virtual-1 empty: none
    bus-ID: 00:01.0 chip-ID: 1af4:1050 class-ID: 0300
  Display: wayland server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: gnome-shell
    driver: N/A display-ID: 0
  Monitor-1: Virtual-1 model: QEMU Monitor built: 2014 res: 1280x800 dpi: 100 gamma: 1.2
    size: 325x203mm (12.8x7.99") diag: 383mm (15.1") ratio: 16:10 modes: max: 1280x800 min: 640x480
  API: OpenGL v: 4.5 Mesa 23.1.2-1~mx23ahs renderer: llvmpipe (LLVM 15.0.6 256 bits)
    direct-render: Yes
    

Try if you want to install Sway over that Gnome installation and see how it works with the dependencies...
Best regards

[manyroads]

@Senpai Thank you for the pointer. I hope it helps some folks here. I am using EndeavourOS most of the time and running tiny WMs, mostly. I have conducted extensive Wayland testing on my Vanilla Debian base with success (that's not to say I like it as much as x11). As an old guy with about 30 years of Linux use, I simply like what I can do with x11. I know it will end, but hopefully not before I do.

I'll leave daily Wayland use for the future, when I can be happy with a single 'Compositor'.