Y’all have to understand how crazy these headlines look to us non-Linux folks. I always get excited when I see something reference wine, then it’s Linux. Then got me extra excited here while I tried to figure out what the tie is between wine and Vulcan’s, and wine and vulcans and performance, and what a penalty might be.
I had a solid 3 seconds of internal absolute wonderful thought chaos as I read this headline and pondered the possibilities.
Steam downloads its own client updates. It’s very rare for them to need to update the flatpak itself because usually any updates can be accomplished through the built in updater.
Mesa comes as separate flatpaks which is hidden in the GUI, and is automatically install when you install a flatpak. The system can have multiple versions of the driver installed. When Steam is ready to use a newer Mesa version, it will do it automatically.
Mangohud, on the other hand, is a flatpak you need to install manually via the command line. You should follow the instruction on their Github page for that.
P.S: In case you like a GUI for things. You should install Flatseal, which provide a GUI for configuring flatpaks.
Makes sense, I was wondering how that worked when I saw some of those in my list. Is that another layer to the flatpak, like a Docker layer or are Flatpaks allowed out of their sandboxes to talk to other Flatpaks?
A flatpak can name extensions that are mounted into the running container if they’re installed.
or are Flatpaks allowed out of their sandboxes
Be careful when thinking of flatpaks as sandboxes. What they confine is (by default) up to the maintainer of each flatpak, and most of the ones I have audited are very permissive.
You can mitigate this somewhat by editing the permissions of each flatpak before running it for the first time, with the command line or a GUI like flatseal. But that only goes so far, since some of the permissions are not fine-grained enough to provide meaningful sandboxing while still allowing games to run. (For example, shared memory and network access.) You might also consider creating a second linux account just for games, and logging in to that account’s desktop when installing or running them.
A Flatpak container is better than nothing, and will probably keep you safe from most programming mistakes, but I wouldn’t consider it a security/privacy sandbox by any means. If you want that, a hypervisor-based virtual machine would be better.
I’m not sure on the exact details of how it sources mesa, but you can check what version of mesa steam is using by clicking help in steam, and selecting “Steam Runtime Diagnostics”. My flatpak steam install reports that I’m using Mesa 24.0.2-arch1.1, which is the same version I get if I check glxinfo | grep Mesa. I’m assuming that means flatpak Steam is using my system’s mesa.
I do have some versions of Mesa installed through flatpak in the form of freedesktop.Platform packages, but they’re older versions than what was reported from inside steam.
I wonder if this will be backported to Proton? I know on the Deck they have a history of backporting fixes and improvements, and this seems like a change worth doing if there is a significant gain here.
I thought that stuff like this couldn’t happen on Wayland by design but maybe that’s only true for keyboard inputs. Unfortunately, I have no idea how to help you but I hope that this information was at least useful to someone who knows more than me.
It’s an issue even on Windows, Some games just like to hog your mouse inputs even when you tab out of the program. Worse is a few games I’ve played that locked my mouse to the middle of the screen when I alt tabbed so I couldn’t click on anything!
I would guess both the game and discord are xwayland and since it all happens on that side that happens.
Seems like a similar thing to the xeyes trick to check if an app is really running on native Wayland: if the eyes don’t move, mouse events aren’t going to an xwayland client.
It’s all xwayland. Wayland support in Wine/Proton is barely usable yet. Even Valve’s gamescope, although a Wayland compositor/client, still only exposes xwayland by default.
I’m in a similar boat. I’ve got a bunch of small Wayland niggles, but I’m waiting to investigate them until after I switch to Tumbleweed when it gets Plasma 6 (I’m currently on Kubuntu).
Really enjoying Tumbleweed so far. The extra testing cycle they do versus Arch has a measurable effect on stability and need to fiddle with things after a routine system upgrade.
I had to downgrade it to play anything on my ultrawide, some really weird stuff happening in 9.0 with multiple monitors. It can’t detect mouse input on the right 1/3 of my screen. Very glad they let us choose versions
I would guess to help excuse [compatibility] errors. Make you cognizant of the experimental nature, perhaps head you off before complaining to the developers.
There’s no way to set it as default completely. You can set it as default for titles that Valve hasn’t explicitly overriden, but if Valve decides that a certain game works with Proton 8 or Hotfix, it will automatically install those. I really wish there was a way to force Experimental in all cases.
linux_gaming
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.