Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
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,618

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

tuubi Sep 28, 2018
View PC info
  • Supporter
Quoting: scaineI 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.
I think that might be because Redhat is the only company properly pushing for desktop Wayland currently (as far as I know), and in the grand scale of things, there might be bigger priorities for them as well. On the other hand, Wayland has been doing the job perfectly on my old Jolla for years. Mobile was an easier and juicier target I guess, with many interested parties.

I don't know what Canonical tested but I doubt that the protocol itself caused the instability. Must have been the implementation, and in this specific case Gnome's Wayland compositor. Desktop is complicated, and you can probably see that the migration from X to the very different Wayland was never going to be technically simple.

I have no doubt Wayland will some day be the standard on desktop as well, but nearly twenty years on Linux have taught me to be patient. As you said, X might have its faults, but it does the job. That doesn't mean Wayland wouldn't be better.
Scoopta Sep 28, 2018
Quoting: Hori
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 doesn't even work for gaming right now - I'd say "really soon" is greatly exagerated.
People kept saying that Wayland will come soon for the past few years now. It's like those end-of-the-world doomsayers, they schedule a new one each year and then postpone it again.
Even if Wayland does "replace" Xorg, Nvidia will have to do that too. Right now you can't use Wayland with an Nvidia GPU, not if you want to do any gaming on it - and Proton is built for gaming.

I see Wayland and Nvidia as two big issues that are highly unlikely to be fixed any time soon (a few years) - and only after they get fixed can we talk about Wayland slowly becoming popular.

What do you mean Wayland doesn't work for gaming? It totally does if the engine actually supports it, most just don't. Although seeing as most stuff uses either SDL or GLFW there should be indirect support for it. I've actually been meaning to test unreal on Wayland but haven't gotten around to it. As far as the Nvidia problem goes it's just stupid but leave it to Nvidia to be stupid.
vulture2 Oct 4, 2018
Quoting: callcifer
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.

I don't really know about Wine, but AFAIK that claim comes from times before subsurfaces where main problem was that menus couldn't be larger than windows and shared input made it even more problematic

AFAIS, nothing is missing to implement it to work as it should to be 100% conformant with Windows, I'd just guess that they for some reason want to work against the flow and no one really investigated it to do it differently than his point blank assumption. Subsurface in this case is exactly what is needed. It can act as separate window, it is not clipped to window it is being attached to, its origin is always relative to parent surface, subsurface can be surface for another subsurface and so on. The only case when coordinates would matter is for things like floating toolbars which supply screen coordinates on windows for their positioning and sometimes even the screen.

I fail to see one single missing point in how Windows menus work and I coded quite a lot of that in my life. It just requires adapting.

Wine would have quite a few options here. To implement desktop mode only which would be exactly the same as it is on X.Org with virtual desktop as wine allows it.

There is one thing that never made sense to me. What us the point of hiding desktop size when you can call https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/group__iface__wl__shell__surface.html#ga7f134a4466914ef277401d23dfc8a59f and check the size of that surface. You could as well create one maximized surface without any drawing and set everything as its subsurfaces with native coordinates

There are bazillion of solutions here.
scaine Oct 4, 2018
View PC info
  • Contributing Editor
  • Mega Supporter
Sounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on! :D
Scoopta Oct 5, 2018
Quoting: scaineSounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on! :D
I actually really hope so. I personally don't have any bugs with wine in XWayland but I tend to put myself on the bleeding edge. Currently outside of Steam and my steam games 100% of the software I use is Wayland native and so I'd love to see wine work natively in Wayland. That'd at least address the few games I play with proton. Then it's just steam itself and all my native games. Some will probably never support it but one can dream.
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.