Non-Steam games do not gain focus when using gamepad/deck UI and gamescope

[alkazar]

Your system information

• Steam client version (build number or date): 1648689145 / Wed, Mar 30 7:34 PM UTC -05:00
• Distribution (e.g. Ubuntu): ChimeraOS 32 (testing) / Arch Linux
• Opted into Steam client beta?: Using Steam Deck client
• Have you checked for system updates?: Yes

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 -steamos3 and -steamdeck non-Steam games do not gain focus.

However, the -steamdeck option 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 -steamdeck option 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 -gamescope option; 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:

1. Use non-Steam Deck hardware (an Aya Neo in my case)
2. Switch Steam to use the Gamepad/Steam Deck UI
3. Setup a gamescope session, similar to SteamOS 3.0
4. Run Steam with -gamepadui -steamos3
5. Run Steam with -gamepadui -steamos3 -steamdeck -- to do this I had to also create a dummy steamos-update script and edit my sudoers file to allow execution of that script with sudo without a password

At 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.

[doraskayo]

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.

[doraskayo]

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:

1. Setting the 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.
   • This X property currently isn't set at all in the non-Steam game case.
2. Placing the non-Steam game's app ID in the correct order under the GAMESCOPECTRL_BASELAYER_APPID X property on the root X window.
   • This X property is currently set, but the non-Steam game's app ID is placed incorrectly within it (it's placed last), giving the lowest focus priority to the non-Steam game rather than the Steam UI.
3. Stopping the rendering of the Steam UI when it's not focused.
   • Currently the Steam UI keeps sending damage frames even when not focused in the non-Steam game case, resulting in gamescope trying to figure out which window to focus on each frame.
4. Setting the 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.
   • This X property is currently set to 0 but remains unchaged when the Steam Overlay is opened and closed.
5. Setting the 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.

[doraskayo]

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.

[alkazar]

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:

• Boomerang Fu
• Spelunky
• Streets of Rage 4
• Dirt 5

[doraskayo]

@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.

[doraskayo]

@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.

So apparently this is why I couldn't get it to work with the Steam Flatpak: ValveSoftware/gamescope#484.

[tmcd35]

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.

[alkazar]

This is no longer an issue.