WineConf 2022 Talked Up Vulkan, PE Conversion Progress, Wine 8.0 Early Next Year

[user1]

And what about Pipewire driver?

I heard someone already developed a Wine Pipewire driver, but I don't know whether it's already upstreamed or not.

[birdie]

And what about Pipewire driver?

Pipewire has the exact same user API as PulseAudio and Wine already supports the latter. No idea what you're waiting for as it's already there.

Is it true that the whole PE conversion badly affects Wine's performance? Or maybe I'm confusing with this claim about the new WOW64 method to run 32 bit apps (which also idk if it's true).

Never heard anything like that.

[user1]

Pipewire has the exact same user API as PulseAudio and Wine already supports the latter. No idea what you're waiting for as it's already there.

The idea of that driver is to use Pipewire directly, instead of relying on the pipewire-pulse compatibility layer.

For those interested, I found the Gitlab thread about that new driver.

[RejectModernity]

Pipewire has the exact same user API as PulseAudio and Wine already supports the latter. No idea what you're waiting for as it's already there.

As user1 mentioned yes, I want to use pipewire directry without pipewire-pulse layers. SDL2, Mumble already work directry with pipewire.

[uid313]

Maybe Wine could get some beautiful themes that would be nice. It would be great with an Adwaita theme for Wine. Now many Windows Forms applications look worse on Windows 11 than they did on Windows 10.

[Myownfriend]

The idea of that driver is to use Pipewire directly, instead of relying on the pipewire-pulse compatibility layer.

For those interested, I found the Gitlab thread about that new driver.

Thank you for linking that. I've also been interested in things adopting native support for Pipewire. I've used SDLs Pipewire backend and I'm glad to see that Wine is going to support it, too.

[hamishmb]

As user1 mentioned yes, I want to use pipewire directry without pipewire-pulse layers. SDL2, Mumble already work directry with pipewire.

Does the pulseaudio layer have problems that direct use doesn't, out of interest? Some day soon I'll try PipeWire on LMDE.

[shmerl]

What's the story with Wine Wayland driver? How close it to being merged?

[shmerl]

Pipewire has the exact same user API as PulseAudio and Wine already supports the latter. No idea what you're waiting for as it's already there.

No, Pipewire has a pulseaudio frontend, but it has its own API as well. So working with it directly is an option.

[rhadlee]

Yeah of course, PE is basically the .dll format used by Windows. On Windows, all such modules are .dll obviously, so this conversion actually keeps compatibility with Windows for the most part. Important for DRM checks, anti cheats and other low level stuff.

What I described is just a side effect. I'm not saying they have to go back to using fake dll with unix modules. But rather that they really ought to take optimizations more seriously, for libc stuff, so their implementation is on par with glibc.

For the longest time, Wine‘s Home problem was (is) that it’s not stable and/or compatible enough to run Windows software well. I find it understandable that Wine maintainers are turning to a conservative attitude when it comes to code changes that offer a mere marginal performance improvement but risk breaking stuff.

And it’s open source after all. It’d be a perfectly reasonable approach to fork a Wine variant that opts for optimizing performance more aggressively.