vchernin
commented
2 years ago I wonder how involved a fix for this will be. Are there any relevant debug logs we can get?
Open CyborgDragonFire opened 2 years ago
vchernin
commented
2 years ago I wonder how involved a fix for this will be. Are there any relevant debug logs we can get?
xinyazhang
commented
2 years ago Fedora 34 (my primary OS) only ships Flatpak 1.10.x so probably I cannot verify how it works, for now. (Upgrading to 35 may help but it also risks breaking my current workflows. I have to pick up a relatively free time to do this. Note: Christmas is not guaranteed Okay for my case.)
In addition I think older flatpak installations will not retire any time soon (Debian 11/CentOS 8/Ubuntu 20.04/etc), so we need to maintain the compatibility with both the older and new setups for a while.
P.S. I'm still maintaining this package, but not monitoring the upstream so this package is not updated in a timely manner. Feel free to send pull requests and I'll merge them if it looks fine.
CyborgDragonFire
commented
2 years ago This happened to MangoHud as well, it stopped working, when it switched from:
com.valvesoftware.Steam.Utility.MangoHud
to
org.freedesktop.Platform.VulkanLayer.MangoHud
From memory there were Two issues, one being it was in the wrong branch, "master" instead of "21.08" And the second was that steam & proton were not picking up the path correctly.
I went back to try and find that issue again, but I COULD NOT FIND IT. It's gone. Was it deleted? Why?
But the config to temporary fix everything was something like:
"XDG_CONFIG something, something = really long path of stuff that magically fixed it somehow and got it all working again"
It was an environment variable override, that you added with Flatseal, and it was for proton to tell it to re-add MangoHud to the path, so it could work again. In short, @gasinvein is a wizard. And we could really use his magic over here, or at least pointing out where that issue that explained all of this went to.
So, as far as I'm aware from following along the MangoHud issue, this needs to be fixed on the proton side eventually, but there is a stopgap we can use in the meantime. Or I could have gotten all of this wrong, that missing MangoHud issue was quite technical.
Either way I'm willing to help out in any way that I can, if you need something just say.
PS @xinyazhang would it be ok if I edited the README.md to add some better documentation to this project, so we could close issue #1
gasinvein
commented
2 years ago @CyborgDragonFire
It was an environment variable override that you added with Flatseal for proton to tell it to re-add MangoHud to the path, so it could work again.
You don't need it anymore, official Proton should be able to pick up MangoHud now (a workaround on the Steam flatpak app side was applied).
CyborgDragonFire
commented
2 years ago Yes, that is completely accurate for MangoHud. We would like to whip up something similar to what you did, but for this gamescope package. Allow flatpak gamescope to work with proton nested sandboxes as well. But we can't find the issue thread where you discussed it and found the solution.
How did you get MangoHud working in a nested sandbox? So we can apply that same or similar solution to this gamescope package.
gasinvein
commented
2 years ago I don't know much about gamescope and what it does, but I'm pretty sure the issue with it is an entirely different one.
The issue with official Proton was that pressure-vessel didn't mount the extension directory with MangoHud, because it has no way of knowing about it. The applied workaround is adding the share subdirectory of the extension to the apps' XDG_DATA_DIRS environment variable, which pressure-vessel does know of.
CyborgDragonFire
commented
2 years ago OK, so for everyone's befit, I opened Flatpak Steam from the terminal and did a test. I started a test game from my collection, in 4 different ways:
The results were:
My current setup is Manjaro. Flatpak: 1.12.2 Official Proton: 6.3-8 Community Proton: 6.3-7
Hopefully this helps you guys debug this issue. Just a warning the log ended up being almost 1,800 lines long.
xinyazhang
commented
2 years ago PS @xinyazhang would it be ok if I edited the README.md to add some better documentation to this project, so we could close issue #1
You're welcome!
Alex-Bujorianu
commented
2 years ago I cannot use Gamescope with the Flatpak version of Steam, not even with Linux native games like Valheim. EDIT: I installed the Flatpak version of Gamescope, com.valvesoftware.Steam.Utility.gamescope and it works now. However, the Flatpak version seems to be out of date, as it does not recognise the FSR option (-U).
CyborgDragonFire
commented
2 years ago @Alex-Bujorianu Yes the current flatpak gamescope build is out of date at time of writing, there is already an open issue about the delay #8, and you can follow the update progress here #11 The rest of your comment is off-topic for this issue, but stems from the lack of beginner-friendly documentation, we are aware of this and are working on it.
TheGreatestJannet
commented
2 years ago Any progress on this? Is it still broken? I have tried it with Elden Ring, the game launches but from the looks of it it still isn't working with Proton Experimental on Flatpak Steam.
doraskayo
commented
2 years ago I'm not sure if it was mentioned already, but the remaining issue with the official Proton versions and gamescope is with Flatpak itself.
gamescope launches its own Xwayland instance(s) inside the sandbox and expects games to use them as their X server. However, when the Flatpak portal is used internally by Proton's pressure-vessel to launch a Flatpak subsandbox for a game, Flatpak only exposes the host's X11 socket to the subsandbox, and not the X11 socket created by gamescope's Xwayland instance in the main sandbox. This is why the game window opens as a separate window in the desktop and not inside the gamescope window, and why we effectively lose the "gamescope functionality" as mentioned in this thread with official Proton versions.
The unofficial Proton versions provided in Flathub do not package or use pressure-vessel. In this case there's no subsandbox involved and games have access to gamescope's X11 socket because they run in the same sandbox. This is why using unofficial Proton versions "works around" the issue.
The bottom line is that Flatpak seemingly assumes that a Flatpak app would never launch an X server that a subsandbox would need to access. I haven't found an issue discussing this limitation in Flatpak's GitHub, so I'm not sure if anyone is aware of it.
Edit: note that it may be possible to get this working with some specific support for this use case in pressure-vessel itself (potentially with additional changes to gamescope). For example, moving gamescope's X11 sockets to ~/.var/app/$APP_ID/sandbox to be exposed to the subsandbox, and then relocated to /tmp/.X11-unix inside the subsandbox right before launching a game. However, I'm not familiar with the capabilities and limitations of the Flatpak subsandbox enough to tell if this is indeed possible.
@smcv, FYI
smcv
commented
2 years ago The bottom line is that Flatpak seemingly assumes that a Flatpak app would never launch an X server that a subsandbox would need to access
Yes, Flatpak makes that assumption. Gamescope is one of only a few things that wants to do this, so it's a reasonable assumption.
Some directories are already shared between Steam and the subsandbox, so there are multiple places where gamescope could create a socket that the subsandbox will be able to see (/tmp and $XDG_RUNTIME_DIR among others), but doing this for /tmp/.X11-unix is complicated by various things:
/tmp/.X11-unix to protect unrelated X11 socketsDISPLAY environment variable normally gets inherited from the host, not copied across IPC from the first Steam sandboxIf gamescope could somehow be taught to create its socket in $XDG_RUNTIME_DIR, and just put a symlink to it in /tmp/.X11-unix, then the process that's launched in the subsandbox could be a wrapper that creates a similar symlink in the subsandbox's /tmp/.X11-unix and then execs the actual game? (But the wrapper would have to be either a shell script, a python3 script or a statically-linked binary, because it will be run in a library stack that is not the Flatpak runtime.)
doraskayo
commented
2 years ago @smcv, do you think introducing an --allow=per-app-x11 option in Flatpak to essentially share the /tmp/.X11-unix directory of the app with its subsandboxes would be a reasonable (and technically viable) first step to remove this limitation? The second step likely being to pass the DISPLAY environment variable specified by the subsandbox invocation to the subsandbox.
I get the feeling that making this work through other means would sacrifice compatibility. For example, if an app opens the X11 socket without following symlinks, expects it to be a socket file for security reasons, etc.
gasinvein
commented
2 years ago It seems like flatpak/flatpak#5036 would be helpful here as well.
orowith2os
commented
1 year ago @gasinvein I don't think it will be. Just being able to access the host's X sockets isn't the same as being able to create them, which is one issue I've had with Distrobox before. The only solutions are to either apply an overlayfs or chown /tmp/.X11-unix.
Being able to share the X sockets with subsandboxes seems like the most reasonable solution.
gasinvein
commented
1 year ago Just being able to access the host's X sockets isn't the same as being able to create them
That issue is about sharing /tmp/.X11-unix with host, not just mounting all the sockets that were there when the accessing app was started. If --filesystem=/tmp/.X11-unix could work in flatpak (it doesn't), it would've solved the issue.
orowith2os
commented
1 year ago Migrated to the new extension at https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.gamescope/issues/6
Now that it seems that this package is back from the dead, I would like to bring this long-standing issue to light.
Since Flatpak 1.11.1 beta or later, Flatpak allows for nested sandboxes, like the sandboxes used by Proton 5.13 & Proton 6.3 This gamescope package does not work with these nested sandboxes.
Before the Flatpak 1.11.1 beta, Proton 5.13 & Proton 6.3 would not work with flatpak. Here is the issue from Steam package: https://github.com/flathub/com.valvesoftware.Steam/issues/642
To get around this issue, the community created flatpak specific versions of Proton & Proton-GE:
com.valvesoftware.Steam.CompatibilityTool.Protoncom.valvesoftware.Steam.CompatibilityTool.Proton-GEThis gamescope package only works with the community made Proton versions, Not the official versions.
The current stable Flatpak release is 1.12.1 With this current Flatpak release, I can install Steam and play like I normally would with a native non-flatpak install. I can select Proton 6.3 within the Steam GUI, launch games, and they work perfectly in flatpak just like native. And with the latest versions of MangoHud & vkBasalt they work seamlessly with the standard releases of Proton & Proton-GE as well.
org.freedesktop.Platform.VulkanLayer.MangoHudorg.freedesktop.Platform.VulkanLayer.vkBasaltHowever, this seamlessness is not the case with this flatpak gamescope package. Again it requires the unofficial unsupported community made Proton versions.
It is time this was fixed. Because it is quite jarring for everything else to work great but then when you try to play that one game that needs gamescope to work better, and it doesn't seamlessly work like everything else you are left there scratching your head ... until you remember you have to install the community Proton build.
This fix could also be useful to other applications using nested sandboxes like HeroicGamesLauncher when it finally gets a flatpak release.