Imho, linking to GitLab (source) is the best way to share on Lemmy. I see news about the Wine 10 release all day, and these are not shown as crossposts due to different links. Here are some other crossposts:
I really hope Proton 10 will have some sort of Wayland support, even if it would be hidden behind an environmental variable
We also need a native Wayland client for Steam, though it’s tied to Chromium Embedded Framework’s native Wayland support. Probably it will come with Electron’s support. No idea when.
Could you elaborate on the advantages, I’m using wayland and steam for games, no issues so far.
It’ll be more performant, lower latency, have proper HDR support (current method is a hack), scale properly based on your displays, and probably be generally less buggy long-term (probably more buggy when it first gets added since it’s a pretty fundamental change).
You’re currently using a compatibility layer called xwayland to run it, which adds a ton of cruft.
HDR support
Doesn’t valve already use gamescope (Wayland compositor) with HDR support? And KDE?
Yes, but it’s a hack, when it’s properly implemented you won’t need gamescope and it won’t have to be fullscreen as far as i’m aware, although i could be wrong about the fullscreen thing.
Ah, I guess the HDR support in Wayland is still exposed via an “experimental” interface. But it looks like a handful of Wayland compositors support it, including wlroots which a bunch of smaller compositors are based off of.
Even with support from the compositor, you need support for it in every part of the graphics pipeline.
Currently you can either use Wine with Wayland + Vulkan layers + KDE or gamescope + KDE (or gamescope directly in TTY).
wlroots doesn’t support HDR.
Ooo, the MR it links to is 10mo old and still open.
Fractional scaling
xwayland*
I really hope Proton would stop running a container. It makes running additional programs harder (opentrack for example) and our computers less ours
No way. Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.
It makes running additional programs harder (opentrack for example)
Then we need better tooling and documentation to interact with the container, not to get rid of them. I don’t see any technical limitation that would prevent your use case. It’s just not implemented or maybe simply undocumented.
our computers less ours
How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.
Containers are good for a number of reasons, and definitely will not and should not be going away, instead use one of these tools to bypass it:
It’s a real hassle for running headtracking. And once they take away the possibility to run xterm instead, we won’t even be able to take a look inside
I’ll take a look at protonhax, thanks. But I’m afraid that will still require to run opentrack twice
Does it? What containerization does it use? I thought it was similar to wine, just a process pointed at a windows exe, and an environment to make the app think it’s running in a windows filesystem.
It’s a custom solution called pressure-vessel, which seems to be based on flatpak. You can read about it here. This is used to create a reproducible linux environment and has nothing to do with the windows translation layer. They run wine (proton) inside the container as you would expect.
There is a recent effort to port this solution outside of steam in the form of umu. As far as I know it’s in a working state but I don’t know if it’s at feature parity with steam, especially on the game-specific fixes front. The end goal is to be a universal launcher that can be used from all frontends, so that all windows games run reliably and identically regardless of which GUI you use to manage your games.
EDIT: welp, I just now noticed this info has already been posted by another user 🤷
Something internal. In order to run a third party app with access to the process (like headtracking), the only way I’ve found out to achieve that was to download a windows version of opentrack too and run it twice. One on Linux side, one inside the container and make them talk to each other via UDP
Wow, I’m impressed you actually got that working. Sounds like quite a hack.
Yes it does.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md
I believe there is a project to add a Steam independent version of it to Bottles, Lutris, and other proton guis.
Ahh, I always wondered what “pressure-vessel” was. Thanks for the resources.
Thought this was a satire until I realised that Wine is a linux application
What is Wine anyway? All I can work out is that it definitely is not an emulator… (probably it’s a fermented drink made from grapes, but implemented in Linux.)
The bottle thumbnail doesn’t help either. lol
Dvorak at last
By better hidpi support, does this mean that those “windows” specific windows that launch sometimes when I do things wine related will actually have a normal size on my 4k monitor instead of being microscopic?
deleted by creator
Have you tried lutris?
