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