You’d probably have to ask whoever makes the Flatpak since IIRC that is not made by Valve.
Any reason you’re not just using the native client? Been using Steam for 4 years on Fedora with no issues whatsoever.
Also:
Silly question, but are you running Fedora in Wayland mode? Or do you run it with X?
Its on Xorg because I am on nvidia right now.
It appears that the flatpak is an official Steam release (at least according to flathub).
I tried the RPM fusion repository and I am having the same issues now (controller not working, games running and closing with no discernible errors).
https://flathub.org/apps/details/com.valvesoftware.Steam
Note: This is a community package of Steam gaming plaform not officially supported by Valve. Report bugs through linked issue tracker.
The “Developer” on Flathub is just the original developer of the software, not who’s making the package.
I havent had Controller issues so far but I can’t say that I’m playing every game in existence so…
Controller not being detected on the native version seems to be fairly common though judging by the ProtonDB entry:
https://www.protondb.com/app/588650
Seems to work fine via Proton though… if that’s a solution for you.
Had that in the past with at least 3 games: Undertale (didn’t start because of missing libs), Deus Ex Mankind Divided (known issue with the native port), and Rise of the Tomb Raider (still no idea if that was just me).
For Undertale it was fairly easy to figure out by starting Steam via the terminal. There’s also an environment variable you can pass for more output, but I forgot what it was. The others ran “fine”, they were just crashing for no apparent reason.
I said it before and I’ll say it again: Native Linux gaming is a mess until Steam or the devs themselves figure out the library dependency issues. Native releases tend to work well on release and get worse over time or don’t work at all (in the case of Undertale for example).
Running any of these 3 games via Proton is way less headache.
1 Like
You know what, I used to hate this comment you said out back then but now I seem to see its wisdom over time. Maybe Proton is the way?
1 Like
I get it, I wish it wasn’t the case, but it’s unfortunately the experience I had over the last couple years 
I don’t know… maybe the Steamdeck will actually do something in that regard over time. Maybe Valve will eventually publish some guidelines how devs can package their games to avoid these issues? I’d imagine it’s a fairly complex issue…
I guess Flatpak could be a way. I don’t know much about Flatpak but I think in theory Valve could release an official Flatpak, and games could then be published/installed as Flatpak extensions? Valve could host their own Flatpak repo after all.
1 Like
ditto
1 Like
i started with Intel based Fedora machine (F28) iirc
and around F30/F31 i switched to Ryzen
but if you meant GPU… then yes
started out with Vega56 , then 5700xt… now a 6900xt
1 Like
I am, yes (Vega 56).
Although controller detection is probably unrelated to that 
And even though I am on AMD, I still had the issues with the games I mentioned above 
That said though I also had good experiences with native games. Black Mesa was amazing to play (except for one hiccup in the middle, still no idea what happened there). Tomb Raider (2013, the first in the Survivor trilogy) was going well as well (with the exception of incompatible savegames to the Windows version and low performance in some areas, but that’s an OpenGL limitation).
If we count RPCS3 as native (because the emulator is native, but the games aren’t obviously) then Demon’s Souls and Nier as well.
And also of course a whole list of games played via wine or Proton.
1 Like
This is my limited experience of native Linux gaming too. Linux is a lot more compatible with Windows software than it is with Linux software.
I wouldn’t say “software” in general, but more specifically anything proprietary like games or workstation-type-software. The latter are usually pretty on point with the support because they (presumably) get a constant stream of revenue from it.
There’s a reason software in official repos gets recompiled with every distro release, even when there were no changes to the source. And that’s just by design of how the Linux software world works. Everything is always supposed to be on the latest version possible (in the constraints of the distros philosophy of course), but just updating the libs would break dependent packages. So to solve this everything gets recompiled on a distro release to fix that issue.
But that isn’t happening for games, and it’s pretty clear why. Once the game is finished, it’s finished. It might receive some bugfix patches but after a year or so there’s no reason to update it anymore. And considering games make the largest part of their revenue in the first 1-2 months of release, updating it years later down the line just to it stays compatible with a tiny fraction of the playerbase is just not commercially viable.
Games that are getting constant updates don’t display this same kind of issue for that reason. Don’t Starve (Together) is a good example. It’s got a native port and it runs wonderfully. Why? Because it’s still getting constant content updates and therefore a revenue stream that makes it viable.
But I guess we’re drifting off-topic.
So the bombshell implication is that games as a service is best case scenario for Linux…
eh, not necessarily. Just need to figure out the dependency issues.
I mean in a perfect world the games would just be open source and could be compiled for each distro. The artworks and stuff can still be closed or copyrighted… but that’s not gonna happen.
I have to say I’m kind of surprised steam doesn’t do something like this from is first attempt at getting mass Linux support. I suppose the endgame is using flatpak to manage all of steam’s game libraries, but I strongly dislike the direction software delivery on Linux is going. I think that shared libraries was one of Linux’s big strengths over Windows in the home desktop space and seeing everything turn into a gigabyte download of repeated dependencies is not something I’m thrilled to see happen across the board just for the sake of compatibility.
They did. It’s called the Steam Runtime, was based upon Ubuntu 12.04, and is a total nightmare for Valve to support, these days. Like already mentioned - Linux ecosystem is built on the idea that source is available, and if it isn’t, you need to support it yourself.
The biggest issue with the Steam Runtime is that it is in a forever state of supporting 32-bit libraries as the world is slowly but surely dropping 32 bit support. Worked fine up until Ubuntu 18.04, after that things got… Messy.
They still do. If you read the error in eel’s log you’ll see it’s still calling that.
Whether that’s still based on Ubuntu 12.04 can be doubted for obvious reasons but it is still there.
This is from a current installation:
$ pwd && ls | grep ubuntu
/home/tarulia/.steam/steam
ubuntu12_32
ubuntu12_64
Doesn’t appear to work quite as well as they thought it would though.
1 Like
These days, with VFIO and virtualisation being a thing, I’m surprised noone has had the bright idea of supporting a qemu VM with GPU passthrough. Just give the game a preconfigured set of values, set up an easy way to give it say, six dedicated CPU cores and one dedicated GPU while running or whatever, and provide a 60 MB full Linux system with all necessary support that boots in like 10 seconds or so. This would solve pretty much all backwards compatibility issues forever.
Ah well.
VFIO is way too niche to support. The idea of telling the average gamer he has to buy 2 GPUs (especially in the current market) is not exactly appealing.
And yes I know 1 GPU VFIO setups are technically possible but… c’mon.
Case in point:
I was meaning to do a VFIO setup and bought most of the parts for it (except for 2nd GPU), but never went through with it because I just can’t be bothered with the hassle. And I’d consider myself an enthusiast user.
Well, depends… Most gamers buy a K chip if they go Intel and AMD seems to do all APU on Zen 4 according to rumors, so that frees the discrete GPU to do fun stuff. Not to mention https://libvf.io
I agree it is currently a hassle, but if someone made it into a Lutris script? 