Plasma 5.20 Beta? It is rock solid, excluding the taskbar thumbnails on Wayland - or rather because Pipewire needs "per user" init scripts

LuckyCyborg · 09-20-2020, 02:58 PM

Well, I managed to build Plasma 5.20 Beta, with Frameworks 5.74 and Applications 20.08.1 ...

So far so good, as the Plasma 5.20 Beta is surprisingly stable - basically I seen no crash under X11/Plasma5 and everything works as supposed.

Same does Wayland/Plasma5, up to the Pipewire integration for taskbar thumbnails (which works, BTW) and much more important: screen-casting - aka remote desktop tings like TeamViewer, RDP or VNC.

First of all, to bring up this Pipewire support, I needed to add a xdg-desktop-portal package, built from a SlackBuild adapted from SBo.

In the end, manually starting /usr/bin/pipewire from a console, the taskbar thumbnails works for Wayland and/or Qt applications - still no luck with Firefox, which I should keep on X11, because with the Wayland frontend it have serious rendering issues.

However, studying Pipewire, I arrived to conclusion that regarding its init scripts, it is a very special snowflake...

Apparently, we should start /usr/bin/pipewire like a daemon, when the desktop environment - Wayland/Plasma5 is bring up, and only one single instance should ran for this particular user, then to shutdown this particular daemon instance when the DE shutdown.

This should be done PER USER, as there could be several desktops started for different users in a computer.

Basically, on the other distros which are systemd-based, they uses systemd "user target" to do this trick, BUT there is no systemd in Slackware, as it is obviously...

So, I observed that Plasma 5.20 permits to configure and run startup and shutdown scripts, then I imagined something like this:

to have an /etc/user.d/user.pipewire script which is executed with the arguments of "start" or "stop" just like any init script, on startup or shutdown by the Wayland/Plasma5.

To run "/etc/user.d/user.pipewire start" as user - to bring up the Pipewire is rather simple, BUT looks like my Slack-Fu is not good enough to imagine also the "stop" case...

As I said previously, we can have several instances of /usr/bin/pipewire running - one for each user, then we should shutdown precisely the one running for our particular user, so the "killall" way looks out of scope. Rather, I need to kill a precise /usr/bin/pipewire instance.

So, I ask the Slackware Gurus to be kind to help me to imagine this special init script for Pipewire, running "as user" and "per user".

Any suggestions are appreciated.

Ser Olmy · 09-21-2020, 08:32 AM

I'm no "Slackware Guru", but how about creating a PID file called pipewire.$UID.pid in /run when pipewire is started?

The "stop" logic would then be:

Check for the existence of pipewire.$UID.pid
Extract PID from file
Optional: Verify that the PID does indeed point to a running instance of pipewire
Kill the process

Just a suggestion.

Edit: Seems only root can write to /run, so I guess one would have to use another directory.

ZhaoLin1457 · 09-21-2020, 11:10 AM

@LuckyCyborg

Well, certainly also myself I'm no "Slackware Guru" but if I understand right, you want a script like the ones from /etc/rc.d, but able to be launched on startup/shutdown by Plasma5 to handle the starting and stopping of Pipewire as logged-in user.

There's a caveat: from what I know, Plasma5 have support for startup and shutdown scripts, just like have also KDE4, BUT both KDE4 and Plasma5 cannot pass parameters to those scripts.

That's why I imagined an script named "/etc/user.d/pipewire_start" , with a symlink named "pipewire_stop" in the same folder. The first one is for startup, the second one for shutdown of Pipewire.

As you specified, they should be executed as logged-in user, by something like a DE, i.e. Plasma5. And they can handle multiple instances of Pipewire, one for each user.

Code:

#!/bin/sh
#
# Pipewire startup/shutdown script for Slackware Linux

PIDFILE="/run/user/${UID}/pipewire.pid"

LOGFILE="/tmp/pipewire-${USER}/pipewire.log"
#LOGFILE="${HOME}/.local/share/pipewire/pipewire.log"


pipewire_start() {
  if [ -s $PIDFILE ]; then
    PID=$(cat $PIDFILE)
    if ps -p $PID > /dev/null; then
      echo "Pipewire appears to be already running?"
      exit 1
    fi
  fi

  rm -f $PIDFILE
  mkdir -p $(dirname $LOGFILE)

  echo -n "Starting pipewire server..."
  /usr/bin/pipewire >> $LOGFILE 2>&1 &
  
  if [ $? -eq 0 ]; then
    PID=$!
    echo "$PID" > $PIDFILE
    echo " done"
  else
    echo " failed"
    exit 1
  fi
}

pipewire_stop() {
  if [ ! -s $PIDFILE ]; then
    echo "$PIDFILE does not exist or is empty."
    rm -f $PIDFILE
    exit 1
  fi

  PID=$(cat $PIDFILE)
  rm -f $PIDFILE

  if ps -p $PID > /dev/null; then
    mkdir -p $(dirname $LOGFILE)

    echo -n "Stopping pipewire server..."
    kill $PID >> $LOGFILE 2>&1

    while [ -d /proc/$PID ]; do
      sleep 1
      echo -n "."
    done
    echo " done"
  else
     echo "Pipewire server is not running."
     exit 1
  fi
}


# Find out how we were called.
case $(basename $0) in
  pipewire_start)
    pipewire_start
    ;;
  pipewire_stop)
    pipewire_stop
    ;;
  *)
    echo "$0: call me as \"pipewire_start\" or \"pipewire_stop\" please!"
    exit 1
    ;;
esac

Apparently, the best place to store the PIDFILE which it uses to keep the track of Pipewire instance started for a particular user is /run/user/$UID and I imagined also the redirection of error and standard output to a log file, which you can chose to be put in ~/.local/share or /tmp directory.

I hope that my script will helps, BUT I warn you that I do not tested it with Plasma 5.20 beta, then YMMV.

PS. How the heck you convinced SMPlayer to embed the video under Wayland? Only way I found under Wayland/Plasma5 to run MPlayer from SMPlayer is to use a separate window for it.

LuckyCyborg · 09-21-2020, 02:50 PM

@Ser Olmy

Thanks you very much for suggestions! Looks like the handling via pid files is the way to go, as demonstrated also by the script proposed by @ZhaoLin1457

@ZhaoLin1457

You script works absolutely under Plasma 5.20 beta, thank you very much!

Looks like that I did a mistake thinking that I can pass parameters to the startup/shutdown scripts of Plasma5. You are right, they can't have parameters. However, I think that this duet of startup/shutdown scripts can become quite complicated if you arrive to have multiple scripts to bring in the game - and PulseAudio looks like a perfect candidate, because even Slackware patched it to auto-start as user, I observed that many times it behave nastily (and consuming 100% of a CPU core) when you logout and login again as ordinary user.

Looking on what they do in Ubuntu, guess what? In fact also PulseAudio is ran as "user target" then some kind of shutdown when the DE leaves would be a thing to experiment.

So? In the end I think I will opt to use a pair of scripts: /etc/user.d/user.local and /etc/user.d/user.local_shutdown to be called by Plasma5, and the rest of scripts to be called with arguments by those two, just like /etc/rc.d/rc.local and /etc/rc.d/rc.local_shutdown do.

Regarding the SMPlayer, what I did is to force it to use QT_QPA_PLATFORM=xcb aka X11 usage, via a wrapper script and renaming the binary as smplayer.bin, for it to manage embedding of MPlayer, which is not Wayland aware. It is something like:

Code:

#!/bin/sh
#
# Shell script to start SMPlayer.
#
# Force the usage of XCB platform:
export QT_QPA_PLATFORM=xcb

# Start SMPlayer:
exec /usr/bin/smplayer.bin "$@"

The SMPlayer wrapping works fine both in X11 and Wayland.