What’s Happening In KDE Remote Desktop – Improved Unattended Mode and More

Remote desktop has been one of the weaker areas of the transition to Wayland. There's a lot of software written exclusively for X that has a direct Wayland equivalent. Within KDE, we already have a Plasma-native RDP and VNC solution for Wayland, but we're aware that it hasn't yet reached the level we want it to.


This is a companion discussion topic for the original entry at http://blog.davidedmundson.co.uk/blog/whats-happening-in-kde-remote-desktop-improved-unattended-mode-and-more/
17 Likes

HUZZAH! This is very exciting news. Thanks to David for getting the word out to an audience salivating for news on this, and to himself and all colleagues for all the work bringing it to this stage.

The above mode isn’t so great when there’s just you. If I’m connecting to my home PC from a tiny laptop, it’s very unergonomic to have the remote screen be larger than my laptop display and have to scroll around it.

THIS!

Additionally if my remote PC is in an office, I don’t want my colleagues to see my cursor moving around clicking on windows when I’m not there.

THIS TOO! Honestly it might go without saying but it has been unaddressed for so long that I was starting to wonder if I was a total aberration for having these priorities.

Best of all, after the remote session is closed and the user logs back into the host machine, all their windows return to where they were last positioned on the host setup.

This is cool as hell, and something I don’t think we had anywhere before (if it works… sounds a bit like the Wayland session-restore protocol which Nate & co told us was going to need app adoption which would take years).

The “What’s next” section delivers some sobering news on multi-user (will be devastating for at least one very invested user here I know) but is at least to be acknowledged for setting expectations. I guess the 6.8 feature-freeze moment is why this blog happens now, when what will or won’t make the cut is known.

The ambition towards standardisation (which David already expressed in these forums) is very encouraging to hear. No illusions that it will be easy, but in the Wayland world where unfortunately a lot of competencies of the desktop have become horribly balkanised, I’m glad there is wide recognition that remoting is one of those things that ideally should be a “common good” that reaches across setups.

I’m going for a lie down, it’s all a bit much!

3 Likes

this is fantastic news! :slight_smile: It is exactly what I was missing in Plasma and it was forcing me to use Gnome instead

One question, this will be a “separate session” or the same “active session” but just showing the lock screen? cause it would be great if it is a separate session so the machine I’m taking control can use the power settings as idle and power off the monitor, instead of just my lock screen active while I’m taking it with RDP

Thank you so much for your hard work, I’ll be waiting for 6.8 to check it out!

1 Like

If I understood David’s post correctly, the difference is that in the case of the remote session it rearranges existing windows to fit the constraints of the remote client and rearranges them back on disconnect.

So this is essentially just between the window manager and the remove client interface.

Session restore requires app support because this involves windows which are potentially new to this session, e.g. a browser restarting and wanting to have its windows spread out like before.
In this case the app needs to tell the window manager which window is which of the ones it saved before.

2 Likes

OK, that makes sense. I thought this would be in the context of it being separate sessions baremetal vs remote, but it sounds like it is treated as all one continuous session, transitioning between baremetal and remote at will?

I’m not totally sure I’m grokking the model here but if that’s correct then it very definitely is cool as hell, and novel as far as I’m aware. It would suit me down to the ground.

As I read the post, I interpret it that it’s treated like a screen reconfiguration - when the remote client connects, KWin treats any active physical screens as disconnected, and a new virtual screen (with the remote client’s dimensions) as connected. Then, when the remote client disconnects, the inverse happens.

If that’s correct, then KWin could say “where was window A when it was on screen 1? Put it back” when switching back to the physical display(s).

1 Like