With this blog I would like to introduce KRdp, which is a new library implementing the required glue to create a server exposing a KDE Plasma Wayland session over the RDP protocol. It also contains a command-line based server which will allow remote clients to control the current Plasma Wayland session.
It would be nice to implement a virtual monitor funcionality as an extension of remote desktop.
This would allow the use of a tablet/phone/tv/another pc as an extra monitor when needed.
Thatâs one of the planned features. In fact, screensharing already supports virtual monitors, we âjustâ need to hook the same support up for remote desktop.
Link to the flatpak goes to the mirrorlist, might want to update it and take .mirrorlist off the end so it just downloads for users.
Hi,
The KDE vnc tools are well design, ui && ux, congratulations to the dev.
please, have a look here to improve krfb
So, is this âvirtual monitorâ the same thing as âwireless displayâ as in https://askubuntu.com/questions/1017249/samsung-tv-mirror-screen ? (I think itâs miracast?)
If itâs different thing, is there then any plans to add support for casting a KDE/plasma desktop wirelessly to a smart-TV?
KRdp handles this slightly differently due to this - it will ask for remote desktop permissions on startup and then reuse that for each incoming connection. That said, it is a workaround for lacking persistence in xdg-desktop-portal, which was recently addressed upstream. Once the KDE implementation also supports this, youâd have the option of remembering the permission.
I donât have any plans for that myself. As far as I know, the wireless display stuff is mired in proprietary protocols and closed source implementations. I seem to recall there is an open source alternative to Chromecast at least, but donât know the status of that.
Hi,
thanks for your answer, you mean it will be solve in the future? nice 
for the moment I unfortunately donât use wayland on my devices due to the problem I explain in my detailed post, the "Remote control requestedâ pop up on start with the share devices
I ssh the devices with Konsole, for sure, but for some software you canât only ssh the devices, you have to remote the devices with a vnc software.
krdc and krfb are 2 nice softwares, well design, UI and UX are good, congratulations.
No problem to remote a windows or android device with krdc.
No problem to share you desktop with krfb and remote your linux device with a windows or android remote software.
I am having some trouble getting it work on arch right now but i guess it is to be expected since itâs still in alpha.
One question, will this support unattended access in the future?
Like the xrdp service, which starts on system boot and creates itâs own âhiddenâ session when you connect.
Iâve been testing it on Arch myself, so it should work there, any specific issue youâre running into?
One question, will this support unattended access in the future?
This has been asked before and will be something we will look into at some point. Itâs not going to be easy as it will most likely also require login manager integration, so donât expect it to arrive soon.
Hmm i guess it was a problem with the client. wlfreerdp gives me an empty window, thincast (flatpak) does not work, but remmina (pacman) works until it stops working with this error reported by krdp:
14:44:21:647] [2:43] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_ACTIVE - peer_recv_pdu() fail
[14:44:21:647] [2:43] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
org.kde.krdp: Unable to check file descriptor
org.kde.krdp: Closing session
Good to know that itâs in the plans. Unfortunately i need unattended access and the option to show the lock screen when connected for this to be viable for me.
Still I am very happy that RDP support is being worked on.
Thank you for your hard work, looking forward to future developments.
wlfreerdp in general is not in a great state, for me it starts with a size of 0x0 and resizing it makes it crash. So I tend to use xfreerdp instead, which works fine.
Hi. When i run
" flatpak run org.kde.krdp -u {username} -p {password}"
I have
Could not find certificate and certificate key, generating temporary certificateâŚ
Temporary certificate generated; ready to accept connections.
org.kde.krdp: Initializing Freedesktop Portal Session
org.kde.krdp: Unable to listen for connections on QHostAddress(ââ) 0
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path â/org/freedesktop/portal/desktopâ interface âorg.freedesktop.portal.Remo
teDesktopâ member âNotifyKeyboardKeycodeâ: Marshalling failed: Invalid object path passed in arguments
qt.dbus.integration: QDBusConnection: error: could not send message to service âorg.freedesktop.portal.Desktopâ path ââ interface âorg.freedesktop.portal.Sessionâ member âCloseâ: Object pat
h cannot be empty
org.kde.krdp: Closing Freedesktop Portal Session
org.kde.krdp: Unable to listen for connections on QHostAddress(ââ) 0
Seems like itâs not allowed to listen on the required address/port, make sure the flatpakâs permissions are correct. It will try to listen on the IP address 0.0.0.0, or in other words, all interfaces, port 3389 by default.
Will a head-less non-shadowed session use case be supported?
By default on XRDP and on Windows, a remote session does not have to be locally authenticated. When a remote user connects, they are presented with a login screen and afterwards any other sessions by that user are disconnected including the local session. RDP of course also supports shadowed sessions where both the remote and local screens are synchronized.
With both KDE and Gnome deciding to use RDP instead of RFB (VNC) for remote desktop connectivity on Wayland, I see however that both are implementing it in a shadowed approach. This mirrored approach is more typical of VNC solutions.
Will behavior similar to XRDP and Windows be supported in the future?
Super pumped that KRDP is in alpha! Looking forward to a great product. Thank you for the hard work!
I have fresh installed Kubuntu (23.04) and Arch in HyperV VMs and tried to install the flatpak file I downloaded using the listed command:
flatpak --user **--install** krdp-alpha-20230808.flatpak to which I receive:
error: âDownloads/krdp-alpha-20230808.flatpakâ is not a flatpak command. Did you mean ââinstallationâ?
So Iâm assuming that the command should be:
flatpak --user **install** krdp-alpha-20230808.flatpak
To which I receive:
error: The application org.kde.krdp/x86_64/master requires the runtime org.kde.Platform/x86_64/6.5 which was not found
Both distros result in the same error.
Was hoping you could point this novice in the right direction to solve this error.
Edit: Solution =
flatpak install org.kde.Platform/x86_64/6.5
Got confused since
flatpak search org.kde.Platform/x86_64/6.5
results in
No matches found
I think you might be running into some of the funkyness of the flatpak command syntaxâŚI had to trial and error it myself, but I think for installing and searching, you would need to leave off the architecture and version info and just use org.kde.PlatformâŚsee my searching attempts below:
host:~> flatpak search org.kde.Platform/x86_64/6.5
No matches found
host:~> flatpak search org.kde.Platform
Name Description Application ID Version Branch Remotes
KDE Application Platform Shared libraries used by KDE applications org.kde.Platform 6.5 flathub
KDE Application Platform Shared libraries used by KDE applications org.kde.Platform 5.15-22.08 flathub
KDE Application Platform Shared libraries used by KDE applications org.kde.Platform 5.15-21.08 flathub
QtSNI A Qt platformtheme plugin that offers a flatpak-compatible SNI tray icon org.kde.PlatformTheme.QtSNI 5.15-21.08 flathub
QtSNI A Qt platformtheme plugin that offers a flatpak-compatible SNI tray icon org.kde.PlatformTheme.QtSNI 5.15 flathub
QtSNI A Qt platformtheme plugin that offers a flatpak-compatible SNI tray icon org.kde.PlatformTheme.QtSNI 5.12 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 6.5 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 6.4 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 6.3 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 6.2 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 5.15-22.08 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 5.15-21.08 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 5.15 flathub
QGnomePlatform Qt Platform Theme aimed to accommodate GNOME settings org.kde.PlatformTheme.QGnomePlatform 5.12 flathub
Maliit plugin for SailfishOS Keyboard plugin used in Sailfish OS for Flatpak applications org.kde.PlatformInputContexts.MaliitSailfishOS 5.15-22.08 flathub
Maliit plugin for SailfishOS Keyboard plugin used in Sailfish OS for Flatpak applications org.kde.PlatformInputContexts.MaliitSailfishOS 5.15-21.08 flathub
Maliit plugin for SailfishOS Keyboard plugin used in Sailfish OS for Flatpak applications org.kde.PlatformInputContexts.MaliitSailfishOS 5.15 flathub
Maliit plugin for SailfishOS Keyboard plugin used in Sailfish OS for Flatpak applications org.kde.PlatformInputContexts.MaliitSailfishOS 5.12 flathub
I have the same result when issueing the krdp command. I have set permissions for krdp using flatseal i.e. granting permissions for dbus. I have no firewall installed. Could the problem be that my vmconnect session has port 3389 already open? If not any hints on what permissions should be available and/or other ways I might be able to troubleshoot the problem. Thanks
Could the problem be that my vmconnect session has port 3389 already open?
Oh that is quite likely to be the cause then yes. Try passing some other port using --port to the flatpak run command and see if connecting on that port works.