Quoting: scaineI wish I had your knowledge of wine, ngl. I understood most of those words, but they aren't lining up a message I can take in.

Heh, a lot of it comes with just getting your hands dirty and a whole lot of time. I'm no Wine developer though! That is all way beyond me.

If there's anything I can explain better, let me know! Sometimes I'm too verbose. A lot of the information such as what registry keys to set etc came from the Wine 9.0 release notes [External Link] (it took me a while to figure out how to "unset" the "DISPLAY" environment variable though) and I wanted to try and collate as much as I could. That would also make it easier for others to correct any steps I did wrong.

I think the main thing I was able to find out (which might be wrong, and I'm more than happy to be corrected) pretty much boils down to:

• Valve aren't building Proton 9.0's Wine with Wayland enabled, as the Wayland backend is opt-in at the moment.


• There could be a few reasons for this. The Wayland driver still isn't ready for "prime time" in the context of gaming (there are still some issues in some games, Frogging-Family/wine-tkg-git#1110 (comment) [External Link] ), and also the Steam Overlay does not support Wayland (if you run newer native SDL2 games such as Factorio with "SDL_VIDEODRIVER=wayland %command%" in the launch options, the Steam Overlay will not work, ValveSoftware/steam-for-linux#8020 [External Link] ) and this could also have implications for controller support etc. So there is no reason to build their Wine 9.x fork with Wayland just yet. There could also be some more build dependencies, I don't know a whole lot about building Wine but I think the Arch folks had some concerns about this (GitLab: archlinux/packaging/packages/wine#11 (note) [External Link] ), and I have no idea how something like this might impact the build process for Valve Wine.


• Builds of Proton that use Wine 9.x with Wayland enabled (as in enabled at build time and also properly enabled in the prefix), are able to use the Wayland backend, but seemingly not within Steam for some reason.

Quoting: scaineI choose a version of Proton in Steam and click play. Very rarely, when I do this, the game doesn't quite run correctly, and I have to try a different version.

It's really a testament to how far we've come. A lot of work from so many talented people has brought us to this point. Anyone remember Wine Steam and the workarounds to get it to run, like --no-cef-sandbox? Not to mention the work done on the Mesa graphics drivers side to get games running as good as they do now.

I was a nay-sayer when I heard about Proton back in 2018, I actually thought it would kill Valve. I figured they'd lose immense amounts of money on this and we'd lose Steam, I was very doomsday about the whole thing. I'd been messing with Wine and didn't really acknowledge it as anything more than something to experiment with. At the time I had no idea about DXVK, esync, or anything else. I was still using vanilla Wine for my gaming experiments, and figured that's how Proton was going to be.

And then I tried Proton (I was shocked at how easy it was to enable and did not believe it would work), and after I did and every single game I tried worked flawlessly (at the time, and after I moved them off my NTFS drive), I got rid of my Windows partition and did a full all-in Arch install -- The same install I'm using right now actually! I did a full playthrough of Yakuza 0 and it was utterly magical.

I did eventually find some games that needed workarounds (Yakuza Kiwami iirc needed you to build Wine with a custom patch posted by CodeWeavers(?) on the Proton issue tracker), some games worked but weren't performant for a while (A Hat in Time benefitted immensely from D9VK, now part of DXVK) and some games didn't work until a few weeks ago (Catherine Classic now works with GE-Proton afaik, but I bought it at launch in early 2019), but even now with 1921 games according to the Steam library dropdown, I haven't had a case where a game didn't just work in a long time. I was delightfully proven wrong.

When Valve announced the Steam Deck, I saw some people with the same attitude I had back when Proton was announced. I think a lot of those people were proven wrong just like I was too!

There is rarely any need to tinker these days, so you normally don't have to do anything beyond what you described. I was just being nosy about whether I could try out the Wine Wayland driver with Proton 9.0 now that it uses Wine 9, not even really for practical purposes, just to see what kind of fires there were. :wink: Once Wine Wayland is all enabled by default, you should be able to just press "Play" and have your games running natively on Wayland and just take it for granted, just like how a lot of the time these days we take Proton for granted.

View this comment - View article - View full comments

If anyone is curious: It appears that Proton 9.0 is not built with the Wine Wayland backend enabled. When building Wine I believe you have to use the "--with-wayland" flag - See example in Wine-tkg build system's wine-tkg-git build.sh script [External Link] and this Arch Wine packaging issue [External Link] where they didn't enable Wayland support at first for the Wine package

Trying to run a prefix that has the "Graphics" regstry entry at "HKCU\\Software\\Wine\\Drivers" set to "x11,wayland" will work when running with my system Wine (and using "DISPLAY=") with the same prefix, but not with Proton 9.0 Wine.

Example commands using the same prefix but with Proton 9.0 versus System Wine 9.2:
- (Using Proton 9.0 Wine fails with "The graphics driver is missing. Check your build!") DISPLAY= WINEPREFIX="/path/to/steamapps/compatdata/<appid>/pfx" "/path/to/steamapps/common/Proton 9.0 (Beta)/files/bin/wine" regedit
- (Using system Wine 9.2 in place of Proton 9.0 Wine works as expected) DISPLAY= WINEPREFIX="/path/to/steamapps/compatdata/<appid>/pfx" wine regedit

This is not a huge deal for now, but something worth noting. :smile:

EDIT: Interestingly, using a build of Proton-tkg based on Wine Master, I can run the Wine Wayland backend with things like Winecfg and regedit, but when passing "DISPLAY= %command%" as a launch option, games cannot launch from Steam. The Proton log errors with "Application tried to create a window, but no driver could be loaded.", "Make sure that your X server is running and that $DISPLAY is set correctly." - So I guess using the Wine Wayland driver with Steam right now is a bust. Fwiw, using Wine-tkg based on Wine Master, games can launch (although it is not a great experience if you have a multi-monitor setup with only one or two scaled displays, but the others unscaled, and the Wayland driver has no fractional scaling support yet so applications look blurry unless you're using 100%/200%/etc scale).

View this comment - View article - View full comments

Another game for the "ignore" list :smile:

View this comment - View article - View full comments

I don't think Persona 3 Reload makes it clear, but the "Reflections" setting is what toggles ray-tracing. On desktop at 4k and Steam Deck at 800p, I don't see any visual difference, but I a massive performance boost on Steam Deck with it disabled (although the game does drop to ~50fps in quite a few areas, and toggling any other setting apart from resolution scale doesn't help).

The Preview channel seems to have helped performance by a lot though, the "Reflections" setting has much less overhead.

View this comment - View article - View full comments

Quoting: a0kamiWayland support already ? Wow, that's nice

This specific PR has been in the works for two years (GodotEngine/Godot#57025 [External Link] was the initial PR, and a separate PR containing the same code changes + PR feedback was made at GodotEngine/Godot#86180 [External Link] with squashed commits and rebased against master), but there have been attempts to implement Wayland support into Godot as far back as Godot 3.x in 2019 with GodotEngine/Godot#27463 [External Link].

View this comment - View article - View full comments

Quoting: CatKillerWow. I sunk a load of time into that when I first switched to Linux. It worked fine in Wine back then.

The game still worked fine until Wine 9.0-rc3 recently, and I guess the regression snuck into Wine 9.0. You can see the Wine bug report here: https://bugs.winehq.org/show_bug.cgi?id=56119 [External Link] (Looks like it was a specific regression in Wine's DirectDraw implementation? https://gitlab.winehq.org/wine/wine/-/commit/ee7d047dd55a4b2338eb2d64f85b7d984b39812f [External Link] )

So, it wasn't broken for very long. :smile:

EDIT: I misread the issue originally and thought the user meant the issue was only present in 9.0-rc3, but they just reverted the commit on 9.0-rc3 (presumably the latest at the time, 30/12/2023). The issue notes this was broken since Wine 8.18, and the offending commit is 3 months old. So, it was broken for a few months. Not great, but not the end of the world either way (and with Wine-GE, which many use for gaming over vanilla Wine nowadays, you may have not have been impacted).

View this comment - View article - View full comments

Have you picked up a copy? Or are you skipping it for whatever reason?

Very similar to what another user mentioned, the comparison to ARK has definitely put me off. I am also hesitant now moreso than ever because of the plans to include PvP (to me, this is a singleplayer experience). They do offer dedicated server software but I'm conscious that they may end up including Epic Online Services or some form of client-side Anti-Cheat. It does use Unreal Engine 5 if I'm not mistaken, and they plan to include crossplay, so I'm very cautious of this game.

The developer also has another game in Early Access, Craftopia, which has been in Early Access for a few years now. This isn't as huge of a factor for me as it is for others, but something that is in the back of my mind.

But mainly, I'm conscious of not getting caught up in launch hype for a game. I prefer to wait until things settle down (which is why I haven't bothered with Baldur's Gate 3). It's a psychological thing I think, when there's a lot of mainstream hype around a big release, it creates too much pressure to play the "in" thing.

The gameplay seems fun at least, and like it would have some cute moments, the pricetag seems about right too. But until that player count sinks down and until I see how they implement crossplay, I'll be holding out.

View this comment - View article - View full comments

Quoting: ShmerlSteam Deck is already using fsync with corresponding kernel API, so it already benefits from better than wineserver approach

To this point, most custom kernels (i.e. Tkg, Zen) already have fsync too! :smile: It is disabled for some games when Proton auto-detects them though, for example Yakuza 0 does not use fsync (uses option `nofsync`), but NieR:Automata does (you can check if a game is using esync/fsync and what options it has by inspecting the Proton log, enabled in launch options with PROTON_LOG=1).

View this comment - View article - View full comments

Very cool to see another game using DXVK Native, it has come a long way!

View this comment - View article - View full comments

Quoting: CookiesHow does the HDR option work? Is it enabled out of box or in game settings? Is it SteamOS only or any distro?

To my understanding, it simply tells a game that this platform can support DRM, and allows you to enable it.

This option should work on any distro if your window manager and GPU drivers have support. The work on the Proton side is part of DXVK/vkd3d-proton, which got HDR support last year (requires env var DXVK_HDR=1). Window managers are another story though, for example right now KWin Wayland development versions of Plasma 6 has early HDR support and it should ship as part of Plasma 6. GameScope (in an Embedded Session only, maybe?) has HDR support, which is why the Steam Deck supports HDR. There may be some configuration options required though, see `gamescope --help` for a list of the options that you might need/want to tweak for HDR.

In short, it tells games that you can enable HDR (as many games will grey out the option by default), and it should work on any distro but right now it's mainly SteamOS that has all of the components together by default - If you do this manually, or if your distro is bleeding-edge enough and happens to do this, it should work there as well. SteamOS just has the most out-of-box HDR experience at the moment.

View this comment - View article - View full comments