So.. Lets talk about Wayland (long term feature request and discussion)

[t8d7]

As we know, Wayland is not network compliant, and leaves most of it's rendering to it's clients. Xorgxrdp's method on adding in a module to xorg provide a virtual display won't work with Wayland, because wayland doesn't have a rendering api.

From https://wayland.freedesktop.org/faq.html

Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.

So, wayland clients like Weston and Mutter now carry the Rendering API.

With that said, if we were to approach Wayland, would it be better to provide a module for Weston/Mutter (sounds easier), or be a wayland client ourselves and provide a common API for other wayland clients (depending on what it entails to be a wayland client, could be quite a lot of work).

I don't know if being a wayland client would require us to have our own render, or if there is a common render wayland client existing that is (or could be) implemented by others.

I went down a rabbit hole I'm not entirely sure is the correct one for this conversation.. but could at least start one.

[moobyfr]

IIRC, there is already some code in weston for a RDP backend:
https://www.phoronix.com/scan.php?page=news_item&px=Weston-RDP-GL-Accel

[t8d7]

That's pretty great. I could dig into it to try implementing it in xrdp, but this is around 2 months old. It's probably wise to let it mature out of devel. As a path forward, because Weston was nice enough to start the precedent on implementing an rdp compositor, we can ask the Mutter team to follow suit, and that gives us a few desktop environments for virtually free.

[ohault]

This issue is becoming pretty important.

[rstanuwijaya]

Seems like will require a lot of work to make this happens. Most likely it will need to support a different backend than current xorgxrdp to connect a headless wayland session to the xrdp server. Even more, a separate backend might be needed for each DE (gnome, kde, and wlroots).

Nevertheless, considering many distros are deprecating Xorg, I'm really looking forward for the devs to support this feature in the future.

[matt335672]

I'll add some of my thoughts here, having been prompted by @HubKing in #2840.

I'm far from an expert in this area. I'd appreciate anything below which requires correction to be pointed out. I'd rather provoke a discussion though rather than saying nothing at this point.

Main points:-

• We're not the only project which needs an architectural solution for this - see this discussion on TigerVNC.
• Rather than choosing to use the reference compositor called Weston, desktops seem to be picking their own (GNOME : Mutter, KDE : kwin). So there are many compositors out there. It's not clear to me how much compositors can be interchanged, or whether nested compositors are possible (see the TigerVNC thread linked above).
• According to the Arch Wiki, most compositors require KMS.
• There's an interesting Linux kernel module called VKMS which might allow a virtual display to be created which could run a compositor.

By this stage, there are a lot of warning bells ringing:-

1. It seems unlikely that remote desktop use-case has been considered in the Wayland design (again, see the TigerVNC thread). There are significant implications for performance here if not running on the machine console, maybe by using VKMS or nesting compositors.
2. This is all mostly Linux-specific at present. xrdp works on other platforms too, notably FreeBSD. On platforms without systemd, xrdp actually works better as multiple sessions per user are available.

In other words, it's a bit of a mess at the moment.

It's not clear (to me at least) how this will pan out. My own thinking is to keep an eye out on what the TigerVNC crowd are up to. Red Hat are, or used to be a sponsor of TigerVNC, so if there's any interest in the virtual desktop market, I'd expect TigerVNC to get a steer before we could.

[Nexarian]

I agree with everything @matt335672 said. I think @jsorg71 has ideas about how to get Wayland working with XRDP. I wanted to link the two actual commits where GNOME dropping X11 support is being discussed:

• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99

Also do note that, like all media, tech media picks things that are most likely to be sensationalized. The fear we all have is that all Linux distros drop X11, and then XRDP is utterly dead. Let's put that part of our fear aside and recognize that because remote desktop is popular and useful, it is unlikely we'll be left out in the cold like that. That being said, the problems with remote desktop are sufficiently surfaced as a blocker for "everyone move to Wayland" which is good, but it doesn't guarantee that at some point the powers-that-be will decide "Everything works well EXCEPT remote desktop, and the pros of moving outweigh the cons, we can't support everyone." I've seen big organizations make decisions like that, so we need to be prepared. Note that the comments on some of these merges have been silenced because it was so noisy, so there is sufficient reason to believe that XRDP and Gnome and X11 will be around for many years to come.

One suggestion I have is to work on helping https://gitlab.gnome.org/pnowack and https://gitlab.gnome.org/jadahl with the technologies behind gnome-remote-desktop, and then we can share each other's code. My AVC444 and YAMI work is along this path (and is generically sharable between XRDP and GRD), but it's a tiny tiny piece of that puzzle.

The big action-item to try to see if we can throw out weight behind is this one: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/90, if anyone reading this has free cycles and/or is looking for a good and hard project to get into open source, this is definitely one! That is how I myself got into this. I picked something I wanted, and banged my head against the wall until I made a useful contribution.

However, that will only "fix" gnome, and there are many others. Having each window manager have it's own RDP compositor would be a maintenance nightmare, and leave lots of lesser-known window managers like i3 or Cinnamon in the dust. The hope would either be that getting this working on Gnome provides a footprint/feedback-loop for other window managers to do this or it creates pressure for an all-Wayland solution.

At this point I generally agree with Matt that provoking a discussion and a paper trail is critical here.

[jsorg71]

I'd have to agree with Tiger VNC guys. Wayland is not designed for remote desktop, multi session, or non GPU use cases. It's a composite only display system. It's designed by the xorg guys to simplify.
I think we can support this use case but you will have to use a GPU or more CPU power it use it with the same experience quality. MS even turns of composite desktop with the multiple session terminal servers but Wayland has no non composite options.
Nexarian, me, and others have been working on GPU support in xrdp which can be used here.

todo, unknowns here

1. clipboard in chansrv would need to change.
2. RAIL in chansrv, how would that even work? Since wayland is build into the window manager, is this possible?
3. sesman should only start KDE or Gnome, or whatever window manger that has wayland support. no xorg or waitforx.
4. wup would be used instead of xup. I think wup would just use pipewire to get a desktop stream.

Core xrdp is not dependent on X11 even though the x in the name. The x was meant to mean whatever. The backend, Xorg with xorgxrdp and chansrv are display dependent so they would need to change.

If Wayland ever gets there, lets support it. Can we even run native Firefox, Chrome and OpenOffice on Wayland without XWayland? It is taking forever....

I think the Xorg use case will remain for a very long time. The 50+ users on one server, traditional terminal server, legacy apps.

[nielsdg]

Hi, someone pointed out this thread to me to see if I can shed some light here about what's possible in the Wayland ecosystem currently and what is in progress. (for full disclosure, I work at the RHEL GPU team, which has done some big efforts over the last years in preparing the move to Wayland)

For a lot of the things that xrdp needs to properly function on a Wayland system, these are already available today in the broader Wayland ecosystem and that are agnostic of the compositor/DE in use. Most of these are actually exposed to applications through portals, a set of cross-desktop D-Bus interfaces which can also be used within containerized apps such as flatpak, if they want to.

Most of all, a project like xrdp would implement its remote desktop logic with 2 of these portals:

• the RemoteDesktop portal. This portal allows you to inject events like mouse events, keyboard presses etc
• the ScreenCast portal. This portal allows you to read the contents of the desktop (or a specific window). These textures will be passed on to you through pipewire which you can then send over the network with RDP/VNC

You can find an example of how to use these portals in Python here: xdp-remote-desktop.py (note that you might need some specific packages installed for this). It should show a window which screencasts your current desktop and presses the <Super> button.

Now, there is one final part that is still WIP and which ties into the aforementioned gnome-remote-desktop issue: the ability to start a headless session. GNOME is currently experimenting already with an implementation for this (see for example gdm!180), after which we can hopefully figure out what the API should look like, and would allow us to propose a common API as well.

So while Wayland isn't totally ready yet; it should be possible already to start experimenting with some of these things while we're working things out further, especially on starting a session.

Feel free to let me know if you have any questions or remarks! :-)

[matt335672]

Thanks very much for adding that @nielsdg. It's very interesting, particularly as it gives us a way to proceed which is compositor/DE-agnostic.

[Nexarian]

I've been chatting with @pnowack in the FreeRDP gitter and he had a few tips for us that I'll capture here for future reference:

• Add Headless service for GRD
• Add graphical remote login for GRD

The Remote Desktop Portal API exists since half a decade. You just need to use it. Several parts from it were inspired or copied from GNOMEs private API, that g-r-d uses. This for example applies to the whole clipboard part, virtual monitors, and the lock keys. So, it is kinda true, that GNOME defines the direction here.
However, there is some effort to standardize the efforts eventually:

https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1