Hacker News Reader

Comment by magicalhippo | Hacker News Reader

Been hoping Wayland would help improve the sad state of remote desktop on Linux but from what I can see I'll have to way another 5+ years for something useful :(

I've installed KDE Neon on a NUC to play around with and I really like it a lot. But the lack of proper RDP server support is the primary thing keeping Windows on my primary machines.

Key features required:

- Ability to resume local session from remote client and later locally again.

- Ability to start session from remote client if no local session exist, and later resume it locally.

- Performance (framebuffer-delta ala VNC is no-go).

- Functional clipboard, so I can copy/paste between client and host. Text required, though images and files would be nice.

Anyway, really nice piece of code. Sure it's 500 lines but it seems quite straight forward.

View on HN

We haven't forgotten about you, but we could use your help if you want it done fast. We've made some important progress towards supporting this functionality recently. A protocol our people have been working on is currently undergoing standardization[0] which enables software keyboard devices. A similar protocol could enable software pointer devices. We also made another[1] protocol for efficiently capturing the contents of the display.

Plug all of these together and an RDP server is probably possible. Maybe a few weeks of work with FreeRDP for the motivated programmer. My email is in my profile, reach out if you want to make some connections and get started.

[0] https://lists.freedesktop.org/archives/wayland-devel/2018-Au... [1] https://github.com/swaywm/wlr-protocols/blob/master/unstable...

Great to hear! I did some minor contributions to FreeRDP before, but it felt a bit too daunting to contribute to this.

However as mentioned the Wayland code posted looked quite nice, and so did FreeRDP as I remember it, so I'll at least have a look and see if I can help.

Another issue with remote desktop (using VNC) on Linux is keyboard layouts (for inputting non-latin characters). With X server, the server passes a physical key number (keycode) and modifiers state (whether keys like Shift or Caps Lock are active) to the client and the client converts it to the corresponging character (keysym) using translation tables loaded earlier from the X server.

When you are accessing another computer remotely using protocols like VNC the local computer's keyboard layout can be different and it can produce characters not present in remote computer's translation tables. The VNC protocol itself transmits keysyms, not keycodes. So there can be a situation when there is no matching physical key number (keycode) for given character. So VNC servers like x11vnc had to modify translation tables on the fly and insert non-existing key into the tables and pass that key's number to X clients.

I wonder if this problem is solved with Wayland. As I understand, Wayland uses similar scheme and the compositor sends only a physical key number (keycode) along with the modifiers to the client and the latter does the translation. By the way, would not it be easier if the compositor did the translation itself?

The hack I described can also cause issues with hot keys. If I run application locally and it has a hotkey like Ctrl + S, and my keyboard has two layouts (English and Russian) then it will probably work with both of them because the application can bind the hotkey to physical key number. But when we send key presses remotely over VNC we send only a keysym (a letter code), not a keycode. If the remote server doesn't have Russian layout it is unable to guess what physical key was pressed and cannot recognize that I pressed Ctrl + S in Russian layout.

This feature list makes me think of Xpra. This uses X11, not wayland, though.

https://xpra.org/

"Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.

It gives you remote access to individual applications or full desktops.

On X11, it is also known as screen for X11: it allows you to run programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state.

It can also be used to forward full desktops, from X11 servers, MS Windows, or Mac OS X.

Xpra also allows forwarding of sound, clipboard and printing services.

Sessions can be accessed over SSH, or password protected over plain TCP sockets with or without SSL.

Xpra is usable over reasonably slow links and does its best to adapt to changing network bandwidth constraints."

xorgxrdp has been a great remoting option for X11 linux, check https://github.com/Microsoft/linux-vm-tools/blob/master/ubun...

Reply on news.ycombinator.com