Remote control on X11 desktops, and a Control button only where it works
Agent 0.3.95 takes the screen of any Linux desktop running X11, which is most of them: Mint, XFCE, MATE, KDE and GNOME on Xorg. It also asks the machine whether it has a screen at all, so the Control button stops appearing on headless servers.
Yesterday we shipped remote control for Linux, and it worked on exactly one kind of Linux desktop: GNOME on Wayland. That is the default on Ubuntu, and it was the machine on the bench, so it was the machine that got built against. Then that machine was rebuilt as Linux Mint this morning, and pressing Control on it produced a helper that died looking for an interface only GNOME has.
Agent 0.3.95 fixes both the narrow case and the wider one.
Any X11 desktop
Cinnamon, XFCE, MATE, KDE on X11, LXQt, and GNOME itself when you pick "on Xorg" at the login screen: all of these now work, with the same session bar, the same monitor picker, the same quality and frame-rate controls as Windows and GNOME.
The X11 route is the simpler of the two. There is no compositor to negotiate with and no consent dialog to avoid: any client holding the session's cookie may read the screen, so the agent starts a small helper as the logged-in user, reads the root window through GStreamer, crops it to the monitor you chose, and paints the cursor in. Monitor layout comes straight from RandR, so a three-screen desktop shows up as three screens with the right one marked primary. Input is unchanged from the Wayland build: it goes in at the kernel's input layer, which means it works on the lock screen too. On a Mint desktop the lock screen is just another window, so you see the unlock prompt and type into it.
One thing X11 does not do for us is tell us when the picture changed. GNOME's screencast only sends frames when something moves; X11 hands over eight images a second regardless. The helper compares each frame with the last one it sent and drops the repeats, so an idle desktop still costs nothing on the wire.
What a Linux desktop needs, then: a graphical session, GStreamer's tools with
the ximagesrc plugin (on Debian and Ubuntu that is gstreamer1.0-tools and
gstreamer1.0-plugins-good, both installed on every desktop we have looked
at), and /dev/uinput for input. GNOME on Wayland keeps its own route.
Wayland sessions on other desktops are the one gap left: KDE, Cinnamon and
Sway on Wayland expose no screencast interface the agent can use without
asking the person at the keyboard, and asking is not unattended support. Log
those machines in on X11 and they work.
A Control button only where it works
The wider problem was on the device page. The day Linux remote control shipped, every Linux machine in our own fleet on the new agent grew a Control button. Sixteen machines. One of them has a screen. The rest are web servers, a Pi, a couple of VMs, and the server that runs Wegweiser itself, and pressing Control on any of them opened a session that had nothing to show.
The server was inferring the answer from two facts it had: the operating system and the agent version. "Linux, and new enough" is true of a headless server. Nothing the server can see distinguishes a desktop from one, so it should not have been the one deciding.
From 0.3.95 the agent decides. It looks at its own host: is there a local graphical session, a logged-in desktop or a display manager waiting at its greeter; are the capture tools installed for that session type; is the input device there. It reports the verdict, with a reason, and checks again every minute, because the agent is a system service that starts before the desktop does and its first answer on a freshly booted machine is usually "no session yet". The Control button appears when the answer is yes and is simply absent when it is no.
When it is absent on a machine you think should have it, hover the OS tile at
the top of the device page. The agent's reason is there, in words you can act
on: "GStreamer's ximagesrc element is missing (gstreamer1.0-plugins-good on
Debian and Ubuntu)" rather than a button that does nothing. On the machine
itself, wegweiser-agent --rc-probe prints the same verdict.
Windows machines are unchanged: the Windows helper follows whatever desktop has input, so a logon screen or a monitorless server both count as a screen to show, and they say so.
What you will see
Nothing you need to do. Agents on the supervised update channel move to 0.3.95 on their own, and as each Linux server reports in, its Control button goes away. Linux desktops keep theirs, and the ones that were never GNOME on Wayland get a working one for the first time.