Hi everyone! (I was asked to report the feature request here to keep track of it, since it affects multiple desktop components under Wayland) I work at a research lab where we have very powerful servers connected to large data storage via a fast link. A lot of image processing as well as simulations are run on these machines, and it is incredibly convenient as people can take a working environment with them, and we also can share an expensive system extremely efficiently among many scientists. This is how it is set up currently: 1. The user ssh-tunnels into the server they want to connect to (RDP ports are not exposed) 2. A RDP connection to xrdp[1] is created 3. xrdp-sesman[2], the session manager module of xrdp, creates a session for the user after authenticating them 4. Plasma/X11 is started for that user session and renders to the remote display, instead of an actual display If a user disconnects, the session is kept running, and they get their session back as soon as they log in again. To terminate a session, the user has to log out explicitly. We are also utilizing Apache Guacamole[3] to make this process even more convenient so people can avoid installing any additional software and get almost the same experience as if they were using e.g. Remmina[4] to connect remotely. Of course, this complete workflow will not work at all when Plasma is running on Wayland, and XRDP, as the name suggests, is very X.org-specific (it is a fantastic tool though and serves us well). In the long run it would be great if we could switch to Wayland and keep using Plasma (surprisingly, if stripped down just slightly Plasma is not much heavier than light desktops, and users like to use the desktop's tools, e.g. the Dolphin filemanager). GNOME has a remote login in the works that looks similar to what XRDP provides and works on Wayland[5], but it would be fantastic if KDE could provide a similar feature. Having any XDG portals or interactivity will not work - as soon as the user is authenticated, they should get a session noninteractively and there should not be a need to stay logged in for the session to continue to exist (the servers are headless, and if needed, the admin can always set session resource limits for users via logind). A feature like this could for example be implemented by having a system service that takes incoming RDP connections and uses SDDM to authenticate and spawn a new Wayland session that can be interacted with using the transient seat protocol. Or if SDDM is too heavy, some lightweight service to handle the session authentication part. In any case, this will require non-trivial work on a lot of components, and there's likely multiple ways to implement this feature (and it wouldn't even necessarily have to be RDP-based, but we found the protocol to be a bit more efficient than VNC in testing). Thanks to everyone for the phantastic work on Plasma! Cheers, Matthias [1]: https://www.xrdp.org/ [2]: https://manpages.debian.org/testing/xrdp/xrdp-sesman.8.en.html [3]: https://guacamole.apache.org/ [4]: https://remmina.org/ [5]: https://wiki.gnome.org/Initiatives/Wayland/Remoting#Remote_Login
There's already the beginning steps toward this with KRdp: https://invent.kde.org/plasma/krdp
There’s also this effort by Google: https://mail.kde.org/pipermail/kde-devel/2024-February/002476.html with https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1
Yep, this is planned for Plasma 6.1, or maybe 6.2 if it slips.
*** Bug 479500 has been marked as a duplicate of this bug. ***
KRFB Desktop Sharing is an application that is part of the KDE software suite that shares the X11 or Wayland screen over VNC. It is mature and has worked well for me for a long time now. Maybe it will suite your needs as well - at least until KRDP is ready.
Arch has packaged krdp and it is now apart of the system settings. Can this be closed now?
No, krdp does not work at all like xrdp yet. The whole session management part is missing (unless that has changed extremely recently) and you basically need to have physical access to the remote computer to make krdp viable. Check out https://wiki.archlinux.org/title/xrdp and https://github.com/neutrinolabs/xrdp?tab=readme-ov-file#features
Same here. At my university, I currently run a headless linux terminal server for our students. It currently uses xrdp to offer Xfce desktop sessions, but I'd like to move to KDE sooner or later. RDP (not VNC) is a requirement. Most important things needed: * Virtual sessions, i.e. sessions for which no physical screen exists on the server. * Multiple users at the same time, each user having his own independent desktop session, running with his permissions and his environment. * User login and authentification using PAM. * If a user disconnects, his session should be preserved (except for sessions where the user explicitely logs out). If a user logs in, he should be reconnected to his existing session if such a session exists. Otherwise, a new session and desktop should be created for him. Moreover, perhaps compression should be configurable: The server has a high-bandwidth connection (10 Gbit), but no or a very low-end graphics card (typical for servers). So compressing 20 or 30 simultaneously connected user sessions could seriously suffer from CPU limitations (I don't know what xrdp does, but it shows neither bandwidth nor CPU load problems).
*** Bug 423577 has been marked as a duplicate of this bug. ***
I have been looking for the same thing coming from the VNC camp, but I think this applies equally here as KRFB and KRDP have the same scoping limitation when it comes to supporting this feature (they are to be launched from inside an already-running session). What KRFB does have, though I have not examined it, is the `krfb-virtualmonitor` utility which adds an output to an existing session using KWin's virtual backend. I will make an assumption that KRDP could utilise this backend as well (if anyone knows this is incorrect, please speak up.) For either app to be able to do what we seek -- launch a session with a virtual display as its primary (sole) output -- work is needed on the `startplasma_wayland` (or presumably now this will simply be `startplasma`) script. I have a report for this here: https://bugs.kde.org/show_bug.cgi?id=492285 There may be a chicken-and-egg flaw in this line of thought as my comprehension of the technologies involved is limited. If so, any clarifications are welcome.
(In reply to Robin Bankhead from comment #10) > I have been looking for the same thing coming from the VNC camp, but I think You might find the following blog posts by Arjen Hiemstra interesting (if you haven't already read them): https://quantumproductions.info/articles/2023-08/remote-desktop-using-rdp-protocol-plasma-wayland https://quantumproductions.info/articles/2024-06/krdp-plasma-61 I asked Arjen by email at ahiemstra [at] heimr.nl on June 27th if he could write another blog post about current status but with no answer so far. Btw, can anyone confirm if it's the right email address? Generally I have a feeling that KDE devs could be sharing more information with users on directions and work being done (No, "This week in KDE" is not enough as it just lists recent changes without showing broader picture or going in depth like above posts).
Another requirement for full remote desktop usage, i.e. full xrdp replacement: Support at least remote clipboard sharing and remote sharing of the client drives (filesystems) with the Microsoft Windows RDP client. xrdp already does this for virtual X11 sessions, we successfully use it. (at least for me, the other sharings, like sound sharing, printer sharing or usb device sharing, are not required).
(In reply to Klaus Kusche from comment #12) > Another requirement for full remote desktop usage, i.e. full xrdp > replacement: > Support at least remote clipboard sharing and remote sharing of the client > drives (filesystems) with the Microsoft Windows RDP client. > xrdp already does this for virtual X11 sessions, we successfully use it. > > (at least for me, the other sharings, like sound sharing, printer sharing or > usb device sharing, are not required). Something you might want to look into as a workaround: Weston has an RDP backend (uses FreeRDP)[1]. In theory you could run that (using the kiosk shell to be totally unobtrusive), and run the Plasma session nested inside that. The Plasma session did work nested in Weston's (default) DRM backend; I tried its VNC backend but could not get it to work at all; I did not try the RDP backend, but if it works at all it should work for this technique. (I did have success nesting Plasma inside Cage, and using WayVNC. The Plasma session works well, though Firefox causes some input dysfunction.) Not wishing to drag this offtopic but thought the info might be helpful. [1] https://man.archlinux.org/man/extra/weston/weston-rdp.7.en
(In reply to Robin Bankhead from comment #13) > (In reply to Klaus Kusche from comment #12) > > Another requirement for full remote desktop usage, i.e. full xrdp > > replacement: > > Support at least remote clipboard sharing and remote sharing of the client > > drives (filesystems) with the Microsoft Windows RDP client. > > xrdp already does this for virtual X11 sessions, we successfully use it. > > > > (at least for me, the other sharings, like sound sharing, printer sharing or > > usb device sharing, are not required). > > Something you might want to look into as a workaround: Weston has an RDP > backend (uses FreeRDP)[1]. In theory you could run that (using the kiosk > shell to be totally unobtrusive), and run the Plasma session nested inside > that. Thank's for the hint. As far as I can tell from the documentation, weston-rdp seems to lack the same features as Krdp: - It does not provide any user and session management: It does not authenticate RDP logins using PAM and it does not switch session ownership to the RDP user. - It does not seem to provide persistent sessions. - I does not seem to provide clipboard and drive sharing with the client. (as far as I know from xrdp, the server side of drive sharing is quite complex, requiring a fuse filesystem implementation).
Just some idea: Why not write another plugin for xrdp instead of reinventing the wheel? Xrdp handles the user authentication, it handles the session management, it handles most parts of the RDP protocol including compression, it handles most of the clipboard and local drive sharing, it handles audio redirection, ... It would just require a driver plugin similar to xorgxrdp to connect the xrdp server to the wayland compositor.
... and it seems to be work in (slow) progress, see https://github.com/neutrinolabs/xrdp/issues/2637
There has been some progress with KRdp gaining PAM support: https://invent.kde.org/plasma/krdp/-/merge_requests/123 We don't yet have things wired up to handle all the auth methods that FreeRDP+PAM support, I think.