| Summary: | KDE Connect keeps asking for permission for the first time remote input is used on Wayland for each boot | ||
|---|---|---|---|
| Product: | [Applications] kdeconnect | Reporter: | Prajna Sariputra <putr4.s> |
| Component: | common | Assignee: | Albert Vaca Cintora <albertvaka> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andrew.g.r.holmes, cyberfeign, unblended_icing552 |
| Priority: | NOR | Keywords: | qt6 |
| Version: | 24.01.85 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/network/kdeconnect-kde/-/commit/f059491b95ebc8b221f4ebcb7e217042764994a8 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Prajna Sariputra
2023-12-26 06:44:10 UTC
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 |