Bug 480235

*** 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.

Is approving the dialog the only way to grant permissions or can I do that from command line somehow as well? Because if so, I could configure a command in KDE Connect and execute this remotely until the issue is fixed properly.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/289

Git commit 663b708b8568d7b843307b40295e29e723e23e59 by Nicolas Fella.
Committed on 12/06/2024 at 14:22.
Pushed by nicolasfella into branch 'master'.

Fix remote desktop restoring

DeviceTypes is QFlags, which doesn't really work with QVariant,
causing the saved data to not be restored.

To fix this force it to uint when reading/writing

M  +3    -2    src/remotedesktop.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/663b708b8568d7b843307b40295e29e723e23e59

(In reply to Nicolas Fella from comment #8)
> Git commit 663b708b8568d7b843307b40295e29e723e23e59 by Nicolas Fella.
> Committed on 12/06/2024 at 14:22.
> Pushed by nicolasfella into branch 'master'.
> 
> Fix remote desktop restoring
> 
> DeviceTypes is QFlags, which doesn't really work with QVariant,
> causing the saved data to not be restored.
> 
> To fix this force it to uint when reading/writing
> 
> M  +3    -2    src/remotedesktop.cpp
> 
> https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/
> 663b708b8568d7b843307b40295e29e723e23e59

Thanks for the amazing work.

Git commit d0ccdb2ba75dc3a72f56059e10707f83baf4ab5d by Nicolas Fella.
Committed on 12/06/2024 at 14:31.
Pushed by nicolasfella into branch 'Plasma/6.1'.

Fix remote desktop restoring

DeviceTypes is QFlags, which doesn't really work with QVariant,
causing the saved data to not be restored.

To fix this force it to uint when reading/writing
(cherry picked from commit 663b708b8568d7b843307b40295e29e723e23e59)

M  +3    -2    src/remotedesktop.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/d0ccdb2ba75dc3a72f56059e10707f83baf4ab5d

Thanks, this has been bugging me with KDE Connect!

Sadly though, the problem persists with Steam Remote Play; after a logout/reboot, I have to manually confirm to allow remote input on the first attempt to stream a game. Subsequent connections within the same desktop session are handled automatically, though.

I'm not too sure whether that's the same issue, hence not reopening with this comment.

(In reply to Calvin Hoy from comment #11)
> Thanks, this has been bugging me with KDE Connect!
> 
> Sadly though, the problem persists with Steam Remote Play; after a
> logout/reboot, I have to manually confirm to allow remote input on the first
> attempt to stream a game. Subsequent connections within the same desktop
> session are handled automatically, though.
> 
> I'm not too sure whether that's the same issue, hence not reopening with
> this comment.

By "same desktop session", do you mean that it still works even after restarting Steam but not the system, or does it only keep working if Steam isn't restarted? If it's the latter then chances are that's because Steam didn't ask for persistence using version 2 of the portal interface, in which case that would be a bug in Steam instead of Plasma.

(In reply to Prajna Sariputra from comment #12)
> (In reply to Calvin Hoy from comment #11)
> > Thanks, this has been bugging me with KDE Connect!
> > 
> > Sadly though, the problem persists with Steam Remote Play; after a
> > logout/reboot, I have to manually confirm to allow remote input on the first
> > attempt to stream a game. Subsequent connections within the same desktop
> > session are handled automatically, though.
> > 
> > I'm not too sure whether that's the same issue, hence not reopening with
> > this comment.
> 
> By "same desktop session", do you mean that it still works even after
> restarting Steam but not the system, or does it only keep working if Steam
> isn't restarted? If it's the latter then chances are that's because Steam
> didn't ask for persistence using version 2 of the portal interface, in which
> case that would be a bug in Steam instead of Plasma.

I just checked, and it DOES continue to work after closing and restarting Steam; only after a logout does the permission dialogue appear again.

I'm on Plasma 6.1.0 though; as Nate set the "Version Fixed In" to 6.1.1, I'm gonna wait for that version to reconfirm if the problem still occurs with Steam.

*** Bug 485697 has been marked as a duplicate of this bug. ***

(In reply to Prajna Sariputra from comment #12)
> If it's the latter then chances are that's because Steam
> didn't ask for persistence using version 2 of the portal interface, in which
> case that would be a bug in Steam instead of Plasma.

What needs to change with regards to updating an application from version 1 of the portal interface to version 2? Is it as simple as passing a flag to the XDG Desktop Portal or do parts of the application need to be refactored?

I'm noticing both Krfb and Steam exhibit this behavior where remote input is not restored on subsequent boots, while KDE Connect reliably retains permissions. Presumably, if we could write a quick patch for Kfrb to fix this behavior it could similarly be passed along to VALVe as a way to solve their application's problem as well.

(In reply to orangestar from comment #15)
> (In reply to Prajna Sariputra from comment #12)
> > If it's the latter then chances are that's because Steam
> > didn't ask for persistence using version 2 of the portal interface, in which
> > case that would be a bug in Steam instead of Plasma.
> 
> What needs to change with regards to updating an application from version 1
> of the portal interface to version 2? Is it as simple as passing a flag to
> the XDG Desktop Portal or do parts of the application need to be refactored?
> 
> I'm noticing both Krfb and Steam exhibit this behavior where remote input is
> not restored on subsequent boots, while KDE Connect reliably retains
> permissions. Presumably, if we could write a quick patch for Kfrb to fix
> this behavior it could similarly be passed along to VALVe as a way to solve
> their application's problem as well.

Krfb should also work if you have version 24.05.1 or newer (https://invent.kde.org/network/krfb/-/commit/01739fbf313d54abb1afb12367e7772b39a4dbfc), and the patch for it is pretty much the same as what KDE Connect got for 24.02.0 so if KDE Connect works already then Krfb should be fine once you update, although of course it'll still ask the first time after you update. Also keep in mind that for persistence to work correctly you'll want to make sure it's started the same way every time, in the past I've noticed that opening it using Kickoff/KRunner, via autostart or manually running it in a terminal window can result in the portal thinking it's a different app and rejecting persistence.

The main changes required are that the app needs to pass two new options to the SelectDevices call, which are `persist_mode` and `restore_token`, and if the user does allow persistence then the token will be sent by the portal as a response to the Start call, which the app will then need to remember and use next time it calls SelectDevices. The details are in the portal documentation: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html

(In reply to Prajna Sariputra from comment #16)
> Krfb should also work if you have version 24.05.1 or newer
> (https://invent.kde.org/network/krfb/-/commit/
> 01739fbf313d54abb1afb12367e7772b39a4dbfc)

Well now I have absolutely no idea what's going on anymore. While trying to confirm my version of Kfrb (I'm on 24.05.2) I accidentally ended the input session with KDE Connect, and now none of my apps are persisting across sessions or reboots: https://i.imgur.com/yQsdcoF.png

No idea how I would troubleshoot this. I'm on Plasma 6.1.2 with XDG Portal 1.18.4, Arch with Linux Zen kernel 6.9.7

(In reply to orangestar from comment #17)
> (In reply to Prajna Sariputra from comment #16)
> > Krfb should also work if you have version 24.05.1 or newer
> > (https://invent.kde.org/network/krfb/-/commit/
> > 01739fbf313d54abb1afb12367e7772b39a4dbfc)
> 
> Well now I have absolutely no idea what's going on anymore. While trying to
> confirm my version of Kfrb (I'm on 24.05.2) I accidentally ended the input
> session with KDE Connect, and now none of my apps are persisting across
> sessions or reboots: https://i.imgur.com/yQsdcoF.png
> 
> No idea how I would troubleshoot this. I'm on Plasma 6.1.2 with XDG Portal
> 1.18.4, Arch with Linux Zen kernel 6.9.7

Strange, I'm also on Arch Linux, with Zen kernel 6.9.8, Plasma 6.1.2, XDG Portal 1.18.4 and KDE Connect/Krfb 24.05.2 as well and persistence works after one reboot with KDE Connect and two with Krfb (although that might be because I just closed the window instead of using the Quit menu option) after I deleted the stored restore token for those two apps (they're in `~/.local/share/kdeconnect.daemon/kdeconnect.daemonstaterc` and `~/.local/share/krfb/krfbstaterc`).

So, I'd suggest deleting those two files I mentioned so Krfb and KDE Connect will be forced to request a new restore token, and see if it helps.

Also, how are you starting Krfb and KDE Connect?

(In reply to Prajna Sariputra from comment #18)
> Strange, I'm also on Arch Linux, with Zen kernel 6.9.8, Plasma 6.1.2, XDG
> Portal 1.18.4 and KDE Connect/Krfb 24.05.2 as well and persistence works
> after one reboot with KDE Connect and two with Krfb (although that might be
> because I just closed the window instead of using the Quit menu option)
> after I deleted the stored restore token for those two apps (they're in
> `~/.local/share/kdeconnect.daemon/kdeconnect.daemonstaterc` and
> `~/.local/share/krfb/krfbstaterc`).
> 
> So, I'd suggest deleting those two files I mentioned so Krfb and KDE Connect
> will be forced to request a new restore token, and see if it helps.

Deleting those files did the trick! Thank you! Hopefully that wont happen too often.

> Also, how are you starting Krfb and KDE Connect?

On Arch, if you install the `kdeconnect` package it comes already setup to autostart, so I have no clue how that works. I have a service running under my user according to `systemctl status --user app-org.kde.kdeconnect.daemon@autostart.service` (found via tab-complete) which states `Loaded: loaded (/etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop; generated)`. That seems relevant.

As for Krfb, I simply added the program to the autostart tab in the settings, which means its using a generated .desktop file in `~/.config/autostart`.

(In reply to orangestar from comment #19)
> 
> Deleting those files did the trick! Thank you! Hopefully that wont happen
> too often.
>

Did this resolve your problem with Steam as well?

(In reply to Samuel Jimenez from comment #20)
> Did this resolve your problem with Steam as well?

Since the state isn't stored in a standard filename or format, and I'm unsure if Steam was using the new version of the portal protocol or not, I didn't bother to try. I used the find command with this:
`find . -name '*state*' -not -path "*steamapps*"`
but the only file I got is unrelated
`./friends/broadcastpublicstatenotification.res`
so this would probably need to be passed along to VALVe.