You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!

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

Posted by , | Views: 10,003

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.

27 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more information here.
37 comments
Page: «4/4
  Go to:

scaine 27 September 2018 at 10:01 pm UTC
View PC info
  • Contributing Editor
  • 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 28 September 2018 at 1:00 am UTC
legluondunet
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".
tuubi 28 September 2018 at 9:29 am UTC
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 28 September 2018 at 3:35 pm UTC
Hori
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 4 October 2018 at 1:09 pm UTC
callcifer
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 4 October 2018 at 3:58 pm UTC
View PC info
  • Contributing Editor
  • Supporter
Sounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on!
Scoopta 5 October 2018 at 7:03 am UTC
scaineSounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on!
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.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Community Livestreams
  • Everspace - Live. Fight. Die. Repeat.
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts