You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues

By - | Views: 23,779

After some pretty quick updates following the initial release of Steam Play, things have quietened down somewhat. However, work on the next version of Steam Play is in progress.

It was expected it would slow down after the initial release period, since they were rapidly pushing out fixes to get it into a somewhat stable state. Stable enough for them to put it into the main Steam client that is, since you no longer need to opt into any beta to access Steam Play.

Going over some recent changes: DXVK 0.72 has already be pulled in, along with a small fix for .NET launchers failing. The update to DXVK by itself is a pretty big deal, considering the amount of fixes and improvements that make it into each release. Steam Play's Proton is currently on DXVK 0.70 which is three versions behind now.

Looking at the custom build of Wine they're using, there's a good few windowing issues being fixed including issues with multiple monitors, a workaround for black screens on alt+tab (a bug in mutter) and better ALT+F4 handling for the GNOME Shell desktop.

No idea when the next version will come, since Valve haven't given out any sort of roadmap for it. You can see any info across Valve's various GitHub repositories.

Article taken from GamingOnLinux.com.
Tags: Steam Play, Valve
25 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
35 comments
Page: «3/4»
  Go to:

tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: callcifer
QuoteWayland wouldn't have gained this much traction
On the desktop? 90%+ of Wayland usage is on not-desktop, like car infotainment systems. On the desktop, anyone using Nvidia is by necessity on X11 which, according to this very website, is almost 70% of users. So if anything has traction on desktop, it's X.
All major desktop toolkits working on Wayland support and distributions aiming to make it the default sure seems like traction to me. Of course I'm not expecting X to go away completely any time soon. Speaking of Nvidia, I expect they will come up with support as soon as their workstation clients demand it.

Quoting: callcifer
Quoteclearly not required to implement crucial features if current Wayland-compatible toolkits make do without it and have not complained about this. [...] Of course it's understandable that Wine could use a more Windows-compatible feature set and their frustration isn't unfounded.

It doesn't matter one bit what "Wayland compatible toolkits" are doing. Wine runs Windows programs. That's its entire reason of existence. As long as Windows uses windows to implement menus and dropdowns, Wine needs to do that too. So the responsibility in fixing this lies not with Wine people, but with the protocol and DE folks who, as you can see, are not interested in solving it.
I don't follow your reasoning. Wine has a problem, so Wayland needs to fix it? Since when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks? Can't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.
callcifer Sep 27, 2018
Quoting: tuubiI don't follow your reasoning. Wine has a problem, so Wayland needs to fix it?
Wine doesn't have a problem, Wine works just fine. The problem was invented by DE people who think their compositors should prevent clients from positioning their own children. Naturally, Wine cannot solve a problem in a compositor's code.

Quoting: tuubiSince when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks?
Wine isn't a compatibility layer, it's the compatibility layer. When it comes to Linux adoption on the desktop it's one of the single most important pieces of software, ever.

Quoting: tuubiCan't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.
What's required is for them to let windows position their own children. Not one DE developer managed to articulate why exactly that would be a security problem. And yes, that IRC log contains most of that discussion.


Last edited by callcifer on 27 September 2018 at 2:36 pm UTC
tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: callcifer
Quoting: tuubiSince when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks?
Wine isn't a compatibility layer, it's the compatibility layer. When it comes to Linux adoption on the desktop it's one of the single most important pieces of software, ever.
I get why you'd say that, and I think Wine is a really cool piece of software, but it's still something I've never depended on for anything important. It was certainly not a factor in my adoption of Linux on the desktop all those years ago. Maybe the DE devs (or their employers) aren't that bothered about Windows software either.

Remember, Linux isn't a coherent community working for a single goal. We're a bunch of people and organisations with different priorities. That said, I bet a company of Valve's resources should be able to influence this, maybe by providing their own (fork of a) DE/compositor that's a better fit for Wine or simply by starting a discussion with the relevant developers.

Quoting: callcifer
Quoting: tuubiCan't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.
What's required is for them to let windows position their own children. Not one DE developer managed to articulate why exactly that would be a security problem.
Wayland client windows don't know their own position on the desktop, so why should they be able to influence that of others? By my understanding of the Wayland design, if a (child) window needs special handling as a part of the UI, it shouldn't be a generic window but a surface directly controlled by the client. That's simply how the protocol was designed and I know it's different from what we're used to. This is a form of enforced sandboxing and a security feature.
the3dfxdude Sep 27, 2018
Quoting: lqe5433Wine is only working with X.org, and X.org will be replaced with Wayland really soon, so I don't see the point of this. Games should use SDL2 on Linux, or Wine needs to use Wayland.

That's the desktop-gaming oriented popular media opinion. I see linux usage in many companies, and there is no way Wayland will replace Xorg anytime soon. Xorg will continue to be the defacto standard for many years because that is where the real money is. Valve will likely continue to support the largest platform for market share as well.
gustavoyaraujo Sep 27, 2018
There is an interesting issue I have noticed yesterday:
Tried to play SEGA GENESIS & MEGA DRIVE CLASSICS with a friend, he was on Windows,
and We couldn't play online due to a different platform block...
Looks like playing it on Linux really counts like so, but for multiplayer games, the invite on Stem doesn't work.

Can some check if this issue is happening in other titles?
Comandante Ñoñardo Sep 27, 2018
I hope they fix also the "press SPACE to continue" bug in Bioshock 2 Remastered...
I know there is a workaround with PROTON_NO_ESYNC=1 %command% -nointro
Or using an Xbox controller for to pass that screen.. But the game should work out of the box.

In my opinion, Proton Devs must focus first in the compatibility of the BIG franchises and big AAA games...
tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: the3dfxdude
Quoting: lqe5433Wine is only working with X.org, and X.org will be replaced with Wayland really soon, so I don't see the point of this. Games should use SDL2 on Linux, or Wine needs to use Wayland.

That's the desktop-gaming oriented popular media opinion. I see linux usage in many companies, and there is no way Wayland will replace Xorg anytime soon. Xorg will continue to be the defacto standard for many years because that is where the real money is. Valve will likely continue to support the largest platform for market share as well.

I don't think either of these assessments is accurate. Most companies that use Linux simply do not care beyond the obvious: Things should work reliably and securely. Not many businesses depend on Xorg directly. This doesn't mean there's not a lot of work to do and a lot of inertia to overcome.

I can think of Redhat as one of the companies that actually do care, and they're rather enthusiastically pushing for Wayland, with Canonical now in the same boat. I don't remember any big company being against this development yet, but I might have missed something.
Purple Library Guy Sep 27, 2018
Quoting: lqe5433I still prefer open-source engines (like doom 3), or Feral ported games to Wine. I believe it will never work flawlessly.
Well, it is supposed to be (non-)emulating Windows, after all. Working flawlessly would be quite inaccurate. ;)
scaine Sep 27, 2018
View PC info
  • Contributing Editor
  • Mega Supporter
I had such high hopes for Wayland. Then nothing visibly happened for nearly a decade and only in the past year or so we're seeing talk of it becoming a thing (as an end-user - of course, lots of talk about it in development circles). Except, I run Nvidia, so that's pretty much that.

As for "Nvidia will support Wayland when their customer base demands it", well maybe. But I won't be demanding it - X works just fine here and I can't see any benefit in moving to Wayland. Things like "it's more secure" don't matter much on a single-user system and if you're telling me Wine is broken on Wayland, well Wine is way more important to me than an immature-but-somehow-more-secure graphics stack.

I want what works. Wayland feels like a solution a problem that doesn't really even apply today.

I thought it would give us seamless discrete card switching, better multi-monitor, smooth window scrolling everywhere, better switching into/out of fullscreen games, less tearing, more reliability. In fact, none of that has really happened. Indeed, Canonical found it less reliable and more likely to crash the whole session.

I see the point of it (cleaner code, more modern architecture), I just don't see why people care so much when it all boils down to is "it's cleaner behind the scenes". Especially when it actually brings major pain points to actually deal with - all the DEs having to support branches which support Wayland, no network support, no driver compatibility.

I feels weird to me.
Cybolic Sep 28, 2018
Quoting: legluondunet
Quoting: CybolicThanks. Yeah, that sure is a minor fix and unrelated to what I was hoping for.

And what are you hoping for? [...]
I was hoping for what I mentioned in my quote just above ;)
"I'm hoping it's related to the issue with launching the Batman Arkham games [...]"

There are currently issues with launching those games (and others relying on .NET, that can be solved by launching the game first with the Windows version set to XP and then again back to the default Win 10. It's a fairly trivial fix and they're popular games, so I'm just hoping to see it made easy for "the common folk".
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.