Remote desktop on Linux under Wayland: why the screen shows but the mouse does nothing
A remote session to a Linux machine that shows the screen perfectly but ignores every click is not a bug in your network or your tool's settings. It is Wayland doing exactly what it was designed to do — and the fix depends on understanding which half of the job is being refused.
X11 let every program see everything
For decades the Linux desktop ran on X11, where any program connected to the display could read the whole screen and send keystrokes and mouse movements to any window. That is what made remote desktop on Linux easy: a tool simply asked X11 for the screen and injected input, the same way automation utilities such as xdotool do.
It is also what made X11 a security problem. Any program you ran — a game, a browser extension helper, anything — could log every key you typed into every other window. Wayland, which is now the default session on GNOME and KDE Plasma in most major distributions, was built to close that door.
What Wayland changes
Under Wayland each application sees only its own windows. It cannot read the rest of the screen and it cannot send input to other applications. Remote access has to go through two separate, explicitly permitted channels instead:
- Screen capture goes through the desktop portal and PipeWire. The first time a tool asks, the desktop shows a dialog asking which screen or window to share. Once approved, capture works well.
- Input goes through a separate portal (RemoteDesktop) or a system-level mechanism such as a virtual input device. Support for this has arrived later and unevenly across desktops and tools.
This split is why the symptom is so specific. A tool that supports Wayland capture but still injects input the X11 way will show your screen correctly, and your clicks will reach only the few windows that are still running under XWayland — the X11 compatibility layer — while native Wayland windows ignore them.
| Symptom | Most likely cause |
|---|---|
| Black screen, or a share dialog appears on the host every time | Capture going through the portal; someone must approve it at the host |
| Screen shows, no clicks or keys work anywhere | Input injected the X11 way under a Wayland session |
| Clicks work in some apps but not others | Those apps run under XWayland; the rest are native Wayland |
| Everything works after logging in, nothing at the login screen | The login screen is a separate session the tool is not attached to |
Check which session you are running
Open a terminal on the host and run echo $XDG_SESSION_TYPE. It prints wayland or x11. This single answer explains most Linux remote access problems, and it is worth checking before changing anything else.
The fixes, in order of effort
- Log in to an X11 session, if your desktop still offers one. On the login screen, after choosing your user, a gear or session menu usually lists options such as "GNOME on Xorg" or "Plasma (X11)". Choose it once and most desktops remember it. Screen capture and input then work the old way.
- Use a tool with native Wayland input support. Some remote access tools now implement input through the RemoteDesktop portal, which asks the user at the host for permission to control the machine. This is the direction everything is moving in.
- Use your desktop's built-in remote desktop. Recent GNOME and KDE releases include their own remote desktop servers that speak Wayland natively. They are designed for LAN use or a VPN rather than for reaching a machine across the internet — see why not to expose RDP before forwarding any port to them.
Unattended access is harder under Wayland
The portal dialogs are the point of Wayland's design: a person at the machine approves sharing. That is exactly right for helping someone who is sitting at their computer, and exactly wrong for reaching your own machine while nobody is there. Some desktops let an approval be remembered; others ask again after every restart. If unattended access is the goal, test it by restarting the host and connecting without touching it — the same test described in restarting a computer remotely.
More guides
How much data does remote desktop use? A per-hour guide for metered connections
A remote session can cost 50 MB an hour or several gigabytes, on the same tool. What drives the number, how to estimate it before you run out of mobile data, and the settings that actually reduce it.
Never put RDP straight on the internet — and what to do instead
Port 3389 is scanned continuously, credential stuffing against it is automated, and it is the most common entry point for ransomware. Four safer ways to reach the same machine.
Why a remote connection will not establish, and how to tell which layer failed
NAT, CGNAT, symmetric NAT and corporate firewalls each break the connection in a different place. A diagnosis order that identifies the layer in a few minutes.
Try RemoteFrames
Install the host on the computer you want to reach, then enter its 6-digit code in any browser. No account — two free 10-minute sessions a day.
Try RemoteFrames