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

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.

All major desktop toolkits working on Wayland support and distributions aiming to make it the default sure seems like traction to me. Of course I'm not expecting X to go away completely any time soon. Speaking of Nvidia, I expect they will come up with support as soon as their workstation clients demand it.

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.

I don't follow your reasoning. Wine has a problem, so Wayland needs to fix it? Since when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks? Can't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.

I don't follow your reasoning. Wine has a problem, so Wayland needs to fix it?

Wine doesn't have a problem, Wine works just fine. The problem was invented by DE people who think their compositors should prevent clients from positioning their own children. Naturally, Wine cannot solve a problem in a compositor's code.

Since when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks?

Wine isn't a compatibility layer, it's the compatibility layer. When it comes to Linux adoption on the desktop it's one of the single most important pieces of software, ever.

Can't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.

What's required is for them to let windows position their own children. Not one DE developer managed to articulate why exactly that would be a security problem. And yes, that IRC log contains most of that discussion.


Last edited by callcifer on 27 September 2018 at 2:36 pm UTC

Since when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks?

Wine isn't a compatibility layer, it's the compatibility layer. When it comes to Linux adoption on the desktop it's one of the single most important pieces of software, ever.

I get why you'd say that, and I think Wine is a really cool piece of software, but it's still something I've never depended on for anything important. It was certainly not a factor in my adoption of Linux on the desktop all those years ago. Maybe the DE devs (or their employers) aren't that bothered about Windows software either.

Remember, Linux isn't a coherent community working for a single goal. We're a bunch of people and organisations with different priorities. That said, I bet a company of Valve's resources should be able to influence this, maybe by providing their own (fork of a) DE/compositor that's a better fit for Wine or simply by starting a discussion with the relevant developers.

Can't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.

What's required is for them to let windows position their own children. Not one DE developer managed to articulate why exactly that would be a security problem.

Wayland client windows don't know their own position on the desktop, so why should they be able to influence that of others? By my understanding of the Wayland design, if a (child) window needs special handling as a part of the UI, it shouldn't be a generic window but a surface directly controlled by the client. That's simply how the protocol was designed and I know it's different from what we're used to. This is a form of enforced sandboxing and a security feature.

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.

That's the desktop-gaming oriented popular media opinion. I see linux usage in many companies, and there is no way Wayland will replace Xorg anytime soon. Xorg will continue to be the defacto standard for many years because that is where the real money is. Valve will likely continue to support the largest platform for market share as well.

There is an interesting issue I have noticed yesterday:
Tried to play SEGA GENESIS & MEGA DRIVE CLASSICS with a friend, he was on Windows,
and We couldn't play online due to a different platform block...
Looks like playing it on Linux really counts like so, but for multiplayer games, the invite on Stem doesn't work.

Can some check if this issue is happening in other titles?

I hope they fix also the "press SPACE to continue" bug in Bioshock 2 Remastered...
I know there is a workaround with PROTON_NO_ESYNC=1 %command% -nointro
Or using an Xbox controller for to pass that screen.. But the game should work out of the box.

In my opinion, Proton Devs must focus first in the compatibility of the BIG franchises and big AAA games...

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.

That's the desktop-gaming oriented popular media opinion. I see linux usage in many companies, and there is no way Wayland will replace Xorg anytime soon. Xorg will continue to be the defacto standard for many years because that is where the real money is. Valve will likely continue to support the largest platform for market share as well.

I don't think either of these assessments is accurate. Most companies that use Linux simply do not care beyond the obvious: Things should work reliably and securely. Not many businesses depend on Xorg directly. This doesn't mean there's not a lot of work to do and a lot of inertia to overcome.

I can think of Redhat as one of the companies that actually do care, and they're rather enthusiastically pushing for Wayland, with Canonical now in the same boat. I don't remember any big company being against this development yet, but I might have missed something.

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

Well, it is supposed to be (non-)emulating Windows, after all. Working flawlessly would be quite inaccurate. ;)

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.

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

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.

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.

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

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.

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.

Sounds like someone could be contributing to Wine and fix the Wayland issues that other devs appear to have given up on! :D

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