The Era Of True Wayland WINE Gaming Is Coming
The era of Wayland gaming is almost upon us. Now you might say, I already can game on Wayland, I do game on Wayland, I am gaming on Wayland, at this very moment, Proton worked just fine. Not exactly true. If it's some native Linux title built with a game engine that supports Wayland or the developer goes out of their way to add Wayland support into a game, yes, that is going to run under Wayland. If we are talking one of those Windows Steam games that relies on Proton, that is running under Xwayland because Wine historically did not have a Wayland driver, which makes the GameScope stack really weird.
So you have the game running on top of Xwayland, on top of GameScope, on top of your regular desktop. And all of this due to some magic happening in the background, not only gives you a playable experience, but a good gaming experience. To make Wayland gaming possible, there is a lot of moving parts and a lot of people have been involved. And now we are on the cusp of that changing. Recently, fallback to Wayland when X11 fails was merged and also included in the 9.22 release of Wayland, Wayland driver enabled in default configuration.
Now, I want to be clear what this means because it does not mean that if you're gaming under Wayland with Wine 9.22, all of a sudden your Wayland gaming is going to be Wayland gaming. What it means is in the default configuration of Wine, the Wayland driver is going to be enabled and isn't something you need to go and compile into Wine. This is done for a good reason because the Wayland driver, frankly, isn't done yet. It's most of the way there, mostly good enough, but there are still some features that are missing, there are still some bugs that need to be discovered, and it hasn't had widespread testing yet.
And that's what this does. It makes it available by default in Wine, so if users want to go out of the way to go and test it and see what it's like and help out the Wine project, now it is a lot easier to do. So, if you're paying attention to the Wine bug tracker to the Wine meta list, you should expect a lot more bugs being discovered, not because this version is suddenly more buggy, but because there are more eyes on the Wayland driver. Now, as you could probably expect, this isn't work that's just spawned out of nowhere. You don't just say, oh, I want Wayland support. Wine hasn't had Wayland support before. Oh, now it's suddenly there. This has been quite a long-running project, not because it's been, like, arguing about how to get it done or anything like that.
It's just had a lot of pieces to make it function. So, this has been going on for about four years now, and most others are certainly involved. There are patches from random other people and all of those other things. The project has been mainly headed by Alexandros Frantzis of Collabora, first being announced on December 15th, 2020, a Wayland driver for Wine. And one of the reasons this is being made, besides just having a Wayland driver and Wine being cool, is giving users less of a reason to rely on Xwayland, because even so back in 2020, but especially now, I would argue that gaming is probably one of the biggest use cases for Xwayland.
Yes, there are random other legacy applications, and Xwayland isn't going away anytime soon. I'm sure there's going to be some distro that goes ahead and disables it out of the box, but most others are not going to do that. Besides gaming, most other applications are already Wayland native. The only other big application I can think of that is not is Discord, and that's not because Electron doesn't natively support Wayland. It's because they're relying on an old version of Electron, and Discord is just not exactly great at application maintenance. But the idea is not without its challenges. The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and Win32, which brings a unique set of challenges in the integration of Wayland with Wine. Since Wayland's window model is not based on a single flat 2D coordinate space as X11's was, the Wayland protocol doesn't allow apps to control their absolute position on the screen.
Win32 apps heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases like transient windows, menus, tooltips, etc. This is an issue that I've discussed in a prior video. There is a protocol being worked on. Uh, bike-shedded might be a better term for it. There is a protocol that exists that is in discussion that might eventually possibly make its way into some form. Whether it's going to be a useful protocol, we'll have to wait and see.
This was also announced over on the Wine mailing list. Now, you can't click this link right here because since this went up and the video being recorded, they moved the mailing list and they did not redirect any of the links. Luckily, they did archive everything so you can go and find it if you know what you were doing. A lot of this is also included over in the blog post, but something new I want to talk about is what was supported at the time. GDI apps, including layered slash translucent windows, openGL apps, window resizing, maximized and full-screen window states, mouse and keyboard, only QWERTY input, so that right there already indicates that a lot of stuff was very much missing, mouse curses, menus, tooltips, etc., single display.
What needs more work or is completely missing? Minimize, better z-order and activation handling, keyboard layout support, window grabs, GTK menu mouse handling bug, cannot click to select items, multiple displays and the really big one when it came to gaming, Vulkan, because if you don't know, the way we play DirectX games on Linux is through DXVK DirectX to Vulkan, so if you don't have Vulkan support, you don't have most of the games that people want to play, but even so, that doesn't mean the driver in this state was completely unusable. It was certainly functional enough to do a bit of a demo. Let's jump ahead to here. This is notepad running.
If we go ahead a bit further, this is the windows version of Battle for Wessonoth, and further ahead, here is the windows version of Super Tux Kart. Now obviously, you don't need to run the windows versions of these games, but not supporting Vulkan yet, you needed something that did OpenGL, and most windows games are not OpenGL anymore, so you kind of got to rely on the Linux games, but in most cases are going to support it, at least to some extent. Likewise, here is the windows version of Mozilla Firefox. It was, okay, it's rendering a bit weirdly, it's an old version, it's of course the windows version, but it worked, with the exception of a couple of things not rendering properly, but mostly works. One of the things I really like about Collabora is when they get involved in the project, usually you don't just have the single announcement post and then hear nothing about it until there's an update on Pheronix when it's actually released. Every so often, there will also update posts. June 7th, 2021, Wine on Wayland meets Vulkan, multi-moder support, and more.
Another one on December 22nd, 2021, Wine on Wayland year end update, improve functionality and stability. Then December 12th, 2022, Wine on Wayland 2022 update, more games, more apps, more fun. There wasn't one for whatever reason in 2023, but then there was another one in 2024, Wine on Wayland, a year in review, and a look ahead. Now whilst the project was clearly going strong and was clearly going to be something that we actually care about at some point in the future, it didn't get upstreamed for quite a while. That didn't happen until 2023, which I think is honestly a good idea, because you want to make sure it's actually in a good state before you go into upstream, because usually once something's in upstream in any project out there, getting it changed from that point is going to be a bit more annoying because there's processes and testing and all of this stuff that gets in the way of rapid development.
So wait until things are in a relatively good state and then start upstreaming. But whilst I say upstreamed, this was by no means the only part of upstreaming. WineWayland.drv, part one, introduce the Wayland driver. The part one is very important. This is the first of many parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive, to the degree possible, set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve the process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so some MRs, especially the initial ones, will be a bit more preparatory in nature.
To aid in the understanding of and justification for some code introduced in such MRs, all the remaining driver commits are always going to be available at his branch. Now, when he says many and a lot, this is not an exaggeration. Part two, display configuration enhancements. Part three, handle dynamic wl output events. Part six, handle wl pointer mouse events. Part seven, basic window management. Part 13-1, basic OpenGL support. Part 13-2, more OpenGL functionality. We're getting into Final Fantasy release numbers, with part 10 of the Vulcan updates being three separate parts. So, in total, with just the numbered parts, I think it works out to be something like 16 or 17 patch sets, just for the core functionality.
And that's only talking about the specifically numbered patch sets. There are other things which are like one-off, little commits, some by Alexandros, some by other people, and those were the open ones. This is what has been merged, currently specifically mentioning wineWayland.drv, so there might be other patch sets that don't mention it in the title. 27 merged merger requests. The only patch set that was numbered that didn't get merged was part 12, display mode change emulation. That's because this was introduced in a separate patch set, so the functionality is there, just not through that means. Now, this merger request we saw at the start of the video was made quite a while ago, but its merger is something that happened because of a random off-hand comment on a completely unrelated thread.
I guess it is related to wineWayland, but this is it. WineWayland use subsurfaces for unmanaged windows. By the way, after this, I feel like the driver is much more usable. Would it be acceptable to enable it by default? Is there any other major feature missing, given that virtual display settings is being worked on? One of them is clipboard support. Now, this isn't super big when we're talking about gaming, there are a couple of cases where it matters, but this really matters when we're talking about windows applications, like if you're trying to run a notepad or maybe more importantly, something like Photoshop. Without clipboard support, Photoshop becomes a lot more annoying to use when you're importing images. But also, WinTab support is something that is still missing. This is related to drawing tablets to have pressure sensitivity and things like that.
Now, again, is this a major thing that a lot of people are going to use? No, but it is something that definitely should be there. I can't really think of much else. The wineWayland driver certainly isn't perfect, but it is astonishingly good, given the impedance mismatch of Wayland and Win32. This is related to functionality that is present on every other system, but is not present under Wayland because security, I guess.
For some reason, seeing this comment thread today inspired me to actually try to implement WinTab support in the wineWayland driver. I managed to get a functional work in progress going. It's a pretty big mess, though. I think the first order of business would be to get some patches going to clean up the WinX11 WinTab code and ideally move most of the actual WinTab32 specific logic out of WinX11. But that's pretty off topic here. If anyone wants to talk about that, feel free to reach out directly.
I'd love to see WineWayland get to a shape where it could potentially be preferred over WinX11 on XWayland, which hopefully, given some additional testing, is what is going to happen. Now, is that going to be tomorrow? Probably not. Next week? Probably not as well. However, Wine 9.23, or what was going to be Wine 9.23, which is now Wine 10RC1, is set for December 6th, with the full release expected sometime in January 2025. My expectation is, with this being available by default, sometime during Wine10, we will see this going from enabled by default to enabled as the default.
I don't know when it's going to happen, but it's looking like it's going to be relatively soon, and then WineWayland Gaming, WineWayland, just Wayland in general, is going to be here and no more relying on XWayland. For now, though, XWayland it is. So, let me know your thoughts down below. Do you care about Wine on Wayland? Is XWayland fine? Did you even realise this was happening? I'd love to know.
So, if you like the video, go like the video. And if you really like the video and you want to become one over, these amazing people over here, check out our Patreon, Subscribe, Liberapay linked in the description down below. That's going to be it for me, and enjoy those video games..
