SUMMARY I tried to add support in KDE Connect's remote input plugin for the new persistence feature in v2 of the remote desktop portal protocol in https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/639. While it works if I restart the KDE Connect daemon (I just get the notification instead of the permission request dialog), the token appears to be invalidated after a reboot, so the permissions prompt appears again. If I try the same patched KDE Connect in a GNOME 45.2 Wayland session the restore token does persist across reboots, which leads me to suspect that the issue is in the KDE portal. STEPS TO REPRODUCE 1. Build KDE Connect with the aforementioned MR 2. Try to use remote input from another connected device 3. Accept the remote control permission request with persistence enabled 4. Reboot 5. Try step 2 again OBSERVED RESULT The permission dialog appears again. EXPECTED RESULT The remote control request should be granted immediately, with just a notification appearing. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.80 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 Kernel Version: 6.6.10-arch1-1 (64-bit) Graphics Platform: Wayland XDG Desktop Portal: 1.18.2 ADDITIONAL INFORMATION https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is also needed for the patched KDE Connect to work, since it only requests control of input devices and doesn't need the screens. Alternatively another app that also supports v2 of the remote desktop portal might exhibit the same issue, but I don't know of any such app at the moment. Also, as per the portal documentation (https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html) the restore token is supposed to be invalidated after each use and a new one issued in the Start call's response, but both the GNOME and KDE portals appear to just use the same token anyway.
*** Bug 480435 has been marked as a duplicate of this bug. ***
I'm not only having the issue of it not being persistent, but the permission dialog doesn't always show up. I believe this occurs when restarting plasmashell in some instances and not when rebooting though.
(In reply to Dashon from comment #2) > I'm not only having the issue of it not being persistent, but the permission > dialog doesn't always show up. I believe this occurs when restarting > plasmashell in some instances and not when rebooting though. After further testing, it definitely survives plasmashell restarting, but I know sometimes when it starts working. I would open the system tray and end the permission for it. Hoping that it would pop up again the next time I tried to use it. Thus fixing the problem. Whenever it stops working, I can usually get it to work again and give me the popup again by killing the kdeconnectd process and starting again.
Oh, if you're using KDE Connect and you're stopping the remote control session via the system tray icon then I think that's actually a problem from the KDE Connect side, I don't think it has support for automatically restarting the remote control session if the user stopped it manually at the moment, so KDE Connect will just try (and fail) to use the old cancelled session, and you won't see a notification or permissions dialog until you restart kdeconnectd and try using remote input again.
(In reply to Prajna Sariputra from comment #4) > Oh, if you're using KDE Connect and you're stopping the remote control > session via the system tray icon then I think that's actually a problem from > the KDE Connect side, I don't think it has support for automatically > restarting the remote control session if the user stopped it manually at the > moment, so KDE Connect will just try (and fail) to use the old cancelled > session, and you won't see a notification or permissions dialog until you > restart kdeconnectd and try using remote input again. Ok, so I definitely shouldn't do that anymore. Now all that is left to solve is why it stops working sometimes.