Wayland driver development - December 2021 update and next steps

[Alexandros Frantzis]

Hi everyone!

Since the last Wayland driver update [1] a lot of work has been done to
improve the functionality and stability of the Wine Wayland driver, and
to provide a cleaner and more reviewable/upstreamable patchset. The
driver has now reached a point where it would benefit from wider
community testing.

In the mailing list discussions earlier this year it was recommended
that we go through wine-staging as a stepping stone towards upstream. To
this end, I have prepared a patchset and attached it to the existing bug
for a Wayland driver, as per the wine-staging guidelines, at:

https://bugs.winehq.org/show_bug.cgi?id=42284

This is intended to be an active patchset, meaning that it will receive
updates regularly, as feedback is received and issues are fixed.
Development will continue in the development branch (currently at [2])
which will be used as the canonical source for any updated patchsets for
wine-staging.

The vast majority (but not all) of the commits in the series affect only
the driver itself. However, there is still a lot of surface area, mostly
in terms of interfaces used to interact with Wine core, that could lead
to broken code when upstream is updated. This has been more pronounced
the last few weeks with the various changes in the driver interface.

I will be tracking upstream and providing updated patchsets as needed
and as timely as I can. I want to make sure that this patchset will not
cause undue burden on the wine-staging maintainers. However, if the
maintainers feel that this patchset will make life difficult for them, I
am open to different ideas about how to move this driver towards upstream.

A related question now that holiday season is approaching: what happens
if a wine-staging patch breaks due to an upstream change, such that it
requires intervention from the original author, but this is not provided
in time for the next release? Is the patchset disabled for that
wine-staging release and re-enabled when fixed? Let me stress again that
my aim is to track upstream and respond in a timely manner, but
sometimes this is not possible, and I want to be clear about how the
situation is handled.

---

Now, some information about the state of the driver.

First of all a non-exhaustive list of what's supported, minus bugs:

* Window state handling: resizing, maximization, minimization (often
  no proper minimized window contents, though), fullscreen.
* OpenGL and Vulkan (including using wined3d and DXVK).
* Display mode changes (emulated with compositor scaling, rather than
  real display hardware mode changes).
* Multiple monitors.
* Mouse capture/clipping/relative motion (but note that Wayland
  compositors don't tend to deal with non-fullscreen cases very well).
* Popups, menus and other transient windows (except when cross-process,
  see below).
* Keymaps set/updated from the Wayland compositor should work
  transparently.
* HiDPI scaling (configurable to use either application/wine or
  compositor scaling).
* Copy/paste both ways, drag and drop in the direction from native
  Wayland to Wine.
* Systray (minus right-click menu positioning, see below).

TL;DR of how to use the development branch:

$ git clone -b wayland https://gitlab.collabora.com/alf/wine/
$ cd wine
$ ./configure --with-wayland [--with-vulkan --with-vkd3d]
$ make [-jN]
$ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...

There are some known cases where the driver doesn't work properly, that
I think deserve an explicit mention since they may trip people up.

The first is when applications try to render to window created by
another process. Although this not a typical scenario, it's how
Chrome/Chromium and thus applications using CEF, including some game
store apps, work. For now, the workaround is to instruct the application
to use "in-process" GPU handling (with the "--in-process-gpu"
command-line) or turn-off GPU rendering completely (typically with
"--disable-gpu --disable-software-rasterizer"). For example, one can run
GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"

Some applications launch a separate CEF process internally, so passing
the flag in the command line doesn't work, it needs to be passed to the
CEF process instead. I have had some good results with detecting and
overriding the arguments in CreateProcessInternalW (e.g., Rockstar
Launcher), but of course that's a complete hack.

I am trying to find a way to resolve this issue, but the solution is
still an open question, and could require a Wayland extension, although
there other (more complex) possibilities I need to explore further.

The second case involves the standalone systray included in the driver,
based on the one from winex11. Due to the context/right-click menu being
drawn from a process different from the one owning the systray window,
the driver heuristics to anchor the window to its effective Wayland
surface parent don't work. The practical effect is that the menu is
rendered as a Wayland toplevel and thus placed by the Wayland compositor
at arbitrary locations on screen (although it's still usable).

Finally, please note that although there are certainly still bugs in the
Wayland driver, Wayland compositors also have their share fair of issues
(my main testing happens on Weston, GNOME and occasionally kwin). So,
please try to use a recent version of your favorite compositor, so that
you can enjoy the best possible experience.

Thanks,
Alexandros

[1] https://www.winehq.org/pipermail/wine-devel/2021-June/188412.html
[2] https://gitlab.collabora.com/alf/wine/-/commits/wayland