Hello, I am writing this because this topic was at first a question I had and I couldn’t find an answer to it, information about it online is scarce and outdated so here I am to share what I have figured out; so

Let’s establish things

  • Remote Machine = The device processing the program/audio and holding the files, streaming them over to the Local Machine
  • Local Machine = The device which initiates the connection to the Remote Machine, hears the audio, interacts with the programs and receives the files requested

What we’ll be using (L/R means Local or Remote respectively)

  • SSH (openSSH) L&R
  • waypipe L&R
  • pipewire, pipewire-pulse and wireplumber L
  • sshfs L
  • Any wlroots based Compositor L
  • Any Terminal Emulator L
  • FUSE L

In my case my compositor of choice will be Labwc, keep in mind all of the components used have a lot of options and you could benefit from checking out whats hot in each of them, I will only cover settings up to things WORKING

First things first install the packages and on the Local Machine make sure you have your sound system running for your User, if you hear audio already you should be okay otherwise review your specific distro documentation on how to start the services

For example on Arch: systemctl start pipewire pipewire-pulse wireplumber --user

Next is to start your Compositor of choice and open up a terminal emulator, you should first make a connection from the Local Machine to the Remote Machine with SSH and your credentials so

For example: ssh -p 7777 -l user 192.168.100.2

Managed to connect to your Remote Machine? Great now we’ll need to do the set-up, we’re going to need to make an environment variable set automatically on each SSH login

This variable has to set-up on SSH LOGIN ONLY as to not disturb the Remote Machine’s local audio playing for when it is used locally, there might be many ways to setup this, in my case I’m gonna add this line to ~/.bash_profile

For example: if ! [ "x${SSH_TTY}" = "x" ]; then export PULSE_SERVER=localhost:4713; fi

This will automatically execute on login, evaluating if it’s an SSH login, and adding the environment variable PULSE_SERVER=localhost:4713 which will tell applications running locally (On the Remote Machine) that the audio socket is the SSH socket we will open, which sends it back to your Local Machine’s audio service (Encrypting it)

When this is done, we can exit the Remote Machine’s shell and everything is basically ready on the Remote Machine

Now on our Local Machine we have to modify our SSH command to create the audio socket we have mentioned prior

For example: ssh -p 7777 -l user -R 4713:localhost:4713 192.168.100.2

The important part is -R 4713:localhost:4713 which is creating the socket on both ends and redirecting through your localhost and onto your audio server’s default listening port (4713), now we just have to make the Audio server listen to your localhost loading it’s Remote sound module

For example: pactl load-module module-native-protocol-tcp listen=127.0.0.1

This needs to be run each time the Local Machine’s audio server restarts, but don’t worry about that adding complexity you won’t need to remember this

Next up we should set-up waypipe, this application allows forwarding both Wayland native applications AND wayland compositors themselves, so if there is an X11 only application you can’t forward through Waypipe, you can start a compositor instead and use it from there (Wine games, to say my use case) just like a Remote Desktop

For example: waypipe --video h264 ssh -p 7777 -l user -R 4713:localhost:4713 192.168.100.2

In my example command, I use hardware accelerated video encoding which greatly increases performance, you may just want to use waypipe alone however which uses default settings, I highly recommend reading waypipe documentation for achieving the best performance for your setup and test it with your application of choice

For example: WLR_RENDERER=gles2 Labwc (executed on the Remote Machine Shell, will open it on your Local Machine’s Compositor)

Finally, for setting up Remote File Access we use sshfs prior to connecting to the Remote Machine, this utility mounts a Remote Filesystem on a local directory through SSH and FUSE using the sftp protocol which is all encrypted

For example: sshfs -p 7777 user@192.168.100.2:/home/user/RemoteDirectory/ /home/user/LocalDirectory/

Nice, now we have it all set up and ready to work, we can finally make it convenient to use, in my case I prefer to run all of this as a script easily accessible on my terminal as a single command that executes the script located on my scripting environment, and we add two more commands that just unload the Audio Server module and the Remote Filesystem mount when we’re done

For an example script:

pactl load-module module-native-protocol-tcp listen=127.0.0.1
sshfs -p 7777 user@192.168.100.2:/home/user/RemoteDirectory/ /home/user/LocalDirectory/
waypipe --video h264 ssh -p 7777 -l user -R 4713:localhost:4713 192.168.100.2
pactl unload-module module-native-protocol-tcp
umount /home/user/LocalDirectory/

Let’s say we create this script and it’s saved in our home folder, we just have to make it executable (chmod +x scriptdir) and run it from our Terminal Emulator

For example: ./Remote\ Machine1.sh

And it will automatically set up everything for us and ask for our Credentials, we have a perfect workspace that imitates that of a remote desktop experience, on Wayland (may not be exclusive to this but that’s what I’m doing here)

Did I miss anything? Have suggestions? Let me know what can be done better and I’ll update this post, thanks for reading and have a good one

  • petrichornetrainfall@piefed.social
    link
    fedilink
    English
    arrow-up
    3
    ·
    8 hours ago

    So a lot of documentation in general typically only covers beginner or expert levels, with almost no intermediate.

    It’s always “here’s how to say hello world” or “here is how to extend our implementation at a low level”.

    So it’s nice to have examples of intermediate use cases for power users who need to do more than the most basic examples, but don’t plan on submitting PRs to add or change functionality.

    More info, guides, and examples are always better than less (as long as it’s accurate).