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

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

I can't seem to find the commit / changelog for the .NET fix, could you point me in the right direction? I'm hoping it's related to the issue with launching the Batman Arkham games (though this can be worked around), but I'm assuming it isn't yet.

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

I mean sure wine and proton should be future proofed but leaving existing bugs isnt the way to do that. Plus Wayland has been going to replace X.org really soon for like the last 5 years, and yet here we are still.

I just manually replace my DXVK in Proton to the latest version. Still, it's good to see an update is coming our way - things were too quiet for a few weeks now.

I can't seem to find the commit / changelog for the .NET fix, could you point me in the right direction? I'm hoping it's related to the issue with launching the Batman Arkham games (though this can be worked around), but I'm assuming it isn't yet.

Here: https://github.com/ValveSoftware/Proton/commit/97db8b5d8d2109a3c93e11f1d6f2e8e8957774a0

I mean sure wine and proton should be future proofed but leaving existing bugs isnt the way to do that. Plus Wayland has been going to replace X.org really soon for like the last 5 years, and yet here we are still.

Add to this that most people use a nvidia card with non open source drivers. Right now I can't even switch on Ubuntu to a Wayland session because of that. Nvidia support for Wayland seems far behind.

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

You may want wayland to replace xorg really soon but its not happening for at least three to five years that will give the wayland team to you know fix it so its useable with games.

I can't seem to find the commit / changelog for the .NET fix, could you point me in the right direction? I'm hoping it's related to the issue with launching the Batman Arkham games (though this can be worked around), but I'm assuming it isn't yet.

Here: https://github.com/ValveSoftware/Proton/commit/97db8b5d8d2109a3c93e11f1d6f2e8e8957774a0

Thanks. Yeah, that sure is a minor fix and unrelated to what I was hoping for.

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

You may want wayland to replace xorg really soon but its not happening for at least three to five years that will give the wayland team to you know fix it so its useable with games.

I'm totally okay with the current X.Org. I don't understand it, but as long as it works I don't care. Eg. Canonical wanted to replace it in 18.04.

I still prefer open-source engines (like doom 3), or Feral ported games to Wine. I believe it will never work flawlessly.

Thanks. Yeah, that sure is a minor fix and unrelated to what I was hoping for.

And what are you hoping for?
For me one feature that miss in Wine are the Windows media player components compatibility: a lot of games devs had the worse idea to use Windows Media player component in all their cinematics so they can not play in Wine (Age of empire II, Darksiders etc...).
I know Wine team is working on this, but it will probably be a long way to implement this...


Last edited by legluondunet on 27 September 2018 at 12:02 pm UTC

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

Wine 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:

It 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

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

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

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.

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.

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.

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.

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

They 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

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.

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

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

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