Lamco RDP Server does not correctly use RemoteDesktop portal persistence on KDE Plasma.

[Sergey7210]

Lamco RDP Server does not correctly use RemoteDesktop portal persistence on KDE Plasma.

Environment:

• Plasma 6.6.3
• xdg-desktop-portal-kde 6.6.3
• lamco-rdp-server 1.4.2

Observed:

• Multiple permission dialogs appear (2–3 per start)
• Only one permission (input via libei) is persisted
• Other dialogs do not offer persistence (no "Allow restoring" checkbox)
• Logs show "No restore token in response"

Evidence:

• Token is correctly stored and loaded for libei session
• No tokens exist for other portal requests
• KDE portal does support persistence (confirmed by Krfb working correctly)

Conclusion:
Lamco appears to:

• create multiple independent portal sessions
• not request persistence for all of them
• duplicate input permission requests
• mix ScreenCast and RemoteDesktop flows incorrectly

Expected:

• Single RemoteDesktop session
• Single permission dialog
• persist_mode enabled → restore_token reused

This leads to repeated permission prompts on every start.

[lamco-office]

Apologies for the delay in responding. I've been deep in a refactor and external issues that have pulled attention away from issue triage; back on track now.

Thanks for the careful analysis, especially the comparison against Krfb to isolate this as a lamco-rdp-server behavior rather than a KDE portal limitation. Your observations match how the server currently wires ScreenCast and RemoteDesktop: it opens them as independent portal sessions rather than as a single RemoteDesktop session with ScreenCast as a sub-stream.

Consolidating into a single RemoteDesktop session with proper persist_mode on each request is the right architectural fix, and it's tracked in the portal-handling rework. No timeline to promise yet, but the analysis here is spot on and will feed directly into the redesign. Keeping this open until the fix lands.

[glamberson]

Root-caused this precisely today while investigating a separate report on openSUSE Tumbleweed (KDE Plasma 6.7.1) — same symptom class as this issue: input persists across restarts, screen sharing does not.

Confirmed root cause: the libei/WlrDirect input strategies acquire video through a second, standalone Screencast portal session (separate from the RemoteDesktop session used for input) — see src/server/mod.rs:501-540. That standalone session's SelectSources call hardcodes:

SelectSourcesOptions::default()
    .set_cursor_mode(cursor_mode)
    .set_sources(enumflags2::BitFlags::from(ScSourceType::Monitor))
    .set_multiple(false)
    .set_persist_mode(PersistMode::DoNot),   // <-- here

while the sibling RemoteDesktop session (input) on the same code path successfully requests and reuses persist_mode: 2 with a saved restore token. Confirmed via the KDE portal's own D-Bus journal on a live repro:

Start called ... session_handle=.../ashpd_pxvCdpRlpn   options: persist_mode=2   <- RemoteDesktop (input), persists fine
...
SelectSource called ... options: persist_mode=0                                  <- standalone ScreenCast (video), never persists
Start called ... session_handle=.../ashpd_IfJRgCD1nu

This matches your report exactly: one persisted permission (input via libei), the ScreenCast/video grant re-prompting every start with no restore-token option offered.

Severity note beyond what's in the original report: on an unattended/headless-adjacent host, this doesn't just mean an extra dialog — the server blocks indefinitely in Screencast::start() waiting for a human to click a dialog that nobody is there to see. I let a live repro sit for 90+ seconds at 0% CPU with the portal's Start D-Bus call still pending before killing it.

Fix candidate: request PersistMode::Application (or equivalent) on the standalone ScreenCast's SelectSources call, save/load its restore token the same way the RemoteDesktop session already does, and pass the saved token into CreateSession/Start. Filed for the KDE/libei path specifically; open to confirming whether the same standalone-ScreenCast code path is hit on other input-only strategies (wlr-direct).

[lamco-office]

Fixed in dev. The libei path now attaches ScreenCast to its own RemoteDesktop session instead of opening a second standalone session, so there is one session and one permission dialog, and the screen-sharing grant persists under the same restore token as input. This also removes the headless case where the standalone session blocked waiting for a dialog. Will ship in the next release.