Part 4 of the Wine work for Wayland is now merged

The fourth part of an ongoing series of submission to Wine to get full Wayland support has been merged in. The merge request was opened 4 weeks ago, and it was merged into the Wine project on June 29th.

With the focus of this most recent work to give the "minimum necessary infrastructure to display the contents of some simple, software rendered windows" as detailed by the developer it involved two major steps:

• Associate a window with a Wayland surface and give it the xdg_toplevel role, so that the compositor can display it. We also have to implement the required initial xdg_surface configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
• Implement the window_surface interface for the Wayland driver. For now we provide a simple (and suboptimal) window_surface_flush implementation: for each flush we create a new wl_shm buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the window_surface to minimize copying of data from the window_surface to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.

Thanks to this work many software rendered applications can now actually display dynamic content on screen with Wayland but you can't interacct with them just yet. Small steps but it's a pretty big project to get moving from X11 to Wayland.

For those of you not clear on why it's needed: Wine currently needs X11 and so if you're on Wayland you'll be running things through XWayland (basically X running under Wayland like a compatibility layer). This adds more complexity to it and more ways performance could be reduced. Obviously the ideal situation is to just have Wine and Wayland talk directly with no extra middle layer.

The end result will mean Wine will work on Wayland without needing XWayland. This work should be in the next release with Wine 8.12 due out next weekend with their usual bi-weekly development releases.