Hacker News new | ask | show | jobs
by while_true_ 131 days ago
Still using X11, so no Noctia for me. Patiently waiting for somebody/someone to get remote desktop on Wayland. https://bugs.kde.org/show_bug.cgi?id=481912
3 comments

You probably know this already, but the problem isn't remote desktop into a logged-in session (krdp supports this) but rather logging in remotely into a headless server without a local session running. This is slightly more complicated because the login manager has to get involved and present its UI remotely. This is what that bug is tracking.

If you're happy to use Gnome with GDM as the login manager, remote headless sessions are supported already with gnome-remote-desktop: https://gitlab.gnome.org/GNOME/gnome-remote-desktop#headless....

Personally, I am fine with starting sessions via ssh, don't need extra remote login.
Depends on everybody needs obviously, but say you have your dev machine that is remote, and you want to connect to it from a laptop (for real-estate reason or just for working from everywhere you want), maybe you want everything on the same (remote) machine like browser, db, IDE, etc and access to it as a remote "desktop" not just an ssh session.

Of course cli tools would be enough for somebody who likes a full TUI dev environment (and for my own use cases that would be enough) but for some people I understand the need, and I feel it is a regression for them to not have it.

I'm not familiar with the space, but wouldnt something that streams the whole screen like a video (WebRTC or Moonlight and VNC works like this ) work here too as well, and would be universal? Wayland already supports screen capture (into a texture, at interactive framerates) fairly well.
I'd say the problematic part is not capturing the desktop but injecting controls into it. Proper universal support for simulated input is still missing.
I have not used Wayland specifically, but did do this for X11, Windows, Qt, too much stuff to count... It usually takes the form of an api call like

DispatchEvent(&MouseEvent{MOUSE_L, 1345, 3432});

It's almost literally always this

This is something implemented by the compositor, so with KDE this may be addressed by the new Plasma Login Manager. GNOME already supports this.