On Sat, 08 Feb 2025 at 14:18:28 +0000, Andrew M.A. Cater wrote:

On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote:

For now I know that I should remove vino from the recommended ones but I don't know exactly which remote access system would be best to replace it with.

Since nobody seems to have asked this question yet:

Is accepting remote access from other machines considered to be a core
part of the functionality of Cinnamon? If not, then maybe it doesn't
need a remote desktop server to be part of a default installation,
especially if there is no particularly suitable candidate?

GNOME pulls in gnome-remote-desktop *because* it's relatively tightly integrated with the rest of GNOME - gnome-remote-desktop relies on implementation-specific interfaces built into libmutter and gnome-shell
for its benefit; gnome-control-center has built-in UI for enabling and disabling remote access via gnome-remote-desktop (and/or ssh), so that
it can be off-by-default but easy to enable if/when desired; and GNOME
upstream considers gnome-remote-desktop to be part of their overall
"product".

But if similar statements aren't true for Cinnamon, then perhaps it
doesn't need feature parity on this particular point? For example looking
at MATE and Xfce, I don't see an obvious remote-desktop service.

If people really want VNC, then TigerVNC is there in Debian for
all architectures.

Note that there are two flavours of remote access with rather different requirements and expectations, orthogonal to the specific protocol
that's used.

The traditional Unix approach to VNC was for the remote user's login
to be into an entirely new, independent desktop session, like a GUI
equivalent of logging in with ssh. Outside the Unix world, I believe
this approach is basically equivalent to Windows Terminal Services.
A local user can't see or interact with GUI applications started by the
remote user, and vice versa, even if they are both logged in as the same
uid. Xvnc, tightvncserver and tigervnc-standalone-server are examples of
this approach if I understand correctly.

gnome-remote-desktop, krfb, wayvnc and the now-unmaintained vino are more
like the way remote access has traditionally been done on Windows and macOS desktop systems, where the remote user's login is remote-controlling
an existing desktop session. This is less like a GUI equivalent of ssh,
and more like a GUI equivalent of conspy or vtgrab, with applications
started by either the local or remote user being visible and interactable
for the other. tigervnc-scraping-server and tigervnc-xorg-extension seem
to be implementations of this approach.

Neither of those two approaches is a drop-in replacement for the other.

I'd suggest RDP in some form: Microsoft seem to be going this way
for suggested interaction with WSL and Red Hat have dropped VNC
because it doesn't work well with Wayland.

Are you sure that's why Red Hat have de-emphasized VNC? VNC and RFB
are both general-purpose protocols for remote keyboard/video/mouse,
and in principle it shouldn't matter where you got the pixels from or
where you're sending keyboard and mouse events to.

The important difference between X11 and Wayland for remote access
is that in X11, individual X11 clients are powerful enough to act as a
remote access server, and the X11 server is largely powerless to prevent
them from doing so (vino was an X11 client like any other, which is why
it worked in Cinnamon despite having been designed for GNOME).

With Wayland, ordinary applications do not have complete control over
the compositor via the Wayland protocol, and remote-access servers
like gnome-remote-desktop, krfb and wayvnc need to use a more-powerful out-of-band mechanism, often specific to one compositor implementation
(mutter, kwin and wlroots, respectively).

I believe gnome-remote-desktop always supported running under GNOME
in Wayland mode (with video capture via GNOME-specific mechanisms
that provide a Pipewire stream from the compositor), but if I remember correctly it was originally a VNC server, then it gained RFB support and
was able to provide both protocols for a while, then VNC was removed. I
don't know the specific reasoning for that - presumably some problem
with either the VNC protocol or its specific implementation of VNC,
combined with wide enough availability of RFB clients that VNC was no
longer considered particularly interesting - but I think it's more likely
to have been orthogonal to X11 vs. Wayland.

If what you're thinking of is VNC servers that connect to an existing X11 session (like tigervnc-scraping-server or vino), then you're right to say
that they can't work under Wayland, but that's a fact about their implementation of video capture and input event injection rather than a
fact about the VNC protocol specifically.

Or, if what you're thinking of is VNC servers that provide their own independent X11 display (like Xvnc), rather than "doesn't work well with Wayland" it would be more accurate to say "doesn't provide Wayland".

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)