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

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

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

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.

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.

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.

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.

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

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.

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.

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.