[HN Gopher] Wprs - rootless remote desktop for Wayland (and X11,...
___________________________________________________________________
Wprs - rootless remote desktop for Wayland (and X11, via XWayland)
applications
Author : happy-dude
Score : 156 points
Date : 2024-05-09 23:02 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dannyobrien wrote:
| Can anyone compare this to waypipe, which I've heard of more
| often for remote wayland execution.
| coppsilgold wrote:
| > 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...
| dsp_person wrote:
| 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 wrote:
| 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.
| coryrc wrote:
| AFAIK the only way is to always run a remote X server (i.e.
| Xvnc) and always connect to it, even when sitting at the
| local computer.
|
| Maybe you could do something with dpms but that leaves the
| keyboard active still.
| XorNot wrote:
| Yeah see this has always been where I think Windows
| dominates Linux.
|
| Going from local to RDP to local feels seamless and secure.
| I wish we could get that experience on Linux.
| doubled112 wrote:
| Does GNOME's new RDP server get us any closer to this
| dream?
| nicolasavru wrote:
| 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.
| metadat wrote:
| 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.
| shmerl wrote:
| 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.
| pxc wrote:
| 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'.
| metadat wrote:
| Xpra can also stream rootless single windows, to html5 or
| other Xpra clients. I found it annoying with a bunch of sharp
| edges compared to getting a full desktop, though. You must
| have a different use-case :)
| pxc wrote:
| I used to use WinSwitch instead of just plain Xpra, which
| was nicer. I think it may be unmaintained now.
| JackeJR wrote:
| Use this to get the functionality without setting up a
| windows server instance
| https://github.com/kimmknight/remoteapptool
| philsnow wrote:
| Rootless is a good UX especially if you use a tiling window
| manager locally, because of the cognitive dissonance when one
| of your tiled windows is a remote fvwm desktop or similar.
|
| Likewise, I think the overwhelming majority of tiling window
| managers are very keyboard-oriented, so if you use the same
| or a similar one on a remote rooted vnc session, there will
| be conflicts between local and remote keybindings unless
| you're really careful about it. Better to just let the local
| WM manage everything.
| prmoustache wrote:
| 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.
| erremerre wrote:
| xrdp on raspberry and ssh bitvise in windows, it is my way to
| use headless raspberry with graphic interface, and it works
| absolutely fine.
| pmontra wrote:
| 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.
| tripdout wrote:
| How would this compare to a Wayland VNC server like WayVNC?
| froh wrote:
| vnc isn't rootless, is it?
| billpg wrote:
| "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.....
| kaba0 wrote:
| 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.
| aragilar wrote:
| I'm not sure this is true for apps that commonly forwarded
| though? My impression is tk for example uses xlib heavily and
| so has much better behaviour over the network than GTK, and
| the majority of apps I've seen where the audience uses X
| forwarding commonly seem to be using tk.
| epcoa wrote:
| Somebody in a thread the other day lamented how almost
| always X clients are sensitive to network drops. And the
| suggestion is to use Xpra! (It's "like tmux") Xpra doesn't
| forward X though, it is a rootless X server that then
| forwards everything as compressed bitmaps like VNC. It's a
| nice homage to how awful X is even at its one oft purported
| benefit around here.
|
| X11 network transparency is a pretty poor technology, one
| can go through each of the "Fallacies of Distributed
| Computing" document to understand why.
| StillBored wrote:
| "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."
|
| While true for things like firefox, and GUI libs that think
| they know better than the host, its not ideal, and entirely
| dependent on the language/toolkit being used. And it's a side
| effect of X being too low level and not having a standard
| widget toolkit as one gets on Windows/mac. On those
| platforms, it's not just the widgets but file open dialogs
| provided by the OS, skinned consistently across applications,
| and things like global keyboard shortcuts (ex, copy/paste)
| tend to work close to 100% of the time.
|
| If one goes back to the win3.x/macos7/etc timeframe it was
| almost unheard of for applications not to follow system wide
| color themes. WHich is why "dark mode" 1995 worked more
| reliably than it does on any platforms today. Today, doing
| something like inverting to a "dark" theme is suddenly
| something that each application hacks in, and when the OS
| provides a theme option, the applications frequently don't
| follow it correctly/etc.
| znpy wrote:
| 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...
| delusional wrote:
| 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.
| StillBored wrote:
| No, way, that can't be right....?
|
| Much of the reason RDP and WebGL work so well is that they
| send the raw command stream/assets to the rendering side
| rather than continuously sending a stream of compressed frame
| buffer data. RDP, for example, can send the raw video stream
| being played, or recompress it, and send it rather than
| trying to render it to the screen and then recompress the
| resulting output, which is what you get with something like
| VNC. Thats why its completly possible to stream video over
| RDP on links that choke up pretty much everything else.
|
| For an incredibly wide range of things, high level GUI
| command streams are going to be significantly less data
| intensive than the resulting rendered and compressed video
| stream. AKA the GUI command stream is itself an applicaiton
| specific compresion algorithm. A draw line command can affect
| tens of thousands of pixels around the line due to
| antialiasing, and that won't ever compress as well as the
| drawing (x,y,brush). So while sending a bunch of textures,
| shaders, and the like might be a huge initial overhead, its
| going to quickly pay for itself over the lifetime as used in
| something like a game/etc, particularly at high resolution
| and refresh rates.
|
| Never mind, of course, the overhead of doing a bunch of local
| rendering, compressing it, sending it over the wire, and
| doing video playback. If it weren't for hardware video
| encoding/decoding, it would essentially be a case of pegged
| CPUs on both sides just doing graphical updates.
|
| This may just be one of the issues with Wayland compositing;
| over time, I've become more convinced that the loss of
| standard GUI widgets and a serializable drawing stream might
| be a huge mistake.
| akvadrako wrote:
| RDP hadn't worked that way for years.
|
| https://techcommunity.microsoft.com/t5/security-
| compliance-a...
|
| And we do have hardware encoding / decoding. The latency is
| quite reasonable, like 15ms in total, so modern solutions
| like parsec work for any app, including games and CAD.
| epcoa wrote:
| 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.
| IshKebab wrote:
| > 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.
|
| Are there? I don't think anyone seriously thinks X is the way
| forward do they? They just don't like some of Wayland's poor
| choices, which I think is fair.
| immibis wrote:
| As someone who actually researched X I don't really see the
| problems with it. Xorg has some, but the X11 protocol seems
| to have fewer problems than the Wayland protocol.
|
| For instance it already supports mixing windows with
| different colour modes, which can be used for HDR.
| epcoa wrote:
| X11 the base protocol is wholly unsuited to the needs of
| modern display systems, full stop. Moreover, the base
| security profile is also completely outdated. Now you can
| always extend the protocol, and continue to use the
| myriad extensions over the years like XRENDER, DBE, DnD,
| etc, etc (or paper over deficiencies with contraptions
| like NX/x2go and Xpra). The question is what useful
| benefit is being provided by that miniscule still
| relevant base that justifies its existence along with the
| other legacy cruft and baggage.
|
| "X11 seems to have fewer problems than the Wayland
| protocol" is too vague to be cogent so I will not address
| it. But the argument is more than just X11 vs Wayland, as
| Wayland isn't the only alternative display system nor is
| it the only answer to network transparent remote display
| technology either. "Wayland sucks" really is not a valid
| response to "X I don't really see the problems with it."
|
| True, X11 the wire protocol isn't the most horrible thing
| in a world where SOAP exists, but in practice the latency
| story is overall bad. Yes you can pipeline with xcb and
| not with Xlib, so a _few_ of the rehashed latency issues
| by the peanut gallery are false attribution, but the core
| protocol still makes many basic operations inherently
| synchronous and strictly ordered, many just a consequence
| of how the X server manages state. There are fundamental
| architectural issues.
| immibis wrote:
| I don't think that using extensions to support new
| features is much of a problem - if you disagree with that
| then you'll have to admit that Wayland has an even bigger
| problem because it requires even more extensions.
|
| X11 doesn't inherently require that many round trips.
| Xlib does, because Xlib is bad. But, for example, clients
| choose their own object IDs, so they don't need round
| trips to find the IDs of newly created objects. Of course
| it requires a few round trips to do anything, but that is
| also true of Wayland. The complaint was about excessive
| round trips, not a few.
| epcoa wrote:
| > I don't think that using extensions to support new
| features is much of a problem
|
| You are arguing issues that were not even raised. Read
| 1st para more carefully, especially the last sentence.
|
| > X11 doesn't inherently require that many round trips.
| The complaint was about excessive round trips,
|
| Why do NX, x2go, and xpra exist if the X11 protocol over
| high latency networks is such a peach? It's lovely that
| clients don't need to round trip for IDs, but this is
| like saying the Trabant is one the best cars ever made
| because it possesses a steering wheel (and fwiw Wayland
| has an even more flexible client side ID allocation). As
| already said, just because something isn't horrible
| doesn't mean it's any good either. There is so much other
| typical crap that has to go on that is suboptimal:
| property requests, chatty window management, inefficient
| frame synchronization, inefficient event handling. Even
| if certain operations don't require a lockstep roundtrip,
| overall chattiness also contributes to latency.
|
| > Of course it requires a few round trips to do anything,
| but that is also true of Wayland
|
| The Wayland project is not perfect (it is implementing de
| facto X12 and a large undertaking in a computing world
| much more complicated both technically and financially
| than 1986), but it's patently ridiculous and just
| misinformed to imply the core protocol doesn't address
| some fundamental shortcomings of X11. Meanwhile I thought
| it should be obvious that dispensing with the baked in
| network transparency of X11 was done as a conscientious
| choice not because a bunch of smart people just "forgot".
|
| From https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-
| x-server..., someone with actual skin in the game.
|
| "So here's the thing: X works extremely well for what it
| is, but what it is is deeply flawed. There's no shame in
| that, it's 33 years old and still relevant, "... "Though
| the code happens to implement an unfortunate
| specification,"
| npteljes wrote:
| 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 wrote:
| I love Spice too but it has been deprecated for a while now.
| https://access.redhat.com/documentation/en-us/red_hat_enterp...
| npteljes wrote:
| Oh no. Thanks for passing the news along.
|
| EDIT: just an FYI for everyone interested, here's a bit of
| info about how Proxmox is handling it. TL;DR Spice is still
| at least maintained until 2029, so it's not going to just go
| away anytime soon.
|
| https://forum.proxmox.com/threads/plans-for-spice.113339/
| bbarnett wrote:
| That's redhat deprecating spice in its releases.
|
| That doesn't mean spice is being deprecated.
| spqrr wrote:
| 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.
| Yeroc wrote:
| 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.
| hongspike wrote:
| Cool project.
|
| Maybe a dumb question but what rendering method does Wprs use?
| nicolasavru wrote:
| 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.
| Shish2k wrote:
| 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)?
| M95D wrote:
| Aren't you asking too much? We barely have these on the local
| machine...
| aruggirello wrote:
| Xpra?
| the8472 wrote:
| 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.
| nicolasavru wrote:
| 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
| binkHN wrote:
| > Like xpra, but for Wayland, and written in Rust.
| mijoharas wrote:
| One thing I couldn't find in the project. What does WPRS stand
| for?
| therein wrote:
| May be `wayland-pseudo-root-server`.
| nicolasavru wrote:
| xpra, but for wayland, and in rust
|
| x->w, ra->rs
___________________________________________________________________
(page generated 2024-05-10 23:01 UTC)