Wprs – rootless remote desktop for Wayland (and X11, via XWayland) applications

[billpg]

"We've built X. It allows you to run graphical applications over a network."

"Here's an optimization for when the X display is the same machine as the process."

"We've built Wayland. We all run applications on the same machine as the display and X gets in the way."

"We'd like to run applications from machines over the internet."

"We've built Wprs. It allows you to run graphical applications over a network."

That's the circle of life.....

[delusional]

The X protocol is from a time before proprietary/differentiated GPU devices. Network transparency looks very different when you're doing simple stuff like "render a line" or "render a box". Nowadays even 2D applications are essentially sending arbitrary programs to a standalone accelerator (the GPU) which they expect to have incredible bandwidth.

In the simple case of the past, it made sense to send the primitives. In the complex now it's way more robust to stuff the bitmap over the wire.

[epcoa]

There are two seemingly irreconcilable camps at this point as to whether X itself is fundamentally sound technology for remote display or any kind of display technology going into the future. There are many reasons hashed out to death about this. Yes you could continue to add new X extensions, and the second system effect is a real consideration, but neither of those are absolute arguments against starting fresh without legacy baggage both in design and implementation.

X earned its place in the UHH over 30 years ago, at least let’s not pretend this was some universally beloved technology either.

[kaba0]

X being network transparent hasn’t been true for decades — no one uses xmotif and similar GUI libs, they just grab a buffer and paint stuff themselves, making the X protocol an inefficient format to carry bitmaps around.

Local-first is the correct approach as the end computers are significantly more powerful than 30 years ago. Plus, we can transport bitmaps far more efficiently with compression, so it’s quite obviously an improvement on every metric, it is pretty shortsighted to note it down as circular development.

[znpy]

It’s not a circle, it’s plain stupidity. Running stuff over the network has always been a requirement and somehow wayland people decided so ignore that requirement, producing an half-assed spec and quarter-assed implementations.

All this could have been avoided, and yet here we are…

[npteljes]

What I never understood is how Spice is not elevated to a separate product. It does a fantastic job handling the graphical, audio, and peripheral connections to VMs, so how come there isn't a Spice server that I can just install to whatever Linux system and remote to it with the Spice clients that are already there?

Also, I'd like to plug Sunshine - I think it works on Wayland, and from the tests I did it does a fantastic job on a local network to make a desktop usable, even from an Android device. The downside is that whatever happens on the remote screen, it must happen on the host screen as well, so you can't have the host locked while you do gaming on it for example.

[IceWreck]

I love Spice too but it has been deprecated for a while now. https://access.redhat.com/documentation/en-us/red_hat_enterp...

[Yeroc]

I looked at the Sunshine / Moonlight combination at one point as I thought something focused on latency would also be great for interactive desktop applications. It turns out though that clipboard synchronization isn't even supported so that was a complete non-starter for me.

[spqrr]

https://www.spice-space.org/xspice.html

Gives you an X server that you can connect to with spice. It's bare bones (no audio, etc.), but looks useable.

[metadat]

Is it better than xrdp though? I found xrdp last week and it's stellar, basically a microsoft-compatible RDP server for Linux. It's a complete solution, no drama and simply amazing.

Every other Linux remote desktop solution I tried was a mess, including Xpra (which was quite involved to even get installed and Debian, and then a letdown, yikes).

I wonder what happens with Wprs when you try to launch virt-manager, which requires root.

[pxc]

For me, definitely yes, because it's rootless. Being able to stream individual windows is an absolutely killer feature. Having to deal with non-native window management is a nightmare, not to mention that it leaves you pulling down more pixels than you need to.

Microsoft has similar functionality but it's gated behind enterprise licenses. I ran Xpra for free when I was a kid and it was magical; many years later I've still never played with Windows' Terminal Services, which is the MS thing that can do rootless IIRC. The way MS gates the necessary windowing features is why to this day you can't do rootless with X2Go or Xpra with normal Windows clients.

Is there special reason the usual GUI PolKit privilege elevation wrappers can't work with a remote X session? I think I used to be able to use kdesu and similar just fine over Xpra. Note that 'rootless' in this context (windowing) means 'without a root window', i.e., without rendering a desktop. It has nothing to do with the usage in projects like podman where 'rootless' means 'not requiring elevated privileges'.

[prmoustache]

Can xrdp open windows in single apps? This is my main use case for using waypipe (mostly) and xpra. I don't want to show a full desktop nor having to deal with keyboard shortcuts highjack between host and remote.

[shmerl]

I think freerdp is a better option since it has integration with Wayland and even some Wayland DEs are adopting it as remote access feature.

[pmontra]

I use remmina for that. It's simpler to configure. For example, it can export a local Linux directory to a Windows machine as a network share without messing with command line options. Not that CLI is bad, far from me, but it saves the time to learn the options for xrdp.

[erremerre]

xrdp on raspberry and ssh bitvise in windows, it is my way to use headless raspberry with graphic interface, and it works absolutely fine.

[dsp_person]

Can this be used to switch back and forth between different computers? If I remember correct Xpra supports this.

E.g. (1) open a session on desktop with firefox, thunderbird, vscode. (2) Then grab laptop and go to a coffee shop, connect with wayland-tranpositor to the desktop to resume the session with those programs where you left off with them. (3) Then go home and resume from the desktop.

I guess for (1) and (3) you are just running both the server and client on the desktop, and then for (2) you close the client on the desktop and run it on the laptop?

It would be cool if it could do shadowing, or have multiple clients running at the same time.

[XorNot]

There's a second crucial element to this: can it lock the local screen while you do this?

I did this a whole lot in the lab with Windows - walk away, and log in remotely and monitor my session, then head back in and log back on locally.

I never found a way to do this with Linux that just restores the session the way Windows seems able to. Instead all I ever found was "the remote screen is unlocked and the cursor is moving" or whatever.

[nicolasavru]

Yes. A wprs session is persistent on the server (currently a single session per user, we're going to support multiple sessions for a user when we get to it), so you can connect/reconnect from different client computers.

If you start the application in a local wprsc connecting to a local wprsd instead of in the local compositor directly, you can later connect to the session with a remote wprsc.

Locking the screen (the other subthread in here) is not applicable to this, applications are drawn wherever the wprsc is running and only one wprsc can be connected at a time.

[Shish2k]

Is there any open-source remote desktop that forwards the full desktop experience (not just pixels, but also audio, input devices beyond keyboard & mouse, with high refresh rates and low latency)?

[nicolasavru]

wprs: * does audio by forwarding a pulseaudio/pipewire socket, but it doesn't work so well for remote networks. I'd like to do something better in the future. * defaults to 60fps and can support significantly higher refresh rates, depend on your cpu and bandwidth. * aims to be low latency but prioritizes quality and so requires a good cpu and network connection to be low latency * should be able to handle (possibly with some additional code) any input devices wayland supports

[the8472]

pixels, audio, input devices should work these days. additional devices could be forwarded with usbip

high refresh rates and low latency are non-trivial problems because they require realtime video encoding which is less bandwidth efficient than offline encoding which means you need a network transport which can shovel high bandwidth data at low latency and gracefully handle packet losses. if you do it over the open internet you also need to adapt to variable bandwidth. all these things have been done, but someone would still need to tie all of it together in an open source solution. There's the sunshine/moonlight combo for remote game streaming, but it lacks other features for remote desktop use.

[M95D]

Aren't you asking too much? We barely have these on the local machine...

[Qwertious]

I think Arcan can do that ( https://arcan-fe.com/ ). And arguably Plan 9?

[aruggirello]

Xpra?

[dannyobrien]

Can anyone compare this to waypipe, which I've heard of more often for remote wayland execution.

[coppsilgold]

> Can anyone compare this to waypipe, which I've heard of more often for remote wayland execution.

https://github.com/wayland-transpositor/wprs#comparison-to-w...

[mijoharas]

One thing I couldn't find in the project. What does WPRS stand for?

[therein]

May be `wayland-pseudo-root-server`.

[nicolasavru]

xpra, but for wayland, and in rust

x->w, ra->rs

[tripdout]

How would this compare to a Wayland VNC server like WayVNC?

[froh]

vnc isn't rootless, is it?

[hongspike]

Cool project.

Maybe a dumb question but what rendering method does Wprs use?

[nicolasavru]

wprs doesn't do its own rendering, it passes through already-drawn image buffers from applications on the server side to the local compositor on the client side, which then composits/renders them however it wishes to.

[binkHN]

> Like xpra, but for Wayland, and written in Rust.