Hi all,
I would like to provide an update and get some feedback on the current state of the experimental Wayland driver, which was first announced two months ago [1].
The goal of this driver is to allow Windows applications to run directly on Wayland compositors, eventually removing the need for XWayland for many use cases. XWayland, like X11 in general, is receiving less and less developer attention and is unlikely to support modern features like improved fence synchronization or HDR. In addition, since it's yet another layer to go through, it's a source of complexity and potentially of inefficiency. Some more details and thoughts about XWayland vs direct Wayland in the context of Wine can be found here [2].
The focus of this update is to support a number of new features that are useful for applications and games, and which have also been considered potential integration pain points for the Wayland driver. These are copy/paste, drag-and-drop and support for changing the display mode.
More detailed instructions for building were included in the first announcement email, but here is a quick version:
$ git clone -b wayland https://gitlab.collabora.com/alf/wine/ $ ./configure --with-wayland $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
I have uploaded a video showcasing the new features here:
Copy/paste support works well in both directions (native Wayland apps <=> Wine apps) with many common formats already supported.
Drag and drop also works in the direction of native Wayland apps to Wine apps for many common formats, but not the other way around. My understanding is that drag and drop in both the X11 and Mac drivers also works only in one direction.
Implementing the display mode change is particularly interesting since Wayland doesn't allow applications to directly change the display mode in the display hardware, but a similar effect can be achieved for particular surfaces by scaling in the compositor (typically using the GPU). In case of a Wine mode that doesn't match the current compositor mode, the driver instructs the compositor to scale the window contents so that they appear as if the hardware display mode had been changed while respecting the aspect ratio.
There are still some rough edges in the implementation of display mode changes, like proper interactions with real mode changes from the Wayland side, which are being worked on.
---
In previous discussions there were some concerns about accepting the Wayland driver into staging, unless there was more confidence that it would eventually be accepted upstream. What's the best way to get an answer to this question of (eventual) upstream acceptance? Even in this somewhat experimental state the driver is viable for many use cases. What would be required to drive this effort forward on the path to staging and, later, upstream inclusion?
Thanks, Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2020-December/178575.html [2] https://www.winehq.org/pipermail/wine-devel/2020-December/178633.html