KRFB on Wayland, Have to confirm "Remote control requested"

[nl.smart]

SUMMARY

---

I have to confirm the share screen on the devices running krfb on Wayland.
“Remote control requested” pop-up appear on the shared desktop screen, even if I select “Enable Unattended Access” with krfb on Wayland.

---

STEPS TO REPRODUCE

1. In system settings → startup and shutdown → Login Screen (SDDM) → Behaviour → automatically login with session Plasma (Wayland)

2. In system settings → startup and shutdown → Autostart → add krfb

3. Launch krfb and Select “Enable Unattended Access” to allow the unattended Access.
   

   

4. Reboot your device.

OBSERVED RESULT
On boot device I have to allow the access to the remote computer even if I selected “Enable Unattended Access” running krfb on Wayland, this pop-up appears on screen :

Remote control requested pop-up :

EXPECTED RESULT
Remote the computer sharing a desktop with krfb on Wayland without to click on the pop-up “Remote control requested”.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106
Qt Version: 5.15.9
Krfb Version : 23.04.1

ADDITIONAL INFORMATION

============

KDE KRFB Wayland :

Hi,

I’m very pleased & thankful for your effort.

Krdc and krfb are 2 nice kde product, with a fully GUI setup !

A new feature appears with krfb on Wayland, "Remote control requested”, good idea to improve the remote computer security, but not practice for a home usage and remote the x86 or arm devices build for home server without screen, keyboard and mouse.

With “Remote control requested”, I have to confirm the share screen, but I can’t because no screen, mouse and keyboard are plugged on my devices running krfb on Wayland. Same issue on arm devices running Wayland.
X11 don’t provide this feature, I start krfb on X11 with the Autostart software on startup and then I remote with krdc the devices sharing their desktop with krfb on X11, really simple and practice.

How to avoid this new krfb Wayland feature ? I mean the pop-up showing “Remote control requested”.

Is it a krfb on Wayland bug ? which don’t take the function “Enable Unattended Access”, no issue like this with krfb on X11. I don’t know how to select this pop-up “Remote control requested” with ssh…

Is it a solution ? I suggest :

It will be great to use fully Wayland on the devices I manage with krfb.
As you know some Linux distro are now fully using Wayland.

Thanks for reading this post, no problem to provide more info, I stay tune.

edit : no problem with krdc on Wayland to remote windows 7 and 10 devices (windows vnc sharing server → ultra vnc 1.4.20)
no problem to remote a x86 Linux device sharing desktop with krfb on Wayland, the Linux device is remote with an android vnc viewer => bVNC Secure VNC Viewer

Kde user since ~ 2003

[RobLW]

I have noticed this over the last months as well. I would also recommend supporting krfb to be started before a user is logged in. While at home I don’t mind having my user auto login, on a machine shared by users this might not be suitable.

In reality, VNC has always been the poor performer, having sluggish feeling compared to RDP to windows boxes. Wish there was a much better and more modern approach to remote desktop in the Linux world. VNC is over 20 years old now, wasn’t great at the start and it’s less great today.

[nl.smart]

Thanks for your feedback.

The dev are working hard, krfb and krdc are often up to date.

[RobLW]

@nl.smart - I would possibly suggest NoMachine. I’ve now got this setup and running smoothly. Basically works out of the box but requires you to install it on your client which you connect from as well (be sure to turn off the server on your client desktop). I setup H.265 codec on my server as it seemed a bit sharper.

[danieloneill]

Hmm, the option to “Allow without confirmation” would be great.

I have this same issue with KDE Connect, where I am laying in bed and want to control my mouse to queue up a youtube video, but instead I have to get up and walk to my PC, click the button, then go back to my bed. The whole point of “remote control” is a bit lost when I do that!

I think I’ve traced it to xdg-desktop-portal-kde which handles the virtual input in my case, but I suspect it also provides the interfaces for krfb.

For a “catchall” solution which would handle both of our woes, it would be nice to have a “Remember this choice for this client” checkbox on the confirmation dialogue itself (also?)

[kfanyo]

Linux Kernel v6.1.50, Desktop Sharing v23.8.1

I had the same problem and it turned out that the “Change Unattended Password” attempts to the change (Or perhaps actually does create a separate, different password) the password in the “Connection Settings” pane.

Result? If you change the unattended password so that it is different from the “main” password (A reasonable thing, to my mind), KRFB asks for permission on the host machine to allow the connection. If the unattended password is the same as the “Connection Settings” password, smooth sailing.

[nl.smart]

Hi,

KDE 6 is alive, congratulations to the dev !

So, I did a test with krfb on wayland, I have to confirm the share screen on the devices running krfb on Wayland.

I hope soon a solution

KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.6.21-1- (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Celeron® J4105 CPU @ 1.50GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 600

[nls@ody ~]$ krfb --version
krfb 24.02.0
[nls@ody ~]$

Edit : I found a bug on KDE 6, my taskbar is on the top screen, can’t access to the settings by doing enter edit mode, the settings windows are superimpose, see below the screenshot

[ngraham]

The overlap bug will be fixed in Plasma 6.1. For now you can manually drag the edit mode toolbar down to the bottom of the screen.

[CHN-beta]

Hi, I have just read the source code and written a patch for this purpose. Apply the patch to xdg-desktop-portal-kde, and the “Remote control requested” window will not appear, krfb will be granted automatically.

diff --git a/src/remotedesktop.cpp b/src/remotedesktop.cpp
index 9c27b10..100d6f3 100644
--- a/src/remotedesktop.cpp
+++ b/src/remotedesktop.cpp
@@ -136,10 +136,6 @@ uint RemoteDesktopPortal::Start(const QDBusObjectPath &handle,
         Utils::setParentWindow(remoteDesktopDialog->windowHandle(), parent_window);
         Request::makeClosableDialogRequest(handle, remoteDesktopDialog.get());
         connect(session, &Session::closed, remoteDesktopDialog.data(), &RemoteDesktopDialog::reject);
-
-        if (!remoteDesktopDialog->exec()) {
-            return 1;
-        }
     }
 
     if (session->screenSharingEnabled()) {

I tested on 5.27.10.

If you are using NixOS, here is an expression to apply this patch:

    nixpkgs.overlays = [(final: prev:
    {
      libsForQt5 = prev.libsForQt5.overrideScope (final: prev:
      {
        plasma5 = prev.plasma5.overrideScope (final: prev:
        {
          xdg-desktop-portal-kde = prev.xdg-desktop-portal-kde.overrideAttrs (prev:
            { patches = (prev.patches or []) ++ [ ./krfb.patch ]; });
        });
        xdg-desktop-portal-kde = final.plasma5.xdg-desktop-portal-kde;
      });
    })];

[starvald]

i’ve only this the patch to work on one of two machines.

the laptop will connect but only if KRFB is launched from the command line (not autostart), the minipc will still ask for permission then refuse to work.

[CHN-beta]

After applying the patch and recompile, have you reboot (or logout and then login) your minipc?
Besides, remember to select “Enable Unattended Access” and set a password.

[loveisfoss]

I tried to compile xdg-desktop-portal-kde with the patch but I got lost in the dependencies. Do you think this is going to be merged upstream? Is there any MR done? It’s a little annoying that unattended access doesn’t work.

[CHN-beta]

I think this patch will not and should not be merged upstream. I just removed the “Remote control requested” window unconditionally, which could introduce a certain secure issue. Upstream should disable the window only when “Enable Unattended Access” is checked.
I have not created any merge requests. I am not familiar with KDE and QT development, and the patch is not suitable for upstream. I only created this patch to convenience my personal use.

[loveisfoss]

I see. This issue is kind of a problem through and I do not understand why it feels like it is getting very little attention.

[toreg]

I tried your patch, but after login with KRDC, the session freezes and fails, with the following messages:

kf.notifications: No event config could be found for event id "NewConnectionAutoAccepted" under notifyrc file for app "krfb"
kf.notifications: No event config could be found for event id "UserAcceptsConnection" under notifyrc file for app "krfb"
/usr/include/c++/13.2.1/optional:477: constexpr _Tp& std::_Optional_base_impl<_Tp, _Dp>::_M_get() [with _Tp = PipeWireCursor; _Dp = std::_Optional_base<PipeWireCursor, false, false>]: Assertion 'this->_M_is_engaged()' failed.

I have to add though that my version of xdg-desktop-portal-kde is 6.0.4-1.

[toreg]

This seems to be of interest:

wayland: Add support for the persistence feature of the remote desktop portal...

Edit: Now I can add links.

As it seems there is a bug preventing this MR to work across reboots: 480235 – Persistence in the remote desktop portal does not work across reboots

This is a bug in KDE, as the same function seems to work with Gnome.

[CHN-beta]

Sorry, I have no idea why this error happened. Although I am familiar with C++, I am not familiar with these KDE stuff.

[CHN-beta]

It may not work on plasma 6.2. I only tested on plasma 5.27, and after update to plasma 6.x, I have never use this patch.

[grumpy]

I had the same problem and got it working by deleting the krfb configuration files as described in 480235 – Persistence in the remote desktop portal does not work across reboots

~/.local/state/krfbstaterc
~/.config/krfbrc

There were the files I deleted. Then restart.

[Razvan]

The same confirmation it is asked on
Plasma Version: 6.3.4 (kubuntu 25.04 beta)

In my opinion Krfb is a very important piece now on plasma wayland, given the fact it’s one of the two working remote access software (even if krdp it’s not working for me).

Maybe the developers of the krfb and krdp can set up a way to receive donations from interested users which can help speed up their progress / implement necessary features.