Supporting org.freedesktop.RemoteDesktop1

[Aleix Pol]

On Sat, Sep 12, 2026 at 11:40 AM David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> I should be transparent here that Cendio (TigerVNC people) are funding
> the work above on making a KDE implementation.
>
> > Makes sense  to iterate. It's a bit weird to add it on top rather than
> > deprecating other approaches but I guess time will tell.
> >
> > I see this doesn't seem to go through XDG Desktop Portal like the
> > former one.
>
> The intention is that it's only for super trusted services.
>
> One rationale given from the Mutter side is they don't want to be
> parsing keyboard maps from anything untrusted and that when this is
> running you would potential disable kscreen + disable user settings
> for keyboard setting controls and so on.
>
> You don't want every random app doing that, so that makes some sense.
>
> There's also the issue of prompts, though we do have a KDE mechanism
> for that, that part feels like NIH.
>
> >Will this one be fine for flatpak apps? I see the spec
> > distances a bit from the use-case but it makes me wonder what the
> > use-case looks like:
>
> Supporting in RustDesk or whatever should relatively trivial. it's
> similar to the portal but you change some paths and names. I
> Shipping in a flatpak I think is still viable, but would require an
> explicit manifest permission to org.freedesktop.remote1 dbus service
> rather than the portal.
>
> It does seem a bit of giving up on the portal, but we'd need a remote
> portal v2 for our needs anyway, so does it matter if it goes via the
> portal or directly? The only user/app facing difference it gives is
> whether we support static vs runtime permission granting, and I can't
> see a good use case for runtime here.
>
> David

Cool then can we take it all the way and figure out what it will look
like with a portal that supports this (and I guess deprecates the v1
part of the protocol)?

In the end, it's remote desktop. It _always_ needs to be by super
trusted components. If the software distribution isn't figured out, I
think we are leaving an important part of the problem in the shade and
leaving the door open for a v3 that addresses software distribution
(and potentially regresses some of the rest).

And FWIW, we do have KDE mechanisms but we always knew that these were
not end-game material. But I understand the plan with this proposal is
to address the problem at once.

Aleix