Fun with remote Wayland: WayPipe

Applications
#1

Hey all,

this is just to make you aware that the waypipe tool has been accepted for the SailfishOS:Chum repo.

Now, this is not something huge and exciting, I just took the code, packaged it and found that it does indeed work. For some definitions of “work”.
So, if you are looking for another thing to play around with on your SFOS phone command line, this might be for you.
If you are only interested in stuff that is actually ready for prime time and can be used productively, you can probably stop reading this now.

You can read about waypipe here, but in short it’s a tool to run applications using Wayland running on one machine, and display and interact with it on another machine.
This is similar to what is known as “X11 forwarding” to Unix people.

What this can do:

  • install waypipe on a SFOS phone
  • install waypipe on another Linux computer
  • call a command on the phone which launches an application on the computer, and have its display/output/window show up on the phone, where I can interact with it.

Here I use the example of kreversi, a KDE game.

user@sailfishpone:~ $ waypipe ssh myuser@linuxbox env QT_QPA_PLATFORM=wayland-egl QT_SCALE_FACTOR=3 dbus-launch kreversi

which should display a new app window on the phone where you can play a game of Reversi.

As you can see there are some caveats:

  • as you can see, I put QT_SCALE_FACTOR into the environment to have the UI appear large enough. You might have to play around with this to get proper display. Obviously this will work only for Qt applications.
  • the remote machine must be able to set up “proper XDG environment” for the user, i.e. must be running at least systemd-logind or PAM modules which set up a working XDG_RUNTIME_DIR and other stuff. (E.g. I was not able to launch any apps on a box which has no systemd stuff and also otherwise minimal/headless config.)
  • minimizing the window on the SFOS side sometimes makes the app not show anything again (although it is still running).
  • performance: I found that enabling the built-in compression can make the performance much better than running it plain. Luckily there is a benchmark function that will determine the best value to use for you. Run waypipe bench XX where XX is the bandwidth on MB/sec the connection between the two devices. Depending your SFOS device and version, it will tell you to use something like waypipe -c lz4=6 or waypipe -c zstd=2 .

Potential other uses

In theory it should also be possible to do the reverse, i.e. have an SFOS app (or at least all of Lipstick) displayed on a remote computer running a wayland composer, but I have not found the right incantation to do that.
Maybe someone here can figure it out.

Another thing which came to mind is using this is for example install some kind of Linux-VM on the device (i.e. an lxc-container), and proxying wayland clients from that system locally to the Lipstick display.

Hacking

The original software repo is here: M. Stoeckl / Waypipe · GitLab

Packaging for SFOS is available at the Chum organisation: GitHub - sailfishos-chum/waypipe: Packaging for waypipe

And the package in chum-testing is here: Show sailfishos:chum:testing / waypipe - SailfishOS Open Build Service

One limitation of the current package is that both DMABUF and VAAPI functionality of waypipe is disabled, as we lack (afaik) the necessary dependencies, libvaapi and libgbm.

21 Likes
#2

BTW, instead of a single KDE app like in the example above, you can even run a full Plasma desktop over the network.

Well I say run.

It will start and show something on the phone. It will not be usable. Or at least it was not on my setup.

But you can

user@sailfishpone:~ $ waypipe ssh myuser@linuxbox plasmashell
#3

Hey, thanks for the package.
Played some time with it. Looks interesting.
I was able to run telegram-desktop from Arch lxc container (harbour-containers from chum) via ssh.

waypipe ssh -p 222 user@10.102.238.7 env QT_QPA_PLATFORM=wayland-egl QT_SCALE_FACTOR=2 telegram-desktop

Might be used to play with remote QT apps, but not stable because lipstick has different features then other desktop wm (like new windows, resize etc).

p.s. also I’ve tried desktop (client) → phone → lxc Arch container (server) and it works with telegram-desktop also.

2 Likes
#4

Hm I wonder if running a nested WM via waypipe, and then the application on the WM would help with that?

Something like waypipe mutter --nested and then launch the app on mutter?

#5

Not sure (I’m not fully understand this approach). It sounds like much easier just to start lxc container in a separate window (maybe with plasma-mobile interface, not available right now in harbour-containers, but should be achievable).

#6

LXC itself doesn’t provide any virtual framebuffer to write to. You need another software to provide something for the graphical applications in the containers that then displays this on your host or share the access files of your hosts gpu and compositor with the guest. Waypipe is a fitting solution to solve this problem.

2 Likes
#7

Oh that looks super cool! I was thinking about exploring something along those lines to have android apps run on a remote Waydroid container (e.g. on a Raspberry Pi) to avoid killing the battery of the linux smartphone.

1 Like
#8

LXC itself doesn’t provide any virtual framebuffer to write to.

Yes, but mentioned harbour-containers application already has automated Xwayland/xfce install and run which already works out of box.

#9

I might be completely wrong here, but if i want to launch a plasma session on m pc, i always do startplasma-wayland . (or x11 for that matter)

#10

That’s correct, but you don’t want to initialize some display compositor etc., you only wand the application part. You already have your Wayland compositor running on the device you use to access the remote machine with.

1 Like
#11

There are many paths to Rome, each have their advantages and shortcomings.

#12

Thanks for the clarification, i expected sth like that;)

#13

The solution for this seems to be to use the --display option. So e.g.

waypipe --display /tmp/wp-kodi_${RANDOM} ssh nephros@htpc kodi-standalone

The man page is worth a read.

1 Like
#14

No success yet, but I have been trying this today - although I’m not sure if this even needs waypipe.

On SFOS:

waypipe --socket "${XDG_RUNTIME_DIR}/waypipe.sock" client

In the chroot:

# hoping for a foot-terminal to pop up somewhere on the phone's screen
waypipe --socket "${XDG_RUNTIME_DIR}/waypipe.sock" server foot

Depending on the app I try, the error messages are different - or absent - but it always fails.

For foot they are:

err: wayland.c:672: wl_compositor: need interface version 4, but compositor only implements 3
err: wayland.c:672: wl_data_device_manager: need interface version 3, but compositor only implements 1
err: wayland.c:672: wl_seat: need interface version 5, but compositor only implements 3
err: wayland.c:1512: no compositor

The same errors show when running without waypipe, but I hoped they may go away by using it.

By the way, I’ve had these env vars set on both sides:

export XDG_RUNTIME_DIR=/run/user/100000/
export WAYLAND_DISPLAY=../../display/wayland-0
export QT_QPA_PLATFORM=wayland # or wayland-egl