4 ms·

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 re

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-August/039237.html https://lists.freedesktop.org/archives/wayland-devel/2018-Au... [1] https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable...

magicalhippo 8y ago
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.
codedokode 8y ago
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.

magicalhippo 8y ago

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.

codedokode 8y ago

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.