Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Wine and Wayland take another step closer with more code merged

By - | Views: 28,845

The ongoing work bit by bit to get Wine and Wayland to fully work together on Linux has taken another step, with a third big merge request accepted. Wine 8.4 from mid-March was the first development release to actually have some of the initial Wayland work in it.

From the merge request that's now accepted:

This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change).

In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works.

We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design:

  1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread.
  2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread).
  3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread.

Why is this actually needed? Well currently Wine uses X11, and so for anyone running Wayland it will then be run through XWayland, which is basically X running under Wayland like a compatibility layer. As Collabora said in their original announcement back in 2020 talking about it they said it's "a source of complexity and possible inefficiencies" and so it would "be ideal if Wine could talk directly to Wayland to enable a leaner and more efficient stack on modern systems"

So the end result should be for users on Wayland, which will eventually be everyone, to have Wine work without the XWayland layer and have it all work nicely far into the future.

Article taken from GamingOnLinux.com.
18 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
14 comments
Page: «2/2
  Go to:

pleasereadthemanual May 26, 2023
Quoting: DesumI thought Wayland's security made running Wine without xWayland a technical nightmare because of all the unsafe things Windows allows programs to do?
Isn't this true of X, too? I guess sandboxing X.org in Wayland helps some of this, but WINE is meant to be able to run viruses just as well as normal programs.

I doubt sandboxing it will help much if you're running malicious software. Especially since most Wayland compositors don't implement any extra security features aside from the basic stuff the protocol asks for. GNOME seems to be the compositor most ahead in this, because it actually asks you before a program tries to look at your screen (much to the chagrin of some users in its implementation. Though KDE/Wlroots compositors might have implemented this now.

Quoting: ShmerlAnd as I also added above, one of the factors is the GPU. Nvidia blob is the drag on Wayland usage due to it causing poor experience on it. But the trend for Nvidia is negative as you can see on the same page, so that will speed things up for Wayland adoption.

Yes, NVIDIA with Wayland compositors is pretty bad. Sway doesn't support NVIDIA at all, so you end up with black flashes every few seconds. On KDE, display scaling is broken and everything looks wrong. Among a bunch of other issues I can't name because I ran away quickly. GNOME is the best compositor, but wake from suspend is hilariously broken, too, and it has difficulty fullscreening some programs. GNOME is at least smoother than X.org for me and I don't get black flashes. When I run GNOME on X.org, the top half of my screen flashes black occasionally. Yes, X.org. Shrug.

I've decided to just run KDE on X.org now because it doesn't flash black at all. If I have problems with this, I guess I can try i3...

I'm buying an AMD card next time...
fenglengshun May 26, 2023
Quoting: Jarmeryes exactly. The big question is "when" - I think I've been hearing some version of this exact same statement for years now. It's always "coming soon" so we shall see. For now I'm still on x11 just because it irks me to switch to wayland and then for all my games it's just running x on top of wayland. Why not just run x natively. I'll be very glad when it runs natively on wayland! But the when ...
Based on the pace of the merge requests, what's in the Collabora winewayland.drv directory, and what's in the winehq winewayland.drv directory, I would realistically say that Wine Wayland will land sometimes during the 9.x development cycle -- if we're being optimistic, it might land in the staging branch of 8.x development cycle, but I doubt it.

I really do not see it being well-tested enough to land in 9.0 stable release, I think it's more likely to land in 10.0 stable release, the stable release for 2025. And I don't foresee Valve creating a non "opt-in for separate beta branch" release of Proton Experimental with Wayland driver before 2025 as well -- even late 2024 would be optimistic in my opinion.

Of course, this is just my opinion, and I didn't even count the LoC or the complexity of the rest of unmerged winewayland driver. But I did test out wine-wayland in nix, and it still have issues, so that's why I feel pretty confident in saying 2025 as the "when", based on the current pace of the merge requests. Much like WoW64, it's best to not pay attention to it too much, until the devs are ready to announce something to users.


Last edited by fenglengshun on 26 May 2023 at 6:02 am UTC
drjoms May 27, 2023
Quoting: Jarmer
Quoting: drjomsSo in a nutshell, direct or indirect consequence of this - we shall have wine/proton working natively with Wayland?

yes exactly. The big question is "when" - I think I've been hearing some version of this exact same statement for years now. It's always "coming soon" so we shall see. For now I'm still on x11 just because it irks me to switch to wayland and then for all my games it's just running x on top of wayland. Why not just run x natively. I'll be very glad when it runs natively on wayland! But the when ...


Well, the whole point if I undersdtood, for proton to run on wayland. Which will mean exactly that.
From personal experience, I did not notice any FPS drop between wayland and X. I used both for long time, swithced over to wayland(from xfce4 to gnome) about half year or less ago.
drjoms May 27, 2023
Quoting: DesumI thought Wayland's security made running Wine without xWayland a technical nightmare because of all the unsafe things Windows allows programs to do?
Actually no, funny that you mention security, way I understand it, every Xorg app runs in its own window. Meaning app or two can run together and never be aware of each other. Meaning that even Xorg apps are more secure by default if run under Wayland. One app can not steal input of another another app.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.