Steam + KDE Wayland: "An application is trying to control input devices"

2026-06-06 · Research report

Short version

The prompt is a feature of Wayland's security model, fired by KDE's xdg-desktop-portal-kde through the Input Capture portal interface. Steam (when running its in-home streaming server, or when Steam Input wants to drive the desktop mouse/keyboard) is asking the compositor to inject input events, and KDE requires explicit consent every time the request comes from a new process/session.

Best fix right now — pre-authorize the input-capture request so KDE stops asking:

flatpak permission-set kde-authorized input "" yes

The "" is a wildcard app-id (you do not have to be running the Flatpak build of Steam for this to work; the permission table lives in xdg-desktop-portal and is consulted for all clients). If you only want to pre-grant Steam specifically, you can also pass its app-id. This command requires the flatpak package even if you don't use Flatpak apps.

If you'd rather not touch the permission store, two more user-facing workarounds are documented in the workarounds section.

What's actually happening

There are two distinct portals in play and they both use the same dialog wording on KDE, which is why the cause is hard to pin down at a glance:

  1. RemoteDesktop portal — used by anything that wants to take over input (mouse, keyboard, touch) and optionally screen. Steam's in-home streaming server uses this on the host side, as does KDE Connect's remote-input plugin, Sunshine, RustDesk, and Gnome Connections.
  2. InputCapture portal — used when an app wants to inject synthetic input events but is not asking for full remote-desktop control. Steam Input (especially when emulating a mouse from a gamepad) and Deskflow (barrier/synergy successor) use this.

On KDE Plasma 6.x, both portals are handled by xdg-desktop-portal-kde and they show a near-identical dialog: "Remote control requested — An application is requesting access to remotely control input devices" (or, on more recent Plasma builds, the shorter "An application is trying to control input devices" wording). The compositor (KWin) is the one actually enforcing the policy — it intercepts the request and pops the dialog before any uinput magic is allowed.

Steam's in-home streaming triggers it because:

It's not a CachyOS bug per se — CachyOS is Arch-based and inherits the upstream Plasma 6 + xdg-desktop-portal-kde stack. CachyOS users hit it more visibly because the CachyOS gaming meta-packages aggressively enable Steam Input by default, and the CachyOS kernel exposes more HID/gamepad devices to userspace by default.

What you can do right now (ranked by effectiveness)

1. Pre-grant the input-capture / remote-desktop permission (recommended)

Plasma 6.3 added a permission store called kde-authorized in the xdg-desktop-portal permission database. It bypasses the dialog for matching apps. It was introduced for remote-desktop; the input key covers the InputCapture portal, and a community PR against xdg-desktop-portal-kde is extending the same table to it (see "What's being fixed upstream" below).

Run the appropriate command for what you want to allow:

# Allow any process on the host to use the InputCapture portal silently
flatpak permission-set kde-authorized input "" yes

# Same, but for the RemoteDesktop portal (also useful for Steam streaming)
flatpak permission-set kde-authorized remote-desktop "" yes

# Verify what you just set
flatpak permission-list | grep kde-authorized

The "" (empty string) is a wildcard app-id — it matches any application that doesn't have a more specific id registered with the portal. The KDE developer's note in the official docs is that host applications (Steam being one) don't always expose an app-id, so the wildcard is the practical option. If you do know the app-id, prefer that: e.g. com.valvesoftware.Steam for the Flatpak build, or the systemd unit name for native Steam.

To undo:

flatpak permission-set kde-authorized input "" no
flatpak permission-set kde-authorized remote-desktop "" no

Confirmed-working reports: this is the exact recipe that worked for the Manjaro user with the same issue, the KDE Discuss user with the Steam controller dialog, and the openSUSE KDE Connect user. The Arch BBS user with a similar Steam Remote Play case used a different (RDP-into-the-host) workaround but acknowledged this would be the clean fix.

2. Unconditional permission in KDE's Legacy X11 App Support (per upstream KDE)

This is what the KDE bug tracker comment for bug 502866 ("Plasma does not remember input device permissions") recommends as the only currently-working approach for the InputCapture case. Open:

System Settings → Applications → Legacy X11 App Support → Application Permissions

…and enable "allow without asking for permission" for pointer and keyboard. The KDE developer note explicitly says: "This works, but it's only a workaround and will stop working once Steam moves to a Wayland client." As of mid-2026, Steam on Linux is still primarily an X11 client under XWayland, so this works. Native Steam Wayland is a longer-term project.

CachyOS ships with XWayland support out of the box; the Legacy X11 App Support module is part of plasma-workspace and is present unless you've explicitly removed it.

3. Disable Steam Input for streaming (CachyOS wiki recommendation)

The CachyOS gaming wiki calls out a specific env var for exactly this class of issue:

# Add to Steam launch options for the game being streamed
PROTON_NO_STEAMINPUT=1 %command%

This tells Proton/Steam to not engage Steam Input for the game, which means no gamepad-to-mouse translation, which means no InputCapture request from that path. Trade-off: you lose Steam Input's per-game mappings (good for a lot of games, bad for games that genuinely need Steam Input's gyro-to-mouse, touch menu, etc.).

You can also disable Steam Input globally in Steam → Settings → Controller, but that defeats the point if you have a Steam Controller or want gyro aiming on a DualSense.

4. Switch to X11 session (nuclear option)

The prompt goes away entirely because the X11 session doesn't enforce portal-based input isolation. On CachyOS: log out → click the session chooser at the bottom-left of the login screen → pick "Plasma (X11)." Downsides: no proper HDR, no secure input isolation (X11 is fundamentally insecure about input grabbing — the very thing Wayland fixes), and a few games that need Wayland's explicit-sync behavior will hitch.

Not recommended unless you've exhausted the other options.

5. Switch to a non-Wayland remote-input path

Two practical options:

What's being fixed upstream

You're not the only one hitting this, and the upstream plumbing is actively being worked on:

Practical takeaway: this should get better over the next few Plasma releases, but in the meantime the pre-grant command above is the cleanest path.

Verifying it's the portal and not something else

Quick sanity check before applying any fix:

# Watch the portal interact with Steam in real time
journalctl --user -u xdg-desktop-portal-kde -f

# In another terminal, start a Steam streaming session.
# You should see a RemoteDesktop or InputCapture call right when
# the dialog pops up on screen.

If you see neither, the prompt may be coming from a different subsystem (e.g. krfb, KDE's built-in RDP server, or an unrelated Flatpak permission). The dialog title is your best clue — "Remote control requested" comes from the RemoteDesktop portal, "Input capture requested" comes from the InputCapture portal, and either grants cover the typical Steam-streaming case.

My recommendation for your setup (CachyOS + KDE Wayland + Steam streaming)

Do these in order, stop after the first one that works for you:

  1. flatpak permission-set kde-authorized input "" yes — covers Steam Input, Steam streaming's input injection, KDE Connect, and Deskflow all at once. This is the move most Linux-on-Arc/CachyOS users in 2026 end up at.
  2. If you want a UI confirmation that the permission is really persisted: open System Settings → Legacy X11 App Support → Application Permissions and flip the pointer+keyboard switches to "allow without asking." This is the KDE-developer-recommended path per the bug 502866 comment thread and you can see the setting change visibly.
  3. If the prompt keeps coming back only for one specific streaming game, set PROTON_NO_STEAMINPUT=1 in that game's Steam launch options.

Option 1 is the surgical fix; option 2 is the broad hammer; option 3 is the per-game escape hatch. Avoid option 4 (X11) unless you're ready to give up HDR and the security model.

Sources