SUMMARY On Wayland, KDE Connect uses the remote desktop XDG portal to implement the remote input functionality, however this means that the first time remote input is used for each boot the user has to be physically near the system to accept the permissions dialog that appears (or use a separate wireless input device). In the past the KDE portal implementation had a path to allow skipping the dialog for non sandboxed apps like KDE Connect, but it has been removed since https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/223, so apps have to be updated to use the new version of the remote desktop portal (https://github.com/flatpak/xdg-desktop-portal/pull/1004) to enable support for persistence. STEPS TO REPRODUCE 1. Use KDE Plasma and KDE Connect on Wayland 2. Try the remote input function from a remote device OBSERVED RESULT On every boot KDE Connect asks for permission to control the system. EXPECTED RESULT KDE Connect should only request permission once, and then it should be able to keep the permission if the user allowed it. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.91.90 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.6.8-arch1-1 (64-bit) Graphics Platform: Wayland
A possibly relevant merge request was started @ https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/639
I found a solution for this in my case. Maybe just a quick fix and not something to use for patching? Anyway, seems like if the daemon is started too early in the boot process it will ask for permission. I followed instructions from this Reddit comment: https://www.reddit.com/r/kde/comments/12x3drp/comment/jhhweyl/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button "You can get around it by disabling KDE Connect's autostart file (do cp /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop ~/.config/autostart in a terminal and then edit the ~/.config/autostart/org.kde.kdeconnect.daemon.desktop file by adding Hidden=true to it), if you have the KDE Connect plasmoid/applet set up it should still start on boot anyway. Without rebooting/logging out you can just kill the kdeconnectd process and then run kdeconnect-cli --refresh to start it back up, and from then on it should just pop up a notification on remote input instead of that permission prompt."
The Reddit post refers to another separate issue where the portal fails to detect that KDE Connect daemon being unsandboxed (whose API request should bypass permission prompt). This issue is about the portal removing the unsandboxed app exclusion which requires KDE Connect to support RemoteDesktop session persistence the standard way (instead of relying on unsandboxed app checking). TLDR: Workaround no longer works in newer versions of KDE Plasma.
Git commit 356e7f9eda11821a6c0048eca4ff1bcb983ca486 by Nicolas Fella, on behalf of Prajna Sariputra. Committed on 28/01/2024 at 13:55. Pushed by nicolasfella into branch 'master'. RemoteDesktop: Include clipboard_enabled and the restore data even when no screens are requested The [portal documentation](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html) says that the Start call should return at least three values, which are `devices`, `clipboard_enabled` and `restore_token`, regardless of whether screens are included in the portal request. In particular this fixes persistence not working for apps that only request inputs and not screens like KDE Connect's remote input plugin (I have some WIP code for that here: https://invent.kde.org/psariputra/kdeconnect-kde/-/commit/89ca5684ed4b650cfdbf98ceb067cdf1927a5d41) M +11 -11 src/remotedesktop.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/356e7f9eda11821a6c0048eca4ff1bcb983ca486
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/268
Git commit 9bfcb5b1469079eced1c8b9f650792dc213be7a3 by Nicolas Fella, on behalf of Prajna Sariputra. Committed on 28/01/2024 at 13:55. Pushed by nicolasfella into branch 'Plasma/6.0'. RemoteDesktop: Include clipboard_enabled and the restore data even when no screens are requested The [portal documentation](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html) says that the Start call should return at least three values, which are `devices`, `clipboard_enabled` and `restore_token`, regardless of whether screens are included in the portal request. In particular this fixes persistence not working for apps that only request inputs and not screens like KDE Connect's remote input plugin (I have some WIP code for that here: https://invent.kde.org/psariputra/kdeconnect-kde/-/commit/89ca5684ed4b650cfdbf98ceb067cdf1927a5d41) (cherry picked from commit 356e7f9eda11821a6c0048eca4ff1bcb983ca486) M +11 -11 src/remotedesktop.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/9bfcb5b1469079eced1c8b9f650792dc213be7a3
Git commit 383ad27b5964c8ff14330bf702c68d1f9928f96f by Nicolas Fella, on behalf of Prajna Sariputra. Committed on 28/01/2024 at 14:00. Pushed by nicolasfella into branch 'master'. [plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` M +144 -11 interfaces/systeminterfaces/org.freedesktop.portal.RemoteDesktop.xml M +29 -1 plugins/mousepad/waylandremoteinput.cpp M +1 -0 plugins/mousepad/waylandremoteinput.h https://invent.kde.org/network/kdeconnect-kde/-/commit/383ad27b5964c8ff14330bf702c68d1f9928f96f
Git commit f059491b95ebc8b221f4ebcb7e217042764994a8 by Nicolas Fella, on behalf of Prajna Sariputra. Committed on 28/01/2024 at 14:00. Pushed by nicolasfella into branch 'release/24.02'. [plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f) M +144 -11 interfaces/systeminterfaces/org.freedesktop.portal.RemoteDesktop.xml M +29 -1 plugins/mousepad/waylandremoteinput.cpp M +1 -0 plugins/mousepad/waylandremoteinput.h https://invent.kde.org/network/kdeconnect-kde/-/commit/f059491b95ebc8b221f4ebcb7e217042764994a8