[RFC] Wayland driver development update

[Alexandros Frantzis]

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:

    https://youtu.be/rRss-Fdap7o

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