Gnome/Wayland asks to Allow Remote Interaction to use Xbox Controller as mouse
Could this be part of the issue: Xwayland should have the XDG portal disabled by default with a Wayland opt-in command line option to enable it. It's best to read the last URL below about the merge request to see what's going on.
Gear:
- Having used Steam for Linux on Mint XFCE 18 through 21 on Tower PC, I've never had this problem (obviously being X11 and not Wayland) -- and still don't have an issue.
- My Steam Deck obviously doesn't have this problem either (Arch, KDE, but flips between depending on Game vs Desktop mode.
- I'm now also have Fedora Silverblue 39 (Gnome 45) on a Framework 13 7840U (32GB, 1TB NVMe) which exhibits this very problem -- only when Steam is open. Even the Desktop Sharing turned off that dialog pops up.
More details for the Steam for Linux on Fedora Silverblue 39 with Gnome 45, combinations tested:
With Steam (flatpak or rpm-ostree) closed -- If closed, the Remote Desktop dialog doesn't appear when the following controllers are used in any fashion.
- Steam Controller doesn't trigger dialog. Left thumb pad acts as mouse/trackpad in Gnome.
- 8bitdo NES30 Pro (Xbox mode) via Bluetooth, no symptom; via Wired, no symptom
- Xbox wired controller, no symptom
- I installed
neditan old, reliable X11 text editor -- nothing, mouse or controller -- no RDP Share popup.
Steam only needs to be open for the symptom.
-
Steam for Linux via Flatpak. My preferred installed version. In use before the rpm-ostree install.
Compatibility: Steam Play for supported titles: Enabled, cannot turn off; Steam Play for unsupported titles: Disabled
(I also frequently get a "Steam not responding" and must click Wait or wait for it. On my AMD Framework 13, it shouldn't be "waiting". Could be a Flatpak rights issue, I dunno atm.) -
Steam for Linux via rpm-ostree repo (
rpm-ostree install steam steam-devices) hoping it was a Flatpak issue. rpm-ostree install of Steam has same symptoms.
Compatibility: Steam Play for supported titles: Enabled, cannot turn off; Steam Play for unsupported titles: Disabled
(The rpm-ostree install doesn't give the me "Waiting" issue.)
My research findings:
Trying to find the true root cause so I can enjoy my Steam Library when I've my Framework 13 only, I finally came across these posts. These are "breadcrumbs" in the order I found them:
- https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
- https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303
- https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
- https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1170/diffs?commit_id=cfcbb075c23fc668e84a381c9c2c165a95798cf4
So if I understand it correctly, it looks like a portion of Wayland required an alteration to not default to being "always responsive" to XTEST. As the merge request was just 5 months ago (as of today), I've no clue as to how soon the fix will propagate into the next release(s) of Gnome and Fedora.
If that merge is truly the fix, it might behoove Valve to have one of their advocates reach out to Gnome and help get this fix fast tracked. This "bug" is impacting all Steam for Linux users who use Wayland -- particularly with Gnome combinations.
Thanks. Cheers.
You found more on this topic than I had until I stumbled here and read your links about it. Thanks for adding all that detail, it gives me more to look into for the sake of understanding the issue.
It's great from an accessibility perspective to be able to have Steam auto-start on system boot and use the controller to navigate without an additional prompt being needed. It's one feature I didn't realise I used in Windows as much as I did until I couldn't do the same in Fedora.
It's great from an accessibility perspective to be able to have Steam auto-start on system boot and use the controller to navigate without an additional prompt being needed.
Does this fix the issue for you? Can you explain how you did this?
No, there's nothing I can fix by reading about it. I was just describing the behaviour I liked in Windows and how it's not the same in Fedora. Using Xorg, that popup doesn't happen, so that's one way of working around it but I haven't found a way with Wayland.
Here to report the same behavior on Arch using GNOME.
Your system information
PC
Steam Beta Branch: Stable Client
Steam Version: 1718751621
Steam Client Build Date: Wed, Jun 19 4:09 AM UTC +05.3:30
Steam Web Build Date: Wed, Jun 19 1:36 AM UTC +05.3:30
Steam API Version: SteamClient021
Distribution (e.g. Ubuntu): Fedora Linux 40 (Workstation Edition)
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
GPU: AMD RX 6700 XT
Facing same issue here. I am streaming from Fedora 40 to my Steam Deck(LCD). I am able to stream when I allow to share my desktop with the same modal but steam deck controls do not work. I've tried both controller and KBM.
@aliasbody Did you use PROTON_LOG=1 %command% to generate logs?
Same behavior here on EndeavourOS with KDE Plasma 6.1 and Wayland. Super annoying.
This is also happening under KDE, If I try to use the chord to move the mouse with my controller I get a popup.
If I tell steam input to use a keyboard input on the gamepad I get the same popup again, and worst of all, confirming it doesn't allow the input through, NOR SAVE THAT I WANT THE INPUT TO GO THROUGH.
Which basically breaks steam input's promised controller support for MKB only games.
It is nice that Steam is finally able to move a mouse under wayland, but this is a bit much.
Same issue here with Steam on Gnome with Wayland. Super annoying.
Hi just chiming in with this is the most frustrating bug I have encountered in a while. I use a DS4 and even with it completely unbound in Steam's thing it does stuff, so then I thought... wait hold on. Hold on. Hold on one second. So it's doing stuff, even WITHOUT STEAM? HMMMMMMMMM.
So then I remembered, hey, wait I've had this problem myself before. This is Gnome, automatically adding the DS4, as a TOUCHPAD. So at least on GNOME (I am EndeavourOS Gnome atm) you can just press super key, type 'touchpad' bring up the settings menu, click the 'touchpad' tab next to mouse, and then TOGGLE OFF TOUCHPAD.
After which you can then go into Steam's settings and set 'trackpads' to just do nothing. This will finally stop your trackpads bringing up some weird esoteric PROBABLY NOT USEFUL menu to you in the middle of trying to S rank Metal Gear Rising or whatever.
This also means I guess you can't use it like a mouse right now if you really wanted to do that, but hey, it'll help for right now if you just want to play video games.
Hope this helps anyone else.
Having the same "issue" here. Using a controller connected to my TV, everything's fine when I use it just as a controller.
When I switch to mouse mode to move the cursor out of the way, I get the "Allow Remote Interaction" popup and it works until I exit the steam link app on my tv.
I say "Issue" because its more of an inconveinience to have to get up to allow mouse movement.
IMO its a valid reason for the popup to show up. Ideally, I'd like to find a way for steam to just always be allowed to do remote interaction. If anyone can help set up some sort of udev(?) config that'd be great.
As steam uses the remote desktop portal to do its simulated key presses, a fix might be to just allow those sessions to persist?
setting the persist_mode to 2 sounds like whats needed here, so steam can reuse the rdp session it requested the last time and i dont have to click on share again.
Since libinput is the default for a few years... isn't libei a better solution for this?
Another instance: https://www.reddit.com/r/gnome/comments/1evs764/remote_desktop_dialogue_shown_when_using_a/
Over there I made a user-friendly writeup of what's causing the bug. I'll copy+paste it over here for reference, with some minimal additional commentary:
Steam takes full control of your gamepad. When you're in a game, Steam receives the events from the gamepad, and forwards them into the Steam game via the Steam Input API. So games with controller support get to see the controller. Games without controller support are remapped into keyboard and mouse events by Steam Input and the game sees these remapped events instead.
When not in a game, Steam Input runs in desktop mode. Steam treats your desktop like a game that doesn't support controllers natively: it remaps the controller into fake keyboard and mouse events, and then tries to send those events into the OS to handle. (There might be more complexity involved here with a component called Gamescope, but that's not relevant to the "controlling your desktop with a gamepad" use-case)
Except, the OS isn't a Steam game. It doesn't have the special Steam Input API to inject fake input events. So Steam has to take control of your desktop some other way.
On X11 there was an API called XTEST that was originally intended for app testing purposes. Like you'd run a script, and that script would run your app and then control the mouse and keyboard to automatically test it. Steam Input (ab)uses this XTEST API to move around the mouse cursor and inject virtual keyboard inputs when it's in desktop mode.
On Wayland no 1:1 alternative to XTEST exists, because it's really insecure to let random apps take control of your desktop. An X11 connection is a trivial sandbox escape because an app can abuse XTEST to take full control of the system, open a terminal app, and then run some commands outside of the sandbox. This is why Flatpak considers X11 a dangerous sandbox bypass, by the way. Wayland was designed to allow security sandboxes, so no such insecure API was added.
But it's a useful feature to have. Things like remote desktop software and Steam do use XTEST for legitimate purposes. So the solution was to make a Portal API that asks the user for permission before letting an app take control of the desktop (and also notifies the user when there's an app controlling their desktop). Apps can now ask for permission to control your mouse and keyboard, and if the user allows it they'll be able to do so.
For backwards compatibility, XWayland provides support for XTEST through the portal. The TXEST API has no concept of asking for permission, so XWayland handles it for the X11 app; whenever the app tries to use an XTEST API to inject a fake event for the first time, XWayland asks the portal for permission - once granted, the app will keep having "remote desktop" control over your system until it's closed. If permission is denied, XWayland just asks again the next time the app tries to use XTEST. There's really no better way to handle this because X11 apps expect XTEST to work and have no concept of needing to ask for permission before taking over your device.
Note that those MRs linked above fix bugs related to handling of this XTEST API with Gamescope running inside of another Wayland session. They don't solve the underlying issue of XTEST clients not being portal aware. They don't have any effect on Steam Input controlling your desktop
The solution is for Steam to talk to the portal natively instead of using XTEST. The portal works on both X11 and Wayland. Steam will then be able to knowingly ask for permission to control the screen, gracefully handle rejection by the user (instead of just spamming with more questions), and so on. It can even opt into letting the OS remember that Steam was previously given permission, and (if the user allows it) the permission will be automatically granted without bothering the user each time.
As noted above, once Steam talks to the portal directly it can opt into a persistence mode to stop asking the user every time. (And it would need to handle storing/retrieving the persistence restore token, of course)
Since libinput is the default for a few years... isn't libei a better solution for this?
Yeah libei is a major part of the remote desktop portal's functionality. So yes, it's part of the solution. But it's not useful to apps without knowledge of the portal (otherwise there's no way to get connected to the ei server).
The real solution is to use the portal in some way. A simple solution is to just use the portal directly to move mouse and emulate keyboard. A more complicated but probably more performant solution is to ask the portal for a libei connection and then send events through that, directly into the compositor.
For people looking for a workaround to not receive the confirmation box anymore: I used this https://github.com/Supreeeme/extest on gnome on my living room tv to control the desktop with the steam controller.
this issue has been annoying me ever since i moved to fedora 40 (as fedora 40 uses only wayland by default) its even more annoying because it can interrupt games when you try to change the volume using the home button or use the extra buttons on dualsense controllers it will disable the entire controller until you use your computer mouse or keyboard to click accept. once i learn about rust a little ill try that extest again
Hello,
I have been bugged by this issue most of the year. I use wayland across a number of distros some with KDE and some with Gnome but I mainly use KDE.
As soon as I go into steam settings and click 'enable steam input for xbox controllers' the problem starts. If I turn off 'enable steam input for xbox controllers' the problem then goes away. I can now use an xinput controller without the issue but then I lose all the nice steam input features.
This issue is really killing Linux gaming for me right now. So much progress in Linux gaming then a silly bug like this pops up and spoils it.
I finally found a way around this. Put the following file at $HOME/.config/xdg-desktop-portal/portals.conf:
[preferred]
default=gnome;gtk
org.freedesktop.impl.portal.RemoteDesktop=none
I've only tested this on GNOME, but it seems likely to probably work elsewhere, too. Just replace default=gnome with the appropriate value for your desktop environment. If you take a look in /usr/share/xdg-desktop-portal, there should be a bunch of files that are named something like gnome-portals.conf and kde-portals.conf and so on. The value for default is just the text before the dash in the filename of the file in that directory. You can also use multiple with semicolon separation, like gnome;gtk in the above example.
Edit: It seems that this breaks Steam Input completely in certain circumstances. My main concern was fixing the window popping up while playing a game and some associated input lag, but this will break all Steam Input usage outside of a currently focused window, which means it won't work as a mouse for general desktop usage. Sorry.
I have tested this on KDE Plasma and can confirm it works (with default=kde); however, this is not really a satisfactory solution (at least for KDE) since the cursor icon does not move (just an invisible second cursor that can do things and that immediately "merges" back to the "real" cursor when moving the actual mouse)
also tried with kde and it just makes the mouse invisible and completely disables the steam chord commands as a whole
I finally found a way around this. Put the following file at
$HOME/.config/xdg-desktop-portal/portals.conf:[preferred] default=gnome;gtk org.freedesktop.impl.portal.RemoteDesktop=none
This solution breaks Steam Input, which I use to map my controller to keyboard/mouse input. The screen recordsing warning doesn't come on at all, meaning it's completely disabling it... I just want to whitelist steam.
Happens on my Framework laptop with bleeding edge updates. When the sticks are engaged a remote desktop window asks for permission.
Open Steam and Plug in my Xbox Controller. Push the sticks.
Issue stems from Gnome and Steam interaction
Workaround
By going into Steam and setting the buttons and sticks to none in the Desktop mode settings it stops happening. I can't navigate the menu with the controller then but for my use case I do not care. It's either Gnome or Steam one of the two.
I set all to None all buttons, sticks, everything for Desktop. Gnome is seeing the controller as a remote keyboard. Click Edit.
Operating System: (Basically Fedora 40)
NAME="Nobara Linux"
VERSION="40 (GNOME Edition)"
ID=nobara
ID_LIKE="rhel centos fedora"
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Nobara Linux 40 (GNOME Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=nobara-logo-icon
CPE_NAME="cpe:/o:nobaraproject:nobara:40"
DEFAULT_HOSTNAME="nobara"
HOME_URL="https://nobaraproject.org/"
DOCUMENTATION_URL="https://www.nobaraproject.org/"
SUPPORT_URL="https://www.nobaraproject.org/"
BUG_REPORT_URL="https://gitlab.com/gloriouseggroll/nobara-images"
REDHAT_BUGZILLA_PRODUCT="Nobara"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Nobara"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="GNOME Edition"
VARIANT_ID=gnome
Steam Client:
Steam Beta Branch: Stable Client
Steam Version: 1733265492
Steam Client Build Date: Mon, Dec 2 2:26 PM UTC -07:00
Steam Web Build Date: Mon, Dec 2 2:20 PM UTC -07:00
Steam API Version: SteamClient021
No Opt In For Beta
Video Card
Advanced Micro Devices, Inc. [AMD/ATI] Navi 33 [Radeon RX 7600/7600 XT/7600M XT/7600S/7700S / PRO W7600] (rev c1)
Hello everyone!
From my research into this:
- Steam seems to use libei (specifically liboeffis) to request this portal: https://gitlab.freedesktop.org/libinput/libei - EDIT: THIS IS NOT TRUE, see my below comment. Steam is currently still using XWayland.
- libei does not support persisting of sessions.
So I guess the first step in solving this is to add support for persistent in the remote desktop portal to libei / liboeffis and then ask Valve to opt-into persistence of this setting, implement it and update to the new libei version.
The current spec is here:
https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.RemoteDesktop.xml
See "persist_mode", etc.
The release that added this option to the portal was 1.17.0: https://github.com/flatpak/xdg-desktop-portal/releases/tag/1.17.0
The reason this isn't an issue on the Deck is because, as far as I can tell, Valve patched out the portal request on KDE Plasma on SteamOS.
I created an issue on libei for this: https://gitlab.freedesktop.org/libinput/libei/-/issues/72
I’ve been testing several Linux distros on my laptop and encountered game-related issues with Fedora-based distros, including Nobara and Fedora itself. However, Pop!_OS (Debian-based) didn't have any of these problems. Here’s a breakdown:
Problems on Fedora-based distros (Nobara & Fedora):
Game Freezing: Games seemed frozen unless I alt-tabbed back and forth, making them unplayable.
Steam Issues:
Steam Window Issues: When launching a game on Steam, I couldn’t bring Steam to the foreground anymore.
Steam Interactions: Had to interact with Steam through the tray icon since the Steam window wouldn’t respond. Sometimes, I had to completely close and relaunch Steam to interact with it again.
Resolution on Pop!_OS:
No Freezing: Pop!_OS (Debian-based) resolved the game freezing issue, with no need for alt-tabbing.
Steam Working Properly: Steam behaves normally, allowing full interaction without needing to relaunch or use the tray icon.
To summarize, all game and Steam-related issues were resolved after switching to Pop!_OS.
I’ve been testing several Linux distros on my laptop and encountered game-related issues with Fedora-based distros, including Nobara and Fedora itself. However, Pop!_OS (Debian-based) didn't have any of these problems. Here’s a breakdown:
Can you use the steam input gamepad mouse without having to a use mouse/keyboard to accept the permission screen, in PopOS? I don't have freezing or any issues other than the annoying popup permission screen on NixOS with a modern kernel. I get that popup at least once an hour when using Steam Input controller mapping.
PopOS is known for running modern kernels, which is probably what fixed your issues.
I’ve been testing several Linux distros on my laptop and encountered game-related issues with Fedora-based distros, including Nobara and Fedora itself. However, Pop!_OS (Debian-based) didn't have any of these problems. Here’s a breakdown:
Can you use the steam input gamepad mouse without having to a use mouse/keyboard to accept the permission screen, in PopOS? I don't have freezing or any issues other than the annoying popup permission screen on NixOS with a modern kernel. I get that popup at least once an hour when using Steam Input controller mapping.
PopOS is known for running modern kernels, which is probably what fixed your issues.
Well PopOS kernel is a few months older than the Nobara and Fedora. All I can say is I constantly had a popup on the remote desktop under any Fedora based distros. I have had zero issues using my gamepad and no prompts for anything. It works like I would expect.
Correction to my above comment:
They do not use libei yet, it seems I misinterpreted some things. Steam is running xwayland which handles this.
So Valve would need to run Steam via Wayland natively and then use something like libei or implement the portal themselves.
The most frustrating thing is, the controller works absolutely fine when Steam isn't open, it's only when Steam is open that interactions with it mess with GNOME.
The most frustrating thing is, the controller works absolutely fine when Steam isn't open, it's only when Steam is open that interactions with it mess with GNOME.
You can have steam open, you just have to un-toggle 'enable steam input for xbox controllers' in steam settings.
Still not great because you lose all of the good steam input features.
I'm not using an Xbox controller, I'm using a Steam controller, which causes the same issue. That still works?
Ahh Sorry. Still an issue with steam controller. What I was trying to say was you can still get around the issue for now and use raw xinput or dinput, until it is fixed.
@kisak-valve you closed a duplicate of this, is this getting fixed at all? Word from some developer would be welcomee as this is a long running issue. At least give us the workaround impleemented in steamos (if there is one)
At least give us the workaround impleemented in steamos (if there is one)
Workarounds:
- Don't use gamepads, or disconnect any present.
- Use Steam Input to remap gamepads to frequest keyboard actions like arrow keys, WASD and spacebar. This makes sure you never hit the ~5 minute timeout during gameplay, so you only have to approve Steam's access to the game once.
- Disable the Steam Input gamepad mapping that is being triggered and use only native Gamepad input. Xbox button + Joystick is by mapped to mouse and volume by default... remove these in Steam settings to prevent accidental triggering.
Option 2 works for hours straight... problem is you have make an input map, for every single game you play. Not ideal, but if you need Steam Input, it's the only viable solution. I love the Steam gamepad volume and mouse mapping. and rely on Steam Input for some games with lazy Gamepad support... so I use either Option 2, or just live with the issue and use my wireless keyboard to approve the dialog.
After losing XP YET AGAIN in PoE2 due to this "feature" I have the ultimate solution, that works WITHOUT FAIL
- using a small phillips screwdriver, remove the 4 screws from the bottom of your DS4 controller.
- carefully pry controller apart.
- remove the small ribbon cable under the battery tray. this will disconnect your touch pad.
- undo steps 1 and 2
- enjoy never having this popup during game play again
Hello,
My work around : chose gnome/x11 at login and no gnome wayland.
Manjaro uptodate/gnome
@exzemat Switching to X11 is not a good option due to X11 having tearing issues that Wayland does not.
@AtomBalmBaby No need to modify your controller. It is easier to open Gnome Settings and switch off touchpad input. Note that you may want touchpad input for big picture mode use, and for games that support it like Ghost of Tsushima.
I can confirm this is still a constant issue, at least on Fedora with Steam and a DualShock 4 controller. You must accept and dismiss the popup again with each process and controller connect.
Valve Linux team, please implement a proper fix for this issue. Having Linux gaming with auto-login and big picture mode is pretty great, but this issue is a literal show-stopper.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2741525522
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2743499762
I was about to say the same about X11, it is an outdated display server and should not be used, I agree this issue should be solved ASAP, having FNV modded is a blast, but being kicked out of the game when I use my sprint mod each time I launch the game is a nightmare
I would also like to mention that there is another portal, used by the unofficial Steam flatpak but ignored by Valve for their official binaries, and this is the XDG background portal, which is used by GNOME as a sort of system tray, you see, in the old times the system was a sort of notification panel, but some apps started using it as a background process indicator which was not meant to be implemented like that and that is why the GNOME devs implemented a background apps list using this portal to stop using SLAPUs not meant for managing background processes
We need both fixes, please Valve
@00gavin That was actually one of the first things I tried. It makes no difference if it is on or off
This is a very annoying thing for a specific usecase of mine lol: I own a PSVita and I have setup Sunshine+Moonlight for streaming, and if I were to use a Desktop Layout where I move my cursor with joysticks, it requires the manual permission from the physical mouse, so if something with Steam Big Picture goes wrong, and I need to use the desktop tough luck
(GNOME 47.5 Wayland on Arch)
For anybody wanting a hacky solution until fixed, give https://github.com/Supreeeme/extest a shot, actually works like a charm, you just have to preload Steam with this drop-in replacement of XTest (and there is a pre-made script that replaces ur Steam shortcut)
This issue is also effecting me on the latest steam o Arch with Gnome 47 under wayland and using a 8BtDo SN30 controller.
Same here. I'm using Steam Input with my DualShock 4; every time I launch a game and press a custom command I get:
Once I allow it. My custom commands work, however restarting the game I get this popup again.
Just to add some additional flavor this went away for me when I installed Nobara Linux using KDE instead of Gnome. I will say I like KDE orders of magnitude better just tons of quality of life updates.
For people looking for a workaround to not receive the confirmation box anymore: I used this https://github.com/Supreeeme/extest on gnome on my living room tv to control the desktop with the steam controller.
At last I finally got your solution working. I can't compile it since my computer hates compiling stuff for some reason but I found the download in my package manager for fedora in the Terra repo and it had it precompiled and now it's finally working!
This is also impacting me trying to use Steam Link. It works great until I accidentally touch the screen, causing a mouse input, bringing up the Remote Interaction prompt, and preventing me from seeing anything until I click out of it on the host computer.
This bug is infuriating and is the one thing keeping me tied to X11. I frequently make use of Steam Input to map keyboard hotkeys to my controllers, but I can't do that with a useless prompt jerking control away from my game. It also is most certainly not exclusive to Gnome. I'm running a pretty bog-standard KDE installation in an up-to-date Arch Linux and I can unfortunately confirm it's a problem here.
I was trying Cachy OS for the first time recently. After I installed Steam I tested to see if it's still a problem. When I moved the right stick I got a usual popup but this time I had a new option to permanently allow steam. I selected yes and since have never had another popup.
Works with KDE and Gnome on cachy OS
I'm not sure if this is because Cachy OS is more bleeding edge or maybe they fixed it themselves.
From: nacho-chicken @.>
Sent: 11 April 2025 01:25
To: ValveSoftware/steam-for-linux @.>
Cc: hexmanUK @.>; Comment @.>
Subject: Re: [ValveSoftware/steam-for-linux] Gnome/Wayland asks to Allow Remote Interaction to use Xbox Controller as mouse (Issue #10442)
This bug is infuriating and is the one thing keeping me tied to X11. I frequently make use of Steam Input to map keyboard hotkeys to my controllers, but I can't do that with a useless prompt jerking control away from my game. It also is most certainly not exclusive to Gnome. I'm running a pretty bog-standard KDE installation in an up-to-date Arch Linux and I can unfortunately confirm it's a problem here.
—
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2795484225, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMBNSAD4HBMYPAIFGIHRY232Y4DXPAVCNFSM6AAAAABCOMSSVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJVGQ4DIMRSGU.
You are receiving this because you commented.Message ID: @.***>
[https://avatars.githubusercontent.com/u/57602407?s=20&v=4]nacho-chicken left a comment (ValveSoftware/steam-for-linux#10442)https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2795484225
This bug is infuriating and is the one thing keeping me tied to X11. I frequently make use of Steam Input to map keyboard hotkeys to my controllers, but I can't do that with a useless prompt jerking control away from my game. It also is most certainly not exclusive to Gnome. I'm running a pretty bog-standard KDE installation in an up-to-date Arch Linux and I can unfortunately confirm it's a problem here.
—
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2795484225, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMBNSAD4HBMYPAIFGIHRY232Y4DXPAVCNFSM6AAAAABCOMSSVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJVGQ4DIMRSGU.
You are receiving this because you commented.Message ID: @.***>
For anybody wanting a hacky solution until fixed, give https://github.com/Supreeeme/extest a shot, actually works like a charm, you just have to preload Steam with this drop-in replacement of XTest (and there is a pre-made script that replaces ur Steam shortcut)
Work for steam in desktop mode but failed when launch big picture.
For big picture It's seems possible to do like steamdeck : use spécial session with big picture and gamescope (lite wayland made by steam): so without stock wayland.
I fear that since Steam uses GameScope for steamdeck they dont care about find a solution for wayland...
But i need launch big picture with kodi addon (no a spécial session)
So ...please valve, help us to find a solution/work around !
Agree, also having issues with wayland and steam remote play
To everyone using KDE: This merge request for KWin could fix this issue (at least for KDE users)
The issue is still present on latest Arch + GNOME using steam and remote play
Workaround : i launch steam big picture with gamescope.
Edit, to be clear:
I use x11 session (with openbox)
And i add
''gamescope -W 1920 -H 1080 -- %command%''
In steam, for each game, in ''properties'' : no tearing.
(assume gamescope is installed)
Bonus: steam overlay work with emulator like dolphin
This sucks. It's messing with my retroarch hotkeys. I'm moments away from uninstalling steam.
The latest plasma master allows for input control without asking for permissions. It'll come around eventually.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2888541899
what version?
Git master.
I would be fine with steam to ask once, but use the correct portal config, to allow to remember the decision. So setting persist_mode should be enough.
As suggested multiple times above.
Unexpected "Remote Desktop" screen appears when pressing LT/RT on 8BitDo Ultimate 2C Controller in Hollow Knight (GNOME/Wayland)
- Adding it here as a comment cause my issue was closed as a duplicate
Description:
When using the 8BitDo Ultimate 2C controller with Hollow Knight on Fedora Linux (GNOME/Wayland), pressing the LT or RT buttons causes a "Remote Desktop" window (GNOME Allow Remote Access prompt) to appear. This issue occurs only in Hollow Knight and not with any other games.
Steps to Reproduce:
Connect the 8BitDo Ultimate 2C controller to a Fedora Linux system running GNOME/Wayland.
Launch Hollow Knight.
Press LT or RT on the controller.
The window appears unexpectedly.
Expected Behavior:
Pressing the LT/RT buttons on the controller should perform the intended in-game action (in this case, a "dash") without interruption.
Actual Behavior:
Pressing LT/RT causes the Allow Remote Desktop window to appear, interrupting gameplay and causing a potential disruption in the gaming experience.
System Information:
OS: Fedora Linux 42 (GNOME/Wayland)
GNOME Version: 48.4
Kernel Version: Linux 6.15.9-201.fc42.x86_64
Game: Hollow Knight
XWayland Settings: Disabling Xtest via gsettings set org.gnome.mutter.wayland xwayland-disable-extension '["Xtest"]' did not resolve the issue.
Additional Information:
The issue is isolated to Hollow Knight; other games and applications do not exhibit the same behaviour with the 8BitDo Ultimate 2C controller.
Killing GNOME remote desktop serive has not resolved the issue (It just reappers).
Switching from Wayland to X11 may resolve the problem, but this workaround is not ideal.
Steps Taken to Resolve:
Checked GNOME Sharing and Remote Desktop settings, confirmed no active screen sharing.
Disabled Xtest extension in XWayland settings via gsettings.
Severity: Medium
The issue interrupts gameplay and causes unexpected behaviours, like the game not interpreting correctly when I press LT/RT.
adding my issue here since it's a duplicate apparently
Your system information
-
Steam client version (build number or date): 1751405894 (from pacman)
-
Distribution (e.g. Ubuntu): Arch Linux (bazzite kernel)
-
Opted into Steam client beta?: No
-
Have you checked for system updates?: Yes
-
Steam Logs: steam-logs.tar.gz
-
GPU: AMD Custom GPU 0932
Please describe your issue in as much detail as possible:
On GNOME (Wayland), while using my Steam Deck OLED's buttons and trackpads without Steam running, everything works as intended.
Although, when Steam is running, whenever I press any button or touch any trackpad, I get prompted with this window.
After allowing it, all inputs are working as expected until I use the Steam's on-screen keyboard or after some time and I systematically get prompted again with this exact same window.
Steps for reproducing this issue:
- Launch Steam on GNOME/Wayland;
- Press any Steam Deck OLED input (except the touchscreen).
Just to add to the thread. I used to fix this issue in KDE with this command. Its not the exact error shown, but the behavior is exactly the same, whenever you try to use controller as mouse or any controller shortcut the popup shows up.
flatpak permission-set kde-authorized remote-desktop "" yes
i tried changing it to gnome-authorized but still nothing. But maybe someone knows how to relate the fix in kde with gnome.
Just to add to the thread. I used to fix this issue in KDE with this command. Its not the exact error shown, but the behavior is exactly the same, whenever you try to use controller as mouse or any controller shortcut the popup shows up. flatpak permission-set kde-authorized remote-desktop "" yes i tried changing it to gnome-authorized but still nothing. But maybe someone knows how to relate the fix in kde with gnome.
I think Gnome doesn't honor an autogrant directive like KDE do.
Also suffering from this.
Hope there's a solution at some point.
Arch Linux w/ gnome so reverting to X11 isn't an option without system stability issues
Dropping a comment here to say that I am also still experiencing this.
Worth noting that it does seem that there's a way to have persistent remote desktop, if Steam used the newer freedesktop APIs for it
https://discourse.gnome.org/t/be-able-to-whitelist-a-binary-to-have-access-to-the-remote-desktop-portal-without-confirmation-dialogue/27614
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-selectdevices
I wonder if this will limit the usefulness of the new Steam Controller on GNOME...
Worth noting that it does seem that there's a way to have persistent remote desktop, if Steam used the newer freedesktop APIs for it
https://discourse.gnome.org/t/be-able-to-whitelist-a-binary-to-have-access-to-the-remote-desktop-portal-without-confirmation-dialogue/27614
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-selectdevices
If Valve implements this into Steam then we might finally have something usable!
I'm also running into this on cachyos. First time I use any KBM bindings through steam input after launching a game, every time I launch the game, I get the permissions popup mine doesn't even give me the poorly worded persistence checkbox.
🎮 Workaround: Disable/Update Guide Button Chord Shortcuts
On DualSense controllers, pressing the PS button combined with Touchpad click | L1 | R1 | L3 | R3 or Start Button triggers this remote settings dialog. This occurs because Steam uses these "combination shortcuts" (Chords) as default system-level commands.
[!NOTE]
This behavior also affects Xbox controllers (via the Guide/Xbox button) and other supported hardware on Steam for Linux.
To resolve this, adjust the Guide Button Chord Configuration using one of the following methods:
Option 1: Completely Disable Guide Button Chords
This will stop all combination shortcuts tied to the Guide/PS button globally.
Option 2: Update Specific Mappings
Alternatively, you can edit the layout to update only specific mappings while keeping your other shortcuts active. For example, removing the Trackpad Left Click mapping prevents the GNOME remote UI dialog from appearing.
Path: Steam Settings > Controller > Pair And Manage > Guide Button Chord Layout > Edit
1. Select the Layout:
2. Change the Mapping (setting it to "None"; but you can also just update single sub commands ...):
That's not a solution, that's a temporary workaround at best.
Changing game / desktop configs is unfeasible, this should just work as intended.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-2888541899
This works, but not being able to limit this only to steam is sketchy. The functionality is there but I for the life of me cannot figure out what am I supposed to use as the app_id for non-flatpak Steam. Of course, "" works, but this has the same issue.
Bah, I'm silly. It's not the Steam that requests the permission, but XWayland. So of course it's not possible to only allow it for Steam.
I hope this is resolved before long as it's reported to have the same issues with the steam controller.
Actually, why is it labeled as Distro Family: Fedora?
It's a Gnome issue, not related to the distro used.
It's more of an implementation issue than a DE issue, as there are other
apps that implement the portal with the remember checkbox.
El mar, 5 may 2026, 20:35, JustCryen @.***> escribió:
JustCryen left a comment (ValveSoftware/steam-for-linux#10442)
https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-4381981987Actually, why is it labeled as Distro Family: Fedora?
It's a Gnome issue, not related to the distro used.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-4381981987,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBTEJVVOLWABHLR667MLZL4ZIX7BAVCNFSM6AAAAABCOMSSVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOBRHE4DCOJYG4
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.You are receiving this because you commented.Message ID:
@.***>
Especially when playing remotely, this is pretty breaking. Hoping it gets fixed soon
I just received my new Steam Controller in the mail, and immediately encountered this issue as soon as I connected it to my laptop running Steam on Fedora Workstation. It's pretty alarming when something unexpectedly starts requesting remote desktop access, and the constant request popping up makes for an extremely sub-par first experience with the controller.
Wow I found this thread because I just dug out my old steam controller and set it up to toy around with after getting in a reservation on this past Friday to buy the NEW steam controller only to run into this issue. To read that it occurs on the new steam controller too is very concerning. The popup happens every minute or two for me, so it makes the controller unusable.
I guess I will have to skip my reservation when it pops. I too am on Fedora + GNOME + wayland.
It pops up way more often for me as well, I might have failed to mention that. My controller doesn't need to sleep or Steam client doesn't need to be restarted for this to trigger again.
A minute is maybe too harsh but it happens within a 5 minute window since the previous pop-up, over and over and over again.
Arch with Gnome on Wayland in my case.
I am on Fedora Gnome, also with the new steam controller. If steam is not running, the controller controls the desktop without this issue. The second steam is open, any input on the controller will trigger this window to open
Remote Interaction popup: First thing I noticed about the steam controller experience on Arch w Gnome 50. Pretty abysmal feeling seeing it appear constantly. Haven't seen it on my steamdeck yet, although I haven't entered desktop mode there, just gaming mode.
It happens on KDE Plasma too. In fact it happens on all Wayland sessions. It doesn't happen on SteamOS though (on my Deck), but that's just because SteamOS allows all X11 apps to take control of the keyboard and mouse without asking by default (which can be set in the KDE settings but is a sketchy workaround).
In fact, the whole controls of the Deck face the same problem when this precise option is disabled.
(which can be set in the KDE settings but is a sketchy workaround).
How can one do that?
(which can be set in the KDE settings but is a sketchy workaround).
How can one do that?
You have to go into System Config -> Security and Confidentiality (or something similar, I don't have it in english)-> Legacy X11 App Support and check the last box. Someone took a screenshot on how to a year ago, it's still pretty much the same :
The latest plasma master allows for input control without asking for permissions. It'll come around eventually.
You will get the legitimate KDE warning on why this isn't so safe.
For actual security it's kind of moot, as Steam installs a udev file that allows every app to access uinput and simulate any input device, bypassing all of this wayland permission stuff.
And they can't not do that, as that is the only way to simulate controller input on linux.
(The mentioned above extest is using that to simulate kb+m input too, which is how you can work around this issue in Gnome)
For actual security it's kind of irrelevant, as Steam installs a udev file that allows every app to access uinput and simulate any input device, bypassing all of this wayland permission stuff.
And they can't not do that, as that is the only way to simulate controller input on linux.
(The mentioned above extest is using that to simulate kb+m input too, which is how you can work around this issue in Gnome)
That's not true.
What does have to do the udev rule for the controller with this?
It
allows every app to access uinput and simulate any input device, bypassing all of this wayland permission stuff
I too experience this on Gnome/Wayland with the new Steam Controller. It drives me crazy!
Static hostname: devkit
Icon name: computer-laptop
Chassis: laptop 💻
Chassis Asset Tag: NO Asset Tag
Machine ID: d2c66b5a221c41c2b1675b11360de55c
Boot ID: 7b2a9e52423243fa80e7a1c33b22d915
Operating System: Garuda Linux
Kernel: Linux 7.0.5-zen1-1-zen
Architecture: x86-64
Hardware Vendor: Lenovo
Hardware Model: LOQ 15ARP9
Hardware SKU: LENOVO_MT_83JC_BU_idea_FM_LOQ 15ARP9
Firmware Version: PQCN25WW
Firmware Date: Thu 2025-06-26
Firmware Age: 10month 2w 5d
Hi,
I experience de same under ArchLinux with any controller (including the steam controller).
I found a workaround to make the controller work in game. When you're in a game, go to your Steam Library in the game you're playing. There should be a "controller settings", inside you'll be able to customize the inputs the controller is sending. Check that there isn't any "mouse" or "keyboard" input that could trigger the pop-up. There also is some community preset available for that (and official ones for the Steam Controller)
It worked for me, hope it will for the ones experiencing it.
Experiencing this issue as well with steam controller.
Fedora/Gnome
Also having this issue - Would love to see this fixed - Might decide not to buy the steam controller solely because of this quirk
Arch Linux / Gnome
Hi. I'm on Arch Linux / KDE / Wayland and although after turning on the controller with Steam open and using it for any mouse input I get this message I have no problem in-game after that. It's still very annoying but the controller is worth it imo. I'm launching Steam with -PipeWire and allowing full desktop access, I'm not sure it helps but I'll throw it here in case.
Same here. I am experiencing the exact same behavior on Ubuntu 26.04 (GNOME / Wayland).
The moment I enter a game and move the right analog stick on my controller, the game immediately minimizes and the GNOME desktop portal popup appears asking to "Allow Remote Interaction".
If I click "Share" to grant permission, I can tab back into the game and play normally. However, GNOME does not persist this permission. Every single time I relaunch the game. This is happening across multiple games in my library (most recently tested on Mafia III).
This is almost certainly an issue with Steam Input attempting to emulate a mouse pointer globally, which triggers the Wayland/GNOME remote desktop portal (libei) security prompt.
System Info for reference:
- OS: Ubuntu 26.04 LTS
- DE/Compositor: GNOME (Wayland session)
- Controller: Xbox One Controller
- GPU: NVIDIA RTX 5080
- CPU: Ryzen 7 7800X3D
Same behaviour here on CachyOS KDE Wayland when using the Steam Controller trackpads
flatpak permission-set kde-authorized vivaldi com.vivaldi.Vivaldi yes
flatpak permission-set kde-authorized steam com.valvesoftware.Steam yes
this fixed it for me at least (on plasma, for gnome IDK, I'm just a guy pasting random scripts from the internet into the terminal)
Found it here:
https://discuss.kde.org/t/kde-linux-steam-controller-request-remote-access-dialog/30731
Nice. Plasma will finally remember input permissions selectively per-program.
Nice. Plasma will finally remember input permissions selectively per-program.
This is KDE Plasma right? Which version?
This is KDE Plasma right? Which version?
Git master
It's very disappointing that this still exists in GNOME and there's no workaround. I am experiencing this with my Steam Controller every single day.
@graynk I completely understand the frustration. Since you haven't found a workaround yet, did you try this one?
https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-4148325257
The comment is collapsed in the issue history, so I wanted to bring it back up. It’s currently working for me and completely prevents those annoying dialogs from appearing.
Hi @fedoraBee,
thanks for bringing this up again. I tried it and still have the problem under Fedora 43 with the Steam Controller.
- Disabling "Guide Button Chords" didn't work.
- Editing the "Guide Button Chord Layout" just opens a black window on my system.
This is really a massive disappointment because it renders the Steam Controller completely useless for me. :(
Since you haven't found a workaround yet, did you try this one?
[#10442 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-4148325257)
The workaround will not help, as for Steam Controller it pops up when you use touchpads (and I want to use my touchpads, so there's no sense in disabling them).
What might help is https://github.com/Supreeeme/extest mentioned here earlier, but it seems to be broken at the moment (or at least I couldn't get it to fully work, as I don't quite get how to inject both 32-bit and 64-bit library via LD_PRELOAD and didn't have time to look into it further).
I had GPT 5.4 Pro draft me a patch... it has a lot of trouble with the UI, but it's a start if someone familiar with RFC UI wants to get gnome to fix this.
# GPT 5.4 Pro AI patch output:
xdg-desktop-portal-gnome
src/remotedesktopdialog.ui
Rename "Remember This Selection" → "Remember this app"
Add tooltip/warning text
src/remotedesktopdialog.c
Show app name
Keep emitting the existing persist boolean
xdg-desktop-portal
RemoteDesktop frontend implementation
Offer persist_mode=2 for local input-only requests
Load/store per-app restore_data in PermissionStore
Auto-restore remembered grants
Delete stale grants on restore failure
Refuse persistence for ambiguous Xwayland caller identity
gnome-control-center
Privacy/Security panel
List remembered RemoteDesktop grants
Add Revoke action
0001: GNOME dialog “Remember this app” wording + app identity
0002: xdg-desktop-portal auto-offer persistence for local input-only requests
0003: RFC revocation UI notes
README
What’s in them:
Patch 0001 changes GNOME’s existing persistent checkbox from “Remember This Selection” to “Remember this app”, adds a tooltip, renames the window to “Remote Interaction,” and shows app-specific row text. The current GNOME dialog already has the hidden persist_check control, so this patch builds on existing UI instead of inventing a new path.
Patch 0002 changes xdg-desktop-portal/src/remote-desktop.c so input-only SelectDevices requests get persist_mode = 2 offered to the backend when the app did not explicitly request persistence. The current frontend already has RemoteDesktop persistence plumbing around persist_mode, restore_token, and xdp_session_persistence_*, so this patch uses that existing machinery.
Patch 0003 is intentionally not buildable UI code. It is an RFC patch documenting the Settings revocation contract. Real gnome-control-center code would be larger and needs to match whichever privacy panel structure GNOME wants upstream.
That's unhelpful and actively goes into the wrong direction.
Steam needs to fix this and go through the portal and unfortunately, that's unlikely unless they start shipping native wayland builds.
Let's hope they will at some point. As far as I know one blocker was CEF not being able to run wayland native which has been fixed recently.
Do desktop portals depend on wayland? I thought those are dbus interfaces independent of wayland.
The problem is that the persistence feature of the portal only works with proper app IDs, which requires Wayland. (simplification)
What might help is https://github.com/Supreeeme/extest mentioned here earlier, but it seems to be broken at the moment (or at least I couldn't get it to fully work, as I don't quite get how to inject both 32-bit and 64-bit library via LD_PRELOAD and didn't have time to look into it further).
I was able to get it to work with the help of AI. The issue was that it builds for the wrong architecture (32bit/64bit) and you just need to create the correct libextest.so file. After that even after a restart the controller just works.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-4751117188
That's great to hear. Would you please be so kind as to share the steps/instructions as to what did work for you as prescribed by your AI session? Was it combining @FossPrime patches & additional tunings? Was the PRELOAD dependant if the game was 32 or 64 bit? Or something different?
It would really help out the community of folks trying to make a working solution. Thanks in advance.
That's great to hear. Would you please be so kind as to share the steps/instructions as to what did work for you as prescribed by your AI session? Was it combining @FossPrime patches & additional tunings? Was the PRELOAD dependant if the game was 32 or 64 bit? Or something different?
It would really help out the community of folks trying to make a working solution. Thanks in advance.
Do the Rust installation and group according to the readme.md of extest.
Then, depending on 32/64bit you can generate the correct file like this (for me 32bit is the one that worked):
# build for 64bit
cargo build --release --target x86_64-unknown-linux-gnu
# build for 32bit
cargo build --release --target i686-unknown-linux-gnu
# for 64bit
LD_PRELOAD=~/Documents/software/extest/target/x86_64-unknown-linux-gnu/release/libextest.so steam
# for 32bit
LD_PRELOAD=~/Documents/software/extest/target/i686-unknown-linux-gnu/release/libextest.so steam
Before running the LD_PRELOAD command I made sure that I exit steam, so it reopens correctly using the command.
I can confirm this issue is still present with current software.
My system:
- CachyOS (Arch-based)
- GNOME 50 on Wayland
- Steam 1.0.0.86
- Official Steam Controller
Additional testing/results:
-
The issue only occurs when the Steam Controller desktop layout has the trackpad configured as "As Mouse". Setting the trackpad behavior to "None" immediately stops the Remote Desktop permission dialog from appearing.
-
The dialog reappears after every login. Even if I choose Allow Remote Interaction and click Share, the permission is not remembered across sessions.
-
When the dialog is accepted, GNOME displays the orange screen-sharing/remote-desktop indicator in the top panel, confirming that a Remote Desktop portal session has been started.
-
I tested the workaround of creating
~/.config/xdg-desktop-portal/portals.confwith:[preferred] default=gnome;gtk org.freedesktop.impl.portal.RemoteDesktop=noneThis completely prevents the permission dialog from appearing, but desktop mouse emulation from the Steam Controller also stops working. This strongly suggests Steam's desktop mouse emulation depends on the RemoteDesktop portal.
-
I also installed KDE Plasma 6 to see whether the behavior was GNOME-specific. Plasma exhibited the same behavior, so this does not appear to be limited to GNOME.
One unrelated issue I encountered while debugging was severe Steam overlay lag. Disabling Settings → Interface → Enable GPU accelerated rendering in web views fixed that completely, but it had no effect on the Remote Desktop permission dialog.
Hopefully these additional tests help narrow down where the problem is occurring.
Additional observation:
Editing the controller layout in Steam Input also retriggers the Wayland Remote Desktop permission dialog. This occurs even without launching a game.
Every time a controller configuration is modified and applied, the next touch of the trackpad causes GNOME to request Remote Desktop permission again. This suggests Steam is recreating or reinitializing whatever requests the Remote Desktop portal rather than reusing an existing authorized session.
This is really a massive disappointment because it renders the Steam Controller completely useless for me. :(
My thoughts exactly. In the least douchey way I can say this, I genuinely don't understand how this is a thing.
I have the ability to install Linux, launch steam, and browse the web. Not much more than that due to having only two braincells floating around up there. But if I am instantly and repetitively bombarded with what is bar-none the most insufferable popup I have seen in ten years as soon as I start using their brand new expensive ass controller... I can't help but ask myself how it's even possible that the people who develop the controllers and software haven't fixed this. Did they... not run into this issue with over a year of testing under their belts? The end users already pay for the expensive ass controller, why do we have to pay with our time too? Should be playing games, not signing up for a crash course in remote interactions, accelerated rendering, protocols, portals, xwayland and whatever other jargon.
Shout out to the community nerds who have the capacity to fuck around and figure out this stuff, you guys are heroes. I am but a grumpy bitch who just wants to play some Hollow Knight.
I can't help but ask myself how it's even possible that the people who develop the controllers and software haven't fixed this. Did they... not run into this issue with over a year of testing under their belts?
They probably only tested it on Windows and the Steam Machine... and then didn't even include it with the Steam Machine, so it's kind of a pointless product in the end, as nobody will design games for it.
I am but a grumpy bitch who just wants to play some Hollow Knight.
If you disable the functionality of the touchpads (so that it only has to simulate an Xbox 360 controller and not a mouse), I think you should be able to avoid the pop-up.
Happens with Steam Controller, Steam Flatpak + Bluefin OS
i reported this like 4 years ago, and it's damn unbelievable they haven't been able to fix it till now
and this is getting really frustrating
i just updated to fedora 44 and i still have it
weirdly enough, some months ago i updated from f43 to f44 and didn't have this problem anymore, but i felt like f44 wasn't ready enough and downgraded
now that i updated again, the problem is back...
really frustrating...
@tutacat
That is not correct. Would Steam run natively via Wayland they could leverage the persistence feature (persist_mode) which would make this dialog show up only the first time. Currently Steam runs via XWayland where that can not be supported.
(And KDE implements an optional non-standard workaround for X11 apps that just auto-grants permissions to X11 apps)
Wow, it's really saddening that this issue was opened a couple years ago and is still present today.
It's been driving me nuts on a new Ubuntu 26.04 install, decided to use a spare PC connected to the TV downstairs and in most ways it's been a brilliant way to play games on the sofa - however any time a keyboard input is requested and the on-screen keyboard appears I get the 'remote desktop' popup, which originally I thought was just it randomly opening a settings panel for remote, over the network desktop - had no idea about the whole Wayland portals thing.
It's doubly frustrating as I recall Ubuntu being one of the original supported distros for Linux, with the .deb installer being the preferred method so I've always stuck with that. That Valve have left this issue open for at least 2 years shows a clear lack of testing.
I have nothing constructive or technical to add sadly, other than registering that it happens on a fresh Ubuntu 26.04 install with Steam from the website as a .deb being literally the only thing I've installed, and this issue occurs. It also seems to occur in web views, where in the top-right a controller icon appears saying to use the right stick to navigate, and any input causes the remote input dialog to appear.
Hopefully it doesn't take another two years or more to resolve.
I've seen this Bazzite changelog commit:
https://github.com/ublue-os/bazzite/commit/5422ba11fe38d0c4078fb96f9c2692c19e74e8d2
Can somebody test this?
I've seen this Bazzite changelog commit: ublue-os/bazzite@5422ba1
Can somebody test this?
This commit adds an option that makes Steam capture display with pipewire for the Steam Remote Play. This is irrelevant to this issue.
I've seen this Bazzite changelog commit: ublue-os/bazzite@5422ba1
Can somebody test this?This commit adds an option that makes Steam capture display with pipewire for the Steam Remote Play. This is irrelevant to this issue.
You don't seem to know how does Pipewire, input and portals work on all of this.
Anyhow, to anybody that wants to know: It does work, lets the compositor remember the capture/input session through the portal and just asks the first time with a checkbox saying "Remember... Blahblah"
Hope this closes the issue.
Getting this on my steam deck when trying to remote play into my PC. Happens when i press certain buttons (volume up/down).
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-5131347138
@aliasbody you can close the issue or wait until it's part of the args when launching Steam client.
If you want to fix this: run steam client with -pipewire as args
Running it with -pipewire does not fix the issue. It does break the screen capture though, so there's that 👍
Yes, it does ask whether you want to share the screen or not. And yes, you can even remember the answer. It will still spawn the "allow remote interaction" pop up every single time though.
CachyOS with GNOME. Assuming GNOME is the issue here though (as always).
GNOME is not the issue, the issue is Steam not running via Wayland and not implementing the session-persist feature for the portal.
I have tried to explain this multiple times already in this thread.
There is no point waiting for any external fixes.
At this point this thread should maybe just be locked.
This happens with the new Steam Controller as well, apparently it has something to do with XTEST being used by Steam to send keypresses
See the Gnome bug here: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/work_items/114
Fedora 44 Workstation
Just got my steam controller and found that using the controller on my system means having to repeatedly check a box, and there is no way to fix that on my end. Not the best experience I have to say. GNOME 50 has dropped support for X11, and that has been telegraphed for the longest time, and GNOME 50 has been out for months already, it really is time to fix this.
It's fixed on GNOME 51
If somebody tests this on F45 or GNOME OS, should check this out.
El sáb, 15 ago 2026, 23:03, Vas Zayarskiy @.***>
escribió:
Staphylococcus left a comment (ValveSoftware/steam-for-linux#10442)
https://github.com/ValveSoftware/steam-for-linux/issues/10442#issuecomment-5304220346Just got my steam controller and found that using the controller on my
system means having to repeatedly check a box, and there is no way to fix
that on my end. Not the best experience I have to say. GNOME 50 has dropped
support for X11, and that has been telegraphed for the longest time, and
GNOME 50 has been out for months already, it really is time to fix this.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/10442?email_source=notifications&email_token=ABBTEJXTXTNMGJDHKP3GTDL5KDFZFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZQGQZDEMBTGQ3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5304220346,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBTEJVWBWBRIUPURN7C5W35KDFZFAVCNFSNUABDKJSXA33TNF2G64TZHM3TENBYHE2TMO2JONZXKZJ3GIYTANBTGEZDSNRSUF3AE
.
You are receiving this because you commented.Message ID:
@.***>
Unfortunately steam is quite slow at fixing the bugs and gripes on Linux, and, well, SteamOS game mode doesn't require this to be fixed, because Valve's own compositor (gamescope) is nonstandard and allows input from Steam. Yes, it fixes the initial prompt for them, but because they control it, and they could have fixed it years ago.
But they have many things that haven't been fixed for years, even a solution that is right here.
It is the reason that the steam desktop client always pops up over other windows when starting, menus bug out sometimes, sometimes, every menu breaks. You can see so many old issues that have busy not been closed.
Launch options
PROTON_LOG=1x1 2024-06
Launch lines
gamescope -W 1920 -H 1080 -- %command%x1 2025-04
Upstream links
- ValveSoftware/steam-for-linux/issues/10442x10 2026-08
Your system information
Please describe your issue in as much detail as possible:
When using Gnome with Wayland with a Xbox One X Controller, and when pressing the Guide button + any other option (like joystick up) instead of starting controlling the desktop there is a popup that appears asking to "Allow remote interactions".
Allowing it makes the controller work as a mouse (control volume etc..), but once Steam is closed or the controller is disconnected/reconnected, if we try the same operation it asks for the same permissions again.
Going to "Settings > Controller > Desktop Layout (EDIT) > Disable Steam Input" doesn't solve the problem, it still shows the popup.
Steps for reproducing this issue: