Support us on Patreon
PayPalAfter 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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
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 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 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 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.
1 Likes, Who?
Quoting: HoriQuoting: 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.
0 Likes
Quoting: callciferQuoting: 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.
0 Likes
Sounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on! :D
0 Likes
Quoting: scaineSounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on! :DI 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.
0 Likes
See more from me