I experience the same issue. Steam games are focused properly after they are launched, but non-Steam games remain running in the background without focus. A loading animation in the Steam UI is focused instead.
It would be nice to have this fixed so that non-Steam games would also be playable using the new Gamepad UI. It's the last blocking issue as far as I can tell.
I'm pretty sure that this is exclusively a Steam client issue. All the other components seem to behave correctly according to my tests, including gamescope.
More specifically, looking into the root cause of the focus issue and comapring Steam games with non-Steam games, it seems that the following Steam client logic is missing in the non-Steam games case:
STEAM_GAME X property to be the non-Steam game's app ID (as generated by Steam) on each of the non-Steam game's X windows.
GAMESCOPECTRL_BASELAYER_APPID X property on the root X window.
gamescope trying to figure out which window to focus on each frame.STEAM_OVERLAY X property to 1 on Steam UI's X window when the Steam "Overlay" (it's not actually an overlay; it's part of the Steam UI) is opened, and to 0 when it's closed. This makes the Overlay gain focus when opened and lose it when closed.
0 but remains unchaged when the Steam Overlay is opened and closed.SteamGameId environment variable to be the non-Steam game's app ID. This is required due to a (rather ugly) hack in Proton's WINE which attempts to detect when the on-screen keyboard is open while running under gamescope. When this environment variable is set to something which is not the non-Steam game's app ID (which it currently is), it results in logic which assumes that the on-screen keyboard is open, preventing important input events (such as pointer and controller events) from arriving at the game code.(1) and (2) are enough to give the non-Steam game focus when running under gamescope (confirmed using the xprop utility), (3) is required to avoid degrading performance, (4) is required for a working Steam Overlay (confirmed using the xprop utility), and (5) is required for a working pointer (mouse) and controller input with Proton games/apps (confirmed by setting the correct SteamGameId environment variable manually).
So when this issue is eventually handled, all of the above aspects should be considered and tested as each is individually important for some aspect.
Slightly unrelated to the issue of focus, but also worth mentioning: accessing the Quick Access Menu using an external controller (and some other actions like opening the virtual keyboard and force-closing a running game) requires Steam to properly set up key chords for those actions in Steam Input. However, similarly to the non-Steam game focus issues, these are currently set up correctly only when -steamdeck option is specified. I would expect these to be set up whenever the -gamepadui option is specified.
Edit (08.04.2022): I looked deeper into (5) and found the root cause of this one as well. Edited above. I think the list is now quite comprehensive.
In general, I'm pretty sure that @Plagman is heavily involved in the design and implementation of this system, so I'm pinging him here just in case.
Looks like the effect of the -steamdeck option has changed slightly, or more accurately, the effect of Steam Input has changed. I am no longer seeing duplicate input although Steam Input does still seem to be enabled globally when using -steamdeck.
For example, RetroArch still detects 2 additional controllers, but they are listed as "not configured", so this is usable for now. However, I could imagine this might change in the future, perhaps if the RetroArch controller auto-configurations change to start picking up those additional controllers.
I tested the following local multiplayer Steam games and they do not detect duplicate controllers:
@alkazar, I tried to use the -steamdeck option, and while it ran fine after skipping the OS update stage during the OOTB (Out-of-the-box) "Welcome" wizard, it didn't help at all with non-Steam game focus in my case.
I am using Fedora 35 + Steam from Flathub + SteamPal stable update channel + gamescope from GloriousEggroll's game-utils COPR.
For the record, I experience the exact same issue with non-Steam games not gaining focus when running gamescope along with Big Picture mode (-tenfoot) and without -gamepadui.
@alkazar, I tried to use the
-steamdeckoption, and while it ran fine after skipping the OS update stage during the OOTB (Out-of-the-box) "Welcome" wizard, it didn't help at all with non-Steam game focus in my case.I am using Fedora 35 + Steam from Flathub + SteamPal stable update channel +
gamescopefrom GloriousEggroll'sgame-utilsCOPR.For the record, I experience the exact same issue with non-Steam games not gaining focus when running
gamescopealong with Big Picture mode (-tenfoot) and without-gamepadui.
So apparently this is why I couldn't get it to work with the Steam Flatpak: https://github.com/Plagman/gamescope/issues/484.
I'm using the latest client on the latest install of Manjaro KDE with everything fully updates, and I'm noticing similar issues. Haven't tried with -steamdeck yet. I've been using a wired 360 controller, I've a Steam Controller in the post so will be interested in seeing how this behaves.
Most annoyingly I'm finding if I press the 'B' button on the controller then whatever non-Steam game I'm playing Aborts immediately, as per the command on the -gamepadui UI. All other controls work fine in game but somehow the new Steam UI is still actively listening to and responding to button presses.
I've also noticed, outside of the new UI, that RetroArch is listening to both the Steam Desktop Configuration and the native 360 controller (xinput?) when The 360 controller in enabled in the Desktop Controller Configuration settings. Annoyingly one of my games (Adventure 2600 Reboot) requires this to be activated in order to work. That said I've noticed these Desktop Controller Configuration settings are not accessable using the new -gamepadui.
This is no longer an issue.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
What:
When using the gamepad/deck UI with a gamescope session, non-Steam games do not gain focus. Instead I see the animated Steam logo and can only hear the game sounds.
I noticed that when launching Steam with the options
-gamepadui -steamos3 -steamdeck, non-Steam games will launch. Without both-steamos3and-steamdecknon-Steam games do not gain focus.However, the
-steamdeckoption has a side-effect: it enables Steam Input globally. This makes sense for the Steam Deck, but not for other hardware like my Aya Neo. This results in games with local multiplayer detecting a single controller as multiple controllers.Why:
My ultimate goal is to run the Steam Deck's Steam client with gamescope on my Aya Neo as close to SteamOS 3 and the Steam Deck as possible.
We have gotten many requests from ChimeraOS users who are keen on using the new gamepad/deck UI. However, it is not currently possible to provide a good experience with the Steam options available. But it is so close!
The ask:
It would be great if whatever magic the
-steamdeckoption is doing to focus non-Steam games was either:a) enabled by default when using gamepadui and gamescope OR
b) split into its own option, perhaps a
-gamescopeoption; there may even be additional functionality that belongs in this option that I am not aware of, but I trust Valve to figure out the details ;)Steps for reproducing this issue:
-gamepadui -steamos3-gamepadui -steamos3 -steamdeck-- to do this I had to also create a dummysteamos-updatescript and edit my sudoers file to allow execution of that script with sudo without a passwordAt step 3, note that non-Steam games will not gain focus.
At step 4, note that non-Steam games will now gain focus, however, due to Steam Input being globally enabled, games (specifically local multiplayer games) will detect a single Xbox controller as two controllers.