Wine's Project Leader Has Given A Blessing To The Wayland Effort

[phoronix]

Phoronix: Wine's Project Leader Has Given A Blessing To The Wayland Effort

Published last month was an updated but still experimental version of the native Wayland support for Wine after that code was originally published last year. One of the lingering questions has been around the prospects of mainlining this Wayland driver in Wine while last week the longtime Wine project leader, Alexandre Julliard, provided some clarity on the matter...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-Julliard-Wayland-2021

[yoshi314]

sounds more like 'i don't mind, but get ready to deal with plenty of issues' to me.

[Sethox]

sounds more like 'i don't mind, but get ready to deal with plenty of issues' to me.

That opinion is always the case when building a side-project, that is why the quote "if there is a will, there is a way" exists too.

[birdie]

Even Alexandre admits that Wayland must have had a compositor part of the specification/API but perhaps Phoronix experts among Wayland fans know better.

[emblemparade]

He's exaggerating. Sure, the implementation will have to essentially create a window manager for Windows based on raw Wayland. But ... there's a lot more cruft to XWayland than just that. This will take a while to become stable, but it would be great to remove the XWayland dependency.

[Alexmitter]

He's exaggerating. Sure, the implementation will have to essentially create a window manager for Windows based on raw Wayland. But ... there's a lot more cruft to XWayland than just that. This will take a while to become stable, but it would be great to remove the XWayland dependency.

Wine Window management on X11 was a broken mess anyways. It mapped okayish well to the old style Windows Display Server, but that is not the case for Windows since Vista.
The only thing that will not be possible under a wayland driver would be to allow the application to choose where it is positioned on the display, but that is a issue anyways.

As Wine gaming becomes more important, a proper modern low latency output with good frame control is important. Xorg and Xwayland are just way too bad for that.

[mdedetrich]

Wine Window management on X11 was a broken mess anyways. It mapped okayish well to the old style Windows Display Server, but that is not the case for Windows since Vista.
The only thing that will not be possible under a wayland driver would be to allow the application to choose where it is positioned on the display, but that is a issue anyways.

As Wine gaming becomes more important, a proper modern low latency output with good frame control is important. Xorg and Xwayland are just way too bad for that.

Both Wayland and X11 have their fair share of problems, the difference is that X11 has performance issues (which for the most part aren't a big problem) where as Wayland has issues with it actually being able to do what Wine needs (without ugly hacks which as just mentioned isn't an option).

Looks like it will take a long while for Wine to actually build ontop o fWayland

[treba]

I totally agree that Wine on native Wayland will have some limitations, especially around window positioning systray support. However, my personal usage of Wine pretty much comes down to launching games and simple launcher for them - which in most cases should work pretty well.

So I'm looking forward to this and can think of a few possible optimizations that it makes possible. E.g. using wp_viewporter for emulating screen resolution changes is AFAIK pretty similar to what proton does already, but being a native API the compositor could possible save a copy in process.

[oiaohm]

Even Alexandre admits that Wayland must have had a compositor part of the specification/API but perhaps Phoronix experts among Wayland fans know better.

The current developer of wine wayland backend is not limit self to only wayland protocols. It already has a prototype screen capture using xdg-portal.

The only thing that will not be possible under a wayland driver would be to allow the application to choose where it is positioned on the display, but that is a issue anyways.

This one get tricky when you look at how windows handles low dpi applicaitons on high dpi screens it scales them and the positions the low dpi application on windows thinks it has is not real either. The position on screen under windows a application has may be virtual number not a real position starting with windows Vista. That makes wine life a lot simpler. Like if screen mode does not match what application wants wayland wine does not change screen mode just scales application instead.

The is one of those wacky things. Under wayland wine can ask for a full screen surface of what every dimensions and have it scaled. So wine virtual desktop mode instead of being a small unreadable window on hidpi screen its a full screen image due to scaling.

Really good question here does a program really need to know exactly where it on screen. Or is relative to a large surface pretending to be the screen good enough as in the wayland solution.

Scaling on the wayland driver for wine fixes all the problems of applications crash without changing screen mode back because you never changed the screen mode in the first place.

[oiaohm]

Both Wayland and X11 have their fair share of problems, the difference is that X11 has performance issues (which for the most part aren't a big problem) where as Wayland has issues with it actually being able to do what Wine needs (without ugly hacks which as just mentioned isn't an option).

Horrible as it sounds the idea that its ugly hacks ignores what Windows Vista and later does to upscale low dpi applications on to hidpi screens. Lot of what you need to do to get around the position on screen problems is exactly the same as what was done in Windows Vista for application scaling.

X11 does have the issue due to really changing monitor res that if applications crash that the screen does not change back. Wayland wine backend avoid this simply by not changing screen res at all and instead using wayland protocol included scaling to scale the output buffer instead to the screen.

The fun point here is the differences in features between Wayland and X11 provide different ways of solving the same problems. But it requires you to step back. Remember X11 protocol does not have integrated scaling of output where wayland protocol does. There are plus to using Wayland as well as a few head aches.