SteamOS
SteamOS copied to clipboard
ValveSoftware
Flatpak apps do not get focused in steamcompmgr
Your system information
- Steam client version: 1504895740 (September 8, 2017 at 10:50:37)
- SteamOS version: 1.121
- Opted into Steam client beta?: Yes
- Opted into SteamOS beta?: Yes
- Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:
When attempting to run a Flatpak application that uses X, the application will run in the background but will not gain focus, leading to a permanent loading screen in Big Picture mode. The application can be kill'd, however, so it is technically possible to get back to the menus without restarting.
Steps for reproducing this issue:
- ssh into machine,
sudo su - steam flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepoflatpak install --user flathub org.libretro.RetroArch- Add RetroArch as non-Steam shortcut
- Run RetroArch via Steam
ps -efto see application running,killall retroarchto end it
Worth noting that Flatpak apps do run fine in desktop mode and that RetroArch does exit on start when it can't create an X window + GL context (i.e. attempt to run in an ssh terminal), so I'm led to believe that it's just steamcompmgr not knowing what to do with whatever mess is going on with Flatpak's sandbox.
A quick update on this, posted to the Flatpak thread but is important for the SteamOS side too:
https://github.com/flatpak/flatpak/issues/1025#issuecomment-330886755
The Steam overlay hooks set the STEAM_GAME X window property and steamcompmgr looks for that before focusing any window, so that's probably what's falling apart here. We might move to a different, less fragile approach for this, but in the meantime you can try setting it by hand with xprop or through code (look for air_preload.c in the Free to Play depot for a code example).
Looks like that was it! I preloaded air_preload.so in the Flatpak shell and it loaded up. I'll CC you into the other thread so we can figure out how to get this fixed for reals.
Judging by the reaction I got from the Flatpak devs this is something SteamOS will need to fix... also on the TODO list is updating PulseAudio; @directhex and I are thinking it needs to be 7.0 or higher for audio to work:
https://twitter.com/directhex/status/911977780962840576
I tried updating to 7.1 from jessie-backports and it did not go well, so this either needs more attention than an apt-get upgrade or we'll have to wait for the Stretch rebase.
Maybe you can use devils pie: https://github.com/GNOME/devilspie to auto-match windows and set the properties?
This appears to be fixed by using a more recent OS; in running a SteamOS session on Fedora 27 the problem somehow fixed itself, so the workaround isn't necessary. Maybe a Stretch rebase will magically fix this too...?
(As a side note this also affects the zenity window used for the Steam EULA, so unless you boot to a desktop at first like the custom SteamOS image does you'll get stuck on first boot.)
We had a similar issue (not a flatpak app) and it was caused by linking to xlib statically. We found if you dynamically pick up xlib from steam runtime there's no need for hacks with X properties to get the window to focus.
@flibitijibibo have you had luck setting this via xprop? Due to the audio issues I noticed you were having as well, waiting is painful, but then again, so is trying to hack things. hmm.
I haven't tried the xprop path yet, only the LD_PRELOAD method. If you give it a try, let me know and I'll dig up a SteamOS install to try it...
I have a patch for the SteamOS compositor that I think could fix this issue: https://github.com/alkazar/steamos-compositor/commit/3c746244e902b4d2683bcb864dc41b4365442a8b
I haven't tested any flatpaks, but there are actual games on Steam that have the same problem. That patch fixes those games, namely Dead Cells.
A good easy test case is the RetroArch package, which should still work with Brewmaster. Interestingly this issue goes away if you use steamcompmgr with Fedora... no idea what that's about:
https://plus.google.com/+flibitijibibo/posts/f11ZFpyUzob
I don't actually have a SteamOS install to test on anymore. I developed and tested this on Arch.
Not sure why it would work on Fedora. Perhaps there is some difference in the host libraries that accounts for it.
@flibitijibibo I have confirmed that my steamcompmgr fork (https://github.com/alkazar/steamos-compositor) fixes this issue.
I tested on Arch Linux with RetroArch installed from flatpak, confirmed the issue with original steamcompmgr, then confirmed it works with my forked steamcompmgr.
This would indeed be nice so some of us can start more seriously hacking away at community FlatPaks for SteamOS.
@alkazar , is there a repo (I haven't seen one) to submit the PR fix to? I'll ping [email protected] via email if not. @kisak-valve , is this something you can help with? It would greatly help spark the community efforts to get flatpaks going more for SteamOS and start filling the software gap in a way that does not require something like my previous efforts with my rebuilds on libregeek.org.
The importance here too, is that this opens up SteamOS to the already growing list of apps on FlatHub. Beyond that, Valve could internally host a flathub site or merely code a future landing page accessible from BPM in SteamOS. @alkazar , thank you for your efforts!
@mdeguzis there is no github repo for the SteamOS compositor as far as I can find. I grabbed the source code from Valve's SteamOS debian package repos.
Presumably they have an internal source repository somewhere but didnt bother publishing it.
For all we know this issue is already fixed in an upcoming version of SteamOS.
Another thing to note is that I dont think my patches for the steamos compositor are likely be merged. It is a bit of a hack. The real fix might need to be made to the Steam client and how it communicates with the compositor, and only Valve are able to do that.
Hmm, that's too bad. Once FlatPak apps work better with the closure of this ticket, I plan on kicking my efforts into high gear to support SteamOS more independently of what I can build only from Debian Jessie (and soon Stretch I hope).
A workaround to run RetroArch until the issue is fixed by Valve:
- Go to desktop mode.
- Open the file manager, go to /usr/bin, run xterm.
- Set passwords for desktop and steam user:
passwd desktoppasswd steam - Kill Steam:
sudo pkill steam - Login as steam user:
sudo su steam - Run Steam in desktop mode:
steam - Select "Add a non-Steam game to my library" from "Games" menu.
- Select Xterm, then set up the following launch options:
-e nohup bash -c 'flatpak run --filesystem=/run/pulse org.libretro.RetroArch > /dev/null 2>&1 & PID=$! && while ps -p $PID > /dev/null; do sleep 0.5; WID=`xwininfo -tree -root | grep '\''("retroarch" "retroarch")'\'' | sed '\''s/ *//'\'' | sed '\''s/ .*//'\''`; ISNEWWINDOW=$(xprop -id "$WID" | grep STEAM_GAME); if [ -z "$ISNEWWINDOW" ]; then xprop -id "$WID" -f "STEAM_GAME" 32c -set "STEAM_GAME" 1000000000; fi; done > /dev/null 2>&1'
To add another app, replace the flatpak run --filesystem=/run/pulse org.libretro.RetroArch part with your command, and ("retroarch" "retroarch") with something you find out by command like:
xwininfo -tree -root | grep -i retroarch
UPDATED: Assign STEAM_GAME to newly created windows, fix pulseadio for flatpak sandbox.
I have a patch for the SteamOS compositor that I think could fix this issue: gamer-os/steamos-compositor-plus@3c74624
I haven't tested any flatpaks, but there are actual games on Steam that have the same problem. That patch fixes those games, namely Dead Cells.
I can confirm this patch works. I've made a patch file for it. fix-flatpak.txt
@flibitijibibo I have confirmed that my steamcompmgr fork (https://github.com/alkazar/steamos-compositor) fixes this issue.
I tested on Arch Linux with RetroArch installed from flatpak, confirmed the issue with original steamcompmgr, then confirmed it works with my forked steamcompmgr.
I confirm. Games start launch in foreground
