Experimental Wayland Driver For Wine Now Supports Vulkan, Other Features

[Vistaus]

What about all those proprietary games on Steam? Rekon they will decide to port to Wayland?

Steam itself can native Wayland while the older games (i.e. the ones already published) use XWayland.

[mbrf]

does natives games work on wayland? (both opengl or vulkan)

When they use SDL2, they do(/can)
As far as I can tell, Unity3D works with Wayland via SDL2.
I can't really work out the current state of things for Unreal engine 4 and 5.
There are likely *some* native games that won't be native Wayland.

[oiaohm]

It is simply the fact that any platform that Steam runs on must have support for legacy game titles.

That is true but there are cases where games no longer work on Windows 10 due to changes in windows kernel and api but still work on wine on Linux. There are also a few games where native ports to Linux still work yet the Mac and Windows versions don't work on current versions as well.

Valve with steam has to attempt to support legacy on all platforms but there are gaps.

Its really simple to miss how hard attempting to support all legacy titles are. It also really simple to miss that Windows 10 and Mac OS does not have every title in steam that was historically released for Windows and Mac OS due to how changes over time broke it. Some cases items have been covered horrible ways. Like doom the original from the steam store where you would get the dos version because the windows version no longer worked for quite a few years until the recent new release of windows version. But there are other examples where windows and mac os version break on real windows yet the windows version still works on wine and the game never had a Linux native release.

Game working equals valve being able to sell it. Legacy support is not in fact platform uniform with steam no matter what people think. It comes down to the game. Valve support for Linux is part to increase the amount of their inventory of third party games they can still sell.

[oiaohm]

But the Steam client is a launcher - it doesn't provide an environment for the games to run in. Proton does that for Windows native games, and SDL2 kind of does that for other games, and Unity, I supposed deals with its own things, so whether the Steam client is 16, 32, or 64 bits shouldn't have any influence on its ability to launch a game, regardless of how few/many bits it is, rather the support in the environment in which the game is launched, does.

Valve has in steam Linux native games that don't use SDL2 or Unity that are closed source with no debugging information. There is a catch they are all 32 bit as they are legacy items. SDL2 and Unity3d its is possible to use open source versions when there are issues to diagnose the problem this is not the case with all the Linux legacy games. To have those Linux legacy games work you have items like libcapsule adding extra level of complexity. Yes environment which the game in launched does but particular host libraries have to be functional or the game is stuffed as well. Steam client 32 bit working tells you that particular host provided libraries are fine and if the legacy game is screwing up with one of those it could be a libcapsule problem. There are diagnostic reasons why valve is dragging feet here.

As for Wayland, Windows native games were never made with X in mind, so what determines if things are shown in Wayland, X, or XWayland, is Wine/Proton, so if Wine/Proton has a Wayland compatible driver, then it can show Windows native games in a pure Wayland surface. The same, I assume, goes for SDL2. And I don't know what exactly goes for Unity, if it doesn't use SDL2 - I suppose it has to deal with that internally.

Unity3d
https://wiki.archlinux.org/title/Uni...s_0_x_0_@_0_Hz is SDL2 here is the but some games due to way they are built still have old version of SDL that cannot be forced to use new version that have a bug when using Wayland mode. Yes the 0 x 0 @ 0Hz desktop problem.

Please note when I am talking old version of SDL that you cannot force a new version its legacy binarys SDL 2 newer 8 Jan 2014 even if static linked can be force to use a newer version of SDL for newer support. So older Unity3d titles. Also do note valve still sells some native games using SDL1 static linked to Linux users yes they are wrapped up with correctly configured runtime.

[AHOY]

Wow not a single reply in the mailing list to such a great feature and progress. Maybe it's better this way since Wine developers previous replies were pretty bad and anticlimatic.

Between this and things that happens with projects like Chromium, rofi, GTK, you can understand why "it's been 100 years and Wayland doesn't have all the features". Bury x11 with their NEWBAD apologists. Approve the patches and help standardize protocols. You've been deprecated.

Maybe I misread the entire situation, but it's even better if I'm wrong.

[oiaohm]

Wow not a single reply in the mailing list to such a great feature and progress. Maybe it's better this way since Wine developers previous replies were pretty bad and anticlimatic.

Open source projects are not known for positive reinforcement. No answer normally means no review or everyone who reviewed it could not find a problem.

Between this and things that happens with projects like Chromium, rofi, GTK, you can understand why "it's been 100 years and Wayland doesn't have all the features". Bury x11 with their NEWBAD apologists. Approve the patches and help standardize protocols. You've been deprecated.

Maybe I misread the entire situation, but it's even better if I'm wrong.

The reality is Wayland is designed not to have all the features of X11 because some of the features of X11 are security nightmares so different way of solving the problem has had to be developed.

[pracedru]

That is true but there are cases where games no longer work on Windows 10 due to changes in windows kernel and api but still work on wine on Linux. There are also a few games where native ports to Linux still work yet the Mac and Windows versions don't work on current versions as well.

Valve with steam has to attempt to support legacy on all platforms but there are gaps.

Its really simple to miss how hard attempting to support all legacy titles are. It also really simple to miss that Windows 10 and Mac OS does not have every title in steam that was historically released for Windows and Mac OS due to how changes over time broke it. Some cases items have been covered horrible ways. Like doom the original from the steam store where you would get the dos version because the windows version no longer worked for quite a few years until the recent new release of windows version. But there are other examples where windows and mac os version break on real windows yet the windows version still works on wine and the game never had a Linux native release.

Game working equals valve being able to sell it. Legacy support is not in fact platform uniform with steam no matter what people think. It comes down to the game. Valve support for Linux is part to increase the amount of their inventory of third party games they can still sell.

There are games that work in wine but not in real windows... ok.. How is that an argument against my position?

[oiaohm]

There are games that work in wine but not in real windows... ok.. How is that an argument against my position?

You do need to look at wine. Work on hangover is because 32 bit provide by platform is going away. Like snap packaging has it deprecated.

64 bit steam client for Linux most likely be need before html render and other things disappears. Remember the steam client is able to download and install their runtimes as need for the games. So 32 bit and so on.

Also you need to look closely at wine hangover the goal there is 32 bit and 16 games in time will be using the 64 bit opengl/vulkan libraries by thunking.

Ask how wine comes into it I was not clear. Take the wine win16 applications it can run. There is no 16 bit host libraries provided by Linux distributions right.

The reality here even if the full steam client is not ported to 64 bit for application compatibility with new distributions thunking from 32 to 64 bit will be required. The need for this can appear before items like web renders go end of life.

[pracedru]

You do need to look at wine. Work on hangover is because 32 bit provide by platform is going away. Like snap packaging has it deprecated.

64 bit steam client for Linux most likely be need before html render and other things disappears. Remember the steam client is able to download and install their runtimes as need for the games. So 32 bit and so on.

Also you need to look closely at wine hangover the goal there is 32 bit and 16 games in time will be using the 64 bit opengl/vulkan libraries by thunking.

Ask how wine comes into it I was not clear. Take the wine win16 applications it can run. There is no 16 bit host libraries provided by Linux distributions right.

The reality here even if the full steam client is not ported to 64 bit for application compatibility with new distributions thunking from 32 to 64 bit will be required. The need for this can appear before items like web renders go end of life.

As I said, the Steam client will likely be ported to 64 bit when the dependencies are no longer available in 32bit. And since it is mostly a webapp in a webkit shell I wouldn't think it would be a larger task anyway.
32 bit steam client is perfectly able to run everything it needs to run. Simultaniously more than half of the steam game library is depending on 32 bit support and some are even run with 16bit support through dosbox. I imagine that steam could even support some 8 bit games through dosbox or other emulation layers. I don't see how 32bit is such a problem...

[ssokolow]

I imagine that steam could even support some 8 bit games through dosbox or other emulation layers. I don't see how 32bit is such a problem...

It'd have to be "or other emulation layers". The x86 family has always exposed a 16-bit ISA to programmers even on the models that ran an 8-bit external bus.

...and the problem for pre-x86 stuff tends to be licensing the system ROMs from companies that either don't want the competition to their in-house approach or want too much per license to make bundling them with individual game purchases economically viable.

DOSBox and ScummVM work because they're trustworthy clones of everything they'd otherwise have to license.

...though Apple II games beyond those ScummVM now supports might be possible, given that Sierra trusted AppleWin's legal status enough to bundle it and their early games on various compilations through the years.