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,624

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: «2/4»
  Go to:

X6205 Sep 27, 2018
I wonder if Shadow of War will work, currently it does nothing when i click to play, beside installing runtimes. I suspect some Denuvo blocking, but other games with Denuvo are working so who knows..
callcifer 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.

Wine cannot and will not work under Wayland. Windows programs implement menus and dropdowns as separate child windows that are positioned relatively to the parent window. Under Wayland, however, windows are not allowed to specify positions of their children ("for security", lol) so it won't work. Years ago, when Wine developers raised these concerns in #wayland on freenode, they were told to just stick with X because there was nothing to be done.

So no, X.org won't be replaced with Wayland "really soon". Not even close.

EDIT: Michael Müller explained it better than I could:

QuoteIt is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.

One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.

IMHO, it is not a good solution to remove features just because an application could abuse them. I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position. It is like removing the possibility to delete files, because the user could accidentally click on the wrong file, instead of implementing a recycle bin. Adding a way to recover from situations in which programs misbehave would be a better solution, but this is just my opinion.

The opinion from the Wayland developers is that you should stick to XWayland.


Last edited by callcifer on 27 September 2018 at 12:35 pm UTC
tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: callciferUnder Wayland, however, windows are not allowed to position each other ("for security", lol) so it won't work.
I know it's inconvenient, but that "lol" is uncalled for. It's a bit over the top for most users, but not allowing access to other windows is a legit and actually rather obvious security measure. As far as I understand, this can be worked around for legacy applications on a higher level but it isn't straight-forward.
tmtvl 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.

Wayland is the main reason I keep a close eye on native releases. As soon as sway reaches 1.0-beta I'm switching full time.
callcifer Sep 27, 2018
Quoting: tuubiI know it's inconvenient, but that "lol" is uncalled for. It's a bit over the top for most users, but not allowing access to other windows is a legit and actually rather obvious security measure.

This is not about "allowing access to other windows". The only concern here is whether a parent window should be able to dictate where a child window appears. Linux-with-X, Windows and macOS all seem to answer yes. So yeah, it's definitely a "lol" for Wayland.
tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: callcifer
Quoting: tuubiI know it's inconvenient, but that "lol" is uncalled for. It's a bit over the top for most users, but not allowing access to other windows is a legit and actually rather obvious security measure.

This is not about "allowing access to other windows". The only concern here is whether a parent window should be able to dictate where a child window appears.
This does come down to the same technical decision. Don't know if this is their exact reasoning, but if you know where a window is positioned, you can scrape its contents or whatever. Of course they could add a workaround of some sort to the protocol (rememeber, wayland is a protocol, not a piece of software), but they choose not to. They probably think this is something that needs to be solved higher in the stack.

Remember that various Linux toolkits manage to provide pop-up menus that work fine with Wayland. It's just that Windows does it in an incompatible way, and Wine has to emulate that behaviour.
callcifer Sep 27, 2018
Quotebut if you know where a window is positioned, you can scrape its contents or whatever.

These are completely orthogonal features. Saying "put this window over there" in no way implies "also give me its contents".

Furthermore, these are not arbitrary windows we are talking about - there is a parent/child relationship here and there are no security implications whatsoever in giving a parent window full control (yes including contents) over its children. After all, this is how all the other OSes work.

QuoteThey probably think this is something that needs to be solved higher in the stack.

The "they" here are the people in the IRC log I've linked to and they are DE people, not Xorg. And it can't be solved higher up the stack than that because everything downstream of the compositor is restricted "for security".


Last edited by callcifer on 27 September 2018 at 1:26 pm UTC
Corben Sep 27, 2018
I hope they fix the CEG (custom executable generation) copy protection for proton or the Linux clients (steamcmd is also affected). This prevents me of getting Aliens vs Predator running #530
I can copy the binaries from my working wine prefix (I gave AvP a platinum rating on winehq, then it starts, but crashes after a while. Might be CEG or something else. Haven't found out yet. But as AvP will probably never see any upgrades anymore, so it's in a "stable" state, will never see a native Linux version, I'd love to be able to play it on Linux via proton. Even DXVK is working, though I don't have any sound then... but well, that's a different story ;)
And some more games are affected by this: #753

I'm still happy I could get rid of some manually wine prefixes of games, I play on a regular basis. Like Company of Heroes (the first one), No Man's Sky, etc.
tuubi Sep 27, 2018
View PC info
  • Supporter
Quoting: callcifer
Quotebut if you know where a window is positioned, you can scrape its contents or whatever.

These are completely orthogonal features. Saying "put this window over there" in no way implies "also give me its contents".

Furthermore, these are not arbitrary windows we are talking about - there is a parent/child relationship here and there are no security implications whatsoever in giving a parent window full control (yes including contents) over its children. After all, this is how all the other OSes work.
If they just copied what other OSes did, how could they innovate? Wayland wouldn't have gained this much traction if it was just a more modern X. It is simpler, cleaner and more secure than what it was designed to replace.

Besides, you ignored the point that the parent-child window relationship is clearly not required to implement crucial features if current Wayland-compatible toolkits make do without it and have not complained about this. A single Wayland client can manage its surfaces as it deems necessary, but it has no way to influence those of other clients and it cannot expect to manage the desktop. The fact that this is different from Windows and MacOS is hardly a bug. Of course it's understandable that Wine could use a more Windows-compatible feature set and their frustration isn't unfounded.
callcifer Sep 27, 2018
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.

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.
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.